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.