I'm PhD. in Computer Science from Málaga, Spain. Currently, I am teaching developers and degree/master computer science how to be experts in web technologies and computer science.
I've been reading your article and it's great! A pity I have not discovered it before. Both proposals are similar, although different...
In your proposal, interpolation is direct and cleaner (you do not have to use the translate pipe). However, in your proposal you need a module per language and, in addition, that the language is on the route. In my opinion, if a translation receives a parameter it is more inefficient ( the simple fact of being a function). Another problem that I have detected is that when you change the language, you have to reconstruct the view component tree in which the user is, this is caused by
The movement of the route.
It is necessary for the new language to be injected satisfactorily.
Anything that I can help or share, count on me.
Greetings.
Yes, the change of the language is reconstructing the whole view, but it something we are willing to accept as a trade of as users are not changing the language that often. For some products, there is even a logic in cloud functions serving that page which language version will you be redirected to based on the request.
Why we decided to use the DI instead of the pipe was that we wanted to omit the impure translate pipe in our projects.
But some projects have the setup bit adjusted and have translations in ngrx store, displayed using async pipe. They are even combining and "patching" translations that are dynamically received from CMS (where editors write them) with local ones that we keep as the default and for the development. That means there should never be a missing translation in development nor production and everything new is just being merged with the default.
Overall I've seen multiple variations and they are perfectly fine, the best thing is the typings and errors in compile-time :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi @vojtech !
I've been reading your article and it's great! A pity I have not discovered it before. Both proposals are similar, although different...
In your proposal, interpolation is direct and cleaner (you do not have to use the translate pipe). However, in your proposal you need a module per language and, in addition, that the language is on the route. In my opinion, if a translation receives a parameter it is more inefficient ( the simple fact of being a function). Another problem that I have detected is that when you change the language, you have to reconstruct the view component tree in which the user is, this is caused by
Anything that I can help or share, count on me.
Greetings.
Thanks for the feedback.
Yes, the change of the language is reconstructing the whole view, but it something we are willing to accept as a trade of as users are not changing the language that often. For some products, there is even a logic in cloud functions serving that page which language version will you be redirected to based on the request.
Why we decided to use the DI instead of the pipe was that we wanted to omit the impure translate pipe in our projects.
But some projects have the setup bit adjusted and have translations in ngrx store, displayed using async pipe. They are even combining and "patching" translations that are dynamically received from CMS (where editors write them) with local ones that we keep as the default and for the development. That means there should never be a missing translation in development nor production and everything new is just being merged with the default.
Overall I've seen multiple variations and they are perfectly fine, the best thing is the typings and errors in compile-time :D