Translation is an important step in software localization which helps make software more popular globally, and impacts international user experience. In recent years, localization processes have been evolving worldwide to become more continuous, faster, efficient with automation. In Fedora, the development of the Zanata platform and its plugins, then Transtats, and now the migration to the Weblate platform are part of this common ongoing goal. The localization of a desktop OS like Fedora is highly complex because it depends on many factors of the individual upstream projects which are packaged in Fedora. For example, different translation timelines, resources, and tooling.
What is Transtats?
Transtats is a web application which tries to tie up upstream repositories, translation platforms, build system, and product release schedule together to solve problems of mismatch, out-of-sync conditions and to assist the timely packaging of quality translations. Actually, it collects translation data, analyzes them, and creates meaningful representations.
Fedora Transtats is hosted at https://transtats.fedoraproject.org/
How to see the translation status of my package?
Just select Packages tab from left hand side navigation bar. This takes us to the packages list view. Then, search for the package and click on its name.
For example anaconda. On package details page, locate following:
Here, we have translation statistics from translation platform: Zanata and Koji build system. Syncs with the platform and build system are scheduled, which update differences periodically. Languages in red color indicate that there are translated strings remaining in the Translation Platform to be pulled and packaged, whereas, blue denote translated messages could not make 100% in the built package.
String breakage (or changes?)
In translation of software packages, one of the challenges is to prevent string breakage. Package maintainers should strive to abide by the scheduled Fedora release String Freeze. However, in some circumstances it could be necessary to break the string freeze and to inform the translation team on the mailing list. As well as, to update latest translation template (POT) file in the translation platform. Just in case these actions seem missing – translators may get new strings to translate very late or the application may have some strings untranslated. In the worst case, an outdated translation string mismatch may result in a crash. Sync and automation pipelines are there to prevent this, nevertheless it depends on the push or pull methods followed by package developers or maintainers.
To deal with the same context, we can use a job template in Transtats to detect this string change – particularly useful after string freeze in Fedora release schedule. This would be really helpful for the folks who look for packaging translations without string breakage, keeping translation template (POT) file in sync with translation platform, and testing localized form of the application for translation completeness to back trace.
How to detect string changes?
One of the options in Jobs tab is ‘YML based Jobs’. Where we can see available job templates.
The jobs framework executes all the tasks mentioned in the YAML, create appropriate logs and store results. Track String Change job basically:
- Clones the source repository of respective package.
- Tries to generate translation template (POT) file.
- Downloads POT file from respective translation platform.
- And, finds differences between both the POT files.
Actually, Transtats maintains mapping of upstream repository, Translation Platform project and respective build tag for every package.
Let’s take a closer look into this YAML. We can provide value for %PACKAGE_NAME% and %RELEASE_SLUG% in the next step – Set Values! For example: anaconda and fedora-32. Furthermore, a couple of things seek attention are:
- In case the upstream software repository maintains separate git branch for fedora release, please edit ‘branch: master’ to ‘branch: <fedora-release-branch>’
- In ‘generate’ block, mention the command to generate POT file. Default one should work for ‘intltool-update’ only, however, many packages do have their own.
- A few packages may have gettext domain name different than that of package name. If this is the case, mention the gettext domain too.
As soon as the job is triggered, logs should be populated. If this is not a scratch run, a unique URL shall also be created at the end.
Left hand side is the input YAML and right hand side is respective log for each task. Here we can find the differences and figure out string mismatch.
In Transtats, we can create solutions to different problems in the form of job templates. And, scheduling of these jobs could be a step towards automation.
Sandeep Shedmake
+1 to ‘string change’ detection, 👍
Tom215
I wish there would be some very easy and centralized way to do/review FOSS translations. Sort of a desktop program that would “talk” to all the repositories and different translation systems that different projects use and allow to, for example, just put a check-box near Nautilus when I see a mistake and start translating/reviewing/commenting it. Without applying, looking for team leaders, repositories, programs, separate TMs. Probably still with some centralized registration and reputation system.