Kontinuierliche Lokalisierung¶

Es gibt eine Infrastruktur, die dafür sorgt, dass Ihre Übersetzung genau der Entwicklung folgt. Auf diese Weise können die Übersetzer die ganze Zeit an den Übersetzungen arbeiten, anstatt kurz vor der Veröffentlichung eine große Menge an neuem Text durchzuarbeiten.

Siehe auch

Integration mit Weblate beschreibt grundlegende Möglichkeiten zur Integration Ihrer Entwicklung mit Weblate.

Dies ist der Prozess:

Die Entwickler nehmen Änderungen vor und pushen sie in das VCS-Repository.
Optional werden die Übersetzungsdateien aktualisiert, siehe Einführen neuer Zeichenketten.
Weblate zieht Änderungen aus dem VCS-Repository, analysiert Übersetzungsdateien und aktualisiert seine Datenbank, siehe Repositorys aktualisieren.
Übersetzer übermitteln ihre Übersetzungen über die Weblate-Weboberfläche oder laden Änderungen offline hoch.
Sobald die Übersetzer fertig sind, committet Weblate die Änderungen in das lokale Repository (siehe Lazy Commits).
Änderungen werden in das Upstream-Repository zurückgepusht (siehe Pushen von Änderungen aus Weblate).

Hinweis

Upstream-Code-Hosting ist nicht notwendig, Sie können Weblate mit Lokale Dateien verwenden, bei dem es nur das Repository innerhalb von Weblate gibt.

Repositorys aktualisieren¶

Sie sollten eine Möglichkeit einrichten, Backend-Repositorys von ihrer Quelle aus zu aktualisieren.

Verwenden Sie Benachrichtigungs-Hooks zur Integration mit den meisten gängigen Code-Hosting-Diensten:
Sie müssen auch Hooks aktivieren, damit dies funktioniert.
Manuelles Auslösen der Aktualisierung entweder in der Repository-Verwaltung oder mit Weblates REST-API oder Weblate-Client
Aktivieren Sie AUTO_UPDATE, um alle Komponenten in Ihrer Weblate-Installation automatisch zu aktualisieren
Führen Sie updategit aus (mit Auswahl des Projekts oder --all, um alle zu aktualisieren)

Wann immer Weblate das Repository aktualisiert, werden die Post-Update-Erweiterungen ausgelöst, siehe Erweiterungen.

Vermeiden von Merge-Konflikten¶

Die Merge-Konflikte von Weblate entstehen, wenn dieselbe Datei sowohl in Weblate als auch außerhalb von Weblate geändert wurde. Je nach Situation gibt es mehrere Ansätze, die hier helfen können:

Vermeiden von Merge-Konflikten durch Ändern der Übersetzungsdateien nur in Weblate
Vermeiden von Merge-Konflikten durch Sperren von Weblate bei Änderungen von extern
Vermeiden von Merge-Konflikten durch Konzentration auf Git-Operationen

Vermeiden von Merge-Konflikten durch Ändern der Übersetzungsdateien nur in Weblate¶

Bei einsprachigen Dateien ist es einfach, die Bearbeitung außerhalb von Weblate zu vermeiden – 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 Nachrichtenextraktion, um übersetzbare Dateien aus dem Quellcode zu erzeugen. In einigen Fällen kann dies in zwei Teile aufgeteilt werden:

Die Extraktion erzeugt eine Vorlage (zum Beispiel wird gettext POT mit xgettext erzeugt).
In einem weiteren Vorgang werden die Übersetzungen zusammengeführt (die gettext-PO-Dateien werden mit msgmerge aktualisiert).

Sie können den zweiten Schritt innerhalb von Weblate durchführen und es wird sichergestellt, dass alle anstehenden Änderungen vor diesem Vorgang berücksichtigt werden.

Vermeiden von Merge-Konflikten durch Sperren von Weblate bei Änderungen von extern¶

Wenn Sie Weblate so in Ihren Aktualisierungsprozess integrieren, dass Änderungen gelöscht werden, bevor die Dateien außerhalb von Weblate aktualisiert werden, können Sie Weblates REST-API verwenden, um Weblate zu zwingen, alle ausstehenden Änderungen zu pushen und die Übersetzung zu sperren, während man selbst Änderungen vornimmt.

Das Skript zur Durchführung von Aktualisierungen kann wie folgt aussehen:

