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

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:

/config.xml
/images/good.png
/index.html
/scripts/normal.js
/locales/en/scripts/normal.js
/locales/es/index.html
/locales/fr/images/good.png

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:

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

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

fr:
/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