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

[Aaron Zeckoski]

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