I'm creating a website with front-end angularJs and back-end Java API server. I've already done error message internationalization in API server, but I'm wondering if I should do the translation of api result in server-side? e.g. if a french user requests an apple object, should I return him translated apple object, or just let front-end translate the apple object for him?
There seems to be both opinions on this topic.
The most popular opinion is: internationalization should be on the server-side
My opinion is: internationalization should be on the server-side
Reasonable, but inferior (IMO) choice is: internationalization is on either side or both
I don't know what most of the internet companies are doing, but I worked at a major internet company where we did all the internationalization at the server side.
My reasons for believing sever-side is the best place to internationalize:
- DRY: One of the most fundamental software engineering principles is "Don't Repeat Yourself". For internationalized software, every time you display content you have to decide which string to show, which color to show, which number format to use, which shipping options are available, etc. This is logic, albeit logic that people could argue is part of the "view" and therefore belongs to the domain of the client. But, it is logic, nonetheless, and logic that does not need to run correctly in every flavor of your clients, e.g. are your going to write it in Javascript once, swift, and then in Kotlin? Better to let your data be represented in the model and let the client be a "dumb renderer".
- Critical logic: Anything that your site needs to enforce has to be done at the server-side. Things like nationally-required age of users, how much tax to collect, etc. If some of your localization logic has to run server-side anyway, isn't it better to keep it all in one place?
- Server-side rendering: Search engines are still happier with pre-rendered content, which is why developers go to great lengths to do server-side rendering. Server-side rendering string tokens in the wrong language doesn't make much sense at all!
- Performance: By definition, localization done on the client side is going to create much less opportunity for cache-hits on previously-rendered strings, including static content. Even users with very fast hardware have to pay a performance penalty, and any added logic client-side adds to variability in user-experience based on client hardware.
- Services! If you ever decide to share your APIs with other clients than your own, they will likely expect and appreciate your localization built in. If you try to serve up tokens instead of english (or language-specific) strings, they're going to be like, "Whhhhuuuuuud?" Now I have to download a string-pack and implement translation?
- Duplicated work, expense, and coordination. One person I saw made the argument that the strings should be localized on the client, because what if the client wants to serve a language your service doesn't provide? I haven't seen that, and it wouldn't work very well, anyway. Every time you did an enhancement to your service that provided new string tokens, the client would have at least some failed tokens, unless you did some aggressive versioning, and does anyone like aggressive API versioning? Finally, you expect every client to pay for an independent translation? It's not at all cheap....
Here are some of my references on the topic:
- https://www.quora.com/When-building-a-large-scale-website-whats-the-best-way-to-implement-I18n-in-back-end-or-front-end
- Web Application Internationalization, do it server-side or client-side?
- Internationalization of api error messages on front end or back end?
Do it at the backend for the error messages by sending the locale in the rest call, for front end in the templates go for the Angular i18n with AOT compilation for a better performance
https://angular.io/guide/i18n
Why should you translate error messages in the API? just send a unique error code that can be associated with that specific error and leave the internationalization to the presentation layer (android, web, etc). They will decide/associate that unique error message to the correct message to show to the end-users, and they will also decide what's the correct translation to show; sometimes the literal translation does not fit in the design and a shorter/cut version has to be used, all that is up to the presentation layer, nothing to do with your API.
Menu
389
