[Building Sakai] [WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Tue Jul 10 05:17:45 PDT 2012
I think using the ResourceLoader leads to compatibility with SAK-18678.
This is a reason for doing it the way Lovemore has shown us is good
unless we have a better way to do the same.
SAK-15037 means loading another bundle, which is centralized. We already
have examples for this, but not with javascript AFAICT.
I'm back and busy today, please ask if you need more information.
J-F
On 06/07/2012 20:37, Matthew Jones 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
> <mailto: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
> <mailto: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 <mailto: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 <mailto:i18n at collab.sakaiproject.org>
> >> http://collab.sakaiproject.org/mailman/listinfo/i18n
> >>
> >> TO UNSUBSCRIBE: send email to
> i18n-unsubscribe at collab.sakaiproject.org
> <mailto: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 <mailto:i18n at collab.sakaiproject.org>
> > http://collab.sakaiproject.org/mailman/listinfo/i18n
> >
> > TO UNSUBSCRIBE: send email to
> i18n-unsubscribe at collab.sakaiproject.org
> <mailto: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 <mailto:fribeiro at ufp.edu.pt>
> P-4249-004 Porto
More information about the sakai-dev
mailing list