Handle localization in microservices architecture

Question

I'm developing a multi culture application with different microservices, The microservices communicate with each others with integrations event, so when a new record is inserted the owner of the data send an integration events on a bus and the other microservices who need that record integrate in their storage.

My question is how to handle the localization of the entries. Should I:

1. send to every microservices all the translation every time or
2. the client should call the microservice and the owner of the data to get data and translation or
3. there should be a microservice that translate everything regardless of the nature of the element (a microservice where I ask for a key and a culture and he give me the translation)?

Answer 1

Do not store the translations in multiple locations without some automated way to get them into those locations. Provide a single place for them to be edited. How or if they get cached on their way to the end user is a trivial implementation detail compared to ensuring they can be easily edited in one place.

If it wasn't for the fact that you want users to add to this live this could be part of your build process. It doesn't have to be a micro service. Just don't force your translator to chase a typo into multiple locations.

I know, dev's like their micro services to be independent. But that doesn't mean they can't import the same code library. So what's wrong with sharing a little data when you build?

But since you want users to add to this live you can't store this in multiple locations without some sort of eventual consistency strategy. That's what's really driving you to centralize this.

I can't really tell which would be better for you. But keep thinking of that poor guy trying to fix the typo.

Answer 2

I would handle this by creating a dedicated "Localisation Microservice" which stores all your possible values. Make good use of caching in each of your microservices that need to make calls to it and take the occasional hit when the service is called and its not in the cache for the service. That way you get to keep all the localisation in one place, but the local caching allows it to be performant enough across your system

Answer 3

The question was asked about localization (l10n) and internationalization (i18n), which is what my original answer was focused on. That is a well defined problem.

In the comments, the clarification is that what's really being asked is about market segmentation,rather than the traditional i18n/l10n process. Since I don't have any information on how the market segments are set up, and there is a need to translate product descriptions, I am going to assume that the market segments are "regional" in nature. I.e. the marketing segments cover multiple countries.

With this change I'm making the following assumptions:

1. You've worked out how to identify which market segment applies to your customer
2. You've also worked out how to identify the customer's language

With that, the business rules are going to decide if you have multiple SKUs for the same product to handle the different branding requirements for the different markets. If so, your job is easier. It's a question of filtering the right set of SKUs for your market segment. If you have any sway, I would make that recommendation.

In terms of l10n, my original recommendations still apply. L10n speaks toward how numbers and dates are formatted. I18n speaks toward the words used to describe your products.

One common approach to handling multiple languages for the same SKU is to have a 1..n relationship for the descriptions. If we were to represent this in a document database, you would have something like this:

{
   sku: 51234789
   description_en: "...",
   description_es: "...",
}

You would need to specify the language expected in your request. You can do that either by HTTP headers, or by encoding it into the URL. You would indicate the language in this way:

• Request: Accept-Language: es
• Response: Content-Language: es

It's also not uncommon to encode the language into the URL. An example might be:

https://www.mymajorstore.com/products/5123456789/es

In this case, you would still use the Content-Language response header, but the Accept-Language header isn't needed. At that point the service can select the right description for the product and return the product information with the i18n applied.

---

Due to the multitude of formats for localized numbers and dates, my recommendation is to handle that in your UI.

Microservices Should Work With Data

That means you define the one format for every type of data you intend to exchange:

• Dates will be formatted (example RFC-3339), and don't forget time zones
• How numbers will be formatted: pick on neutral locale
• Data Field names
• Expected value types

The services themselves are blissfully unaware of the concepts of l10n and i18n.

NOTE: one area you may need to actually take the RFC-3066 language specifier for user entered text if you intend to provide machine translations.

Consistent Data Drives Consistent Results

Since the services exchange data using known data formats there isn't any ambiguity over whether the date 01/02/12 is 1 February 2012, 2 December 2001, or 12 January 2002. It also means that you can actually process the data directly. Dates are stored as Dates, integers are stored as integers, etc. There's no translation that has to happen in the back-end.

Translate in the UI

There are a number of i18n and l10n libraries for JavaScript and other platforms. They all use the standards based identifiers to specify the user's language and locale. Often times they are provided by the browser as well.

The answers to your specific questions can fall out from what the library supports and what it doesn't.

1. Send to microservices every time?

• Your browser might actually already be sending it anyway with the Accept-Language header.
• You should only need to do that for specific requests

1. Client should call microservice and owner of data to get translation?

• Again, depends on how you store things. Most of your i18n should be available in the client, but user supplied data won't be.

1. Microservice to translate everything on demand?

• Might not scale well
• You can call the Google Translate service to get machine translations of user entered text when it is uploaded

Again, I would look into seeing what can be done in the client, and reserve any special client/server requests to handle user entered data specifically.

Answer 4

To answer this question, you need to consider your requirements and best practices.

Option 1 does not follow best practices

send to every microservices all the translation every time

This approach is problematic, as it is brittle. How can you ensure that you send it to all microservices? What if one is down? What if services are added later?

Option 2 is okay in a stable setting

the client should call the microservice and the owner of the data to get data and translation

This is a good solution if (1) the owner can be clearly identified and (2) every owner has the translation capability. If this is the case, then this is a good solution, as it allows data retrieval "on demand" and the responsibilities are clear.

This approach is problematic if the owner could disappear, while the data sticks around. It also burdens every service with having to offer translation services.

Option 3 offers the most flexibility and follows best practices

there should be a microservice that translate everything regardless of the nature of the element (a microservice where I ask for a key and a culture and he give me the translation)

A microservice should have a clear job. Option 2 forces every microservice to provide at least two, albeit related, jobs (the core job and the translation job). By providing a dedicated service, we again have clear responsibilities.

All the benefits of Option 2 stay intact as well. Further, if the orginal microservice disappears (for whatever reason), then this will not affect the translation service. It also makes translation-related refactoring much easier.

Takeaway & Advice

You don't provide much context for a more specific answer. However, my general advice is to spend some time on your overall architecture. Without a proper architecture, you easily end up with a "Spaghetti-Cluster".

Therefore, look at the various options to see which one aligns with your existing architecture best. Maybe you end up with yet another, even better option.

Answer 5

It depends on what framework you are using and its provision of translation utilities.

Even more, talking about microservices is talking about the technology, not the more important feature set.

Requesting localized data

A user could have Kroatian, with a fallback alternative of Serbian in the variant Latinic script. As second language German. There are such preference notations, like in a web browser with weights for locales like British English and so on. Something like hr=0.8;sr-lat=0.7;de=0.5;en=0.3 (English < 0.5, hence not offered.)

In an ideal world one would negotiate with a data provider for the best fit. A fallback to one single other language should be noted.

There is also localized data based on the country. Like a price in euros that differs in Germany and more expensive Austria.

Working in a multilingual environment

Here you want to see which languages have content, and for which version, release = how up to date a content is, or whether it might be out-dated.

One might assume a managed list of releases, a version control sysem. A content management system.

The answer

All three options are thinkable, but one should go with the most adequate in every single use-case. Implementing a feature (Feature Driven Development would be nice), you'll see the requirements.

Do not consider everything a nail, when having a hammer, but change tools to fit the task.

Only having several such tasks you can categorize them, probably in those three options. You might want to extract a code pattern, library API to deal with those three scales.