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. Code-Hosting-Integrationen listet anbieterspezifische Einrichtungsschritte für gängige Code-Hosting-Sites auf.

Dies ist der Prozess:

Die Entwickler nehmen Änderungen vor und pushen sie in das VCS-Repository.
Optional werden die Übersetzungsdateien aktualisiert, siehe Neue Zeichenketten einführen.
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 Änderungen aus Weblate pushen).

Hinweis

Upstream-Code-Hosting-Site 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.

Benachrichtigungs-Hooks verwenden, um eine Integration mit den meisten gängigen Code-Hosting-Diensten herzustellen; siehe Code-Hosting-Integrationen. Damit dies funktioniert, muss außerdem Hooks aktivieren ausgeführt werden. Hook-Zustellungen aktualisieren Komponenten, deren Repository-URL mit den Nutzdaten übereinstimmt; siehe Webhook-Ziele abgleichen.
Manuelles Auslösen der Aktualisierung entweder in der Repository-Verwaltung oder mit Weblates REST-API oder Weblate Client
AUTO_UPDATE aktivieren, um alle Komponenten in der Weblate-Instanz automatisch zu aktualisieren
updategit ausführen (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.

Webhook-Ziele abgleichen¶

Forge-Webhooks aktualisieren Komponenten, deren Quellcode-Repository genau mit einer Repository-URL aus den Nutzdaten übereinstimmt (HTTPS oder SSH, wie von Forge gemeldet, sowie gängige Varianten wie ein abschließender Schrägstrich).

Generische Forge-Webhook-Endpunkte sind Kompatibilitätsschnittstellen, und gewöhnliche Repository-Übermittlungen werden nicht kryptografisch authentifiziert. Eine Ausnahme bilden Übermittlungen älterer GitHub-Apps, die Installationsdaten enthalten: Der generische GitHub-Endpunkt überprüft deren Signatur mithilfe von GITHUB_LEGACY_APP_WEBHOOK_SECRET. Beim Repository-Abgleich wird keine Projekt- oder Komponenten-Zugriffssteuerung angewendet, da Webhooks auch private Projekte und eingeschränkte Komponenten aktualisieren müssen. Ihre JSON-Antworten enthalten Diagnosezahlen für Übereinstimmungen bei Repositorys, Branches und aktivierten Hooks. Erfolgreiche Antworten enthalten zudem die vollständigen Projekt-/Komponenten-Slugs und die absoluten API-URLs der aktualisierten Komponenten. Durch die Angabe einer übereinstimmenden Repository-URL lässt sich daher bestätigen, dass ein Repository registriert ist, und diese Kennungen werden offengelegt.

Each matching delivery records a hook event and schedules a repository update. Generic hook deliveries are neither application-rate-limited nor coalesced. Repository operations are serialized to protect repository consistency, but this does not bound the number of accepted deliveries or queued update attempts. An update of an unchanged repository still fetches the configured remote, but stops before merging changes or parsing translation files.

Komponenten, die über eine authentifizierte Integration verwaltet werden, sind vom generischen Webhook-Abgleich und den damit verbundenen Diagnosezahlen ausgeschlossen. Aktuell gilt dies für das VCS-Backend GitHub (über die Weblate-GitHub-App). Diese Komponenten erhalten Benachrichtigungen ausschließlich über ihre eigene, tokenisierte und signierte GitHub-App-Webhook-URL. Auch zukünftige authentifizierte Integrationen werden voraussichtlich dieselbe Trennung verwenden.

Die zurückgegebenen API-URLs gewähren keinen Zugriff auf die Komponenten. Die Weboberfläche und die API wenden weiterhin die üblichen Zugriffssteuerungen an, und Webhook-Antworten enthalten keine Repository-Inhalte, -Übersetzungen oder -Zugangsdaten. Verwenden Sie nach Möglichkeit eine authentifizierte Integration wie beispielsweise App-Webhook-URL.

Geändert in Version 2026.9: Der Abgleich der Host- und Pfad-Suffix-Fallbacks wurde entfernt. Wenn keine Updates mehr erfolgen, passen Sie das Quellcode-Repository an eine URL aus den Forge-Nutzdaten an.

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
Merge-Konflikte vermeiden durch Sperren von Weblate bei Änderungen von extern
Merge-Konflikte vermeiden durch Konzentration auf Git-Operationen

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:

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

For shared repositories, permissions are checked on the component that owns the repository, even when the operation is started from a linked component. Users with repository permissions only on a linked component can open this view to see which permissions they need on the owner. Restrictions identify the owning component when it is accessible; otherwise, ask your project administrator to coordinate access with the repository owner. See Zugriffssteuerung for permission scope.

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.

Von dieser Ansicht aus gestartete Repository-Aktionen werden zur Hintergrundverarbeitung in eine Warteschlange gestellt. Für ein Projekt verarbeitet Weblate die betroffenen Repositorys nacheinander in einer Aufgabe und zeigt den Fortschritt an. Wird dieselbe Aktion wiederholt, wird die bestehende Aufgabe geöffnet; eine andere Aktion kann für dasselbe Repository erst gestartet werden, wenn diese Aufgabe abgeschlossen ist.

Die Repository-Operationen Synchronisieren und Erneut scannen werden, wie oben beschrieben, für die Hintergrundverarbeitung in die Warteschlange gestellt. Die separaten Dateiverwaltung-Aktionen stehen nur für eine einzelne Übersetzung zur Verfügung. Sie schreiben die betreffende Übersetzungsdatei neu und übernehmen das Ergebnis während der Webanfrage; es handelt sich dabei nicht um projekt- oder komponentenweite Vorgänge.

Vorgänge, bei denen Repository-Inhalte gelesen werden, wie beispielsweise Aktualisieren, Zurücksetzen oder erneutes Scannen, führen auch zu einem Abgleich der Übersetzungsdateien in Weblate. Hinzugefügte oder entfernte Übersetzungsdateien werden nach Abschluss dieses Vorgangs übernommen. Die Synchronisierung und der Bereinigungsvorgang für das Glossar werden unter Sprachdateien und Synchronisierung beschrieben.

Aktion	Was es bewirkt	Typische Verwendung
Commit	Committet die in Weblate gespeicherten ausstehenden Änderungen in das lokale Repository.	Ausstehende Weblate-Änderungen durchführen, vor dem Arbeiten an anderer Stelle im Repository.
Push	Pusht committete lokale Repository-Änderungen in den konfigurierten Upstream.	Committete Übersetzungen an Upstream senden, wenn das automatische Pushen deaktiviert ist oder sich verzögert.
Aktualisieren	Ruft Upstream-Änderungen ab, integriert sie mithilfe der für die Komponente konfigurierten Git-Strategie, und gleicht die Übersetzungsdateien ab.	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.
Lokale Änderungen verwerfen	Setzt das lokale Repository von Weblate auf Upstream zurück, verwirft lokale Commits und ausstehende Übersetzungsänderungen, und gleicht die Übersetzungsdateien ab.	Verwenden, wenn Upstream den lokalen Weblate-Repository-Status überschreiben soll.
Übersetzungen zurücksetzen und erneut anwenden	Setzt das lokale Weblate-Repository auf Upstream zurück, gleicht die Übersetzungsdateien ab, und wendet Weblates Übersetzungen erneut an. Siehe Wiederherstellungsverhalten beim Übersetzungen zurücksetzen und erneut 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 und entfernt Übersetzungen, deren Dateien nicht mehr mit der Komponentenkonfiguration übereinstimmen.	Dateiänderungen nach manueller Repository-Arbeit oder Dateierstellung importieren.
Duplikate entfernen	Entfernt doppelte Zeichenketten mit derselben Kennung aus einer Übersetzungsdatei.	Die von Weblate gemeldeten doppelten Zeichenketten korrigieren, wenn die Datei wiederholte Einheiten enthält.
Nicht verwendete bereinigen	Entfernt Zeichenketten aus einer Übersetzungsdatei, die in der Basisdatei nicht mehr vorhanden sind. Die Erweiterung Übersetzungsdateien bereinigen kann dies automatisch durchführen.	Einen einmaligen Bereinigungsvorgang durchführen, ohne die Erweiterung zu installieren.
Veraltete entfernen	Entfernt veraltete Zeichenketten aus einer PO-Übersetzungsdatei.	Einen einmaligen PO-Bereinigungsvorgang durchführen, ohne das automatische Entfernen veralteter Zeichenketten zu aktivieren.

For Git repositories, both reset actions affect only the configured Repository-Branch. They do not reset or remove other local branches. Cleanup deletes all other local branches, including any commits that have not been pushed, and removes untracked files. It does not delete branches from the upstream repository.

If you replace an upstream branch with unrelated history, switching to it in Weblate can fail because Weblate reuses its existing local branch and tries to merge or rebase it. Resetting while another branch is configured does not fix that inactive local branch. For example, resetting master leaves an old local dev branch unchanged.

If no local changes on the affected branch need to be kept, configure a working branch, run Cleanup from Repository maintenance, and wait for it to finish. Then switch to the affected branch again. Weblate creates it afresh from upstream. If the affected branch is already configured, use Discard local changes to replace its local history with upstream instead.

Wiederherstellungsverhalten beim Übersetzungen zurücksetzen und erneut anwenden¶

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

If the Git checkout or its entire .git directory is missing, this operation reconstructs it before reapplying translations. Remote repositories are cloned from the configured upstream branch. Local repositories are initialized with new Git metadata while retaining any surviving working files. Both then use the standard reapply flow. Symlinked checkout directories are never replaced automatically.

For local repositories, reapply can recreate missing strings from the database, including source strings in monolingual base files, when the file format supports adding strings. Missing translation files can also be recreated when the format supports creating them or a valid template for new translations is available. This applies to local glossaries as well as other local components, including when their Git checkout is healthy. Remote reapply does not recreate strings removed upstream.

Required files that the format cannot create must be restored from a backup. Weblate reports restoration failures and keeps the database translations and pending changes.

Any surviving checkout without a .git directory is preserved under DATA_DIR/repository-recovery/<component-id>/<unique-id>/. Its location is written to the application log. These copies are not removed automatically; inspect and remove them manually after verifying recovery. Reconstruction cannot restore lost Git history or files and metadata that Weblate does not store.

Recovery is explicit: background updates do not automatically rebuild checkouts. If a checkout is unexpectedly missing, first verify that the data volume is available to the worker performing recovery. Damaged Git metadata in an existing .git directory requires manual inspection and repair by an instance administrator.

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. Weblate kann neue lokale Commits haben, nachdem Sie frühere Weblate-Commits Upstream zusammengeführt haben. Das passiert typischerweise, wenn das Zusammenführen nicht automatisiert ist und Änderungen tage- oder wochenlang auf ein menschliches Überprüfen warten. Git ist dann manchmal nicht mehr in der Lage, Upstream-Änderungen mit den Weblate-Änderungen als übereinstimmend zu erkennen und weigert sich, eine Umbasierung durchzuführen.

Das Zusammenfassen von Weblate-Änderungen macht es schwieriger, dies zu beheben. Ein Squash Merge erstellt einen neuen Commit, anstatt die einzelnen Weblate-Commits im Upstream-Verlauf beizubehalten. Weblate hat die ursprünglichen Commits immer noch in seinem lokalen Repository, und Git kann nicht mehr nachweisen, dass diese bereits in Upstream enthalten sind. Wenn der Konflikt zudem manuell gelöst wurde, können sich die Dateiinhalte in beiden Repositorys unterscheiden, sodass Weblate auch dann nicht aktualisieren kann, nachdem der Pull Request in Upstream zusammengeführt wurde.

Wenn Upstream keine Weblate-Commits mehr enthält, weil sie zusammengefasst wurden, reicht es möglicherweise nicht aus, das Repository zu aktualisieren. Verwenden Sie Übersetzungen zurücksetzen und erneut anwenden von Repository-Wartung, um Weblate auf Upstream zurückzusetzen und dabei ausstehende Übersetzungen beizubehalten; siehe Wiederherstellungsverhalten beim Übersetzungen zurücksetzen und erneut anwenden. Verwenden Sie Lokale Änderungen verwerfen nur, wenn Upstream die lokalen Änderungen von Weblate vollständig ersetzen soll.

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:

Für Weblate-Änderungen nicht Git-Commits zusammenfassen oder Squash Merge verwenden. Das Zusammenfassen (Squash) ist der Grund, warum Git die Änderungen nach dem Zusammenführen (Merge) möglicherweise nicht mehr erkennt.
Beim Lösen von Konflikten außerhalb von Weblate die Weblate-Commits mit einem regulären Merge Commit zusammenführen und dieses Ergebnis Upstream pushen. Keinen Squash Merge für den konfliktlösenden Pull Request durchführen.
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-Benachrichtigungen¶

Anbieterspezifische App- und Webhook-Anweisungen für GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo und Gitee werden in Code-Hosting-Integrationen behandelt.

Anbieterspezifische Benachrichtigungen¶

Diese veralteten Verweise werden aus Kompatibilitätsgründen beibehalten. Die aktuelle anbieterspezifische App- und Webhook-Einrichtung ist in Code-Hosting-Integrationen dokumentiert.

Siehe auch

Automatische tägliche Aktualisierung der Repositorys¶

Standardmäßig ruft Weblate automatisch täglich Remote-Repositorys ab, um die Leistung beim späteren Zusammenführen von Änderungen zu verbessern. Die Aktualisierungen werden über den Tag verteilt durchgeführt. Setzen Sie AUTO_UPDATE auf "full", um auch Remote-Änderungen in die Arbeitskopie zu übernehmen. Siehe AUTO_UPDATE für Details zur Zeitplanung und zu anderen Aktualisierungsmodi.

Änderungen aus Weblate pushen¶

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 pushen. Weblate kann auch so konfiguriert werden, dass Änderungen automatisch bei jedem Commit gepusht werden, siehe Bei Commit gleichzeitig Pushen.

Die Tabelle mit den Push-Optionen und die anbieterspezifischen Abläufe für Pull-, Merge- und Review-Requests finden Sie unter Ä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:

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 sowie das gewünschte Intervall aus.

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 Übersetzungsweitergabe zulassen 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:

Components must belong to the configured workspace propagation scope. By default, this is a single project (linking a component is not enough).
Übersetzungsweitergabe zulassen aktivieren, um Übersetzungen für passende Zeichenketten automatisch wiederzuverwenden.
Die Übersetzungsweitergabe erfordert, dass der Schlüssel mit einsprachigen Übersetzungsformaten übereinstimmt, daher sollte dies beim Erstellen von Übersetzungsschlüsseln berücksichtigt werden.
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).