- From: Richard Ishida <ishida@w3.org>
- Date: Wed, 26 Jan 2011 09:38:31 +0000
- To: "Phillips, Addison" <addison@lab126.com>
- CC: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Hmm. Either i'm not grasping this fully, or this seems to be tangiential to what Marcos is asking about. If, as Martin notes, you mean 'not provide a default locale', i am not sure that's correct, since there is a way of indicating a default locale - the problem appears to be that it is overly complex and relies on a misuse of the xml:lang attribute. Let's discuss more during the telecon? RI Richard Ishida Internationalization Activity Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/ On 26/01/2011 05:23, Phillips, Addison wrote: > All, > > For discussion tomorrow. > > I would like to respond to the email below as follows: > > --- > We agree that providing a default locale for a Widget is an oversight in the Widget's localization model. The ability to provide multiple languages in the configuration file or in the locales directory structure does not provide the Widget container with clear choice when the runtime language is not one of the languages provided. > > Part of this oversight may be due to an expectation that there would be a "default" set of resources present in the Widget. For example, if you had a structure like this: > > Foo.html > /locales > /de-DE > Foo.html > > ... then the top "Foo.html" is the default and "/locales/de-DE/Foo.html" represents a German appropriate resource for that. The language of the top-level resource can be anything and can be defined using the usual attributes. However, there is no requirement that such content be provided nor that it be in any particular language. > > In practice, most resource systems require that the "base" or "root" locale's resources be present to guarantee full functionality. The description in Widget's P&C implies this. It should either state it explicitly or provide a mechanism for specifying the default. > > The default you propose can also be used to set the runtime locale in the widget container, which is useful for formatting and other needs. > > --- > > Addison > > Addison Phillips > Globalization Architect (Lab126) > Chair (W3C I18N, IETF IRI WGs) > > Internationalization is not a feature. > It is an architecture. > > >> -----Original Message----- >> From: public-i18n-core-request@w3.org [mailto:public-i18n-core- >> request@w3.org] On Behalf Of Marcos Caceres >> Sent: Monday, December 27, 2010 5:29 AM >> To: public-webapps; public-i18n-core@w3.org >> Cc: Richard Ishida >> Subject: [widget] proposal to add defaultlocale attribute to widget >> element (P&C Spec), was Re: [widgets] Span example >> >> On Fri, Apr 30, 2010 at 5:16 PM, Marcos Caceres<marcosc@opera.com> >> wrote: >>> Hi Richard, >>> >>> On Fri, Mar 26, 2010 at 9:32 PM, Richard Ishida<ishida@w3.org> >> wrote: >>>> >>>> The example looks rather baroque, but I think it does illustrate >> a number >>>> of points. (I think that in real life it may be simpler to just >> use >>>> xml:lang="he" and dir="rtl" on the description tag in a >> localized config >>>> file like this. The example does currently illustrate >> inheritance though. >>> >>> Yeah, the example is convoluted on purpose to illustrate all the >> features >>> you mentioned. >>> >>>> >>>> It also shows how to markup up the language while still marking >> default >>>> text for localization failures. I hadn't realised that that was >> how you >>>> indicated the default for localization. FWIW I'd have preferred >> a special >>>> attribute for that, rather than overloading the xml:lang >> attribute, but I >>>> guess it's too late to change that now. An attribute like >>>> localizationdefault="yes" would reduce the need for the extra >> spans. >>> >>> good point. We can add it to our list of things to add in the >> future. >> >> Seems the future finally arrived!:)... After some experience with >> deploying i18nlized widgets and trying to communicate the i18n >> model >> of widgets to developers, Opera strongly feels the need to add a >> "defaultlocale" (or similarly named) attribute to the widget >> element >> defined in the P&C spec. >> >> As was pointed out by Richard, the problem with the current spec is >> that we have overloaded the semantics and functionality of xml:lang. >> As a result, the only way for an author to say that some content is >> not localized was for it not to have an xml:lang attribute (or for >> the >> xml:lang attribute to be explicitly empty). This is causing >> confusion >> amongst our development community. What would be preferable would >> be >> to have some means for authors to explicitly declare the default >> locale of a widget. >> >> Consider the addition of a defaultlocale attribute: >> >> <widget xmlns = "http://www.w3.org/ns/widgets" >> defaultlocale = "en-us"> >> >> <name short="Weather" xml:lang="en-us"> >> The Ultimate Weather Widget >> </name> >> >> <name short="Boletim" xml:lang="pt"> >> Boletim Metereológico >> </name> >> </widget> >> >> As in this case there is no unlocalized content, the user agent >> that >> does not support either 'en-us' or 'pt' will not select any content >> (!). Having the defaultlocale allows the author to hint to user >> agent >> which one of the two to use in case it cannot match any content >> (and >> returns xml:lang to having its original function - indicating the >> language of an element and its children). >> >> A further advantage, which Richard also alluded to, to having a >> defaultlocale is that is avoids the "baroque" constructions like: >> >> <widget ...> >> <name short="Boletim" xml:lang=""> >> <span xml:lang="pt">Boletim Metereológico</span> >> </name> >> </widget> >> >> And has the advantage that the short attribute can also be >> identified >> as being in Portuguese (this is actually fairly critical on the >> Widget >> API side, as widget.shortName.lang would not have a language >> associated with it). >> >> How it would work: to keep it simple, a one-to-one match would be >> used to derive the default locale of a widget. So, saying default >> locale is "en" will only match elements with xml:lang="en". Default >> locale is only used iff the user agent cannot match any localized >> content. >> >> Proposed changes to spec: >> >> 1. The semantics of defaultlocale would be defined as part of the >> widget element definition. >> 2. I18n section of spec would be updated to show examples of usage >> 3. A "default locale" would be defined as part of the configuration >> defaults (Step 3 in processing) >> 4. How to process defaultlocale would be defined in Step 7. >> >> Adding the defaultlocale will not affect existing content as all >> current rutimes behave as is defaultlocale = "". >> >> Thoughts and comments welcomed. I'll start spec'ing this up in the >> meantime. >> >> -- >> Marcos Caceres >> Opera Software ASA, http://www.opera.com/ >> http://datadriven.com.au >
Received on Wednesday, 26 January 2011 09:39:00 UTC