I am currently developing a new web application based on a rich JavaScript client which communicates with multiple REST web services on my server. That application is intended to be used in at least two country with different languages, so we need to localize it.

My question is where should I manage the localization : should the REST services receive request and send answer with localized data, or should the client receive and send generic data and then be responsible to do the localization?


Your REST API will be easier to use by others if you provide string IDs instead of translated strings. Using an API which returns "E_NOT_AUTHORIZED" is more straightforward than if it returns some human-language, and even localized string.

Also, you might want to change the localized strings in future versions, which would be a breaking API change. With the string ID approach, you still return "E_NOT_AUTHORIZED", keeping your API compatible.

If you use a framework like Angular.js, it is easy to implement language hot-switching if you use the string ID approach. You just load another stringtable, and all strings automagically change their language because you just use some filter logic in your templates, like {{errorStringID | loc}}.

Another consideration: To reduce your server load, keep your back-end as simple as possible. You will be able to serve more clients with the same number of servers. Deliver your stringtables through a CDN, and do the localization in the front-end.

  • How do you handle Emails/things that do not touch the frontend? Sep 18 '20 at 15:26
  • 1
    In one of our projects, we have separate frontend and backend stringtables. Works quite well for us. An alternative would be to use a single stringtable (the union of what you need in the frontend+backend). But then you send more data to the client than needed.
    – mh8020
    Sep 22 '20 at 20:03

Have clients send the standardized Accept-Language header in requests, then localize on the server and include a Content-Language header in responses. See RFC 7231 Section 5.3.5 for details.

Localizing on the server side results in fewer round trips and bandwidth consumption than sending clients localization metadata. But a server can't assume what language a client wants, because what if that client is a proxy serving it to somebody else? What if there's a caching layer between the client and server? How is a server supposed to "just figure out" what language should be used for some arbitrary request?

Trying to answer those questions is complicated, so instead require that requests be self-descriptive and use the standard header so clients may negotiate what language they desire. That's called content negotiation. The Accept-Language header is a form of proactive content negotiation where a client tells a server what it's preferences are, then the server decides what to respond with based on those preferences. Reactive content negotiation is where a client sends a request asking the server what kinds of content there are, typically receives a response containing a list of links, and then chooses which one it would like by selecting a link to follow.

  • 1
    Thank you, this is exactly what I was looking for. Your answer should be the accepted one.
    – mwryl
    Mar 17 at 6:20

I would say as much as possible on the server side if you're going to support multiple devices.

Each device will of course use some translations on their own but shared stuff as error messages from the api etc will be same regardless the devices.

  • 2
    I'm not sure to understand why. For shared stuff, even if the client does the localization, I thought I would use a "dictionary" coming from the server, and that I could share that dictionary between my devices. Or did you meant something else? (In my case I will use only one device, but interesting remark)
    – gvo
    Mar 24 '16 at 17:04

It's very much a question of personal taste, but if you do things client side, you'll save on server load (assuming static or cached dictionaries), and can use language agnostic tools for testing the service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.