- From: Francois Daoust <fd@w3.org>
- Date: Mon, 11 May 2009 10:26:00 +0200
- To: Jere.Kapyaho@nokia.com
- CC: marcosc@opera.com, public-webapps@w3.org
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 Monday, 11 May 2009 08:26:41 UTC