# 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

Wenn Sie mehrere Komponenten haben, die sich dasselbe Repository teilen, müssen Sie sie alle separat sperren:

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

Bemerkung

Das Beispiel verwendet Weblate-Client, das eine Konfiguration (API-Schlüssel) benötigt, um Weblate aus der Ferne steuern zu können. Sie können dies auch mit einem beliebigen HTTP-Client anstelle von Weblate-Client erreichen, zum Beispiel mit curl, siehe Weblates REST-API.

Vermeiden von Merge-Konflikten durch Konzentration auf Git-Operationen¶

Selbst wenn Weblate die einzige Quelle der Änderungen in den Übersetzungsdateien ist, können Konflikte auftreten, wenn die Erweiterung Git-Commits zusammenfassen verwendet wird, Git-Strategie auf Rebase konfiguriert ist oder Sie Commits außerhalb von Weblate zusammenfassen (z. B. beim Zusammenführen eines Pull Requests).

Der Grund für Merge-Konflikte ist in diesem Fall ein anderer – es gibt Änderungen in Weblate, die nach dem Zusammenführen von Weblate-Commits entstanden sind. Das passiert typischerweise, wenn das Zusammenführen nicht automatisiert ist und man Tage oder Wochen wartet, bis eine Person die Änderungen überprüft. Git ist dann manchmal nicht mehr in der Lage, die Upstream-Änderungen mit den Weblate-Änderungen abzugleichen und weigert sich, eine Umbasierung durchzuführen.

Um dies zu erreichen, müssen Sie entweder die Anzahl der ausstehenden Änderungen in Weblate minimieren, wenn Sie ein Pull Request zusammenführen, oder die Konflikte komplett vermeiden, indem Sie keine Änderungen zusammenfassen.

Hier sind einige Möglichkeiten, um dies zu vermeiden:

Weder Git-Commits zusammenfassen verwenden noch Zusammenfassen zum Merge-Zeitpunkt . Dies ist die Hauptursache dafür, dass Git Änderungen nach dem Zusammenführen nicht erkennt.
Weblate die ausstehenden Änderungen vor dem Zusammenführen committen lassen. Dadurch wird der Pull Request mit allen Änderungen aktualisiert, und beide Repositorys sind synchronisiert.
Die Überprüfungsfunktionen in Weblate nutzen (siehe Übersetzungsabläufe), so dass GitHub-Pull-Requests automatisch zusammengeführt werden können, nachdem die CI durchgelaufen ist.
Das Sperren in Weblate verwenden, um Änderungen während eines zu überprüfenden Github-Pull-Requests zu vermeiden.

Siehe auch

Weblate-Client

Automatischer Empfang von Änderungen aus GitHub¶

Weblate bietet native Unterstützung für GitHub.

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

Um Benachrichtigungen über jeden Push an ein GitHub-Repository zu erhalten, fügen Sie den Weblate-Webhook in den Repository-Einstellungen hinzu (Webhooks), wie auf dem Bild unten gezeigt:

Die Payload URL besteht aus Ihrer Weblate-URL, an die /hooks/github/ angehängt wird, für den Hosted-Weblate-Dienst ist dies zum Beispiel https://hosted.weblate.org/hooks/github/.

Sie können die anderen Werte auf den Standardeinstellungen belassen (Weblate kann beide Inhaltstypen verarbeiten und verwendet nur das push-Ereignis).

Siehe auch

POST /hooks/github/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus Bitbucket¶

Weblate unterstützt Bitbucket-Webhooks. Fügen Sie einen Webhook, der bei einem Repository-Push ausgelöst wird, mit der Ziel-URL /hooks/bitbucket/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/bitbucket/).

Siehe auch

POST /hooks/bitbucket/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus GitLab¶

Weblate unterstützt GitLab-Hooks. Fügen Sie einen Projekt-Webhook mit der Ziel-URL /hooks/gitlab/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/gitlab/).

Siehe auch

POST /hooks/gitlab/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus Pagure¶

Weblate unterstützt Pagure-Hooks. Fügen Sie einen Webhook mit der Ziel-URL /hooks/pagure/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/pagure/). Dies kann in Activate Web-hooks unter Project options erfolgen:

Siehe auch

POST /hooks/pagure/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus Azure Repos¶

