API internationalization

Question

I have a question about architecture and I would like to know your opinion.

Given a product formed by an API and several consumers (Android apps, iOS apps, web apps ...), where should I implement the API response data localization? In the API itself or in each consumer? When I refer to data response I mean formatting dates, numbers, currencies and translating input errors.

I believe that localizing that kind of data in the API itself, having in mind proper standards such as ISO 639 or "Accept-Language" HTTP header, should be the way to go in order to improve coherence among all the consumers. This approach makes me think about two main problems:

1. Making the API work harder might involve some performance issues if the product scales.
2. It will be a headache when trying to manipulate the API response data in the consumers and it may reduce the scope of action of the consumers. Let's illustrate this: The consumer is a Javascript application with the locale set to "Spanish". It requests the API and API respond with a formatted float (e.g.: "1.300,21"). The JS needs to generate a chart using that float, but it will fail because of the thousands and decimal separators.

What do you think? How would you solve it?

Answer 1

Is the localization part of your core business logic, or just part of the UI?

• Message contents, time zones, number formats: those are probably part of your UI. They should be applied as late as possible, i.e. in the app and not already in the API. Your API should likely deliver these values in a normalized format, e.g. UTC for timestamps.

• Currency conversions are usually not merely cosmetic. They are often part of your business logic. There may be a huge difference between $5 and 5€. So here your API cannot deliver a canonical format, and must treat each currency differently.