OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: AW: [xliff] Localization Directives...


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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC