W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: <Jere.Kapyaho@nokia.com>
Date: Fri, 3 Jul 2009 11:34:56 +0200
To: <marcosc@opera.com>
CC: <public-webapps@w3.org>
Message-ID: <C673AB70.72A4%jere.kapyaho@nokia.com>
On 2.7.2009 14.40, "ext Marcos Caceres" <marcosc@opera.com> wrote:

> On Tue, Jun 30, 2009 at 10:27 AM, <Jere.Kapyaho@nokia.com> wrote:
>> On 29.6.2009 13.30, "ext Marcos Caceres" <marcosc@opera.com> wrote:
>> /JK1/ OK, I've checked it and I think it is now easier to find all the
>> relevant stuff. However, the "Localization guidelines" section (now 8.1) is
>> marked as non-normative, but I think it should be as normative as 8.2 and
>> 8.3. Especially since there is some CC behaviour described.
> 
> Agreed. fixed.

DoC: OK, although in the July 1 ED the section is still marked as
non-normative. Maybe the section should be called "Localization model" to
make it sound more, eh, normative?

> 
>>>> 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?
>>> 
>>> Never is:) That is a left over mistake from when we had multiple configs.
>> 
>> /JK2/ Looks like the third file in 8.4.2 is still labeled
>> "locales/es/gatos.html". Those cats are tough to manage! :-)
> 
> Argh! Fixed.

DoC: OK

>>>> 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".
>>> 
>>> Yes, this is correct.
>>> 
>>>> 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.
>>>> 
>>> Right.
>> 
>> /JK3/ So then, isn't the statement I quoted above actually incorrect?
>> Authors *can* simply put files into a language level folder, so that
>> duplicates of the exact same file are not needed. If they have the same name
>> but the content is different, then that's OK too. (Meaning that a resource
>> called 'a.gif' could be completely different for zh-hans-cn and zh, and what
>> is ultimately retrieved depends on the UA locale.)
>> 
>> One more way to put it is that if your UA locale is zh-hans-cn, and there is
>> no 'locales/zh-hans-cn/a.gif', but there is a 'locales/zh/a.gif', then the
>> latter would be found and used.
>> 
>> If you agree with this reasoning, then I think the statement should be
>> removed. Or am I misreading it somehow? This is actually pretty crucial to
>> the working of the whole model, so it's important to determine that we do
>> have the same understanding, and that the spec text doesn't lead readers up
>> the garden path in any way.
> 
> Ok, I think I stuffed the description up. I means this:
> 
>   locales/en/b.gif
>   locales/en-au/a.gif
>   locales/en-us/a.gif
> 
> If "en" is matched, then a.gif would obviously be missing (as it is
> not in locales/en/). I'm trying to say that authors should not rely on
> the top most level.
> 
> I obviously need to dump the sentence in the spec, but I still need to
> make the above clear. Can you help me out with that?

I think the problem with the authoring guideline in 8.2 is that there are
too many disconnected examples. The third example is all that is needed.
When that is moved to the front of the section, then all the prose can be
about it.

Here is my suggestion. It gets rid of the two other examples and focuses on
the zh-Hans-CN example.

----8<----
Authoring guideline:

Authors need to avoid region, script or other subtags except where they add
useful distinguishing information to a locale folder. In addition, avoid
including empty locale folders in a widget package (unless there is a good
reason to include them).

An example of a widget that uses folder-based localization:

widget.wgt  
  locales/zh-Hans-CN/a.gif
  locales/zh-Hans-CN/f.gif
  locales/zh-Hans/a.gif
  locales/zh-Hans/b.gif
  locales/zh/a.gif
  locales/zh/b.gif
  locales/zh/c.gif
  a.gif
  b.gif
  c.gif
  d.gif
  index.html
  config.xml

Authors can further facilitate the localization process by grouping files
into folder hierarchies made up of matching subtags, as is shown in the
example. Note also that the user agent treats any file or folder outside the
container for localized content as unlocalized content.

Assuming the widget's locale is "zh-hans-cn":
- A reference to a.gif would resolve to locales/zh-Hans-CN/a.gif
- A reference to b.gif would resolve to locales/zh-Hans/b.gif
- A reference to c.gif would resolve to locales/zh/c.gif
- A reference to d.gif would resolve to d.gif, as it is not associated with
any locales and is hence available to all locales.

This works at all sub-levels, so long as the parent subtag matches the child
subtags. So, for example, the "CN" region can make use of the localized
files in the "zh-Hans" folder level, the "zh" folder level, and the
unlocalized files at the root of the widget package. The user agent always
prioritizes files in sub-folders over files in locale folders closer to the
root of the widget package. Conversely, if the widget's locale were "en-US",
references to a.gif, b.gif, c.gif and d.gif would all resolve to the files
in the root of the widget package.
----8<----


>> /JK4/ Is the intent to remove just consecutive repetitions, or any
>> repetitions irrespective of where they occur? Looks like the last example in
>> Step 5 is removing any repetitions, not just consecutive ones.
> 
> No

No to what? :-) 

>> How close is this actually to the BCP 47 filtering (basic or extended)
>> algorithm? I'm thinking reuse.
> 
> BCP47 expands a tag and would conceptually do the matching upon expansion. So:
> 
> "en-us, fr-fr" would become "en-us, en, fr-fr, fr"

Somehow that seems closer to the actual desired outcome! I would suggest
that unless there is no specific reason not to, then maybe we should use BCP
47 filtering as is. Any thoughts from other interested parties?

>>>> /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?
>>> 
>>> Sorry, I don't understand this question. Can you please rephrase it?
>>> 
>>>> 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.
>>> 
>>> As above.
>> 
>> The confusion probably stems from the fact that this wasn't actually a
>> comment against the P&C spec as such, but a more general question as to how
>> the localized material is found and accessed by the widget engine at
>> runtime. The P&C spec tells widget authors how to package it so that the
>> result is as expected, but currently widget implementers don't have
>> corresponding normative documentation.
> 
> Ok, can you help me with this? Is there something I need to add to the P&C?

Yes, and no. :-) Meaning that you don't need to add anything to the P&C, but
tell me what you think about the idea in the next paragraph...
 
>> An idea I have entertained is to rename the A&E spec to 'Runtime operation'
>> or somesuch, and then include in it how the resources should be resolved at
>> runtime, but I don't know if that is the right way to do it, and even if it
>> was, would it gain traction in the WG. Maybe it is better to raise it in
>> another context altogether, rather than as part of the P&C spec review.

...but maybe in another context.

Thanks!
--Jere
Received on Friday, 3 July 2009 09:36:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:32 GMT