mwistrand
commented
8 years ago Since dojo-i18n allows multiple locales to be used simultaneously and for locale data to be loaded dynamically, the main obstacle to incorporating dojo-i18n into the build process is ensuring that the CLDR data and locale messages are loaded only once.
The CLDR data are loaded via dojo-core/request and then cached locally, and the locale messages are loaded via dojo-core/load and then cached locally. Since the locale messages are proper modules, theoretically they should pose no problem since the build will have already loaded them. The CLDR data, however, are JSON files. As such, pointing to the appropriate cache in both development and production is a more difficult problem. One solution is to write an additional module that converts the CLDR JSON files pulled from unicode.org into UMD modules, so that they can be imported by dojo-core/load and cached by the underlying loader.
With regard to webpack, @matt-gadd, @agubler, @tomdye, and I had discussed using globalize-webpack-plugin, but found that doing so would require changes to the dojo-i18n message structure and would mean loading CLDR and message data twice in development.
Whichever solution we settle on, the following are still required:
- A default locale.
- An array of locales that should be included in the final build. Any default locale that has been specified will be assumed and not required in this list.
- An array of paths to bundle directories. Any files found under
${path}/{locale}/(where{locale}is one of the locales listed in no. 2 above) will be included in the build. - All CLDR data for the locales listed in no. 2 above are included in the build.
- It should still be possible to dynamically load any other CLDR data or messages for locales not explicitly included in the list of supported locales.
eheasley
Refs dojo/meta#55