Re: Widgets 1.0 Packaging and Configuration: I18N comments...

On Thu, Apr 16, 2009 at 12:30 PM,  <Jere.Kapyaho@nokia.com> wrote:
> Marcos,
>
> thanks for a lucid and thorough widget I18N model proposal. This should
> really help all concerned to come to agreement about how widgets should be
> internationalized and localized. Also in this case I18N turned out to be
> more than many perhaps thought it would, but the effort is worth it, given
> the importance of being able to present widgets in the user’s language.
>
> I’ve taken a first look at the proposal document (rev1.19 as of April 15);
> please accept a few comments.
>
> Wrt PROPOSAL A2, I would strongly recommend that the single language tag be
> non-empty. There is always some default language that can be retrieved or
> derived. Allowing an empty language tag serves no purpose, and really just
> complicates matters.

I'm worried about absolute edge cases where the system lang cannot be
derived for whatever reason. In which case, I think i does no harm to
leave it as an empty string. For all intents and purposes, that is
equivalent to just saying "use unlocalized content".

> Wrt PROPOSAL A1, the same thing applies. The language tag list should be
> non-empty. Although I’m not convinced that multiple language tags are of
> value.

As examples, both Opera and Mac OS allow language lists (and I
understand those lists are used during localization).

> In this context, it should also be noted that the same widget
> probably shouldn’t use content labeled with two or more completely disjoint
> language tags.

So we are clear, do you mean, for example, "en,zh"?

> At least the language must be a common denominator, even if
> subtags differ.

I asked internally and our localizers said that it was ok most of the
time to allow subtags to differ. Localizers don't always have content
(e.g., software might be released with an english license because it
would be too expensive to hire a lawyer to translate the license to a
different language).

> So there should never be a case where the user’s preferred
> language list is used naively when locating resources that are not found.
> (Example from A1 shows “en-us,en,fr,*” -- in this case if you want resource
> X but it is not found for ‘en-us’ or ‘en’, then you shouldn’t go looking for
> an ‘fr’ version of it.)

This adds another layer of intelligence. I think we should just go
with the list and end-user beware. Otherwise, we should go with A2
(one UA locale only).

> In “The widget’s locale”, the first question strikes me as odd.

I'm going to assume you are talking about "From which localized
content should the widget's locale be derived, and in what order?"

> The
> localizable materials in the configuration document and in the folders seem
> like disjoint enough that there is no issue of mixing those two. The
> widget’s locale is the same for both, as it is determined from the UA
> locale.

Yes, this is probably true in most instances. Though I can think of
lots of  applications where this would not be true. For example, you
could have an "artistic" musical instrument widget, whose only
localization happens in the configuration document (e.g, it's name,
description). But none of the files are be localized. So, if you
derive the locale from the folder first, then the UA is in trouble...
argh, this was a mistake on my part then, C3, as you suggest below, is
the right option probably.

> If there are no entries for the widget’s locale in the config file,
> or if there is no relevant folder content, then a fallback/default is used.

Right! This needs to happen on both counts.

> The second question should be simple enough:

The second question being "should the widget's locale be represented
as a single language tag or as multiple language tags?"

> the widget’s locale should be
> represented as a single language tag, based on the UA locale. If there are
> indeed multiple preferred languages, in the order of preference, then it is
> the first one.

But this is based on matching to element based and folder based
content (ALA C3). So, taking C3, you have at a minimum 2 locales,
which may differ and the unlocalized content. I think that is a good
option.

> IMHO there shouldn’t be any overlap between folder content and config
> document.

Agree. It was dumb of me to think otherwise.

> They serve different purposes: the config document has mostly
> housekeeping data, whereas folder content is presented to the user
> dynamically at runtime. This is why I don’t like PROPOSAL B3. The locale for
> both config elements and folders must be the same.

Soryr, I'm confused. You say element-based and content-based data
serve different purposes, but then you say they need to be the same
locale? why? I think it's ok, for instance, to have the license in
English (element-based) and the UI (folder-based) in Spanish. Of
course, it would be better to have everything in one lang, but that
might not be possible.

> My preference is clearly to have one well-defined, non-empty language tag
> represent the widget’s locale. If there are no config elements or folder
> content for that, then there must be fallback elements / content that is not
> tagged with anything, and that serves as the default data.

that is ok, we should make this a conformance clause in the P&C spec:
i.e., "conformance checker must check that authors have provided
unlocalized fallback content, and warn if they haven't"

> Note that this is
> different from what is described in PROPOSAL C1. Unlocalized content can and
> should be used even if there is a derived widget locale, because somebody
> just didn’t provide localized content for that particular language tag. I
> think PROPOSAL C3 is the closest to this approach, but it considers the
> widget locale to be more than one language tag.

I'm with you, but I still think C3 covers more ground.

I'm strongly leaning towards C3.

> Neither PROPOSAL D1 or D2 says exactly what I at least would like. PROPOSAL
> D2 comes close, but any resources that are not tagged with a language tag
> (i.e. are default resources) should probably go in the ‘locales’ folder.

You are saying that we allow content in the "locales" as the ultimate
place to share unlocalized resources instead of the root of the
widget? That might confuse engines as they only expect to find locale
folders in there. I think it's the reason we created the "locales"
folder in the first place.

> However, it doesn’t really matter where they are found, so if it is OK to
> place arbitrary files in the root of the widget anyway, then the defaults
> might just as well be there.

Right.

> Regarding xml:base, PROPOSAL E1 is the most sensible one. This is what
> Dashboard must be doing also, although someone more intimate with WebKit
> might want to have a look there.

This one is hard to check because they use Info.plist, not config
files. However, there might be a way of testing this, like seeing if
it find the correct start file.

> However, the issue of the subtags
> complicate things a bit: if you really want to find resources that are not
> available for the most specific tag, but could exist for a less specific
> tag, then it is not enough to have just a static xml:base, but additional
> processing rules for resource access are needed.

Right, you need the dynamic reassignment of xml:base to the location
where the file has been found by the engine.

> If subtags are not
> honoured, and the language tag must always be an exact match, then a static
> xml:base would be enough, I guess. I don’t know where we currently stand on
> the subtag issue, but it seems like an important use case.

Agreed. I think we should support sub-tag searching. It's valuable here.

> Hope I’ve added at least some value to the discussion. It might be good to
> ask other WG members to provide their explicit preferences about the
> different proposals, or at least input such as I have. I hope and think you
> can extract some of my preferences from above.

Thank you for taking the time to send comments! they were very helpful!

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

Received on Tuesday, 21 April 2009 16:36:05 UTC