@Rafa recently opened a topic on the translation of Orekit error messages. I was surprised by the reaction of other contributors. Rafat pointed out in his message a topic opened a few months earlier by @Serrof, which I had completely missed. I thus discovered that the translation of messages generated an additional amount of tedious work, which was negatively received by the contributors. I had never worried about this before, and I didn’t know how translations were managed in Orekit. So I examined the code, discussed it with a few contributors, and discovered that the current process could be greatly improved.
Translation is an activity that has absolutely no connection with development, and requires specific skills and appropriate tools.
There are several translation management platforms. One of them particularly caught my attention, it’s called Weblate.
It has an excellent reputation and a friend who contributes to the translation of several projects told me that it was one of the most user-friendly and efficient
It can be self-hosted
So last week, I deployed a self-hosted instance of Weblate:
In order to avoid harmful side effects on Orekit during the Weblate evaluation phase, I have created a new project, which contains the sources of Orekit, but which is not declared in GitLab as a fork of the Orekit project: Testing Zone / Orekit Weblate.
I am now looking for people willing to contribute to the evaluation of Weblate. If you are interested, could you please register here and send me your public IP address (IPv4 and/or IPv6) by private message, so that I can add it to the white list of IP addresses.
You can then create an account on the platform and I will give you access to the project.
Just started exploring the interface and it really looks great!
A particular feature that I really liked is that when adding a missing translation, you see at a glance on screen the translations for all languages that you selected as languages you understand. So e.g., when adding a Spanish translation, I can see both the English and French versions, which is really handy in choosing the best way to translate some technical terms.
I also tried to add a request to add a new language to the project, but couldn’t find a dedicated menu. Is it supposed to have a standard way to send these requests and I’m missing it, or is it just supposed to be sent through the communication panel? I was trying to request the addition of Japanese
To be honest, I hadn’t noticed this detail before. I must say that I’m not multilingual and the availability of the different translations doesn’t help me much.
When I have doubts about the translation of a technical term from French to English, or from English to French, I turn to the invaluable terminology dictionary created by Quebec. It indicates the different possible translations according to the technical field in question:
Unfortunately, this dictionary only covers French and English. But for other languages, there’s always Wikipedia.
I have deliberately blocked the addition of new languages for the moment, because I want to study the following in stages:
the ergonomics and mode of operation of Weblate;
the rights required by the various parties: what rights are required for new translators? What rights can we grant to translators we already know? Is it possible to set up a proofreading and validation process? In which cases?
Is the interaction between Weblate and GitLab reliable? What happens if a contributor directly alters the properties files and creates a conflict in Git? Can we easily deal with this problem?
etc.
Once all these issues have been addressed, we can open up the platform to other languages (again, we will need to check the required rights and the impact).
Thank you for your feedback,
Feel free to continue the test, without doing any mass translation for the moment, because the target project is not Orekit, but a test copy.
Something I have noticed is that, for example, if I go to existing translations, I currently have (as part of the Translators group) the permissions to either directly modify a translation, or to add a suggestion for a modification, that can then be revised and accepted/rejected.
As part of the Translators group, I can also review and accept/reject these suggestions.
So I guess it might make sense to split and have a group of translators with rights only to send suggestions (e.g., new translators), and then other group of translators that can permanently modify translations and accept/reject suggestions?
@MaximeJ and I have carried out some tests and I think we have found the right strategy:
The project is now declared “Protected” (Project => Settings => Access):
Everybody can view it.
Only chosen users can contribute.
Only chosen users can access Git repository.
Reviews are enabled (Project => Settings => Workflow)
Suggestions are turned on (Project => Component => Settings => Translation)
The addition of a new translation is disabled (for the moment) (Project => Component => Settings => Files)
A changeset by translator was pushed on the repository:
But, strangely, no merge request was opened this time (unlike my very first attempt with another test project, pointing to my Orekit fork: the new translations had been pushed to my fork and a merge request had been opened on the upstream project).
I need to understand if this is normal (the target project is the source project here) or if I have configured something incorrectly.
