Add support for translations + French

[anon1892]

This PR adds a working translation of OAI in French.

As suggested in #72, this PR use gettext for all strings (I think), except logs (and for now, config files)
The user's language is detected, and if available, the corresponding translation is used. Else, OAI is still shown in English.

All English text strings are still in the code. Translation files are bigger, but partial translations files show English version if not translated. We may also use little strings to refer to the text for all languages, including English, but a change may not automatically be reflected in others languages and the code is less legible.

To generate .pot file (empty template), use the following command on Linux :
xgettext -d base -o locales/base.pot openandroidinstaller/*.py openandroidinstaller/views/*.py
To generate .mo file (binary data), use this command on the .mo file' folder :
msgfmt -o base.mo base

PS : First commit is messy and a temporary fix. We have to find a better way to handle Python versions.

EDIT : Oops, I didn't ask for the two first commits, lancelot is another PR...
Ah, it's because you pushed to main these two today... (instead of dev?)

[MagicLike]

Looks great at the first glance, although I did not fully understand gettext... :D - Could you also look into potential support for platforms like Weblate

[anon1892]

Weblate is compatible with gettext (see here), but I didn't find how to import English strings in it (it may become evident with an account).
And gettext allows creating a sort of link between strings in the program and others (which are in this PR translated strings) in an external file, if it exists (here a simple explanation)

[tsterbak]

Hey, thanks for moving forward with this! This is a very important topic!

Give me some time to look into it, but at first glance it looks good :) (even though I don't link passing _ around, but maybe thats how it is done? I will have a look)

One major open questions with regards to translation is that the configs currently contain "hard coded" text (in English) that is displayed in the application. One way forward might be to standardize all config texts and use gettext with that 🤔

[anon1892]

Yes, passing _ seemed strange to me too, but it seems it's the way to do...

For config files, I have two ideas

• The first is to create a small script creating a dummy python file with all config strings (then use xgettext on it to have all strings in the template...). Then, just replace self.state.config.metadata.get("notes") by _(self.state.config.metadata.get("notes")) (and similar), I think it works It can seem to be hacky, but it would work all the time I think.
• The second is to replace all hard-coded strings by little shortcuts like unlock_bootloader_xiaomi and then link it with the actual text in .po files. The advantage is that if we want to update a string, we have to change it once. The drawback is that if a language is not fully translated, messages like unlock_booloader_xiaomi can be shown to the user, so we have to put English strings in others languages files if unfinished...

[tsterbak]

This works like a charm! I'm really eager to get this merged and add support for more languages (and potentially integrate weblate).
What is missing mainly is:

• more automation and testing for the builds. That should be straight forward.
• Handling of the configs. A brute force solution here could be to just treat every text that leaves a config and is displayed as a translatable string. We could export every possible string from the configs automatically with a script and create a lookup file (analogues to the base.po, I guess that is possible?). Here, we could even use something like chatgpt to create initial translations of everything. What do you think about that approach?

[anon1892]

more automation and testing for the builds. That should be straight forward.

Automation... Like automatically launch xgettext commands during compilation?
And I also don't understand what you want to test : as it's done for now, if there is a translated string, it's shown, else it's the English one...

Yes, IIRC you can create several .po files by language, I just have to check how to handle that. And yes, I think the "brute force" solution would work fine... So like the first point of my previous message?

[tsterbak]

Automation... Like automatically launch xgettext commands during compilation?
And I also don't understand what you want to test : as it's done for now, if there is a translated string, it's shown, else it's the English one...

Yeah, automation in the sense, that xgettext is installed in the developer setup, there is documentation for it and the translation are automatically updated if the source files are changed. But that I can do. It was not a request for you, just a mental note for me :D

Yes, IIRC you can create several .po files by language, I just have to check how to handle that. And yes, I think the "brute force" solution would work fine... So like the first point of my previous message?

Oh yes, exactly like the first point of your previous message 🙈 I guess I would go that way. The other way you suggested would be cleaner and saver, but also less flexible and harder to read. 🤔

[anon1892]

the translation are automatically updated if the source files are changed.

Actually, if source code is changed, two options :

• Translations have been updated too, so everything will be translated
• Translations don't have been translated, so the new string will be shown in English as default

So... It's already somewhat automated ^^

Yes, and the first point is better in case of missing translations...

[anon1892]

@tsterbak What are your plans for this PR? I can work on it if needed :)

[tsterbak]

@tsterbak What are your plans for this PR? I can work on it if needed :)

I planned to properly work on this later this year. But you can continue working on it if you have time and I'm happy to assist.
I guess the basic next step would be replace the "free text string" as msgid by some proper keys. For example "Boot custom recovery" could be "title_boot_recovery" or something. And the displayed text is then only in the translation files.
What do you think?

[anon1892]

And the displayed text is then only in the translation files.

We already started discussing of the way to do, and in case of partially translated language, I think it's better to keep plain English strings, so users will not be stuck during installation with texts like "unlock_bootloader_warning"...
But I'm not against messages keys in devices config files, since they are almost all the same (at least for each brand), it would allow easier text modifications...

[tsterbak]

I think it's better to keep plain English strings, so users will not be stuck during installation with texts like "unlock_bootloader_warning"...

There should be a default fallback to english if no string is found. The framework should support it. We should definitely use ids like "unlock_bootloader_warning" since otherwise it will be very annoying to ever change texts and it will clutter the translation files a lot.

But I'm not against messages keys in devices config files, since they are almost all the same (at least for each brand), it would allow easier text modifications...

I agree. But replacement should be done carefully to not delete information that is in there, even if they are similar they might not always be the same.

[anon1892]

You're right, I will do that.

[claudep]

I think it's better to keep plain English strings, so users will not be stuck during installation with texts like "unlock_bootloader_warning"...

There should be a default fallback to english if no string is found. The framework should support it. We should definitely use ids like "unlock_bootloader_warning" since otherwise it will be very annoying to ever change texts and it will clutter the translation files a lot.

"Classic" gettext translations do not use keys and insist on keeping the original English text. Every time the original string change, that invalidates the translations. This is totally wanted, otherwise, you may update the English strings and no translator would realize the main (English) string changed, that could lead to serious semantic bugs. The gettext translation toolchain is taken this process into account. Typically, when a string changes, the previous original string is kept in the po file so translators can compare and see what changed. From a developer point of view, the only task is to properly mark the strings for translation, and the rest is taken care of by the translation toolchain.