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:
- You've worked out how to identify which market segment applies to your customer
- 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:
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:
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
The answers to your specific questions can fall out from what the library supports and what it doesn't.
- Send to microservices every time?
- Your browser might actually already be sending it anyway with the
- You should only need to do that for specific requests
- 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.
- 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.