I am trying to understand the best practice for automatically setting a locale and potentially dynamically changing it, when using the jquery-globalize library.
The requirements for getting up and running in jquery globalize, or at least as I understand them are:
- Include the required JavaScript files
- Load CLDR data
- Set locale
Step #1 is out of the scope of this question; assume it as a prerequisite to move forward.
Step #2 is documented for plain JavaScript as looking something like this, in an example they refer to as "dynamic" loading:
$.when(
$.get( "cldr/main/en/ca-gregorian.json" ),
$.get( "cldr/supplemental/likelySubtags.json" ),
$.get( "cldr/supplemental/timeData.json" ),
$.get( "cldr/supplemental/weekData.json" )
).then(function() {
// Normalize $.get results, we only need the JSON, not the request statuses.
return [].slice.apply( arguments, [ 0 ] ).map(function( result ) {
return result[ 0 ];
});
}).then( Globalize.load ).then(function() {
// Your code goes here.
});
If I understand the code properly, it uses a chain of promises: get the JSON, normalize it, then run it through Globalize.load, then do "Your code".
However, this is not dynamic in the sense of the word that I usually use it. It is not responding to user input or state changes. You are stating up front "load the English calendar information".
There are also other modules that would be needed. I don't believe that globalize is "aware" of your directory structure of languages, meaning that you would need to load in all these other files as well, passing them into Globalize.load(JSON) one way or another.
Then, although the documentation is a bit disjointed, I BELIEVE that you need to set the locale, which would be step #3.
Globalize.locale( "en" )
So finally, on to the questions:
- In order to set the locale, you need to be aware of a culture. Is it good practice to pull it from a user agent string or somesuch? In the event that I don't provide the detected locale, should I manually fall back to a given language?
In other words, is there functionality built into globalize to handle grabbing the brower or system culture and try using it automatically, or do I always need to explicitly call Globalize.locale()?
I can only set a culture whose corresponding CLDR JSON is loaded. So on language change or load, do I need to invoke a similar set of calls as the sample "load" script? I don't suspect that simply calling
Globalize.locale(newLocale)is going to do anything unless the JSON is loaded. Something like this?:function changeLocale(locale) { // "validLocales" is not shown in this sample, but imagine it as an array of locales I have explicitly provided CLDR for in my distribution if(validLocales.indexOf(locale) !== -1) {
$.when( $.get( "cldr/main/" + locale + "/ca-gregorian.json" ), ).then(function() { // normalize function }).then(Globalize.load).then(function(){ // rest of stuff function(s) }); } else { // handle invalid locale }
?
This is all what seems... clear-ish... from the documentation, but it isn't explicitly documented like this, so I'm not sure if I'm missing out on default behaviours that I don't have to code for (because they're already inherent).
- To allow extensible globalization for the consumers of the web application (web administrators deploying it), is it then a matter of documentation? "You can't just switch to 'fr', you need to download the CLDR files, place them in X directory, then update the "validLocales" configurable parameter, then modify the initialization script to set a new default? It all seems rather heavy to expect someone deploying my application to undertake, vs. "add a new language file with an ISO country code, such as fr.json".
