Closed iamgergo closed 5 years ago
Some possible solutions:
lang
dir) and build a basic switch for the current locale. This way we can use the compiled versions, however, we need to compile all the available languages also we need to check if the packages have translations with the language and compile it as well.@deiberchacon Hi!
So, I was working on the 2nd way, that I mentioned in my previous comment. Actually, it works. I will write some tests and refactor a bit, then I commit – maybe in a new branch – and you can test if it works well for you as well.
I'll ping you here soon! Thanks!
@deiberchacon I committed and tagged the new release.
Now the package supports multi-locale translations and package translations as well. All the available locales are rendered, but behind the scenes, there is a simple switch-case that determines which is the proper based on the current locale.
This way we can have the performance advantage and also we can change the locale without rerendering the views.
You may update your package to the latest version. Be brave to open a new issue to if you find any bug or weird behavior. I close this issue now.
Thank you!
Since the translations are generated via blade directive, they are stored statically in the compiled templates. This is performance friendly, however, it does not track the current application locale.
It means, if the application local has been changed, the generated translations will have the previous locale.