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.