Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

intl #32

Open
shunkongcheung opened this issue May 1, 2019 · 1 comment
Open

intl #32

shunkongcheung opened this issue May 1, 2019 · 1 comment

Comments

@shunkongcheung
Copy link

Any plan on supporting multi-language? Thanks

@wdavidw
Copy link
Member

wdavidw commented May 1, 2019

The idea was never brought up but I am not against it. We've got english, I could handle the French and if you provide a 3rd language, that could be a good start.

Have you thought about the API. Currently, it is one large object literal with the "{code}_NAME" and "{code}_MESSAGE" properties. I am not sure "{code}_NAME" should and would be easy to translate, I consider them more as code than name. An easy way to handle this issue is to create an alternative "{code}_MESSAGE" property in the form of "{code}MESSAGE{lang}". An other way would be to expose a function which take the lang as argument and which contextualize the return object. The latter approach is dynamic and could provide more flexibility to handle locale with subcodes (eg: fr-CA) and default values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants