Hi everyone, This is an excellent and very important discussion. Thanks to Shigemichi and Enda for their special efforts. I wonder if it would make sense to distinguish between two types of localization directives: 1. internal/invasive: Reside within of the XML instances themselves. Examples: see Enda's mail 2. external/non-invasive: Reside outside of the XML instances. Examples: see Shigemichi's mail From my point of view, we already have quite comprehensive material (namely the ideas which Shigemichi, Yves, and Richard Ishida put together) for tackling the internal localization directives. As indicated during the last conference call, I would imagine that the following might already be a good start for these internal localization directives: A. add a section about localization directives to the XLIFF specification; the section may read sth. like below (I would suggest that we ask Shigemichi, Yves and Richard if we could possibly also/instead copy from their work): The XLIFF localization directives is a set of XLIFF data categories which 1.1 capture information which is helpful for proper, cost-efficient localization (since they enable for example to say which parts should be localized, and which should not be localized) 1.2 can be used without any relationship to XLIFF files (for example in other XML-based formats or in native formats such as Windows resource files) The XLIFF TC encourages anyone who is responsible for creating or maintaining a format, to use the XLIFF localization directives, since they have proven beneficial, and are expected to be supported by many localization tools and service providers in the future. The XLIFF TC distinguishes two types of localization directives: internal and external. 1. internal/invasive: Reside within of the XML instances themselves. 2. external/non-invasive: Reside outside of the XML instances. B. add a list of those XLIFF data catgories to the specification which we recommend as internal localization directives (examples: translate, reformat); we may want to say that the syntax/names of the XLIFF-recommanded internal localization directives is not finalized yet (see Gérard's suggestion wrt. 'less wordy' names). C. add a comment to the specification which reads sth. Like 'external localization directives are targeted for a future version of this specification' Best, Christian -----Ursprüngliche Nachricht----- Von: Shigemichi Yazawa [ mailto:
yazawa@globalsight.com ] Gesendet: Dienstag, 22. Oktober 2002 00:09 An: Enda McDonnell Cc:
xliff@lists.oasis-open.org Betreff: Re: [xliff] Localization Directives... At Mon, 21 Oct 2002 11:59:00 +0100, Enda McDonnell wrote: > > We are due to discuss these issues at an xliff meeting tomorrow, where we > can use this input. An outline of how you provide for this at GlobalSight > with some samples would be very useful for this discussion, if it is > possible. I don't know how much I can disclose the information, but I can talk about an outline. When you import an XML file into the system, you can specify a XML rule file to use for the import. The rule file describes which elements and attributes are to be translated. If no rule file is specified, a default rule is applied. The default rule is that all element contents are translatable and all attribute values are not. A rule file itself is an XML document. Basically, a rule file consists of <translate> and <dont-translate> elements. Both elements have a path attribute which selects a certain part of the document by XPath expression. Obviously <translate> selects translatable element or attribute and <dont-translate> selects non-translatable parts. And these rules are applied on top of the default rule. So you don't need to write <dont-translate> rule for attribute, which is non-translatable by default. <translate> optionally has a inline attribute. If the value of the attribute is yes, the selected element by the path attribute is treated as inline element. An inline element is an element that is included in the other element. The parser doesn't break the segment at the element so the translation can be done on a whole segmented unit (sentence, paragraph, etc). Examples of inline element are <b> or <i> elements of XHTML. There are some other elements and attributes in the rule file, but these are not essential for the discussion. Example: Source XML: <foo> <bar> <baz>This is <bold>translatable</bold> text.</baz> </bar> <baz>This is not translatable.</baz> </foo> Rule file: <rule> <dont-translate path="/foo/baz" /> <translate path="//bold" inline="yes" /> </rule> If the rule file is applied to the source xml, "This is <bold>translatable</bold> text." is parsed as translatable as a whole. "This is not translatable." is parsed as non-translatable. A rule file for a sample xml file in your Attribute.html can be written as below. <rule> <!-- select all elements as non-translatable --> <dont-translate path="//*" /> <translate path="/window/menubar/menu/menupopup/menuitem/@value" /> <translate path="/window/menubar/menu/menupopup/menuitem[@value!='Redo']/@accesskey" /> </rule> ------------------- Shigemichi Yazawa
yazawa@globalsight.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <
http://lists.oasis-open.org/ob/adm.pl >