Marcos, thanks for a lucid and thorough widget I18N model proposal. This should really help all concerned to come to agreement about how widgets should be internationalized and localized. Also in this case I18N turned out to be more than many perhaps thought it would, but the effort is worth it, given the importance of being able to present widgets in the user's language.
I've taken a first look at the proposal document (rev1.19 as of April 15); please accept a few comments. Wrt PROPOSAL A2, I would strongly recommend that the single language tag be non-empty. There is always some default language that can be retrieved or derived. Allowing an empty language tag serves no purpose, and really just complicates matters. Wrt PROPOSAL A1, the same thing applies. The language tag list should be non-empty. Although I'm not convinced that multiple language tags are of value. In this context, it should also be noted that the same widget probably shouldn't use content labeled with two or more completely disjoint language tags. At least the language must be a common denominator, even if subtags differ. So there should never be a case where the user's preferred language list is used naively when locating resources that are not found. (Example from A1 shows "en-us,en,fr,*" -- in this case if you want resource X but it is not found for 'en-us' or 'en', then you shouldn't go looking for an 'fr' version of it.) In "The widget's locale", the first question strikes me as odd. The localizable materials in the configuration document and in the folders seem like disjoint enough that there is no issue of mixing those two. The widget's locale is the same for both, as it is determined from the UA locale. If there are no entries for the widget's locale in the config file, or if there is no relevant folder content, then a fallback/default is used. The second question should be simple enough: the widget's locale should be represented as a single language tag, based on the UA locale. If there are indeed multiple preferred languages, in the order of pereference, then it is the first one. IMHO there shouldn't be any overlap between folder content and config document. They serve different purposes: the config document has mostly housekeeping data, whereas folder content is presented to the user dynamically at runtime. This is why I don't like PROPOSAL B3. The locale for both config elements and folders must be the same. My preference is clearly to have one well-defined, non-empty language tag represent the widget's locale. If there are no config elements or folder content for that, then there must be fallback elements / content that is not tagged with anything, and that serves as the default data. Note that this is different from what is described in PROPOSAL C1. Unlocalized content can and should be used even if there is a derived widget locale, because somebody just didn't provide localized content for that particular language tag. I think PROPOSAL C3 is the closest to this approach, but it considers the widget locale to be more than one language tag. Neither PROPOSAL D1 or D2 says exactly what I at least would like. PROPOSAL D2 comes close, but any resources that are not tagged with a language tag (i.e. are default resources) should probably go in the 'locales' folder. However, it doesn't really matter where they are found, so if it is OK to place arbitrary files in the root of the widget anyway, then the defaults might just as well be there. Regarding xml:base, PROPOSAL E1 is the most sensible one. This is what Dashboard must be doing also, although someone more intimate with WebKit might want to have a look there. However, the issue of the subtags complicate things a bit: if you really want to find resources that are not available for the most specific tag, but could exist for a less specific tag, then it is not enough to have just a static xml:base, but additional processing rules for resource access are needed. If subtags are not honoured, and the language tag must always be an exact match, then a static xml:base would be enough, I guess. I don't know where we currently stand on the subtag issue, but it seems like an important use case. Hope I've added at least some value to the discussion. It might be good to ask other WG members to provide their explicit preferences about the different proposals, or at least input such as I have. I hope and think you can extract some of my preferences from above. Best regards, Jere On 3.4.2009 18.02, "ext Marcos Caceres" <marc...@opera.com> wrote: Hi Addison, On Fri, Apr 3, 2009 at 4:38 PM, Phillips, Addison <addi...@amazon.com> wrote: > Hello Webapps, > > Thanks for the response. Is there is a new draft or editor's copy where these > changes are made? Yes, see [1]; but we are still working out the details. As this change caused some radical changes in the spec, I am still working out how to make the processing model work. I'm currently working on a separate document that outlines the complete solution for discussion [2]. I can send it to i18n for discussion once I'm done writing it. I would prefer to have consensus on a solution before I add anything else to the spec. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets/ [2] (unfinished draft!) http://dev.w3.org/2006/waf/widgets/i18n.html -- Marcos Caceres http://datadriven.com.au
