[WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript

Sat Jul 7 00:29:12 PDT 2012

Profile2 uses the jquery i18n and copies the same properties bundle around so it's a jar and available as a web resource. 

Cheers
Steve

Sent from my iPhone

On 07/07/2012, at 4:37, Matthew Jones <matthew at longsight.com> wrote:

> Right, but for this to work your properties have to both be packaged in the jar (the typical default so resource loader can get to it in shared) and available in the webapp to the tool. AFAIK there isn't any documentation for doing both from one source, either packing the jar then copying the bundle somewhere to the webapp during the build or something else. So this is a slightly annoying step.
> 
> And there's no /direct interface I've found to get the user's locale, so that would still have to be present in every Javascript that needs to use this, as well as the full path to the web accessible bundles. 
> 
> I'm not saying that this isn't a possible way to do it, but I can't find any decent documentation for achieving this at all., was just hoping there was some already. :/
> 
> Another thing about just using the jQuery.i18n.properties would mean that using any service that can dynamically update properties (SAK-18678),or any centralized properties (SAK-15037) wouldn't be present in these files either, so there's at least these 2 edge cases which could be avoided with a *general* /direct/i18n or similar interface.
> 
> On Jul 6, 2012 1:37 PM, "Feliz Gouveia" <fribeiro at ufp.edu.pt> wrote:
> I think we used the jQuery.i18n.properties plugin. Maybe Nuno can confirm that.
> 
> Feliz
> 
> http://archive.plugins.jquery.com/project/jquery_i18n_properties
> 
> On 6 July 2012 17:46, Aaron Zeckoski <azeckoski at unicon.net> wrote:
> > I generally solve this by putting the keys into the page html source
> > or passing the key and text with the relevant request if the first
> > option doesn't work (based on the current user). The problem with
> > trying to pass a massive set of keys is that it is a lot of data and
> > if you aren't careful you can begin to overwhelm the memory available
> > in the browser (especially on a tablet or mobile device) and the page
> > loads (or at least the first JS operation loads) are slowed down
> > waiting for the synchronous request to get the entire set to complete.
> >
> > The shortcut method for passing all the keys and translated values
> > sorta works but it is kind of the lazy way to solve it and has some
> > drawbacks (as mentioned above). I'm not a big fan of passing lots of
> > data you don't need just on the off chance that you might need it but
> > that's just a personal preference.
> >
> > -AZ
> >
> >
> > On Fri, Jul 6, 2012 at 11:41 AM, Matthew Jones <matthew at longsight.com> wrote:
> >> I was recently working on on feature on Schedule/Calendar which was making
> >> some ajax calls all client side, and I wanted to pass some return text back
> >> based on a success or failure. Ideally this message would be displayed in
> >> the UI and be i18n'd, however when searching through the docs, they were
> >> mostly incomplete relating the javascript and there didn't appear to be any
> >> great existing way of doing it.
> >> https://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai#BestPracticesforInternationalizedToolsinSakai-Javascriptbasedtoolsjavascript
> >>
> >> What was there was a presentation from Lovemore about how for evaluation,
> >> they created a new Provider (the EvalResourcesProvider) which returns json
> >> pairs of all messages in evaluation. I was thinking it would be great if
> >> rather than having every tool write this, we could have a central provider
> >> (maybe in the config project) which could return json for any message bundle
> >> and any locale (or the current users preferred locale if not specified).
> >> Ideally an external way to:
> >>
> >> String getString(bundleName,key) {
> >>
> >> return ResourceBundle.getBundle(bundleName,
> >> getUserPreferredLocale()).getString(key);
> >>
> >> }
> >>
> >> Or possibly more efficiently, just return the entire bundle in the
> >> UsersPreferredLocale as json.
> >>
> >> ResourceBundle getBundle(bundleName) {
> >>
> >> return ResourceBundle.getBundle(bundleName, getUserPreferredLocale();
> >>
> >> }
> >>
> >>
> >> The problem is that otherwise there's no way to know the users preferred
> >> locale, and there's no reliable way to get the properties off of a standard
> >> http call (like with the jquery-i18n-properties library). The only other way
> >> I can think of is to pass the entire bundle (or at least the values I need)
> >> as javascript values when creating the template, but this seems easier in
> >> the long run.
> >>
> >> Has anyone thought about this any further and did any work on this?
> >>
> >> Thanks!
> >>
> >> _______________________________________________
> >> i18n mailing list
> >> i18n at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/i18n
> >>
> >> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with
> >> a subject of "unsubscribe"
> >
> >
> >
> > --
> > Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> > _______________________________________________
> > i18n mailing list
> > i18n at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/i18n
> >
> > TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 
> 
> --
> Feliz Ribeiro Gouveia
> 
> Universidade Fernando Pessoa            http://www.ufp.pt
> Centro de Recursos Multimediaticos      Tel 351-22.507.13.06
> M.I.N.D. Lab                            Fax 351-22.550.82.69
> Pr 9 de Abril 349                       fribeiro at ufp.edu.pt
> P-4249-004 Porto
> _______________________________________________
> i18n mailing list
> i18n at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/i18n
> 
> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20120707/69af17ea/attachment.html 