Re: ISSUE-80: Runtime localization model for widgets [Widgets]
2009/2/6 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Having discussed this internally and gone through some examples we agree with the issue identified by Josh. In addition, concerns were raised that even without the prospect of authors forking html to create localised content - which we agree is highly undesirable, debugging localised widgets could become more cumbersome, i.e. a case of checking all relative paths to see if they started with a / or not. A simple override behaviour is easier to understand, and, in our opinion, debug. Agreed. It will make life easier for everyone. We therefore support specifying the kind of behaviour outlined by Josh, i.e. first check the base folder for the file, if no match is found and if the base folder isn't the root, checking there using the same filename. My follow up question is that if this behaviour is specified then can't we also get rid of the behaviour relating to the leading / for relative paths in widgets? Maybe this is already implicit in Josh's proposal? This would also seem to partly address Jon's concerns below. Again, I'm strongly against fiddling with URI semantics or devising our own path scheme. Paths should stay as they are: a forward slash means an absolute path; no slash means a relative path. Whatever solution we settle on must work within those constraints. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: ISSUE-80: Runtime localization model for widgets [Widgets]
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-requ...@w3.org [mailto:public-webapps-requ...@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 jfer...@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
Re: ISSUE-80: Runtime localization model for widgets [Widgets]
On Tue, Feb 17, 2009 at 4:02 PM, Priestley, Mark, VF-Group
mark.priest...@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).
RE: ISSUE-80: Runtime localization model for widgets [Widgets]
Having discussed this internally and gone through some examples we agree with the issue identified by Josh. In addition, concerns were raised that even without the prospect of authors forking html to create localised content - which we agree is highly undesirable, debugging localised widgets could become more cumbersome, i.e. a case of checking all relative paths to see if they started with a / or not. A simple override behaviour is easier to understand, and, in our opinion, debug. We therefore support specifying the kind of behaviour outlined by Josh, i.e. first check the base folder for the file, if no match is found and if the base folder isn't the root, checking there using the same filename. My follow up question is that if this behaviour is specified then can't we also get rid of the behaviour relating to the leading / for relative paths in widgets? Maybe this is already implicit in Josh's proposal? This would also seem to partly address Jon's concerns below. Thanks, Mark From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jon Ferraiolo Sent: 05 February 2009 06:44 To: Web Applications Working Group WG Subject: Re: ISSUE-80: Runtime localization model for widgets [Widgets] 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. Jon Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Sent by: public-webapps-requ...@w3.org 02/02/2009 03:51 PM Please respond to Web Applications Working Group WG public-webapps@w3.org To public-webapps@w3.org cc Subject ISSUE-80: Runtime localization model for widgets [Widgets] ISSUE-80: Runtime localization model for widgets [Widgets] http://www.w3.org/2008/webapps/track/issues/80 Raised by: Josh Soref On product: Widgets Below is a discussion I had with Josh about the localization model for widgets. Josh identifies an issue that may affect localization at runtime that may be overcome by having the widget engines dynamically change folders when it can't find resources. timeless.b...@gmail.com: how do localized folders work anyway? Sent at 12:01 AM on Sunday timeless.b...@gmail.com: oh, it's hidden in base folder me: you put folders that follow the lang-place pattern into a folder called locale. The UA looks for a folder that matches the user's locale prefs timeless.b...@gmail.com: i'm not quite sure i understand or like that imagine i have 100 images and only want to localize 2 if base-folder means that i have to copy the whole set, i'm unhappy me: no, just make all your refs absolute. it's no problem timeless.b...@gmail.com: no, definitely bad that means i have to know in advance if i need to localize a path instead of just having 1 locale that needs to localize a file me: yes. But it supports multiple models of localization. So the model is quite flexible. timeless.b...@gmail.com: supporting a virtual mapping would have been better :( me: we can always change it if you have a better proposal timeless.b...@gmail.com: i guess the simplest question is would you ever have a localized file foo.bar and want access to the original unlocalized file timeless.b...@gmail.com: i claim no me: no, you wouldn't the idea is that you only localize what you want. timeless.b...@gmail.com: yeah so, in my model, instead of 'base folder' a localized file i18n/en-GB/index.html appears as /index.html if the UA selects en-GB me: I'm sure we are thinking of the same thing here, but now I'm worried I've done this wrong. timeless.b...@gmail.com: (so searches go first to i18n/en-GB
Re: ISSUE-80: Runtime localization model for widgets [Widgets]
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. Jon Web Applications Working Group Issue Tracker To sysbot public-webapps@w3.org +trac...@w3.org cc Sent by: public-webapps-re Subject qu...@w3.org ISSUE-80: Runtime localization model for widgets [Widgets] 02/02/2009 03:51 PM Please respond to Web Applications Working Group WG public-weba...@w 3.org ISSUE-80: Runtime localization model for widgets [Widgets] http://www.w3.org/2008/webapps/track/issues/80 Raised by: Josh Soref On product: Widgets Below is a discussion I had with Josh about the localization model for widgets. Josh identifies an issue that may affect localization at runtime that may be overcome by having the widget engines dynamically change folders when it can't find resources. timeless.b...@gmail.com: how do localized folders work anyway? Sent at 12:01 AM on Sunday timeless.b...@gmail.com: oh, it's hidden in base folder me: you put folders that follow the lang-place pattern into a folder called locale. The UA looks for a folder that matches the user's locale prefs timeless.b...@gmail.com: i'm not quite sure i understand or like that imagine i have 100 images and only want to localize 2 if base-folder means that i have to copy the whole set, i'm unhappy me: no, just make all your refs absolute. it's no problem timeless.b...@gmail.com: no, definitely bad that means i have to know in advance if i need to localize a path instead of just having 1 locale that needs to localize a file me: yes. But it supports multiple models of localization. So the model is quite flexible. timeless.b...@gmail.com: supporting a virtual mapping would have been better :( me: we can always change it if you have a better proposal timeless.b...@gmail.com: i guess the simplest question is would you ever have a localized file foo.bar and want access to the original unlocalized file timeless.b...@gmail.com: i claim no me: no, you wouldn't the idea is that you only localize what you want. timeless.b...@gmail.com: yeah so, in my model, instead of 'base folder' a localized file i18n/en-GB/index.html appears as /index.html if the UA selects en-GB me: I'm sure we are thinking of the same thing here, but now I'm worried I've done this wrong. timeless.b...@gmail.com: (so searches go first to i18n/en-GB/ and then to /) if index.html has img src=flag.png me: flag.png gets resolved to i18n/en-GB/flag.png timeless.b...@gmail.com: then whether it's /index.html, or /i18n/fr-FR/index.html if the UA locale is fr-FR, it first looks in /i18n/fr-FR/flag.png and then /flag.png yeah, but that's not what i want it's a disaster me: no, it only goes to one location timeless.b...@gmail.com: yeah, that sucks. you end up w/ millions of included files in dozens of locales because only one needed an override or you have to fork each html file just to make something happy me: hmmm I'm not convinced... I thought I had sorted this out I need to do some tests timeless.b...@gmail.com: we have a VFS, and our UA has a cache, which
ISSUE-80: Runtime localization model for widgets [Widgets]
ISSUE-80: Runtime localization model for widgets [Widgets] http://www.w3.org/2008/webapps/track/issues/80 Raised by: Josh Soref On product: Widgets Below is a discussion I had with Josh about the localization model for widgets. Josh identifies an issue that may affect localization at runtime that may be overcome by having the widget engines dynamically change folders when it can't find resources. timeless.b...@gmail.com: how do localized folders work anyway? Sent at 12:01 AM on Sunday timeless.b...@gmail.com: oh, it's hidden in base folder me: you put folders that follow the lang-place pattern into a folder called locale. The UA looks for a folder that matches the user's locale prefs timeless.b...@gmail.com: i'm not quite sure i understand or like that imagine i have 100 images and only want to localize 2 if base-folder means that i have to copy the whole set, i'm unhappy me: no, just make all your refs absolute. it's no problem timeless.b...@gmail.com: no, definitely bad that means i have to know in advance if i need to localize a path instead of just having 1 locale that needs to localize a file me: yes. But it supports multiple models of localization. So the model is quite flexible. timeless.b...@gmail.com: supporting a virtual mapping would have been better :( me: we can always change it if you have a better proposal timeless.b...@gmail.com: i guess the simplest question is would you ever have a localized file foo.bar and want access to the original unlocalized file timeless.b...@gmail.com: i claim no me: no, you wouldn't the idea is that you only localize what you want. timeless.b...@gmail.com: yeah so, in my model, instead of 'base folder' a localized file i18n/en-GB/index.html appears as /index.html if the UA selects en-GB me: I'm sure we are thinking of the same thing here, but now I'm worried I've done this wrong. timeless.b...@gmail.com: (so searches go first to i18n/en-GB/ and then to /) if index.html has img src=flag.png me: flag.png gets resolved to i18n/en-GB/flag.png timeless.b...@gmail.com: then whether it's /index.html, or /i18n/fr-FR/index.html if the UA locale is fr-FR, it first looks in /i18n/fr-FR/flag.png and then /flag.png yeah, but that's not what i want it's a disaster me: no, it only goes to one location timeless.b...@gmail.com: yeah, that sucks. you end up w/ millions of included files in dozens of locales because only one needed an override or you have to fork each html file just to make something happy me: hmmm I'm not convinced... I thought I had sorted this out I need to do some tests timeless.b...@gmail.com: we have a VFS, and our UA has a cache, which means having it try two paths won't hurt (and it's a readonly VFS, so if i do img src=images/flag.png and my locale doesn't have /i18n/fr-FR/images/, then the UA can skip the check for the file there and go straight to /images/flag.png Sent at 12:12 AM on Sunday timeless.b...@gmail.com: basically, when people try to localize, they often end up forking html files. and often they create stale versions w/o noticing me: I kinda get where you are going, but it seems like the behavior is kinda unpredictable. I'm kinda seeing the problem now. timeless.b...@gmail.com: it's fairly easy to make a tool to show which version of a file would be used me: does it matter that you dont need to have a html file in the localized folders? that way you only need to branch when you need a special layout timeless.b...@gmail.com: if all i have is /index.html and it has img src=flag.png then it should search /i18n/fr-FR/flag.png then /flag.png having to branch html files is dangerous me: ah! /me gets it now :) timeless.b...@gmail.com: note that i switched from en-GB to fr-FR as my locale :) me: ok, that should be easy to specify. it's just a minor extension to what we already have kinda fallback behavior
