24

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?

enderland
  • 12,091
  • 4
  • 51
  • 63
gvo
  • 676
  • 2
  • 5
  • 14

5 Answers5

24

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.

naXa stands with Ukraine
  • 179
  • 9
mh8020
  • 364
  • 2
  • 3
  • How do you handle Emails/things that do not touch the frontend? – Trevor Wood Sep 18 '20 at 15:26
  • 2
    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
  • This puts a lot of burden on the implementer of the API - would not recommend. – Dirk Boer May 12 '22 at 14:16
  • Besides that in 99.999% of the cases performance cost of your localization will have a neglectible impact on your performance (cached on the server). – Dirk Boer May 12 '22 at 14:18
  • Of course things like enum values should not be translated though, but you’ll add two different properties, i.e. *status* and *statusDisplayName* so implementers do their logic on *status*, but show end users *statusDisplayName* – Dirk Boer May 12 '22 at 14:22
10

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.

Community
  • 1
Jack
  • 4,449
  • 2
  • 26
  • 30
  • 1
    Thank you, this is exactly what I was looking for. Your answer should be the accepted one. – mwryl Mar 17 '21 at 06:20
2

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.

SandeliusME
  • 129
  • 1
  • 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
2

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.

Phil Lello
  • 875
  • 6
  • 14
0

Without debt spa needs built-in localization but for other server errors I think, it depends on your needs, if you'll have a core system with multiple platform or blog based web apps, it's be better to centralize localization

M.Farahmand
  • 101
  • 2