[widgets] P&C LC comments on I18N/L10N

Marcos, all,

here's a bunch of comments related to the I18N/L10N related parts of the
Widgets 1.0: Packaging and Configuration spec (Last Call i.e. Working Draft
28 May 2009).

/1/ Order of material

>From an editorial standpoint, I think that the "7.2 Examples" subsection
should really be the last one in this section.

Information about element-based localization, which now is 8.15, should
appear in section 7, because the concepts are used in Section 8 before they
are even defined. It would be good to have all related info in the same
section.

My suggestion for the organization of the material is:

7 Internationalization and localization
    7.1 Localization guidelines
    7.2 Folder-based localization (used to be 7.3)
    7.3 Element-based localization (used to be 8.15)
    7.4 Localization examples (used to be "7.2 Examples", note new name)

This would make the material flow better and have all the concepts defined
before they are used.

Also, the whole of Section 7 should actually appear right before the
processing steps (i.e., after the current Section 8).


/2/ Content of examples

The localization examples are non-normative, but many developers are going
to study them closely, so it pays to fine-tune them a little (and fix a few
bugs).

In the simple example, the second file "/sp/index.html" should be labeled
"/locales/es/index.html". Similarly, in the complex example, "/locales/sp/"
should be "/locales/es".

The complex example refers to several files which really have the same
purpose. I think they should also have the same name, otherwise they cannot
be found by the same reference. That is, "/locales/es/gatos.html" should be
called "/locales/es/cats.html". Or is it intentional?

In "Fallback Behaviour Example", first paragraph, last sentence should read:
"The purpose of this 'fallback' model is to reduce the number of files that
need to be created in order to achieve localization of a widget package."
(remove 'n' from 'then', add 'in order')


/3/ Folder-based localization

Suggested addition to the authoring guideline: "A Conformance Checker (CC)
SHOULD issue a warning if there are empty locale folders in the widget
package."

This statement in the authoring guideline is puzzling: '[That is,] authors
cannot simply put shared files into a language level folder, but need to put
all files needed into the language level folder for the widget to work (for
example, having "a.gif" in both "/locales/zh-Hans/" folder and
"locales/zh").' Isn't this the opposite of what is supposed to happen in the
fallback model? If the same "a.gif" is good for both zh-Hans and zh, it
should be possible for the author to include it just once in "/locales/zh".
If the user's language list includes 'zh-Hans', it will also include 'zh',
as per Step 5. So "a.gif" will be found eventually.

Replace '"shared1.gif, shared2.gif"' with '"shared1.gif" and "shared2.gif"'.

Priority is probably a bad term to use with regard to localized folders.


/4/ The xml:lang attribute

Does the XML specification state that the values of xml:lang attributes must
be unique across instances of the same element? If yes, it is probably
redundant to repeat that in the context of all the elements in the
configuration document. If not, the statement about uniqueness could still
be factored out, for example to section 8.4, to avoid repetition.


/5/ Processing steps

Step 3: the concept of "localized config doc" appears in the Configuration
Defaults table, but that doesn't seem to exist anymore. (See also Step 6.)

Step 5: replace "unprocessed locales lists" with "unprocessed locales list"
throughout.

Consider replacing "user agent's locales" with "user agent locales"
throughout the spec.

In the first example of Step 5, why would en and en-au be swapped around
when decomposed? Would 'canonicalization' be a more suitable term here than
'decomposition'?


/6/ Runtime resolution of localized resources

What specification should describe how a reference to a resource (which
could be in a localized folder) is resolved at runtime, based on the user's
language range? That is not quite in the domain of the packaging
specification, given that it is runtime behavior. This functionality is
sketched in the fallback behavior example, but it is non-normative.


Thanks for considering these comments.

Best regards,
Jere @ Nokia

Received on Wednesday, 3 June 2009 09:48:33 UTC