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

On Jan 18, 2013, at 1:06 , Felix Sasaki wrote:

> 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>

The locale filter rule only says that the legal notice needs to be present for en-CA and fr-CA, and omitted from all other languages. It doesn't say that the content of the legal notice may have to change, which is what I mean by "localizable", as indicated in the examples below.

>> 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.

Except that the combination above doesn't fully express "localizable".

>> 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>

This does not indicate that the content of filtered elements may have to change between locales. It only says that they have to be present in all locales, and that they're not translated.

>> - 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).

The complexity of XPath expressions is an additional problem, but not the one I'm raising here.

Norbert

Received on Friday, 18 January 2013 09:29:45 UTC