Re: [widgets] Further argument for making config.xml mandatory

In my previous email, I included a note that said:

"Note: Some elements marked as not being localizable via xml:lang, such
as screenshot and icon elements, are localizable via folder-based
content localization."

I've thought about it some more, and concluded that screenshot and
icon are actually localizable through the interplay of both
folder-based localization and element-based localization. Consider the
following:

<widget xmlns="http://www.w3.org/ns/widgets">
  <screenshot src="screenshots/mainscreen.jpg"
                 alt="El menú principal muestra los botones
                      para iniciar un juego, acceso a la
                      configuración del juego (include
                      la dificultad y la calidad gráficos),
                      y como cargar un juego guardado."/>

  <screenshot src="screenshots/level1.jpg"
              alt="Nivel 1: La cueva de la muerte!
                      Nuestro Héroe en pelea con el Dr. Maligno
                      y su ejército de conejitos temperamental.
                      xml:lang="es"/>

  <screenshot src="screenshots/mainscreen.jpg"
                 alt="Main menu showing the buttons
   to start a game, access game settings
                      (including difficulty and graphic quality),
                      and load a saved game."/>

  <screenshot src="screenshots/level1.jpg"
        alt="Level 1: The Cave of DEATH! shows our Hero
                      fighting it out with Dr Evil and his
                      temperamental bunnies."/>
</widget>

Assuming Spanish as the UA locale, one could rely on elements being
grouped by language (so screenshot element 1 and 2 would be matched).
In the widget, localized versions of Spanish screenshots would be in:

/locales/es/screenshots/mainscreen.jpg
/locales/es/screenshots/level1.jpg

Folder-based localization would automatically set the xml:base of the
document to  "/locales/es/". So dereferencing of src attribute of the
Spanish screenshots would be:

