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

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

From: <Jere.Kapyaho@nokia.com>
Date: Thu, 7 May 2009 15:06:29 +0200
To: <fd@w3.org>, <marcosc@opera.com>
CC: <public-webapps@w3.org>
Message-ID: <C628B785.6267%jere.kapyaho@nokia.com>
Hi Francois et al,

reading the comments below, Iım puzzled as to why C3 would be preferable. It

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


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 Thursday, 7 May 2009 13:06:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:26 UTC