- From: Francois Daoust <fd@w3.org>
- Date: Mon, 27 Apr 2009 13:24:11 +0200
- To: marcosc@opera.com
- CC: public-webapps@w3.org
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. Marcos Caceres wrote: > Hi Francois, > Sorry for taking soooo long to get back to you. I started addressing > your feedback but then your comments kinda spun out of control and > became a new document: > > http://dev.w3.org/2006/waf/widgets/i18n.html > > I'm hopeful you will find the time to give your two cents about the > proposed solution to i18n. > > Kind regards, > Marcos > > > On Thu, Jan 29, 2009 at 3:21 PM, Francois Daoust <fd@w3.org> wrote: >> Hi, >> >> Here are a few comments on the 28 January 2009 version of the Widgets 1.0: >> Packaging and Configuration located in: >> http://dev.w3.org/2006/waf/widgets/ >> >> They are mostly triggered by the Content Localization section and the >> associated mechanisms to search for files. The following comments may well >> be garbage, that wouldn't be the first time I miss something ;-) >> >> >> The base folder >> ----- >> 1. I wonder if there isn't a problem in the processing mechanism described. >> >> Let's take part of the example in 6.5, and say my locale is "en": >> / >> config.xml >> ... that contains a <content src="cats.html" /> in, say, Korean. >> cats.xml >> Locales/ >> en/ >> cats.html >> >> Per Step 6, the base folder will be "/Locales/en". >> Per Step 7, the Configuration Document is /config.xml because there is no >> config.xml in /Locales/en >> Per Step 8, the "content" element part, the widget start file is the target >> of the "src" attribute. The value is "cats.html". >> Per Step 9, the widget start file is set. I'm done. >> >> I do not see anything here that makes me use the base folder. So final >> widget start file is "/cats.xml". >> I would expect the start file to be /Locales/en/cats.html in that case. Did >> I miss something? >> >> >> 2. In 6.5, a note says: >> "At runtime, the widget user agent will set the (HTML or XML) base of the >> *start file* to the localized folder". >> Based on the above comment, shouldn't that rather be: >> "At runtime, the widget user agent will set the (HTML or XML) base of the >> *Configuration file* to the localized folder". >> >> In any case, this note should appear either in Step 8 to tell processors to >> change the base of the configuration file to the base folder, or at the end >> of Step 9 to remind processors that they need to change the base when >> parsing the start file. >> >> >> 3. I find the definition of *base folder* slightly confusing: >> http://dev.w3.org/2006/waf/widgets/#base-folder >> "The base folder is the folder from which all relative paths are resolved." >> >> From what I understand the base folder has two uses: >> a. to effectively change the base of the [configuration/start] (depending >> on what you decide for 2.) file when it is processed, in which case it is >> indeed used to resolve relative paths, though only in one file >> b. to search for localized default files, in which case it is not really >> used to resolve any relative path. >> >> The definition makes it look as though the processor needs to change the >> HTML or XML base in all the files it processes. >> I confess I do not have any better definition in mind. >> >> My whole point is more that the resolution of relative paths looks confusing >> and could be clarified. I do not think it requires any substantive change to >> the specification. >> >> >> >> The Localized Widget Example >> ----- >> Section 6.5 Content Localization >> http://dev.w3.org/2006/waf/widgets/#content-localization >> >> I see that the example was updated from the Last Call version in response to >> a comment. As it stands, I'm having problems linking the "relevant things to >> note" with the example in itself: >> >> 1. First bullet point is "The config.xml file at the root configures English >> (en/, en-gb/) and Korean versions of the widget": >> - I see the mention to the Korean language in the root config.xml file, but >> why does it configure English? >> - there is an "en-au" subfolder in locales, but no "en-gb". >> >> 2. Second bullet reads "All localized instances rely on the same >> un-localized script (engine.js)". If that's the case: >> - The value of the src attribute in /locales/en-au/cats.html should start >> with a "/": >> <script src="/scripts/engine.js"> >> (that was the case in the published Last Call) >> - the locales/en-au/scripts/engine.js is confusing at best, and should be >> removed >> Alternatively, the bullet could read "The English-Australia version uses a >> localized script (engine.js). The Spanish version uses the un-localized >> script in /scripts/engine.js. >> >> >> >> Minor typos >> ----- >> - 3.2 Internationalized Tag Set Support >> http://dev.w3.org/2006/waf/widgets/#internationalized-tag-set-support >> "to support *of* other" -> "to support other"? >> >> - 6.2 Files and Content Types >> http://dev.w3.org/2006/waf/widgets/#base-folder6.2 >> "For sniffng the content type" -> "For sniffing the content type" >> >> - 6.2 Files and Content Types >> http://dev.w3.org/2006/waf/widgets/#base-folder6.2 >> "defuault functionality" -> "default functionality" >> >> - In Step 3 - Set the Configuration Defaults: >> http://dev.w3.org/2006/waf/widgets/#step-3-set-the-configuration-defaults >> In the Configuration Defaults table, the base folder description links back >> to the line. Correct anchor should be "base-folder", not "base-folder-0" >> >> >> Thanks, >> Francois Daoust. >> >> > > >
Received on Monday, 27 April 2009 11:24:51 UTC