We are currently using l10ns on a medium webapp, a dashboard, in 5 languages, with more than 300 string ids. So far, we have been using the output/all.js file, but it has become too large to include into the bundle, so it's imperative for us to start loading the different locale files instead.
Would there be a way in v3 to have the different methods for internationalization split from the language translation .js files, or better yet, have them load the json files instead, while using just one library file and the correspondent localization rules file?
l10ns_lib.js would have all shared methods, like getTimezoneOffset, getLongLocalizedGMT, etc .. When initialized it would require an array of locales to load.
languages/es.js would have language related configuration, like __getPluralKeyword, __getOrdinalKeyword, etc . corresponding to the language .. (same approach as moment.js)
output/es.json would just have the translation keys, values, variables used to obtain the localization, would be the files the interface would write on, would be the only files to be committed to a project, and would be loaded asynchronously.
Is this a possible approach?
We are currently using l10ns on a medium webapp, a dashboard, in 5 languages, with more than 300 string ids. So far, we have been using the
output/all.jsfile, but it has become too large to include into the bundle, so it's imperative for us to start loading the different locale files instead.Would there be a way in v3 to have the different methods for internationalization split from the language translation .js files, or better yet, have them load the json files instead, while using just one library file and the correspondent localization rules file?
l10ns_lib.jswould have all shared methods, likegetTimezoneOffset,getLongLocalizedGMT, etc .. When initialized it would require an array of locales to load.languages/es.jswould have language related configuration, like__getPluralKeyword,__getOrdinalKeyword, etc . corresponding to the language .. (same approach asmoment.js)output/es.jsonwould just have the translation keys, values, variables used to obtain the localization, would be the files the interface would write on, would be the only files to be committed to a project, and would be loaded asynchronously.Is this a possible approach?