Re: I18N-ISSUE-217: Missing support for localizable items that are not translatable [ITS-20]

Am 18.01.13 01:35, schrieb Internationalization Working Group Issue Tracker:
> I18N-ISSUE-217: Missing support for localizable items that are not translatable [ITS-20]
>
> http://www.w3.org/International/track/issues/217
>
> Raised by: Norbert Lindenberg
> On product: ITS-20
>
> ITS 2.0 is missing support for marking up items that are localizable but not translatable.

You can achieve that via combining "locale filter" with "translate", e.g.

<book xmlns:its="http://www.w3.org/2005/11/its" its:version="2.0">
   <info>
     <its:rules version="2.0">
       <its:localeFilterRule
         selector="//legalnotice[@role='Canada']"
         localeFilterList="en-CA, fr-CA"/>
         <its:translateRule selector="//legalnotice[@role='Canada']" 
translate="no"/>
     </its:rules>
     <legalnotice role="Canada">
       <para>This legal notice is only for English and French Canadian 
locales.</para>
     </legalnotice>
   </info>
</book>


> Translatable items can easily be identified with the "translate" attribute; there's no equivalent attribute "localize".

There is no need for an equivalent. It is a design principle for ITS1 
and ITS2 that the data categories are distinct items and that an 
application can combine them freely, see above.

>
>
> For a simple use case, look at example 2 in section 1.2.1:
>
> <dialogue xml:lang="en-gb">
>    <rsrc id="123">
>      <component id="456" type="image">
>        <data type="text">images/cancel.gif</data>
>        <data type="coordinates">12,20,50,14</data>
>      </component>
>      <component id="789" type="caption">
>        <data type="text">Cancel</data>
>        <data type="coordinates">12,34,50,14</data>
>      </component>
>      <component id="792" type="string">
>        <data type="text">Number of files: </data>
>      </component>
>    </rsrc>
> </dialogue>
>
> The strings "Cancel" and "Number of files: " are translatable. Non-translatable items that may need localization are:
>
> - The URL "images/cancel.gif", which may need to be replaced with a culturally appropriate icon for cancellation, or possibly even an image containing a translated string.

Just for above requirement, here is the rule needed:

     <its:rules version="2.0" xmlns:its="http://www.w3.org/2005/11/its">
<!-- Below needs localization, but no translation -->
       <its:localeFilterRule
         selector="//data[@type='text' and starts-with(.,'images/')]" 
localeFilterList="*"/>
         <its:translateRule selector="//data[@type='text' and 
starts-with(.,'images/')]" translate="no"/>
     </its:rules>

>
> - The coordinates for that image, if the image expands or shrinks during localization, or expansion or shrinkage in surrounding content requires it to move.
>
> - The coordinates for the string "Cancel", if the string expands or shrinks during translation, or a larger or smaller font is used for a localized user interface, or expansion or shrinkage in surrounding content requires the string to move, or the user interface is changed to a right-to-left layout during localization.
>
>
> Another small use case is the string "NavajoWhite" in Example 1 of the same section 1.2.1: This string may need to be localized to a different CSS color specification describing a culturally appropriate background color for corporate policies in the target culture. This must not be confused with translation, as translating the string, e.g. to "blanco navajo", would lead to a CSS syntax error rather than a properly localized user interface.

I think you can accomodate all these use cases with above rules. The 
general issue I see is the complexity of XPath expressions, and having 
somebody in the organization writing these rules for each small bit. The 
situation would be different with a one time big effort (see below).

>
>
> For a much larger use case, look at the main root resource bundle of the Common Locale Data Repository, and consider how ITS could be used to prepare it for localization:
> http://unicode.org/cldr/trac/browser/trunk/common/main/root.xml

That's a quite interesting use case, and I'd be happy to spend some time 
looking into using ITS2 for CLDR. Before doing that it would be great to 
here your feedback about the feasibility of above rules (localeFilter + 
translate).

Best,

Felix

> Some items here are clearly translatable, such as the names of months or of the eras of the Japanese calendar. But most items are not: They are strings following a formal grammar, such as that for date format patterns. To localize them, one has to find various kinds of cultural information about the target locale, and encode it according to conventions specified in Unicode TR 35:
> http://unicode.org/reports/tr35/
>
> Non-translatable but localizable items have to be identified, but kept separate from translatable items, as they can't be handled in the normal translation process (typically they're assigned to localization engineers rather than translators).
>
>
> [The Internationalization working group has discussed this issue briefly on 2013-01-16; but has not taken a formal position.]
>
>
>

Received on Friday, 18 January 2013 09:06:50 UTC