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-request@w3.org
[mailto:public-webapps-request@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+tracker@w3.org>
	
	
	

				Web Applications Working Group Issue
Tracker <sysbot+tracker@w3.org> 
				Sent by: public-webapps-request@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.bmo1@gmail.com:  how do localized folders work anyway?
	Sent at 12:01 AM on Sunday
	timeless.bmo1@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.bmo1@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.bmo1@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.bmo1@gmail.com:  supporting a virtual mapping would
have
	been better :(
	me:  we can always change it if you have a better proposal
	timeless.bmo1@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.bmo1@gmail.com:  i claim no
	me:  no, you wouldn't
	the idea is that you only localize what you want.
	timeless.bmo1@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.bmo1@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.bmo1@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.bmo1@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.bmo1@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.bmo1@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.bmo1@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.bmo1@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.bmo1@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