RE: [widget] proposal to add defaultlocale attribute to widget element (P&C Spec), was Re: [widgets] Span example

Thank you. You're right.

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp]
> Sent: Wednesday, February 09, 2011 12:21 AM
> To: Phillips, Addison
> Cc: public-i18n-core@w3.org; Richard Ishida
> Subject: Re: [widget] proposal to add defaultlocale attribute to
> widget element (P&C Spec), was Re: [widgets] Span example
> 
> Hello Addison,
> 
> I thought I had sent a mail earlier, but there's an important word
> missing below (or I completely misunderstand the whole discussion).
> 
> Regards,   Martin.
> 
> On 2011/02/09 16:32, Phillips, Addison wrote:
> > Proposed reply for tomorrow.
> >
> > --
> > Dear Marcos,
> >
> > [replying on behalf of I18N WG.etc]
> >
> > 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 the top "Foo.html" 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 of 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.
> > ---
> >
> > 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

> >
> 
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Wednesday, 9 February 2011 14:40:25 UTC