Re: ISSUE-80: Runtime localization model for widgets [Widgets]

All,

Mark has explained the logic quite nicely below. The normal handling is a bit like the HTML base URI; you use relative URIs but the base is different depending on the user's language. There needs to be a fallback mechanism like this for all those resources that are not found in a given localised folder. That mechanism could be as simple as to just look for the resource in the root, but there is  an additional twist that maybe needs to be taken into account.

Since we are using BCP 47 language tags, we also need to handle subtags. Let's say that the user's computed language is 'en-AU'. In the example Mark gave there are no matching resources for that language tag, that is, there is no directory '/locales/en-AU/'. However, if you chop off the 'AU' from the tag, you end up with 'en', and there are indeed resources for that (if not all).

So, the question is, should the resource-finding algorithm look for resources in all the intermediate steps from the full language tag to the ultimate fallback level, or should the language tag always either match completely or not match at all? In yet simpler terms, should the search in the example case be: ['en-AU', 'en', '/'] or just ['en-AU', '/']? Of course, BCP 47 language tags can also have script tags like 'sr-Latn-CS' and 'sr-Cyrl-CS', which define Serbian written in Latin or Cyrillic alphabet, in Serbia and Montenegro. These would require quite different resources (HTML files written in the respective alphabets).

--Jere


On 17.2.2009 16.02, "ext Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com> wrote:

Hi Marcos, All,

I think we're all roughly on the same page about potential changes to
the localisation model and should therefore be able to specify something
that keeps everyone happy. I'll try and illustrate using an example.

Widget resource is localised, with the following file structure:

/config.xml
/index.html
/picture.png

/locales/es/config.xml
/locales/es/index.html
/locales/es/picture.png

/locales/en/config.xml
/locales/en/picture.png

/locales/ja/config.xml
/locales/ja/index.html

The desired behaviour is that the widget author can reference the
relevant "picture.png" file without forking index HTML files
unnecessarily. As long as the localisation algorithm allows the author
to use <img src="picture.png"/> in any index.html file and get back the
file they are expecting they will be happy.

If the base folder is "/" (ie the user's locale doesn't match one of the
included locales) then <img src="picture.png"/>, refers to a file that
exists (/picture.png) so there is no problem.

If the base folder is "/locales/es/" then then <img src="picture.png"/>,
refers to a file that exists (/locales/es/picture.png)so there is no
problem.

The same is true if the base folder is "/locales/en/", as even though
the config file is at the root of the widget the img src resolves to
/locales/en/picture.png.

The interesting case is when the base folder is "/locales/ja/", in which
case <img src="picture.png"/> in the localised index.html file does not
refer to a file that exists in the localised folder. I believe that
following your discussion with Josh your suggestion was that, on failure
to locate the file in the base folder, the widget user agent should look
for the file at the root of the widget. This makes perfect sense to me,
and is a change we would support; it makes life simpler for the author
by removing the need to fork HTML.

Furthermore, if this fallback behaviour was specified there should be no
need for authors to use the leading "/" as the widget user agent would
do the work for them. In fact with the fallback behaviour specified I
can't think why an author would want to use the leading "/", with the
possible exception of performance?

So while I'm not suggesting that we change the semantics of URIs, if we
specify the fallback behaviour authors could get by without using the
leading "/", thereby largely addressing Jon's concerns. We may even want
to encourage using the fallback mechanism in the specs, for example
using an non-normative note.

Any thoughts?

Thanks,

Mark











>-----Original Message-----
>From: public-webapps-request@w3.org
>[mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
>Sent: 12 February 2009 14:07
>To: Jon Ferraiolo
>Cc: Web Applications Working Group WG
>Subject: Re: ISSUE-80: Runtime localization model for widgets [Widgets]
>
>
>2009/2/5 Jon Ferraiolo <jferrai@us.ibm.com>:
>> I am all in favor of *not* having to replicate many files in
>the widget distribution just so you can create localized
>versions of a single image.
>>
>> One more thing I'll add. One of the URL techniques in the
>Widgets spec, using "/" as the first character in a relative
>address, works OK in widget workflows where the content is
>always wrapped in a ZIP, but in various Web Widget workflows,
>the widget contents are often exploded into a file system
>where the root of the widget is not the root of the file
>system or the root of the Web site. In those scenarios, you
>can't use "/" as the first character in a relative address,
>which means the entire set of files would have to be
>duplicated for each locale. Hardly ideal.
>>
>
>A slash a the front always indicates an absolute path. We are
>not changing the semantics of URIs.
>
>Kind regards,
>Marcos
>--
>Marcos Caceres
>http://datadriven.com.au
>
>