Consider making file names lower case?

[ollym]

I'm having real issues with dynamic loading the locale files. Consider the below (in CoffeeScript):

lang = (navigator.languages?[0] || navigator.language || navigator.userLanguage) || 'en-US'
loadScript "locale-files/#{lang}.js"

Problem is some browsers will return navigator.language with something like "en-us". Am I expected to parse that and work out what it should be with capitals?

I think it would be easier to just lowercase every file name?

[caridy]

@ollym this is very tricky. adding a lowercase will not help much because I could set my system preferences to use a very specific locale value like en-US-Miami, which should fallback to en-US, and en, and you will have no way to handle that.

essentially I believe that a validation and normalization should happen before you make a network request because you have no way to recover for a failure to load the locale data. Essentially, every app will have a set of locales that the app is suitable to function, that's a whitelist of locales that can be manually maintained, and should be a subset of what is available thru Intl. Under normal conditions, can computation happens on the server side per request, producing either the polyfill url, or a url to load what is needed for the app to function, but it could be done on the client side as well. Makes sense?

[ollym]

@caridy Is it outside the scope of this library provide some utility methods for parsing and normalising language tags then?

[caridy]

This is not a library @ollym, this is a polyfill, which means it implements what is in the specs, nothing more. That being said, we have been discussing some modifications to the specs to expose low level operations like this one you're asking for, here are the details: tc39/ecma402#5.

Now, what you're asking here is a way to prepare the polyfill based on the system locale information, which I think is not a good option, what if you have this in your code: new Intl.NumberFormat('es', {}).format(12356), that has nothing to do with the system locale, it is in many cases the same value, but the locale to be used to format a number and a date is really in the application realm, which is controlled by you.

Another issue with this approach is performance. You will have to wait until after the page is loaded and the JS code executed to decide what locale data to load, which will take a while to do, and until that happen, you can't really format numbers or dates. That will be far from optimal.

[caridy]

@ollym we are working on the specification to provide access to existing abstract operations that will allow you to normalize a locale, more details here: tc39/ecma402#46

I will keep this open until that spec lands, and we can provide a method in Intl.js polyfill.

[caridy]

This polyfill now implements ECMA402 getCanonicalLocales:

IntlPolyfill.getCanonicalLocales('EN-US-MIaMi'); // yield: [ 'en-US-miami' ]
IntlPolyfill.getCanonicalLocales(['EN-US-MIaMi']); // yield: [ 'en-US-miami' ]

fixed by #171

[ollym]

great, thanks!

[caridy]

https://github.com/andyearnshaw/Intl.js/releases/tag/v1.2.1