6

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)?
6
  • Can you give an example?
    – Rik D
    May 6 '19 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 '19 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 '19 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 '19 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 '19 at 18:47
-1

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

1
  • A downvote with no comments? Bit cowardly... Jan 16 at 22:40
-1

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.

4
  • 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 '19 at 20:48
  • 1
    Yes it's not a problem of the client or the UI, they are already translated
    – Sethlans
    May 7 '19 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 '21 at 14:15
  • My answer has been updated to address the concern of market segmentation Dec 27 '21 at 14:40

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.