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 describes basic ways to integrate your development with Weblate. Code-Hosting-Integrationen lists provider-specific setup steps for common code hosting sites.

Dies ist der Prozess:

  1. Die Entwickler nehmen Änderungen vor und pushen sie in das VCS-Repository.

  2. Optional werden die Übersetzungsdateien aktualisiert, siehe Neue Zeichenketten einführen.

  3. Weblate zieht Änderungen aus dem VCS-Repository, analysiert Übersetzungsdateien und aktualisiert seine Datenbank, siehe Repositorys aktualisieren.

  4. Übersetzer übermitteln ihre Übersetzungen über die Weblate-Weboberfläche oder laden Änderungen offline hoch.

  5. Sobald die Übersetzer fertig sind, committet Weblate die Änderungen in das lokale Repository (siehe Lazy Commits).

  6. Changes are pushed back to the upstream repository (see Änderungen aus Weblate pushen).

digraph translations { graph [fontname = "sans-serif", fontsize=10, ranksep=0.6, newrank=true]; node [fontname = "sans-serif", fontsize=10, margin=0.15]; edge [fontname = "sans-serif", fontsize=10]; subgraph cluster_codehosting { rank=same; graph [color=lightgrey, label="Upstream code hosting", style=filled ]; "VCS repository" [shape=cylinder]; } subgraph cluster_weblate { rank=same; graph [color=lightgrey, label="Weblate", style=filled ]; repo [label="Weblate repository", shape=cylinder]; database [label=Database, shape=cylinder]; } "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> repo [label=" 3. Pull "]; repo -> database [label=" 3. Parse translations "]; "database" -> repo [label=" 5. Commit changes "]; "Translators" -> "database" [label=" 4. Translate "]; "repo" -> "VCS repository" [label=" 6. Push repository "]; }

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.

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

Merge-Konflikte vermeiden

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:

Merge-Konflikte vermeiden 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:

  1. Die Extraktion erzeugt eine Vorlage (zum Beispiel wird gettext POT mit xgettext erzeugt).

  2. 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 ausstehenden Änderungen vor diesem Vorgang berücksichtigt werden.

Merge-Konflikte vermeiden 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.

Repository-Wartung

Die Ansicht Repository-Wartung zeigt den Repository-Status für ein Projekt, eine Komponente oder eine Übersetzung an und ermöglicht berechtigten Benutzern die Durchführung von Wartungsarbeiten über die Bedienoberfläche.

Die gleichen Aktionen können auch über Weblates REST-API oder, für die unterstützte Teilmenge, über den Weblate-Client ausgelöst werden.

Die Verfügbarkeit der einzelnen Aktionen hängt von den Berechtigungen, der konfigurierten Versionsverwaltung, der Konfiguration des Push-Vorgangs und davon ab, ob das ausgewählte Objekt gesperrt werden kann.

Aktion

Was es bewirkt

Typische Verwendung

Commit

Übernimmt die in Weblate gespeicherten ausstehenden Änderungen in das lokale Repository.

Ausstehende Weblate-Änderungen durchführen, vor dem Arbeiten an anderer Stelle im Repository.

Push

Überträgt die im lokalen Repository vorgenommenen Änderungen zum konfigurierten Upstream.

Vorgenommene Übersetzungen an Upstream senden, wenn das automatische Pushen deaktiviert ist oder sich verzögert.

Aktualisieren

Ruft Upstream-Änderungen ab und integriert sie mithilfe der für die Komponente konfigurierten Git-Strategie.

Weblate mithilfe der Standard-Integrationsstrategie mit Upstream synchronisieren.

Aktualisieren mit Zusammenführen (Merge)

Ruft Upstream-Änderungen ab und integriert sie mit einem expliziten Merge.

Den Standard-Merge-Stil für eine einzelne Aktualisierung überschreiben.

Aktualisieren mit Umbasieren (Rebase)

Ruft Upstream-Änderungen ab und basiert lokale Weblate-Commits auf Upstream um.

Den Verlauf linear halten, wenn dies Ihrem Arbeitsablauf entspricht.

Aktualisieren mit Zusammenführen (Merge) ohne Fast-Forward

Ruft Upstream-Änderungen ab und erstellt einen expliziten Merge-Commit, selbst wenn ein Fast-Forward möglich wäre.

Merge-Commits zu Auditzwecken oder Branch-Verwaltungsgründen aufbewahren.

Sperren / Entsperren

Verhindert oder erlaubt Übersetzern, weitere Änderungen in Weblate vorzunehmen.

Übersetzungsänderungen während der Repository-Wartung außerhalb von Weblate sperren.

Zurücksetzen und verwerfen

Setzt das lokale Repository von Weblate auf Upstream zurück und verwirft ausstehende Weblate-Änderungen.

Verwenden, wenn Upstream den lokalen Weblate-Repository-Status überschreiben soll.

Zurücksetzen und erneut anwenden

Setzt das lokale Weblate-Repository auf Upstream zurück, wobei ausstehende Übersetzungen beibehalten werden. Siehe Wiederherstellungsverhalten beim Zurücksetzen und erneutem Anwenden.

Einen abweichenden Verlauf wiederherstellen und dabei ausstehende Weblate-Übersetzungen beibehalten.

Bereinigung

Entfernt nicht nachverfolgte Dateien und veraltete Branches aus dem lokalen Repository-Checkout.

Übrig gebliebene Dateien oder veraltete Repository-Status im Weblate-Checkout bereinigen.

Synchronisieren

Zwingt Weblate, alle bekannten Übersetzungen in die Repository-Dateien zurückzuschreiben.

Fälle beheben, in denen Repository-Dateien nicht mehr mit dem Datenbankstatus übereinstimmen.

Erneut scannen

Liest Übersetzungsdateien aus dem lokalen Repository erneut in Weblate ein.

Dateiänderungen nach manueller Repository-Arbeit oder Dateierstellung importieren.

Wiederherstellungsverhalten beim Zurücksetzen und erneutem Anwenden

Der Vorgang Zurücksetzen und erneut anwenden behält ausstehende Übersetzungen aus Weblate bei und setzt den Status des lokalen Repositorys zurück, damit es Upstream entspricht.

Ausstehende Übersetzungen können nur dann wiederhergestellt werden, wenn die Zielsprachendateien nach dem Zurücksetzen noch vorhanden sind oder wenn Weblate sie für die Komponente erstellen kann, z. B. mit einer gültigen Vorlage für neue Übersetzungen.

Wenn keine der beiden Bedingungen erfüllt ist, behält Weblate die ausstehenden Änderungen in seiner Datenbank und meldet einen Wiederherstellungsfehler, anstatt später mit einem allgemeinen Analysefehler zu scheitern.

Merge-Konflikte vermeiden 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 Umbasieren (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

Code hosting notifications

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Code-Hosting-Integrationen.

Provider-specific notifications

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Code-Hosting-Integrationen.

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.

Änderungen aus Weblate pushen

Each translation component can have a push URL set up (see Repository-Push-URL), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see Bei Commit gleichzeitig Pushen.

For the push options table and provider-specific pull, merge, and review request workflows, see Änderungen aus Weblate pushen.

Siehe auch

Siehe Auf Repositorys zugreifen 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:

../_images/github-protected.png

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:

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. Unter Skripte mit Erweiterung ausführen finden Sie Informationen darüber, wie man externe Skripte durch Erweiterungen ausführt.

Übersetzungen aller Komponenten einheitlich 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.

Voraussetzungen für die Weitergabe:

  • Alle Komponenten müssen sich in einem einzigen Projekt befinden (das Verknüpfen von Komponenten reicht nicht aus).

  • Aktivieren Sie Weitergabe von Übersetzungen erlauben, um Übersetzungen für passende Zeichenketten automatisch wiederzuverwenden.

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

  • Die Zeichenketten werden beim Übersetzen weitergegeben, aus dem Repository geladene Zeichenketten werden nicht weitergegeben.

Tipp

Diese Funktion ist aktuell nur eingeschränkt nutzbar, und wir möchten sie universeller gestalten. Bitte teilen Sie uns Ihre Rückmeldung unter https://github.com/WeblateOrg/weblate/issues/3166 mit.

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