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

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:
>> Right. I've moved everything and renamed examples > "Localization examples".
>>
>>> This would make the material flow better and have all the concepts defined
>>> before they are used.
>>
>> I will need you to check this before we republish. Is that OK?
>>
>>> Also, the whole of Section 7 should actually appear right before the
>>> processing steps (i.e., after the current Section 8).
>>
>> I moved everything as you suggested.
>
> /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.

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

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

>>> In the first example of Step 5, why would en and en-au be swapped around
>>> when decomposed?
>>
>> I was missing an en, which might have been causing confusion. Taking
>> the first part of the example:
>> "en-us,en-au,fr,en"
>>
>> Would become:
>> "en-us,en-au,fr,en"
>>
>> And would normalize to:
>> "en-us,en,en-au"
>
> Sorry, but that doesn't correspond to anything I see in the spec now... :-(
> Maybe my original comment was misdirected, but you kind of lost me there.
>
>> _however_, during the F2F, we changed the "normalization" behavior so
>> that the result would now be: "en-us,en-au,en" (i.e., repetitions are
>> removed from left to right, not from right to left).
>
> /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

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

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

> 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.
>
> For the Disposition of Comments, all the comments that are not explicitly
> mentioned here have been addressed. Those that still need discussion or
> editorial action are marked above as /JK1/ ... /JK4/.
>
> Best regards,
> Jere
>
>
>



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

Received on Thursday, 2 July 2009 11:41:59 UTC