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)?
  • Can you give an example?
    – Rik D
    May 6, 2019 at 16:52
  • @Rik D In my environment a Part(entity that will be produced) js handled by the Planning microservice, the execution microservice and the quality microservice. The part has a Code to identify it and has many translations. The code is inserted in the planning microservice and sent to the others to be added in their database when I have to show the data to the user I need to show the correct translation
    – Sethlans
    May 6, 2019 at 17:17
  • If I am in the execution application how do I know the correct translation? Should I send it with the code and store in the execution database or should I call the planning microservice? Or should I have another microservice that knows all the translation?
    – Sethlans
    May 6, 2019 at 17:19
  • If I understand it correctly there’s a user who enters some fields on a “new part” form for different languages. You store this in the Planning database and send a NewPartCreated event to the bus. I would probably add the translations to this event, so other services can store this info if they require.
    – Rik D
    May 6, 2019 at 17:33
  • Yes this is exactly my case and I was wondering if there are a correct way to handle this case or the best way is to send the translation to all microservices that handle the part
    – Sethlans
    May 6, 2019 at 18:47

5 Answers 5


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.


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

  • 2
    It's just laziness on my part. Let me correct that. The point of microservices is usually to have organizational and/or operational independence. Note the OP did not specify requirements in this regard. But, introducing a central "horizontal" dependency is just against all things that microservices stand for. Microservices should control all aspects of their function, be it authentication, localization, UI, persistence, etc. Normally you wouldn't want to "centrally" manage anything. You would want teams to have independence maintaining and operating the service. Feb 25, 2022 at 12:14

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:


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.

  • 2
    The question is more about business related localization; how to handle product names and descriptions in different languages that are used in multiple services. The order confirmation service, invoice service, related product service, etc. all need the localized product info.
    – Rik D
    May 6, 2019 at 20:48
  • 1
    Yes it's not a problem of the client or the UI, they are already translated
    – Sethlans
    May 7, 2019 at 5:37
  • @RikD, I don't necessarily see that as a l10n or i18n problem, which is the problem I answered. What you are saying is that there are products that only exist in certain markets. That's a function of market segmentation. Dec 27, 2021 at 14:15
  • My answer has been updated to address the concern of market segmentation Dec 27, 2021 at 14:40

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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