How to handle i18n on a microservice architecture project?

Question

I'm currently developing a bot for Discord that sends news over webhooks to multiple servers and I've decided to separate that news onto it's own microservice because the bot runs multiple instances of itself so that means this would run multiple times as well (while I could theoretically just tell it to launch on a specific instance, doesn't seem to be a proper design) but also because I want that service to still work even if the hypothetical case the bot was down due to updates or any other reason.

The bot and the microservice communicate over gRPC.

The issue I'm facing is that I have a very low amount of localizable strings on this service. For example the language of the news (Spanish, English, etc.) and the source of the news (Twitter, Facebook, etc.) which have to be localized.

But I'm not sure where would it be wise to store these translations and how to handle them depending on user inputs.

I thought of two approaches:

Solution 1 - Store them within the microservice

The bot uses gettext, so implementing it onto the microservice shouldn't be an issue. I could update the script to extract strings from both projects for them to be translated.

Then on the gRPC protobufs I could add an extra field whenever there's a request specifying the language in which the data should be returned, but that means having a lot of requests having a new language field.

message Request {
    string lang = 1;
}

message Response {
    string title = 1; // The title in the language specified in the request.
}

Solution 2 - Hardcode the localizations on the bot

Considering the news microservice wouldn't be updated often, I could hardcode the language translations within the bot and have them all in the same place. The issue is that if I were ever to update the microservice, it means that I would need to update the bot and generating strong coupling between both of them which beats the point on why I was doing this. It's also an issue since the bot takes it's time to boot up and I'm limited on the amount of times I can restart it daily, so I prefer not having downtime on it.

Answer 1

Regarding the options you are considering:

• Storing translations within the microservice: This option would allow you to keep all of the translation data within the microservice, which could make it easier to maintain as you isolate it from the rest. However, this also means that you would need to update the translations within the microservice anytime you want to make changes, which could be more time-consuming.
• Hardcoding translations in the bot: This option would allow you to keep all of the translations in a single location, which could make it faster to update. Having said this, it might not be ideal if you are planning to have multiple instances of the bot running at the same time as you mentioned, because you would need to update the translations in all of the instances separately.

However, I would suggest a third option:

• Storing translations in a separate database: This would allow you to easily access and update the translations from both the bot and the microservice, and you could use database queries to retrieve the appropriate translations based on user input. Of course, this would incur additional costs, depending on the amount of data you are storing.