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

On Fri, Jul 3, 2009 at 11:34 AM, <Jere.Kapyaho@nokia.com> wrote:
> 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.

Argh, forgot to commit to CVS yesterday.

> Maybe the section should be called "Localization model" to
> make it sound more, eh, normative?

Ok, changed the name.

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

Used your text.

>>> /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? :-)


Sorry. forgot to finish what I was writing there.

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

We could, but that just adds a bunch of redundancy that needs to be
filtered out anyway:
"en-us,en-au,en,fr-ca,zh-hans-cn", would become
"en-us,en,en-au,en,en,fr-ca,fr,zh-hans-cn,zh-hans,zh".

We basically just take one more step and clean up the list. So, with a
bit of magic in our spec, we get:
"en-us,en,en-au,fr-ca,fr,zh-hans-cn,zh-hans,zh".

Is it ok if we just leave this section as is?

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

Lets move the above to another email. However, this sounds like
something that should be in the Widgets URI spec. Having said that,
I'm not fully understanding your proposal. Can you please extend it in
a separate email and maybe also CC Robin on it.



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

Received on Monday, 6 July 2009 14:22:38 UTC