Message Translations

[joao-conde]

Rationale

Add translations to change the default parrot language from English to something else.

Description

• Each message sent to the guild server must be translated.
• It should default to English.
• New translations can be easily added by open source contributors

[joao-conde]

@aquelemiguel @afonsojramos I think we discussed this at a certain point. I have an idea of how to do it. Leave it to me if you agree with the issue.

[afonsojramos]

Yeah, the big move to mostly using the strings.rs file was mostly to help with this. Go ahead!

[aquelemiguel]

Sure, removing other contributors from this.

[joao-conde]

Yeah, the big move to mostly using the strings.rs file was mostly to help with this. Go ahead!

Yes, but at the same time, the translations will no longer be stored in code and therefore not part of the release binary. This would make no sense for tons of translations.

Currently thinking of storing the translations in JSON files making it easier to change or add new ones without changing the codebase.

[afonsojramos]

I actually had already investigated a bit on how to do this properly with community integrations and stuff and I've found that platforms such as https://crowdin.com/ or https://weblate.org/en-gb/ offer a really good interface for managing the translations. Maybe it is a bit overkill, what do you think?

[joao-conde]

Seems a bit overkill to me but nonetheless when I have time I will look into them.

[joao-conde]

Alright, my proposed solution is one that:
1 - does not increase source and binary sizes with each new translation/locale
2 - can be easily contributed by open source devs
3 - custom translations can be easily be made locally

With that in mind, I propose the following:

• a messaging.rs module which implements a key message(message_type, locale = "en") function
• in that module, we keep the base strings we use right now as discord messages (they will be the default, English)
• the idea is message_type will be an enum with the types of messages we send (the queue is empty, the user is not in the channel, etc.)
• locale is the typical language ISO code; if none is given, use the default constants we have in strings.rs right now
• the translations should be stored in JSON files that are read on startup into a hashmap and used for translating from message_type + locale -> string/message

Obviously, this means the binary of parrot alone when run will always default to English. The language translations are only available if the deployed parrot instance has local JSON translation files. Alternatively, we can serve the JSON files somewhere and make HTTP requests to fetch them, but I find this overkill.

What do you think @afonsojramos @aquelemiguel

[aquelemiguel]

Sorry for taking a while to get on this, but I overall really like your implementation! 🙂

the translations should be stored in JSON files that are read on startup into a hashmap and used for translating from message_type + locale -> string/message

A follow-up question: what if for some reason a translation isn't available? For instance, a contributor that has to add a new constant cannot possibly know every translation. Do we default to English?

The language translations are only available if the deployed parrot instance has local JSON translation files. Alternatively, we can serve the JSON files somewhere and make HTTP requests to fetch them, but I find this overkill.

Keep it local, easier and encourages easy open-source contributions. 😎

[joao-conde]

The default would be English, yes. It would be basically lookup for JSON file translation (actually this will be loaded into memory at startup) and if it does not exist, use the default string.rs current English messages.

[aquelemiguel]

Sounds good, proceed with the implementation. 🙂