Kontinuierliche Lokalisierung

There is infrastructure in place so that your translation closely follows development. This way translators can work on translations the entire time, instead of working through huge amount of new text just prior to release.

Siehe auch

Integrating with Weblate describes basic ways to integrate your development with Weblate.

This is the process:

Developers make changes and push them to the VCS repository.
Optionally the translation files are updated (this depends on the file format, see Why does Weblate still show old translation strings when I’ve updated the template?).
Weblate pulls changes from the VCS repository, see Updating repositories.
Once Weblate detects changes in translations, translators are notified based on their subscription settings.
Translators submit translations using the Weblate web interface, or upload offline changes.
Once the translators are finished, Weblate commits the changes to the local repository (see Lazy commits) and pushes them back if it has permissions to do so (see Pushing changes from Weblate).

Updating repositories

You should set up some way of updating backend repositories from their source.

Use Benachrichtigungs-Hooks to integrate with most of common code hosting services:
Manually trigger update either in the repository management or using Weblate’s REST API or Weblate Client
Enable AUTO_UPDATE to automatically update all components on your Weblate instance
Execute updategit (with selection of project or --all to update all)

Whenever Weblate updates the repository, the post-update addons will be triggered, see Erweiterungen.

Avoiding merge conflicts

Die Merge-Konflikte von Weblate entstehen, wenn dieselbe Datei sowohl in Weblate als auch außerhalb von Weblate geändert wurde. Es gibt zwei Möglichkeiten, damit umzugehen: Entweder Sie vermeiden Bearbeitungen außerhalb von Weblate oder Sie integrieren Weblate in Ihren Aktualisierungsprozess, so dass die Änderungen vor der Aktualisierung der Dateien außerhalb von Weblate geleert werden.

Der erste Ansatz ist bei einsprachigen Dateien einfach - Sie können neue Zeichenketten innerhalb von Weblate hinzufügen und die gesamte Bearbeitung der Dateien dort belassen. Für zweisprachige Dateien gibt es in der Regel eine Art von Nachrichtenextraktionsprozess, um übersetzbare Dateien aus dem Quellcode zu erzeugen. In manchen Fällen kann dies in zwei Teile aufgeteilt werden - einer für die Extraktion erzeugt eine Vorlage (z.B. gettext POT wird mit xgettext erzeugt) und ein weiterer Prozess fügt sie in die tatsächlichen Übersetzungen ein (die gettext PO-Dateien werden mit msgmerge aktualisiert). Sie können den zweiten Schritt innerhalb von Weblate durchführen. Weblate sorgt dafür, dass alle anstehenden Änderungen vor diesem Vorgang berücksichtigt werden.

Der zweite Ansatz kann erreicht werden, indem man Weblate’s REST API verwendet, um Weblate zu zwingen, alle anstehenden Änderungen zu pushen und die Übersetzung zu sperren, während man selbst Änderungen vornimmt.

The script for doing updates can look like this:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

If you have multiple components sharing same repository, you need to lock them all separately:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Bemerkung

The example uses Weblate Client, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of wlc, e.g. curl, see Weblate’s REST API.

Siehe auch

Weblate Client

Automatically receiving changes from GitHub

Weblate comes with native support for GitHub.

Wenn Sie Hosted Weblate verwenden, empfiehlt es sich, die Weblate-App zu installieren, damit Sie die korrekte Einrichtung erhalten, ohne viel einrichten zu müssen. Sie kann auch zum Zurückschieben von Änderungen verwendet werden.

To receive notifications on every push to a GitHub repository, add the Weblate Webhook in the repository settings (Webhooks) as shown on the image below:

For the payload URL, append /hooks/github/ to your Weblate URL, for example for the Hosted Weblate service, this is https://hosted.weblate.org/hooks/github/.

You can leave other values at default settings (Weblate can handle both content types and consumes just the push event).

Siehe auch

POST /hooks/github/, Accessing repositories from Hosted Weblate

Automatically receiving changes from Bitbucket

Weblate has support for Bitbucket webhooks, add a webhook which triggers upon repository push, with destination to /hooks/bitbucket/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/bitbucket/).

Siehe auch

POST /hooks/bitbucket/, Accessing repositories from Hosted Weblate

Automatically receiving changes from GitLab

Weblate has support for GitLab hooks, add a project webhook with destination to /hooks/gitlab/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/gitlab/).

Siehe auch

POST /hooks/gitlab/, Accessing repositories from Hosted Weblate

Automatically receiving changes from Pagure

Neu in Version 3.3.

Weblate has support for Pagure hooks, add a webhook with destination to /hooks/pagure/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/pagure/). This can be done in Activate Web-hooks under Project options:

Siehe auch

POST /hooks/pagure/, Accessing repositories from Hosted Weblate

Automatically receiving changes from Azure Repos

Neu in Version 3.8.

Weblate has support for Azure Repos web hooks, add a webhook for Code pushed event with destination to /hooks/azure/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/azure/). This can be done in Service hooks under Project settings.

Siehe auch

Web hooks in Azure DevOps manual, POST /hooks/azure/, Accessing repositories from Hosted Weblate

Automatically receiving changes from Gitea Repos

Neu in Version 3.9.

Weblate has support for Gitea webhooks, add a Gitea Webhook for Push events event with destination to /hooks/gitea/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/gitea/). This can be done in Webhooks under repository Settings.

Siehe auch

Webhooks in Gitea manual, POST /hooks/gitea/, Accessing repositories from Hosted Weblate