Weblate unterstützt Azure-Repos-Webhooks. Fügen Sie einen Webhook für das Ereignis Code pushed mit der Ziel-URL /hooks/azure/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/azure/). Dies kann in Service hooks unter Project settings erfolgen.

Siehe auch

Webhooks im Azure-DevOps-Handbuch, POST /hooks/azure/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus Gitea Repos¶

Weblate unterstützt für Gitea-Webhooks. Fügen Sie einen Gitea Webhook für das Push events-Ereignis mit der Ziel-URL /hooks/gitea/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/gitea/). Dies kann in Webhooks unter Repository Settings erfolgen.

Siehe auch

Webhooks im Gitea-Handbuch, POST /hooks/gitea/, Zugriff auf Repositorys über Hosted Weblate

Automatischer Empfang von Änderungen aus Gitee Repos¶

Weblate unterstützt Gitee-Webhooks. Fügen Sie einen WebHook für das Push-Ereignis mit der Ziel-URL /hooks/gitee/ auf Ihrer Weblate-Installation hinzu (zum Beispiel https://hosted.weblate.org/hooks/gitee/). Dies kann in WebHooks unter Repository Management erfolgen.

Siehe auch

Webhooks im Gitee-Handbuch, POST /hooks/gitee/, Zugriff auf Repositorys über Hosted Weblate

Automatische nächtliche Aktualisierung der Repositorys¶

Weblate ruft automatisch jede Nacht Remote-Repositorys ab, um die Leistung beim späteren Zusammenführen von Änderungen zu verbessern. Optional können Sie dies auch in nächtliche Zusammenführungen umwandeln, indem Sie AUTO_UPDATE aktivieren.

Pushen von Änderungen aus Weblate¶

Für jede Übersetzungskomponente kann eine Push-URL eingerichtet werden (siehe Repository-Push-URL) und in diesem Fall kann Weblate Änderungen an das Remote-Repository weiterleiten. Weblate kann auch so konfiguriert werden, dass Änderungen automatisch bei jedem Commit gepusht werden (dies ist die Voreinstellung, siehe Bei Commit gleichzeitig Pushen). Wenn Änderungen nicht automatisch gepusht werden sollen, können Sie dies manuell unter Repository-Wartung oder über die API per wlc push tun.

Die Push-Optionen unterscheiden sich je nach dem verwendeten Integration der Versionsverwaltung, weitere Einzelheiten finden Sie in diesem Kapitel.

Für den Fall, dass Sie keine direkten Pushes durch Weblate wünschen, gibt es Unterstützung für Pull Requests von GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Pagure-Merge-Requests, Azure-DevOps-Pull-Requests oder Gerrit-Reviews. Sie können diese aktivieren, indem Sie GitHub, GitLab, Gitea, Gerrit, Azure DevOps, oder Pagure als Versionsverwaltung in Komponentenkonfiguration auswählen.

Insgesamt stehen mit Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center und Bitbucket Cloud folgende Optionen zur Verfügung:

Gewünschte Einrichtung	Versionsverwaltung	Repository-Push-URL	Push-Branch
Kein Push	Git	leer	leer
Direkt pushen	Git	SSH-URL	leer
Push zu separatem Branch	Git	SSH-URL	Name des Branches
Kein Push	Mercurial	leer	leer
Direkt pushen	Mercurial	SSH-URL	leer
Push zu separatem Branch	Mercurial	SSH-URL	Name des Branches
GitHub-Pull-Request vom Fork	GitHub-Pull-Requests	leer	leer
GitHub-Pull-Request vom Branch	GitHub-Pull-Requests	SSH-URL [1]	Name des Branches
GitLab-Merge-Request vom Fork	GitLab-Merge-Requests	leer	leer
GitLab-Merge-Request vom Branch	GitLab-Merge-Requests	SSH-URL [1]	Name des Branches
Gitea-Merge-Request vom Fork	Gitea-Pull-Requests	leer	leer
Gitea-Merge-Request vom Branch	Gitea-Pull-Requests	SSH-URL [1]	Name des Branches
Pagure-Merge-Request vom Fork	Pagure-Merge-Requests	leer	leer
Pagure-Merge-Request vom Branch	Pagure-Merge-Requests	SSH-URL [1]	Name des Branches
Azure-DevOps-Pull-Request vom Fork	Azure-DevOps-Pull-Requests	leer	leer
Azure-DevOps-Pull-Request vom Branch	Azure-DevOps-Pull-Requests	SSH-URL [1]	Name des Branches
Bitbucket-Data-Center-Pull-Request vom Fork	Bitbucket-Data-Center-Pull-Requests	leer	leer
Bitbucket-Data-Center-Pull-Request vom Branch	Bitbucket-Data-Center-Pull-Requests	SSH-URL [1]	Name des Branches
Bitbucket-Cloud-Pull-Request vom Fork	Bitbucket-Cloud-Pull-Requests	leer	leer
Bitbucket-Cloud-Pull-Request vom Branch	Bitbucket-Cloud-Pull-Requests	SSH-URL [1]	Name des Branches

Bemerkung

Sie können auch das automatische Pushen von Änderungen nach Weblate-Commits aktivieren, dies kann in Bei Commit gleichzeitig Pushen erfolgen.

Siehe auch

Siehe Zugriff auf Repositorys für die Einrichtung von SSH-Schlüsseln und Lazy Commits für Informationen darüber, wann Weblate entscheidet, Änderungen zu committen.

Geschützte Branches¶

Wenn Sie Weblate auf einem geschützten Branch verwenden, können Sie es so konfigurieren, dass es Pull Requests verwendet und die Übersetzungen tatsächlich überprüft (was bei Sprachen, die Sie nicht kennen, problematisch sein könnte). Ein alternativer Ansatz besteht darin, diese Einschränkung für den Weblate-Push-Nutzer aufzuheben.

Auf GitHub kann dies zum Beispiel in der Repository-Konfiguration erfolgen:

Mit anderen interagieren¶

Weblate macht es einfach, mit anderen über seine API zu interagieren.

Siehe auch

Weblates REST-API

Lazy Commits¶

Weblate fasst Commits desselben Autors nach Möglichkeit in einem Commit zusammen. Dadurch wird die Anzahl der Commits stark reduziert, allerdings müssen Sie es eventuell explizit anweisen, die Commits durchzuführen, wenn Sie das VCS-Repository synchronisieren möchten, zum Beispiel für Merge (dies ist standardmäßig für die Gruppe Manager erlaubt, siehe Liste der Berechtigungen).

Die Änderungen in diesem Modus werden committet, sobald eine der folgenden Bedingungen erfüllt ist:

Jemand anderes ändert eine bereits geänderte Zeichenkette.
Es erfolgt ein Merge von Upstream.
Ein expliziter Commit wird angefordert.
Ein Dateidownload ist angefordert.
Die Änderung ist älter als der in Alter der Änderungen, bis ein Commit erfolgt definierte Zeitraum unter Komponentenkonfiguration.

Hinweis

Commits werden für jede Komponente erstellt. Wenn Sie also viele Komponenten haben, werden Sie trotzdem viele Commits sehen. In diesem Fall können Sie die Erweiterung Git-Commits zusammenfassen verwenden.

Wenn Sie Änderungen häufiger und ohne Überprüfen des Alters committen möchten, können Sie eine regelmäßige Aufgabe für das Ausführen eines Commits planen. Dies kann mit Periodic Tasks in der Django-Adminoberfläche erfolgen. Legen Sie zunächst das gewünschte Interval fest (zum Beispiel 120 Sekunden). Fügen Sie dann eine neue periodische Aufgabe hinzu und wählen Sie weblate.trans.tasks.commit_pending als Task mit {"hours": 0} als Keyword Arguments und dem gewünschten Intervall.

Repository mit Skripten verarbeiten¶

Die Art und Weise, wie Weblate mit dem Repository interagiert, kann mit Erweiterungen angepasst werden. Konsultieren Sie Ausführen von Skripten der Erweiterung für Informationen darüber, wie man externe Skripte durch Erweiterungen ausführt.

Übersetzungen aller Komponenten gleich halten¶

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.

Übersetzungsweitergabe¶

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

Bemerkung

Die Übersetzungsweitergabe erfordert, dass der Schlüssel mit einsprachigen Übersetzungsformaten übereinstimmt, daher sollten Sie dies bei der Erstellung von Übersetzungsschlüsseln berücksichtigen.

Konsistenzprüfung¶

Die Prüfung Inkonsistent wird immer dann ausgelöst, wenn die Zeichenketten unterschiedlich sind. Sie können dies nutzen, um solche Unterschiede manuell zu überprüfen und die richtige Übersetzung auszuwählen.

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).