W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: <Jere.Kapyaho@nokia.com>
Date: Tue, 30 Jun 2009 10:27:44 +0200
To: <marcosc@opera.com>
CC: <public-webapps@w3.org>
Message-ID: <C66FA730.7154%jere.kapyaho@nokia.com>
Hi Marcos,

thanks for your effort. See below for specific points. (Marked accordingly,
see end of this e-mail for the legend.)

On 29.6.2009 13.30, "ext Marcos Caceres" <marcosc@opera.com> wrote:

> Hi Jere,
> Fixes and some questions below. I got stuck on your last point, can
> you please clarify it or suggest more clearly what you want me to do
> there?

Sure, see inline below.

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

>> 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! :-)

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

>> Priority is probably a bad term to use with regard to localized folders.
> I changed it to:
> [[
> In the example below, assuming the widget's locale is "zh-hans-cn":
> * The a.gif file in the "zh-Hans-CN" locale folder would be used
> instead of the a.gif file in the zh-Hans locale folder.
> * The b.gif file in the zh-Hans locale folder would be used instead of
> the b.gif file in the zh locale folder.
> * The c.gif in the zh locale folder would be used instead of the c.gif
> file root of the widget package.
> * The d.gif file would always be used from the root of the widget, as
> it is not associated with any locales and is hence available to all
> locales.
> ]]

I think this now accurately explains what should happen, thanks.

>> /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?
> No.
>> 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.
> Although redundant, I think I will leave this as is. If it's still
> annoying, we can remove it in CR as it would be an editorial change
> and it would have no normative impact. Is that OK?

Yes, that's OK. (I was just trying to eradicate duplicate text.)

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

How close is this actually to the BCP 47 filtering (basic or extended)
algorithm? I'm thinking reuse.

>> Would 'canonicalization' be a more suitable term here than
>> 'decomposition'?
> I think both of those terms are scary, so I've just said "would
> become" instead of "would decompose".

That's simply brilliant. :-)

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

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,
Received on Tuesday, 30 June 2009 08:28:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC