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

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:

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

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

   <description xml:lang="en">
      This element would be used.

   <description xml:lang="en">
      This element would be ignored.

      This element would be used if the user agent's
      locale does not match any localized description


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

   preferences for cities (Lisbon and New York)
  <preference name="preferredCity"

  <preference name="homeCity"

  <!-- city names in Portuguese -->
  <preference name="preferredCity"

  <preference name="homeCity"
              value="Nova Iorque"

  <!-- cities for unknown locale (English)-->
  <preference name="preferredCity"
  <preference name="homeCity"
              value="New York"/>


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,
On Thu, Mar 19, 2009 at 5:21 PM, Marcos Caceres <> wrote:
> On Thu, Mar 19, 2009 at 5:07 PM,  <> 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

Marcos Caceres

Received on Thursday, 19 March 2009 21:32:13 UTC