So we’re now getting much, much closer to a release of Ardour 7.0. We’re not yet in a total string freeze (where we guarantee not to change any translatable text at all before release), but realistically we’re not far from that. To avoid translations delaying the release and/or not being available for the new version, it’s probably a good time for the translation team(s) to start working on the update for 7.0.
Currently Ardour translations for Czech, German, Greek, Spanish, UK English, French, Italian, Japanese, Korean, Norwegian, Polish, Portugese (Brazilian and Portugese versions), Russian, Swedish and Chinese. If you’d like to add another language, you can find the instructions for creating (and maintaining) translations here:
If you’re an existing translator for one of the above languages, please try to find the time to go through the update process as soon as possible. Your work is much appreciated, and we’d like to have as many languages updated as possible before the 7.0 release.
My 2 cents: As a professional translator, this looks like a horrible workflow to me.
If I get jobs, there is always a well working web localization tool (CAT) to work with. Like XTM, memsource, weblate (self-hostable) and many others.
Maybe it’s worth to install something for a better (faster, more easy usable) workflow, if you want free contributions. Many open source projects relate on a CAT. And they are often easy to use for not so advanced users.
We have looked at a few web-centric localization workflows, and at the time, although they were shinier and easier to use for someone who had never done anything like this before, they seemed to have several downsides compared to this “historical” workflow.
Personally, I’m agnostic about such matters, given that I’m not a translator. We also don’t have any one around who has ever volunteered to set up a workflow that would ultimately generate the .mo files that we need a run time. If that happened, I wouldn’t argue against it.