From Fedora Project Wiki

< Changes

Revision as of 17:38, 4 January 2021 by Bcotton (talk | contribs) (Announcing the Change proposal)

Localization measurement and tooling


Provide a public website for end users and contributors, containing Fedora Workstation translation progress and useful files for translators (as an example: translation memories).


Current status

  • Targeted release: Fedora 34
  • Last updated: 2021-01-04
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Language support is a transversal activity, there is no way to know the actual language support provided by Fedora as an Operating System.

Because language support and translations are part of each upstream software, the Linux language community is as spread as the Free Libre and Open Source community is.

The ability to share efforts is limited (with data, tools, etc.):

  • because of the complexity to get an overview of the current localization status of the Linux community,
  • because translators often have a low level of technical knowledge,
  • because development experts are more keen to use English by default, and don't know much about languages support requirements.

Debian did something similar (20 years ago) . But this work:

  • is limited in terms of features (no translation memories there)
  • is too deeply integrated with Debian infrastructure (data extraction, computation and website generation are 100% debian specific)
  • is using a programming language that doesn't allow to share easily with existing i18n/l10n libraries (it did not exist 20 years ago)


Benefit to Fedora

It is a progress for the project: provide a new tool to translator community.

It helps the Linux community to better understand the language support challenges.

It increases contributors effectiveness by providing translation memories and other tools.

These translation memories open new possibilities:

  • to train machines to suggest new translations?
  • to detect quality issues (spellcheck, linters, etc)?
  • the change the way we ship translations to users? (Ubuntu does it, but never bring back translation to main project)
  • to advertise user that Linux is available in many languages?


All of the work is isolated, as long as dnf works, the automation works. The closer to mirror the cheaper it is for network cost (all Fedora is downloaded at each execution).

  • Proposal owners:
    • Francois Andrieu integrate the existing scripts into containers to allow execution into openshift
    • Infra team:
      • provide some space for script execution (50 GB per release)
      • provide the domain name
      • provide a location for static website (about 2 GB per release, may increase over time)
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with mission: In our community, contributors of all kinds come together to advance the ecosystem for the benefit of everyone.


Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience


N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product


A draft with simplistic template is there:

Code and "documentation" are there:

About other project:

Release Notes