W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

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

From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
Date: Tue, 17 Feb 2009 15:02:06 +0100
Message-ID: <0BE18111593D8A419BE79891F6C46909028E7337@EITO-MBX01.internal.vodafone.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>, "Jon Ferraiolo" <jferrai@us.ibm.com>
Cc: "Web Applications Working Group WG" <public-webapps@w3.org>
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
>
>
Received on Tuesday, 17 February 2009 14:03:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT