RE: [widget] proposal to add defaultlocale attribute to widget element (P&C Spec), I18N ACTION-18

Dear Marcos,

[this is a reply on behalf of the Internationalization Core WG]

We agree that not 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 a 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 if the top "Foo.html" is the start file, it is the default and "/locales/de-DE/Foo.html" represents a German appropriate resource corresponding to that same file. 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.

This does not, as you point out, work with items defined in the config.xml file itself.

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 state it explicitly and/or provide a mechanism for specifying the default.

The attribute 'defaultlocale' that you propose makes sense as a means of doing this. The alternative is to overload xml:lang="", but this has a number of negative things associated with it--such as the fact that it prevents the format from indicating what language the default is.

Finally, on a separate topic, we want to note that there is significant progress on internationalization additions to ECMAScript going on currently, which will be of great benefit to widget writers interested in internationalization and which may be of interest to Webapps WG as a result.

Regards (for I18N),

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, 9 February 2011 16:50:42 UTC