Summary and Details¶
- Releases - Translation Status
- Translation update volume estimation for a product release at an early stage of a release cycle. It has three views: combined, detailed and language-wise. Combined will sum up translated and untranslated for all languages for a package. Detailed contains language wise %age representation. Language-wise shows overall picture as well as translated, untranslated statistics of every package for each language.
- Packages - Translation Completeness
- Translation progress, gaps, errors of a package by syncing with source repositories, translation platforms and build systems. Package needs to get sync’d with all three to fill statistics. Stats are represented in tabular and graph forms, per language also. This shows translation trends of last few releases. Summary highlights out-of-sync packages.
- Translation Coverage
- Coverage of a group of packages for a specific release in associated or selected languages. These are based on graph rules. Packages must have branch mapping and respective sync done before they can participate in graph rule.
- Languages & their sets, translation platforms and release streams are grouped as inventory. One release stream can have multiple release branches. Like, Fedora is a release stream and Fedora 28, Fedora 29 are release branches. Inventory could be managed through admin panel. Sample data contains some of them. Inventory are basis to release branches, packages, jobs and graph rules. And hence probably the first thing to look at.
- Release Branch
- A particular release which has a schedule and information regarding in how many languages it will be available. Release branch are primary to branch mapping. A package associated with any of the release streams, automatically being tracked for all release branches underneath. One release branch can be associated with one language set.
- Translation progress would be tracked for added packages. They should have upstream repository URL and translation platform project URL. A package can be linked with multiple release streams and should have a branch mapping. Once all versions / tags are sync’d with respective sources, differences could be generated. Packages should be sync’d at intervals.
- Predefined Jobs
- Functions which are basis to fetch some essential data
- sync with translation platform for projects
- sync with release schedule to update calendar
- sync with build system for build tags
- required for branch mapping (this is one of the first steps)
Logs are kept.
- YAML Based Jobs
Currently, three templates are to choose from. They can be used as-is.
- clone package source repository, filter translation files and calculate statistics
- locate latest built SRPM, unpacks, filter translation files and calculate statistics
- clone package source repo, generates template (POT) as per given command, download respective template from platform and compare/find diff
- Requires four values:
- Package Name (derived stats can be saved only if this is added already)
- Build System (build system associated with added release stream)
- Build Tag (To fill drop down with build tags, run sync job for build tags)
- Release Slug (one can find this out on release page, at tooltip or in URL)
SyncDownstream could be run for any package (also for those not added in transtats) and for any build tag available. This makes the job really wonderful tool to inspect SRPM.
Dry runs are also supported. Each YAML job has a unique URL to see details and share!