[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 Monday, 27 December 2010 13:42:20 UTC