Our (website) translation infrastructure has a pretty high barrier for new translators, especially those who are not familiar with Git and/or the command line. Furthermore, the current process makes it hard to add new languages, as often a team cannot be built easily over a long period of time and a web interface could nevertheless help keep translations until a new person arrives.

Corresponding ticket: #9049


  • provide a usable easy web interface
  • be usable from Tor Browser
  • automatic pull from main Git repo
  • provide a common glossary for each language, easy to use and improve
  • allow translators to view, in the correct order, all strings that come from the entire page being translated, both in English and in the target language
  • make it easy to view the translations in context i.e. when translating an entire page, all strings to be translated should only come from this page. translators should be able to view the page in context.
  • provide user roles (admin, reviewer, translator)


  • be "privacy sensitive", i.e. be operated by a non-profit
  • allow translators to push translations through Git (so that core developers only have to fetch reviewed translations from there)
  • provide support for Git standard development branches (devel, stable, and testing) but we could also agree upon translation only master through this interface
  • provide checks for inconsistent translations
  • provide feature to write/read comments between translators


  • allow translating topic branches without confusing translators, causing duplicate/premature work, fragmentation or merge conflicts -- e.g. present only new or updated strings in topic branches; see https://mailman.boum.org/pipermail/tails-l10n/2015-March/002102.html for details
  • provide a feature to easily see what is new, what needs updating, what are translation priorities
  • provide possibility to set up new languages easily
  • send email notifications
    • to reviewers whenever new strings have been translated or updated
    • to translators whenever a resource is updated
  • respect authorship (different committers?)
  • provide statistics about the percentage of translated and fuzzy strings
  • Letting translators report about problems in original strings, e.g. with a "Report a problem in the original English text" link, that e.g. results in an email being sent to -l10n@ or -support-private@. If we don't have that, then translate MUST document how to report issues in the original English text.

Weblate setup

We are testing a weblate instance to see if it fits our requirements. Read #11759 for more information.

There are several languages enabled and users can suggest translations in several languages:

Translation status

What we plan to do is:

Schematics of the different Git repos, ikiwiki instances, and their relationships.


Currently the repo is following Tails master repo, but the changes generated in translate.lizard are not fed back onto Tails master automatically.

There are several languages enabled, some of them with few or not translations.

You can check out weblate-generated Tails repo with:

git clone https://translate.tails.boum.org/git/tails/index/

This Tails repository has two main differences with other repos:

  • The ikiwiki.setup file has been changed to build more languages
  • There is a .gitlab.yml file to trigger tests when pushed to gitlab CI enabled repositories
  • There are lots of new language files

Reviewing translation platform output

For languages like fr, fa, de, or it that are part of tails master repo, you can get the files to review and submit to tails-l10n:

git remote add translations https://translate.tails.boum.org/git/tails/index/
git checkout tails/master
find . -name '*.fa.po' -exec git checkout translations/master --  {} \;
git reset *

And you will have all the changes to farsi (*.fa.po) to review. The same goes for the other languages.

Staging version

From this repository, a version of the website with more languages will be built #12311 so users can see how the file they are translating looks.

Updating the repo

PO files for enabled languages are built from the mdwn files when building the wiki.

This process is currently done outside of the weblate instance, and merged onto weblate repo by hand. As translate.lizard has so many languages, if there are many changes this process can take a while.

The machine currently doing this work can also provide a staging website, as it is the result of the building of the wiki anyway.

The changes generated while building the wiki can be fed back to weblate by cherry picking.