Automatically receiving changes from Gitee Repos

Neu in Version 3.9.

Weblate has support for Gitee webhooks, add a WebHook for Push event with destination to /hooks/gitee/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/gitee/). This can be done in WebHooks under repository Management.

Siehe auch

Webhooks in Gitee manual, POST /hooks/gitee/, Accessing repositories from Hosted Weblate

Automatically updating repositories nightly

Weblate automatically fetches remote repositories nightly to improve performance when merging changes later. You can optionally turn this into doing nightly merges as well, by enabling AUTO_UPDATE.

Pushing changes from Weblate

Each translation component can have a push URL set up (see Push-URL für Repository), and in that case Weblate will be able to push change to the remote repository. Weblate can be also be configured to automatically push changes on every commit (this is default, see Bei Commit gleichzeitig Pushen). If you do not want changes to be pushed automatically, you can do that manually under Repository maintenance or using API via wlc push.

The push options differ based on the Integration der Versionsverwaltung used, more details are found in that chapter.

In case you do not want direct pushes by Weblate, there is support for GitHub-Pull-Anfragen, GitLab Merge Requests, Gitea pull requests, Pagure Merge Requests pull requests or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit or Pagure as Versionsverwaltung in Component configuration.

Overall, following options are available with Git, GitHub and GitLab:

Desired setup	Versionsverwaltung	Push-URL für Repository	Push Branch
No push	Git	empty	empty
Push directly	Git	SSH URL	empty
Push zu separatem Branch	Git	SSH URL	Branch name
GitHub pull request from fork	GitHub-Pull-Anfragen	empty	empty
GitHub pull request from branch	GitHub-Pull-Anfragen	SSH URL 1	Branch name
GitLab merge request from fork	GitLab Merge Requests	empty	empty
GitLab merge request from branch	GitLab Merge Requests	SSH URL 1	Branch name
Gitea merge request from fork	Gitea pull requests	empty	empty
Gitea merge request from branch	Gitea pull requests	SSH URL 1	Branch name
Pagure merge request from fork	Pagure Merge Requests	empty	empty
Pagure merge request from branch	Pagure Merge Requests	SSH URL 1	Branch name

1(1,2,3,4): Can be empty in case Quellcode-Repository supports pushing.

Bemerkung

You can also enable automatic pushing of changes after Weblate commits, this can be done in Bei Commit gleichzeitig Pushen.

Siehe auch

See Accessing repositories for setting up SSH keys, and Lazy commits for info about when Weblate decides to commit changes.

Protected branches

If you are using Weblate on protected branch, you can configure it to use pull requests and perform actual review on the translations (what might be problematic for languages you do not know). An alternative approach is to waive this limitation for the Weblate push user.

For example on GitHub this can be done in the repository configuration:

Interacting with others

Weblate makes it easy to interact with others using its API.

Siehe auch

Weblate’s REST API

Lazy commits

The behaviour of Weblate is to group commits from the same author into one commit if possible. This greatly reduces the number of commits, however you might need to explicitly tell it to do the commits in case you want to get the VCS repository in sync, e.g. for merge (this is by default allowed for the Managers group, see Liste der Berechtigungen und integrierten Rollen).

The changes in this mode are committed once any of the following conditions are fulfilled:

Somebody else changes an already changed string.
A merge from upstream occurs.
An explicit commit is requested.
A file download is requested.
Change is older than period defined as Alter der Änderungen, das erreicht sein muss, bevor ein Commit erfolgt on Component configuration.

Hinweis

Commits are created for every component. So in case you have many components you will still see lot of commits. You might utilize Git-Commits konsolidieren add-on in that case.

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit:

CELERY_BEAT_SCHEDULE = {
    # Unconditionally commit all changes every 2 minutes
    "commit": {
        "task": "weblate.trans.tasks.commit_pending",
        # Omitting hours will honor per component settings,
        # otherwise components with no changes older than this
        # won't be committed
        "kwargs": {"hours": 0},
        # How frequently to execute the job in seconds
        "schedule": 120,
    }
}

Processing repository with scripts

The way to customize how Weblate interacts with the repository is Erweiterungen. Consult Ausführen von Skripten der Erweiterung for info on how to execute external scripts through add-ons.

Keeping translations same across components

Wenn Sie mehrere Übersetzungskomponenten haben, möchten Sie möglicherweise sicherstellen, dass die selben Zeichenketten dieselbe Übersetzung haben. Dies kann auf mehreren Ebenen erreicht werden.

Translation propagation

Wenn Verbreitung von Übersetzungen erlauben aktiviert ist (was die Voreinstellung ist, siehe Component configuration), werden alle neuen Übersetzungen automatisch in allen Komponenten mit übereinstimmenden Zeichenketten durchgeführt. Solche Übersetzungen werden dem aktuell übersetzenden Benutzer in allen Komponenten korrekt gutgeschrieben.

Bemerkung

The translation propagation requires the key to be match for monolingual translation formats, so keep that in mind when creating translation keys.

Consistency check

The Inkonsistent check fires whenever the strings are different. You can utilize this to review such differences manually and choose the right translation.

Automatische Übersetzung

Die automatische Übersetzung basierend auf verschiedenen Komponenten kann eine Möglichkeit sein, die Übersetzungen zwischen den Komponenten zu synchronisieren. Sie können es entweder manuell auslösen (siehe Automatische Übersetzung) oder es automatisch bei der Aktualisierung des Repositorys mit Hilfe einer Erweiterung laufen lassen (siehe Automatische Übersetzung).