Skip to content

rhinstaller/translation-canary

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

38 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

translation-canary

Translations can crash your program. Creating software for a wide audience means sending your strings away for translation, and giving up control of your strings means that strings with extralinguistic content can come back broken. No one is likely to even realize it until someone fires up your program in Hungarian and it crashes because Gtk bombed out on some busted markup, and the Hungarian speaker is sad, and you are sad, and everything is just the absolute worst.

This is the canary in the translation coalmine.

There are two parts to this project:

translatable:
This contains checks on the strings to be submitted for translation. This ensures that the content of the original strings marked for translation are suitable for translation. These tests are run on the POT file before uploading the POT or the updated PO files to the translators.
translated:
This contains checks on the strings returned from the translators. This ensures that the content of the translated strings won't break anything. These tests are run on the source directory before creating a release.

Both translatable and translated are run by running the module (e.g., python3 -m translation_canary.translatable) with the input file(s) as the argument.

In addition to the python modules, this project contains xgettext_werror.sh, a wrapper for xgettext that treats warnings as errors. xgettext will print warnings as it extracts translatable strings from source files, and these warnings should be addressed instead of silently ignored as they scroll by in the build output. To use the script in a package that uses the gettext template files from autopoint or gettextize, set XGETTEXT=/path/to/xgettext_werror.sh in Makevars.

Usage as a subtree

Anaconda and Blivet use translation canary as a git subtree. If you need to change the canary for these projects, follow these steps:

  1. Make changes and test them in the context of your project.

  2. Copy these changes to the translation-canary repo and make a pull request with these changes.

  3. After that PR is merged, go to Anaconda or Blivet repo root and run:

    dnf install git-subtree
    git subtree pull --prefix translation-canary/ [email protected]:rhinstaller/translation-canary.git master --squash
    

    This produces a squash commit with some ancient parent, and then also a merge commit that merges the squash commit into your current HEAD.

  4. Make a topic branch and PR for merging what you got into your project. For the purpose of making branches and PRs, the commits above are not special in any way.

Note: There is no way to detect subtree presence, it behaves as regular files and directories.

About

Tests for translated and translatable strings

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published