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

Fri Jul 6 11:37:50 PDT 2012

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.orgwith
> >> 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.orgwith 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20120706/72086421/attachment-0001.html 