(personal comments follow) Section: http://dev.w3.org/2006/waf/widgets/#localization
1. The "system locale" example is a little odd looking. Most locale systems are of the language-then-region variety. You should probably replace "Australia, Australian English" with something like "English, Australia"). Perhaps provide a reference to the jargon word "locale". Two good references are: http://www.w3.org/TR/2004/NOTE-ws-i18n-scenarios-20040730/#IDARXSO http://www.unicode.org/reports/tr35/#Locale 2. The description of "localized resource" seems a bit too complicated. It says: -- A localized resource is a resource that may have had some aspect localized for use in an internationalized context (eg. a HTML document written in Japanese) and has been placed inside a localized folder. A widget resource may contain zero or more localized resources. All resources, except a digital signature, can be localized. -- I would tend to say: -- A localized resource is any resource that has been placed inside a localized folder. It's contents might (or might not) be translated, localized, or altered for the given context. For example, a localized folder "ja" (Japanese) might contain an HTML document translated into Japanese. A widget resource MAY contain zero or more localized resources. All resources, except a digital signature, MAY be localized. -- Note that the original phrase "internationalized context" should be avoided in favor of terms like "localized" or possibly "translated". Internationalization is the "how this works" part of this feature. 3. One of the guidelines says: -- At runtime, the widget user agent will set the (HTML or XML) base of the start file to the localized folder (even if the start file does not reside inside the localized folder!). -- This implies that ALL resources that are localized must appear in the localized folder. That is, if you have files 'a', 'b', and 'c' required by the widget, all of them must appear in the localized folder. 4. In the example, the file 'cats.html' has its name localized to 'gatos.html' in the Spanish version (or one might say that 'gatos.html' has its name localized to 'cats.html', I suppose). The root file is called "cats.html" and is described as being in Korean. Really the files should all have the same name. Otherwise, a widget component that refers to 'cats.html' will not load 'gatos.html'---it has no way of knowing what the localized resource is called. Section: http://dev.w3.org/2006/waf/widgets/#step-6 1. In general, I find this section confused about how lookup is intended to work (lookup is modeled on how most resource systems in language such as C, Java, PHP, perl, C#, etc.) work: you start with the user's locale and fall back until you find a match. The elaboration 4647 is that we allow more than one "locale" in a language priority list and we allow for more complex defaulting behavior. 2. I note that you've provided for the use of extended language ranges. RFC 4647 says quite a bit about extended language ranges, ending with this requirement, which is not addressed: Applications, protocols, or specifications that accept extended language ranges MUST define which item is returned when more than one item matches the extended language range. Personally, I would strongly recommend that you NOT allow extended language ranges. Web browsers use basic language ranges today and there is no reason I can see for widgets to use them. 3. You provide an example with a trailing "*" in a range (en-*). Note that, other than in the first position, if you accept extended language ranges the * outside the first position has no meaning and should just be ignored. Note also that the * matches more than just region. For example, it would match "en-Brai" (that's the Braille script subtag). 4. "lang-priority-list" is introduced here without any reference or definition. 5. The phrase "This step makes use of lookup filetering mechanism..." is incorrect. "Filtering" is the *other* type of matching scheme. The proper terminology should be "This step makes use of the lookup matching scheme..." 6. This description is unclear: -- The aim is to match, in order, one of the subtags in the lang-priority-list to a localized folder in the widget package. -- I would tend to say instead: -- The aim is to match, in order, one of the language ranges in the lang-priority-list to a localized folder in the widget package. -- 7. Step 1 includes the keyword "default". You should also add the special tag "i-default" to this list. 8. Lookup provides clear guidance on a range of '*' in the middle of a list (i.e. there are ranges that appear after it), when it says: If the language range "*" is followed by other language ranges, it is skipped. But your text says: If this subtag is a single * and this is not the first subtag in the lang-priority-list, then terminate this algorithm and attempt to locate the configuration document. 9. Step 2 says "subtag". I think you should either called it "range" or call it "tag" (range is preferred here). I think that you would be better of to eliminate most of the instructions here and just reference the algorithm in RFC 4647. 10. There is a normative bit that says: -- During lookup, a widget user agent is not required to alphabetize, or otherwise arrange in order, the file name fields of file entries in the widget archive. -- This can be safely removed, as lookup is not affected by alphabetization. 12. I think David already pointed out the problems with the "ch" example. 13. Note that "language" is misspelled in the first paragraph. -- If you were to convert from extended ranges and follow the standard algorithm, then your section would be a lot simpler. Would you prefer if I were to suggest a complete text for this section? Best Regards, Addison Addison Phillips Globalization Architect -- Lab126 Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: Marcos Caceres [mailto:[EMAIL PROTECTED] > Sent: Monday, May 19, 2008 12:10 AM > To: Phillips, Addison; [EMAIL PROTECTED]; WAF WG (public) > Subject: Re: [widgets] i18n > > Hi Addison, All, > I've attempted to make the widget spec conformant with BCP437. In > particular, I've deferred searching for localized folders to RFC4647 > using "lookup" against a language priority list composed of a basic > language range. WAF would be grateful if (i18n) people could take a > look at the current draft in the spec and make sure that it is ok (so > we can close issue 23 [1]). The i18n text is fairly short (only about > 1 page), so it should not take much time to read, and, hopefully, > respond to. > > In the widget spec, the localization definitions and author > requirements are described in section: > http://dev.w3.org/2006/waf/widgets/#localization > > The i18n processing model (which makes use of RFC4647) is described in > section: > http://dev.w3.org/2006/waf/widgets/#step-6 > > Hope it all makes sense. > > Looking forward to hearing your feedback, > Marcos > > [1] http://www.w3.org/2005/06/tracker/waf/issues/23 > > -- > Marcos Caceres > http://datadriven.com.au
