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

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

From: timeless <timeless@gmail.com>
Date: Wed, 18 Feb 2009 01:26:17 +0200
Message-ID: <26b395e60902171526u2d24ee5dh70f198d3e981a251@mail.gmail.com>
To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
Cc: Marcos Caceres <marcosscaceres@gmail.com>, Jon Ferraiolo <jferrai@us.ibm.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Tue, Feb 17, 2009 at 4:02 PM, 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?

this is mostly right, however i was hoping since it's all a virtual
file system that the / form would work

some more examples:


Ideally for en, es, fr, you'd have /images/good.png,
/scripts/normal.js and /index.html always being valid even though the
actual content would different from locale to locale.

For a system which is actually using a real file system, it knows
which locale it's using, so it would do one of the following:

/config.xml => /config.xml
/index.html => /index.html
/locales/en/scripts/normal.js => /scripts/normal.js
/images/good.png => /images/good.png

/config.xml => /config.xml
/locales/es/index.html => /index.html
/scripts/normal.js => /scripts/normal.js
/images/good.png => /images/good.png

/config.xml => /config.xml
/index.html => /index.html
/scripts/normal.js => /scripts/normal.js
/locales/fr/images/good.png => /images/good.png

Note that the conceptual algorithm for this is probably:
1. expand the container
2. for the selected locale, copy each thing from /locale/{it}/{path}
to /{path}, overwriting the existing content.

And yes, it means that the original data is unavailable while a widget
is running with a certain locale. Whether content in /locales/ is
available is something about which I have no opinion (for various
reasons it might be best not to expose /locales/ at all).
Received on Tuesday, 17 February 2009 23:26:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC