search

tinganho / l10ns

Internationalization workflow and formatting
http://l10ns.org
Apache License 2.0
234 stars 24 forks source link

v3 Suggestion: split translations from library code #162

Open qborreda opened 7 years ago

qborreda commented 7 years ago

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?

tinganho commented 7 years ago

The compiled output should still be the targeted programming language, which in this case is JS. And the goal is to have as little abstraction as possible and thus there shouldn't be a big difference between having everything in JSON file vs. having everything JS files. Right now, that goal isn't accomplished. Though, I have more experience with compiler architecture now, than I had back when I did V2. I have contributed quite a lot to the TypeScript compiler recently, so I should have the knowledge to achieve something great with L10ns, at least when it comes to output.

All the helper functions will be in the future only compiled when needed.

For 1 vs many files. Nothing stops you from writing a loader that loads your preferred language. It just that I think it is more correct to add the correct <script> tag.