Re: [widgets] Base folder and resolution of relative paths

Hi Francois,

the idea of treating the widget package essentially as a local HTTP server
in terms of resources is quite interesting, although like you said there
will be differences. In terms of localized resources, it seems a good
strategy to use the same mechanism as HTTP and Accept-Language to select
localized resources. I donıt know if anyone has done it like this before in
the context of an application; maybe not. But somehow I think we donıt go
all the way to q values. (?)

The most important concept here is really that the locale (or language tag,
if you will) is specific to any given resource. That does have the risk of
having partially localized applications, as you observed, but that is really
the developerıs concern. They just need to make a concerted effort to
localize all that is needed.

Of course there will always be widgets that have nothing localized, so the
mechanism must allow the fallback content to be found as the last step of
the lookup. The drawback there is that if resources are always looked for
according to the UA language list, it might be wasted effort (and a
performance hit) for those widgets that donıt have anything localized. The
search would go all the way from the deepest branch to the root in vain
before finding the fallback content.

Iım thinking the widget locale (as derived from the UA language list) should
be organized by primary subtag so that the most specific tag comes first,
like so: ³en-us, en, fr-ca, fr-fr, fr². At least Marcos seemed to like this
idea. That would simplify things by making the base folder essentially the
first tag in the widget locale. (Or could this be folded to just "en-us,
fr-ca, fr-fr"? Content negotiation should know to drop the subtags
successively anyway.)

Assumptions/premises:
- The content negotiation is applied only to widget: URIs (incidentally,
would a relative URI inside widget content then always be considered a
widget: URI?)
- When referring to content inside the widget package, the
Olocales/some-language-tagı part is never included in the URI. Instead, the
content negotiation mechanism should kick in and find the resource given
just a relative URI like 'flag.png'.
- If the content negotiation finds no localized content (i.e. there is no
requested representation for the resource), a resource with the specified
name in the root of the widget is used. If not present, it is probably an
error.

I'm trying to help Marcos hammer out these things in the P&C spec, so I
really appreciate your feedback.

--Jere

-- 
Jere Käpyaho (jere.kapyaho@nokia.com)
Specialist, Developer Platforms Standardization
Devices R&D, Nokia Corporation



On 11.5.2009 11.26, "ext Francois Daoust" <fd@w3.org> wrote:

> Hi Jere,
> 
> Let me try to clarify my thoughts...
> 
> Note I'm actually suggesting an amended C3: one locale per resource, and
> one locale for element-based localization.
> 
> 
> For folder-based localization, my rationale is that it's useful to view
> a widget package as a local HTTP server because it allows one to create
> a widget from an existing server-based web site with limited changes.
> There will always be differences but trying to stick to HTTP rules when
> possible (and mostly harmless, i.e. when there's no strong benefit not
> to follow these rules) sounds like a good idea.
> 
> In HTTP exchanges, the locale of a resource is resource-specific: the
> server returns the resource in a locale that best matches the list
> defined in the Accept-Language HTTP header field of the HTTP request.
> Two requests with the same language list sent to two different resources
> may return resources in two different languages. That's up to the
> content provider to make sure that things are consistent. I'm suggesting
> that you use the same mechanism for folder-based localization. In
> practice, this means that there is no one locale for folder-based
> localization, it's rather one locale per resource. It sure makes it
> possible to have half of a widget in Russian while the other half is in
> Chinese, which does not make a lot of sense. But then the same thing is
> possible with server-based web sites, and returned languages are based
> on the list of languages supposedly understood by the end user anyway.
> 
> 
> For element-based localization, I don't feel strongly one way or the
> other. Here, we're not talking about one resource per language, but
> about one resource that contains information in different languages. It
> seems better to define one locale for the whole resource for consistency
> reasons, and that's what C3 suggests.
> 
> Francois.
> 
> 
> 
> Jere.Kapyaho@nokia.com wrote:
>> Hi Francois et al,
>> 
>> reading the comments below, Iım puzzled as to why C3 would be preferable. It
>> says:
>> 
>> "... two different locales: one specifically for folder-based localization,
>> and the other specifically for element-based localization."
>> 
>> What is the rationale for this? I would think that the locale influencing
>> the selection of material should be the same for both (and use default
>> unlocalized material if localizations are not found).
>> 
>> --Jere
>> 
>> 
>> On 27.4.2009 14.24, "ext Francois Daoust" <fd@w3.org> wrote:
>> 
>>> Hi Marcos,
>>> Hi WebApps WG,
>>> 
>>> Looking at the new document, I'm actually surprised you could get back
>>> to me so quickly! ;)
>>> 
>>> The main concern I had was that the initial algorithm did not seem to
>>> work in all cases. Now that you've covered the topic in great details in
>>> a separate document, I'm confident you'll end up with something that works!
>>> 
>>> My two cents on the proposals are below.
>>> 
>>> 
>>> 
>>> For folder-based localization
>>> -----
>>> Although the analogy has limits and may not be one that you guys like, I
>>> can't help looking at widgets as some kind of packaged HTTP server that
>>> serves a few resources (with specific security settings).
>>> 
>>> In this analogy, localized files match HTTP content negotiation based on
>>> the Accept-Language request header: the user wants a resource identified
>>> by a URI, sends an HTTP request with a list of accepted languages in an
>>> Accept-Language header, and the server serves the representation that
>>> best matches the list.
>>> 
>>> In HTTP, the consistency of language returned by two different resources
>>> is in the hands of the content provider, who may screw up things and
>>> only partially translate a set of resources that reference each other. I
>>> would leave it in the hands of the widgets developer as well.
>>> 
>>> 
>>> 
>>> For element-based localization
>>> -----
>>> For elements with xml:lang attributes, there's but one resource that
>>> contains different parts in different languages. The above analogy does
>>> not help much. There seems to be a need for consistency between the
>>> elements because such elements may be used for lists of parameters, and
>>> parameters with different locales may not mix well together, as your
>>> examples that use a "preferredCity" parameter demonstrate.
>>> 
>>> So I guess I would select one and only one locale for the config file.
>>> I don't really have any strong position on this.
>>> 
>>> 
>>> 
>>> Votes on proposals
>>> -----
>>> With the above views in mind, I'd vote for:
>>> 
>>> 
>>> - A2 (same as Marcos):
>>> use the hierarchy, more flexibility.
>>> 
>>> 
>>> - B1 (same as Marcos):
>>> use the same list of locales as in regular HTTP exchanges.
>>> 
>>> 
>>> - almost C3, but probably more an additional proposal C4, I'm afraid:
>>> I would define one locale for element-based localization, and the locale
>>> for folder-based localization depends on the resource being
>>> dereferenced. In other words, files in the locales folder are different
>>> representations of the same resource, and each time a file is retrieved,
>>> the best representation that matches the list of user agent locales
>>> defined by B1 is selected.
>>> 
>>> Inconsistencies are possible, but then a half translated widget does not
>>> make any sense, and this solution would allow to use the same set of
>>> files to create a regular Web application (with minor server-side
>>> tweaking to select the bind the locales folder hierarchy to the content
>>> negotiation mechanism based on the Accept-Language folder).
>>> 
>>> [ A different view on this could be: don't define a new mechanism if you
>>> can re-use one that already exists and is already widely deployed, even
>>> if the one that already exists is not perfect. ]
>>> 
>>> 
>>> - D2 (same as Marcos):
>>> one widget locale (for elements based localization).
>>> 
>>> 
>>> - E2:
>>> I'm not entirely sure I got the proposal correctly, but since I view
>>> locale files as representations of a resource located at the root (or
>>> not, there does not need to be a default representation of a resource),
>>> the URI should be that of the root file, and the  user agent would
>>> emulate the behavior of an HTTP server here and select the appropriate
>>> representation.
>>> 
>>> 
>>> HTH,
>>> Francois.
>>> 
>>> 
>> 
>> 
>

Received on Wednesday, 13 May 2009 10:05:45 UTC