-
Notifications
You must be signed in to change notification settings - Fork 6
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
Drop namespace support #14
Comments
I find it also simpler in terms of maintenance since you can find unused translations more easily by matching the strings. |
an other option would be to flatten the messages object during initialisation. |
@maranomynet would you mind reviewing my pr and annotate or merge it. |
this way you can also uglify your translation-keys with |
I'm inclined to like this because it makes things faster and quite a bit simpler. The main use-case I see for supporting namespaces, is that it makes composing large translation objects somewhat easier – but that minor benefit is hardly worth the added complexity. This is supposed to be a micro-library after all. |
I might have been too hasty npm publishing 0.3.0 just now, but #16 won't have any functional impact on the code, so it can wait until the next release anyway. |
@maranomynet I just thought if we can drop namespace support.
I do it the following way
I think it can do all thing you can do with namespaces. It would simplify and for sure fasten the computation of the translation.
What do you think?
The text was updated successfully, but these errors were encountered: