-
Notifications
You must be signed in to change notification settings - Fork 12
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
language detection should not be done #10
Comments
any word on this? |
+1, I'm also burned by this issue. |
well, it's time to switch to transloco... |
Reopening this issue since is not addressed by #9 |
@DmitryEfimenko it will be a breaking change indeed. |
Are you OK with it? If so, I can create a PR |
It makes perfect sense to me. Since is a breaking change, please bump major version and update the README. |
Hi, any updates? I use long locales ex:
this library is throwing an error looking from the wrong locale: |
Hi @DmitryEfimenko, Are you working on this issue? Let me know I'll be happy to raise a PR if needed! |
no, go ahead, @DubeySandeep |
According to the ngx-translate examples, the
translateService.use(lang)
function should be called by the consumer application.This makes sense because the functionality for getting the current language is a part of the business logic of the application. It can be different depending on the app's requirements.
For example, one application might use the short lang ids like en and ru. Another one might use longer locales: en-US and ru-RU. This means that this line of code will not work for these apps using longer locales. It will result in the TranslationLoader trying (and failing) to load en language when it needs to load en-US.
This is why I suggest removing the following lines completly from this fnction
init
:Doing so will put the responsibility of calling
translateService.use()
on the developer of the app - just like it was initially intended byngx-translate
.As a matter of fact, I don't think the
init()
function is necesary. The rest of its functionality could be easily placed in theconstructor
of theTranslateCacheService
. This would simplify the API of the library while preserving the functionality.In either case, this would be a breaking change. Although I understand the desire to avoid breaking changes, I believe this one is necessary.
What do you think?
The text was updated successfully, but these errors were encountered: