Suggestion: Simpler loading of CLDR with loadFromPath() and fix leaking internal path information #405
Description
I don't understand why people writing applications that use globalize.js have to bother with the internal path standard that CLDR uses and understand what module uses what paths? Unless I'm mistaken, in 99% of all cases users will just put the CLDR data somewhere and then use globalize.js without changing any paths.
- It's a headache for web developers as they have to read documentation about CLDR and the "getting started guide" instead of just plugging in globalize.js and the CLDR data and using it.
- It leaks information to a layer that shouldn't even ideally have access to the information. What CLDR data certain globalize.js modules use is not relevant for applications using globalize.js and they should not define them at all.
- It cements the CLDR path standard so if it ever changes in the future I have to rewrite my application with new paths instead of just updating globalize.js and my CLDR json mirror.
Instead of doing this insanity:
$.when(
$.get( "/static/cldr/main/en/ca-gregorian.json" ),
$.get( "/static/cldr/supplemental/likelySubtags.json" ),
$.get( "/static/cldr/supplemental/timeData.json" ),
$.get( "/static/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.
});
Why not just simply provide this interface which does all those things itself instead?
Globalize.loadFromPath("/static/cldr/", ["en"], ["date"], function(success) {
// Your code goes here.
});
- More future proof.
- Much easier and simpler to use.
In addition, I think the README should be updated so this way is strongly recommended and any other method is hidden in some "advanced use" section. The table describing what modules uses what CLDR data should be removed or hidden.
Thank you.