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

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