{widget://}/locales/es/screenshots/mainscreen.jpg
{widget://}/locales/es/screenshots/level1.jpg

(where {widget://} is the yet to be defined URI scheme for widgets).

An outstanding issue: What happens if xml:lang is set on the <widget>
element? Does that mean that, for instance, <widget ... xml:lang="fr">
would only be able to run on a user agent whose UA locale is "fr-*"?

Kind regards,
Marcos

On Thu, Mar 19, 2009 at 10:31 PM, Marcos Caceres <marcosc@opera.com> wrote:
> Ok, here is my first crack at specifying this...If you prefer to read
> it in the spec (so you can follow any cross references, etc), then
> please check out:
>
> http://dev.w3.org/2006/waf/widgets/#element-based-content-localization
>
> [[
> ==Element-based Content Localization==
> This specification defines the notion of element-based content
> localization, which allows authors to use the xml:lang attribute as a
> means to localize the content of certain XML elements that are part of
> the configuration document.
>
> As part of their definition, the XML elements of the configuration
> document are marked as being localizable via xml:lang with the keyword
> "yes" or "no".
>
> If an element is marked as being localizable with the "no" keyword
> (meaning that it is not localizable via element-based localization),
> the user agent must not attempt to do any localization of that element
> in the manner described in this section regardless of whether the
> element contains an xml:lang attribute.
>
> Note: Some elements marked as not being localizable via xml:lang, such
> as screenshot and icon elements, are localizable via folder-based
> content localization.
>
> If an element is marked as being localizable with the "yes" keyword,
> the user agent must attempt to match one or more elements against the
> user agent's locale. To perform element matching for the purpose of
> localization, the user agent must use the lookup mechanism as defined
> in section 3.4 of [RFC4647] (part of [BCP47]) to match, in document
> order, one of the language ranges in the ua-language list to one or
> more element in the configuration document. How matching is performed
> by the user agent depends on whether one element is allowed per
> language or whether elements are grouped by language, as defined
> below.
>
> =One element is allowed per language=
> This means that only one element of this type is allowed per language,
> so the user agent must only use the first element, in document order,
> that matches the user agent's locale and ignore any subsequent
> repetitions of the element that contain a matching xml:lang value
> (even if the content of any proceeding matching element is different).
>
> For example, assume the user agent's locale is "en-us" (English as
> used in the United States). As only one instance of the description
> element is allowed per language, in the following code the user agent
> would match the first description element but would ignore the second
> (and any other subsequent) description element.
>
> <widget xmlns="http://www.w3.org/ns/widgets">
>
>   <description xml:lang="en">
>      This element would be used.
>   </description>
>
>   <description xml:lang="en">
>      This element would be ignored.
>   </description>
>
>   <description>
>      This element would be used if the user agent's
>      locale does not match any localized description
>      elements.
>   </description>
>
> </widget>
>
> However, if the user agent's locale was "*", or did not match any of
> the localized description elements, then the user agent would match
> the third description element above.
>
> =Elements are grouped by language=
> This means that the user agent must match all elements of a particular
> type that match the user agent's locale.
>
>
>
> For example, assume that the user agent's locale is "pt-br"
> (Portuguese as used in Brazil). As multiple instance of the preference
> element are allowed per language in the configuration document, so the
> user agent would match the third and fourth preference elements below.
>
> <widget xmlns="http://www.w3.org/ns/widgets">
>
>  <!--
>   preferences for cities (Lisbon and New York)
>        -->
>  <preference name="preferredCity"
>              value="里斯本"
>              xml:lang="zh-CN"/>
>
>  <preference name="homeCity"
>              value="纽约"
>              xml:lang="zn-CN"/>
>
>
>  <!-- city names in Portuguese -->
>  <preference name="preferredCity"
>              value="Lisboa"
>              xml:lang="pt"/>
>
>  <preference name="homeCity"
>              value="Nova Iorque"
>              xml:lang="pt"/>
>
>
>  <!-- cities for unknown locale (English)-->
>  <preference name="preferredCity"
>              value="Lisbon"/>
>  <preference name="homeCity"
>              value="New York"/>
>
> </widget>
>
> However, if the user agent's locale was "*", or did not match any of
> the localized preference elements, then the user agent would match the
> fifth and sixth preference elements above.
>
> ]]
>
> Kind regards,
> Marcos
> On Thu, Mar 19, 2009 at 5:21 PM, Marcos Caceres <marcosc@opera.com> wrote:
>> On Thu, Mar 19, 2009 at 5:07 PM,  <Jere.Kapyaho@nokia.com> wrote:
>>> The reason why the I18N BP document frowns upon this is because if you have
>>> the material sent for translation, it might (or most probably will) be
>>> translated by different people in different places. So it makes coordination
>>> a little difficult when all the different language texts are in the same
>>> file. That is a big problem if you have substantial amounts of text in the
>>> file. In the case of widgets, there might not be such huge amounts of text
>>> in the config file, so that’s a mitigating circumstance for this horrible
>>> negligence. :-)
>>
>> I see.
>>
>>> Let’s assess how much translatable text there would be in a config file in
>>> the worst case, and then decide if we know well enough to break the best
>>> practice or not.
>>>
>>> Marcos came up with the following list:
>>>
>>> The following elements would be localizable:
>>>
>>> widget (but no id or version, derived from root config, if available)
>>>  name
>>>  description
>>>  author
>>>  license
>>>  icon
>>>  content
>>>  preference
>>>  screenshot
>>>
>>> (BTW Marcos, are you sure “content” and “preference” should be there? Also
>>> maybe author should be dropped. License I can understand, but probably not
>>> to be used to present different versions of a license, just translations of
>>> the same license.)
>>
>> I'm ok to drop author.
>>
>> Content I think we should keep because you might need different start
>> files for different langs to achieve particular layouts.
>>
>> Preferences i don't feel too strongly about, but I can see use cases
>> for having localized preferences.
>>
>> License, I agree, but there is obviously no way to check if it is a
>> translation, but we could certainly put in a Authoring Guideline.
>>
>>> All of these seem to have a fairly limited amount of translatable /
>>> localizable content, so would the ease of processing and the general
>>> simplification warrant the possible inconvenience in having the text
>>> translated? The license seems to be the biggest block of translatable text,
>>> and therefore potentially the biggest problem.
>>
>> I guess as it is one element, it should not bee too much drama.
>>
>>> (NOTE: A system for widget authoring that is connected to the back-end of
>>> the vendor’s translation memory / CMS could generate the config file
>>> automatically, eliminating the need to translate the actual config files by
>>> hand. Translations and other localized material can be assembled into the
>>> CMS prior to generating the config file.)
>>
>> Agreed.
>>
>>
>> --
>> Marcos Caceres
>> http://datadriven.com.au
>>
>
>
>
> --
> Marcos Caceres
> http://datadriven.com.au
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 20 March 2009 09:23:24 UTC