- From: timeless <timeless@gmail.com>
- Date: Wed, 18 Feb 2009 01:26:17 +0200
- 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: /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