setting and changing locale in jquery globalize

Question

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:

1. Include the required JavaScript files
2. Load CLDR data
3. 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:

1. 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()?

2. 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).

3. 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".

Answer 1

The way I personally recommend building an application using Globalize is Application example using webpack and npm.

Now, answering to your questions more directly...

1. 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()?

Globalize is unopinionated about how applications should do it. Some applications might find better to allow its users to select the site language. Some applications might find better to use User Agent information (https://stackoverflow.com/a/674570/798133). Globalize should allow for both usages.

2. 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).

You are correct. Globalize.locale(<locale>) won't do anything except if the proper data has been loaded in advance (either by using Globalize.load() to load the data itself or by using precompiled formatters and parsers for optimal performance). So, yeap, application developer must handle that.

The Application example using webpack and npm I mentioned earlier takes care of loading data and generating optimal bundles for production automatically. Obviously, Globalize allows several other arrangements or usages. Just let me know if you have any other/more specific questions here.

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".

Absolutely. I believe we can do much more improvements to the documentation and to the examples showing our best practices for web applications using Globalize. Application example using webpack and npm is a recent update we've made, which I believe being very pertinent to your question. Just let me know on any questions.