Translations are available on Hosted Weblate at the following URL:

Registered users may contribute to the existing languages, or request a new language translations.

Translating using Weblate

Weblate offers a simple and easy to use interface featuring glossary, machine translation, suggestions based on similar translations in other projects, automatic checks etc. Weblate imports the source code tree directly from the version control system, and commits edits back from time to time.

When registering at Weblate, make sure you use the name and email address you prefer to be used when your changes are committed. We can and probably will amend changesets coming from Weblate, but having things right from the beginning makes things easier.

Weblate performs sanity checks all the time and tries to prevent you from ignoring them. Most common mistakes are inconsistent punctuation, whitespace, missing or extra format parameters, untranslated strings copied into the translation. Please perform necessary corrections when they’re needed, or override the false positives.

Merging translations from Weblate (admin-only)

Weblate rebases its changes every time it pulls from our repository. Pulls are triggered by a web hook from Our Own Kallithea every time it receives new commits. Usually merging the new translations is a straightforward process consisting of a pull from the Weblate-hosted repository which is available under the Data Exports tab in the Weblate interface.

Weblate tries to minimise the number of commits, but that doesn’t always work, especially when two translators work with different languages at more or less the same time. It makes sense sometimes to re-order or fold commits by the same author when they touch just the same language translation. That, however, may confuse Weblate sometimes, in which case it should be manually convinced it has to discard the commits it created by using its administrative interface.

Regenerating translatations after source code changes (admin-only)

When the Kallithea source code changes, both the location as the content of translation strings can change. It is therefore necessary to regularly regenerate the kallithea.pot file containing these strings, as well as aligning the translation files (*.po).

First update the translation strings:

python2 extract_messages

Then regenerate the translation files. This could either be done with python2 update_catalog or with msgmerge from the gettext package. As Weblate is also touching these translation files, it is preferred to use the same tools (msgmerge) and settings as Weblate to minimize the diff:

find kallithea/i18n -name kallithea.po | xargs -I '{}' \
    msgmerge --width=76 --backup=none --previous --update '{}' \

Manual creation of a new language translation

In the prepared development environment, run the following to ensure all translation strings are extracted and up-to-date:

python2 extract_messages

Create new language by executing following command:

python2 init_catalog -l <new_language_code>

This creates a new translation under directory kallithea/i18n/<new_language_code> based on the translation template file, kallithea/i18n/kallithea.pot.

Edit the new PO file located in LC_MESSAGES directory with poedit or your favorite PO files editor. After you finished with the translations, check the translation file for errors by executing:

msgfmt -f -c kallithea/i18n/<new_language_code>/LC_MESSAGES/<updated_file.po>

Finally, compile the translations:

python2 compile_catalog -l <new_language_code>

Manually updating translations

Extract the latest versions of strings for translation by running:

python2 extract_messages

Update the PO file by doing:

python2 update_catalog -l <new_language_code>

Edit the newly updated translation file. Repeat all steps after the init_catalog step from the ‘new translation’ instructions above.

Testing translations

Edit kallithea/tests/ and set i18n.lang to <new_language_code> and run Kallithea tests by executing: