I glanced at the README and found the two things that I dislike in general when it comes to i18n libraries:
- JSON is not flexible enough for complex languages
(e. g. polish)
- retrieving of translation data should not be a concern of the library
@talyssonoc This criticism is not directed at _your_ library. It is a thing that bugs me in general.
My personal favourite for i18n is [newspeak] [0]. It is inspired by [Mozillas L20N project] [1].
[0]: https://npmjs.org/package/newspeak
[1]: http://l20n.org/
I totally agree about the second point! I plan to add something like that in the future.
About the first one, I think I never worked with such a complex language like polish, could you elaborate and/or give some example?
I am not that familiar with the polish language but I know that their are complex rules for the spelling of nouns. It depends on the amount, gender and a few other things (I guess). JSON is too restrictive for that.
As far as I'm concerned local is langage + location... such as "en-US", where language-only is a fallback if there's no match in language-location.
I would probably either have a "default" language, or a configuration to set what the default is. With rules for fallback/forward.
I'd also get rid of the configuration option to specify locales, and use the directory path's /^(default|([a-z]{2})(\-[a-z]{2})?)\.json$/i to look for configured localizations. This means less configuration, and more straight forward defaults.
What I mostly intend with this lib is flexibility.
About the location, the lib doesn't opinate about that. I do use the fallback system here, it only happens that the examples on the lib itself don't use the location.
There is a default language configuration (if I understood what you said), you just have to pass the `defaultLocale` option.
I don't wan't to opinate about the file names, the main reason of this lib is give freedom for the user to set it the way it's easier for him/her. I plan to allow the user to pass an object directly instead of the path too, so it will be even more flexible.
If the user want to use some fiction language that doesn't have a location he'll be able to do that without major efforts.
As far as I'm concerned local is langage + location... such as "en-US", where language-only is a fallback if there's no match in language-location. I would probably either have a "default" language, or a configuration to set what the default is. With rules for fallback/forward. I'd also get rid of the configuration option to specify locales, and use the directory path's /^(default|([a-z]{2})(\-[a-z]{2})?)\.json$/i to look for configured localizations. This means less configuration, and more straight forward defaults.