Integration der Versionsverwaltung¶

Weblate unterstützt derzeit Git (mit erweiterter Unterstützung für GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Gerrit, Subversion, Bitbucket-Cloud-Pull-Requests, Bitbucket-Data-Center-Pull-Requests und Azure-DevOps-Pull-Requests) und Mercurial als Versionsverwaltung-Backends.

Auf Repositorys zugreifen¶

Das VCS-Repository, das Sie verwenden möchten, muss für Weblate zugänglich sein. Bei einem öffentlich zugänglichen Repository müssen Sie nur die korrekte URL eingeben (z. B. https://github.com/WeblateOrg/weblate.git), aber für private Repositorys oder für Push-URLs ist die Einrichtung komplexer und erfordert eine Authentifizierung.

Auf Repositorys von Hosted Weblate zugreifen¶

Bemerkung

Dieser Abschnitt gilt nur für Hosted Weblate (hosted.weblate.org). Wenn Sie Ihre eigene, selbst gehostete Weblate-Instanz betreiben, lesen Sie bitte stattdessen den nächsten Abschnitt.

Für Hosted Weblate gibt es einen dedizierten Push-Benutzer, der auf GitHub, Bitbucket, Codeberg und GitLab registriert ist (mit dem Benutzernamen weblate, der E-Mail-Adresse hosted@weblate.org und einem Namen oder einer Profilbeschreibung Weblate push user).

Hinweis

Auf den Plattformen kann es weitere Benutzer von Weblate geben, die für andere Weblate-Instanzen bestimmt sind. Es wird empfohlen, nach der E-Mail-Adresse hosted@weblate.org zu suchen, um den richtigen Benutzer für Hosted Weblate zu finden.

Sie müssen diesen Benutzer als Mitwirkenden hinzufügen und ihm die entsprechenden Berechtigungen für Ihr Repository erteilen (für das Klonen reicht ein Lesezugriff aus, für das Pushen ist ein Schreibzugriff erforderlich). Je nach Dienst und den Einstellungen Ihrer Organisation geschieht dies sofort oder erfordert eine Bestätigung auf der Weblate-Seite.

Der Benutzer weblate auf GitHub nimmt Einladungen automatisch innerhalb von fünf Minuten an. Bei den anderen Diensten kann eine manuelle Bearbeitung erforderlich sein, also haben Sie bitte etwas Geduld.

Sobald der Benutzer weblate zu Ihrem Repository hinzugefügt wurde, können Sie das Quellcode-Repository und die Repository-Push-URL über das SSH-Protokoll konfigurieren (zum Beispiel git@github.com:WeblateOrg/weblate.git).

Auf Repositorys von Code-Hosting-Sites zugreifen (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶

Bemerkung

Dieser Abschnitt gilt für selbst gehostete Weblate-Instanzen. Wenn Sie Hosted Weblate (hosted.weblate.org) verwenden, lesen Sie stattdessen Auf Repositorys von Hosted Weblate zugreifen.

Bei Self-Hosted-Weblate erfolgt der Zugriff auf Repositorys auf Code-Hosting-Sites in der Regel durch das Erstellen eines speziellen Benutzers, der mit einem SSH-Schlüssel von Weblate verknüpft ist (siehe Weblate-SSH-Schlüssel). Auf diese Weise verknüpfen Sie den SSH-Schlüssel von Weblate mit einem einzigen Benutzer (Plattformen erzwingen häufig die einmalige Verwendung eines SSH-Schlüssels) und gewähren diesem Benutzer Zugriff auf das Repository. Sie können dann die SSH-URL für den Zugriff auf das Repository verwenden (siehe SSH-Repositorys).

SSH-Repositorys¶

Die am häufigsten verwendete Methode, um auf private Repositorys zuzugreifen, basiert auf SSH. Autorisieren Sie den öffentlichen Weblate-SSH-Schlüssel (siehe Weblate-SSH-Schlüssel), um auf diese Weise auf das Upstream-Repository zuzugreifen.

Warnung

Auf GitHub kann jeder Schlüssel nur einmal verwendet werden, siehe GitHub-Repositorys und Auf Repositorys von Hosted Weblate zugreifen.

Weblate speichert auch den Fingerabdruck des Host-Schlüssels bei der ersten Verbindung und stellt keine Verbindung zum Host her, wenn er später geändert wird (siehe SSH-Hostschlüssel überprüfen).

Falls eine Anpassung erforderlich ist, nehmen Sie diese über die Weblate-Adminoberfläche vor:

Weblate-SSH-Schlüssel¶

Geändert in Version 4.17: Weblate erzeugt jetzt sowohl RSA- als auch Ed25519-SSH-Schlüssel. Die Verwendung von Ed25519 wird für neue Installationen empfohlen.

Der öffentliche Schlüssel von Weblate ist für alle Benutzer sichtbar, welche die Seite Über Weblate besuchen.

Administratoren können den öffentlichen Schlüssel, der aktuell von Weblate in der Verbindung verwendet wird (aus SSH-Schlüssel), auf der Einstiegsseite der Adminoberfläche erzeugen oder anzeigen.

Bemerkung

Der entsprechende private SSH-Schlüssel darf derzeit kein Passwort haben, stellen Sie daher sicher, dass er gut geschützt ist.

Hinweis

Erstellen Sie eine Sicherungskopie des erzeugten privaten Weblate-SSH-Schlüssels.

SSH-Hostschlüssel überprüfen¶

Weblate speichert die SSH-Hostschlüssel beim ersten Zugriff automatisch und merkt sie sich für die weitere Verwendung.

Wenn Sie den Fingerabdruck des Schlüssels vor der Verbindung mit dem Repository überprüfen möchten, fügen Sie die SSH-Schlüssel der Server, auf die Sie zugreifen möchten, unter Hostschlüssel hinzufügen im selben Abschnitt der Adminoberfläche hinzu. Geben Sie den Rechnernamen ein, auf den Sie zugreifen wollen (z. B. gitlab.com), und drücken Sie Absenden. Überprüfen Sie, ob der Fingerabdruck mit dem von Ihnen hinzugefügten Server übereinstimmt.

Die hinzugefügten Schlüssel mit Fingerabdrücken werden in der Bestätigungsnachricht angezeigt:

Verbindung zu älteren SSH-Servern¶

Aktuelle OpenSSH-Versionen (z. B. die im Weblate-Docker-Container verwendete) deaktivieren standardmäßig RSA-Signaturen mit dem SHA-1-Hash-Algorithmus. Diese Änderung wurde vorgenommen, da der SHA-1-Hash-Algorithmus kryptografisch gebrochen ist und es möglich ist, Hash-Kollisionen mit gewählten Präfixen für unter USD$ 50k zu erstellen.

Für die meisten Benutzer sollte diese Änderung unsichtbar sein und es besteht keine Notwendigkeit, SSH-RSA-Schlüssel zu ersetzen. OpenSSH unterstützt RFC8332-RSA/SHA-256/512-Signaturen seit Version 7.2 und existierende SSH-RSA-Schlüssel werden automatisch den stärkeren Algorithmus verwenden, wenn möglich.

Inkompatibilität ist wahrscheinlicher, wenn eine Verbindung zu älteren SSH-Implementierungen hergestellt wird, die nicht aktualisiert wurden oder die Verbesserungen des SSH-Protokolls nicht genau verfolgt haben. Die SSH-Verbindung zu einem solchen Server schlägt fehl mit:

no matching host key type found. Their offer: ssh-rsa

In diesen Fällen kann es notwendig sein, RSA/SHA1 selektiv wieder zu aktivieren, um die Authentifizierung von Verbindungen und/oder Benutzern über die Optionen HostkeyAlgorithms und PubkeyAcceptedAlgorithms zu ermöglichen. Der folgende Dreizeiler in DATA_DIR/ssh/config aktiviert beispielsweise RSA/SHA1 für die Host- und Benutzer-Authentifizierung für einen einzelnen Ziel-Host:

Host legacy-host
   HostkeyAlgorithms +ssh-rsa
   PubkeyAcceptedAlgorithms +ssh-rsa

Wir empfehlen, RSA/SHA1 nur als Überbrückungsmaßnahme zu aktivieren, bis veraltete Implementierungen aktualisiert oder mit einem anderen Schlüsseltyp (wie ECDSA oder Ed25519) neu konfiguriert werden können.

GitHub-Repositorys¶

Es gibt zwei Hauptansätze für den Zugriff auf GitHub-Repositorys mit Weblate:

Option 1: HTTPS mit persönlichem Zugangstoken (einfacher für den Einstieg)

Verwenden Sie die HTTPS-Authentifizierung mit einem persönlichen Zugangstoken und Ihrem GitHub-Konto. Dies funktioniert sowohl für den Nur-Lese-Zugriff (Klonen) als auch für den Lese-Schreib-Zugriff (Pushen von Änderungen oder Erstellen von Pull Requests).

Um diesen Ansatz zu verwenden:

Ein persönliches Zugangstoken erstellen, wie in Creating an access token for command-line use beschrieben.
Das Token in die Repository-URL einfügen: https://username:token@github.com/owner/repo.git

Dies ist geeignet, wenn Sie mit Weblate beginnen oder mit einem einzelnen Repository arbeiten.

Option 2: SSH mit eigenem Benutzer (empfohlen für mehrere Repositorys)

Für Setups mit mehreren Repositorys ist es empfehlenswert, einen dedizierten Benutzer für Weblate zu erstellen. Dadurch wird die Einschränkung von GitHub umgangen, dass jeder SSH-Schlüssel nur einmal pro Plattform verwendet werden kann.

Um diesen Ansatz zu verwenden:

Ein spezielles GitHub-Benutzerkonto (z. B. weblate-bot) erstellen
Den öffentlichen SSH-Schlüssel von Weblate zu diesem Benutzer hinzufügen (siehe Weblate-SSH-Schlüssel)
Diesem Benutzer Zugriff auf alle Repositorys, die übersetzt werden sollen, gewähren
SSH-URLs für die Repositorys verwenden: git@github.com:owner/repo.git

Dieser Ansatz wird auch für Hosted Weblate verwendet, das zu diesem Zweck einen eigenen Benutzer weblate hat.

Bemerkung

Beim Verwenden von GitHub-Pull-Requests für Pull Requests wirkt sich die Push-Branch-Konfiguration auf das Verhalten aus: Wenn sie nicht gesetzt ist, wird das Projekt geforkt und die Änderungen werden über einen Fork gepusht. Wenn sie gesetzt ist, werden die Änderungen an das Upstream-Repository und den ausgewählten Branch gepusht.

Siehe auch

GitHub-Pull-Requests
Auf Repositorys von Hosted Weblate zugreifen
GITHUB_CREDENTIALS

GitLab-Repositorys¶

Der Zugriff über SSH ist möglich (siehe SSH-Repositorys), aber falls Sie auf mehr als ein Repository zugreifen müssen, stoßen Sie auf eine GitLab-Beschränkung für die Verwendung von SSH-Schlüsseln (da jeder Schlüssel nur einmal verwendet werden kann).

Falls der Push-Branch nicht gesetzt ist, wird das Projekt geforkt und die Änderungen durch einen Fork gepusht. Ist er gesetzt, werden die Änderungen an das vorgelagerte Repository und den gewählten Branch gepusht.

Das Verwenden von persönlichen oder Projekt-Zugangstoken ist ebenfalls möglich. Das Token benötigt die Berechtigung write_repository, um Änderungen an das Repository pushen zu können. Der Zugangstoken für das Projekt benötigt die Rolle Developer, um Änderungen pushen zu können.

Die URL muss einen Benutzernamen enthalten, für persönliche Zugangstoken ist es der tatsächliche Benutzername ( https://user:personal_access_token@gitlab.com/example/example.git), für Projekt-Zugangstoken kann es ein nicht-leerer Wert sein (https://example:project_access_token@gitlab.com/example/example.git).

Bemerkung

Die Regeln für das Verwenden von Projekt-Zugangstoken haben sich zwischen den verschiedenen GitLab-Versionen geändert. Der nicht-leere Wert ist die aktuelle Anforderung, aber ältere Versionen hatten andere Erwartungen (Projektname, Bot-Benutzername). Prüfen Sie im Zweifelsfall die zu Ihrer Version passende GitLab-Dokumentation.

Siehe auch

GitLab-Merge-Requests
Auf Repositorys von Hosted Weblate zugreifen
GITLAB_CREDENTIALS

Weblate-interne URLs¶

Teilen Sie eine Repository-Einrichtung zwischen verschiedenen Komponenten, indem Sie auf seine Platzierung als weblate://project/component in anderen (verlinkten) Komponenten verweisen. Auf diese Weise verwenden verlinkte Komponenten die VCS-Repository-Konfiguration der (referenzierten) Hauptkomponente.

Warnung

Beim Entfernen der Hauptkomponente werden auch die verlinkten Komponenten entfernt.

Weblate passt die Repository-URL beim Erstellen einer Komponente automatisch an, wenn es eine Komponente mit einem passenden Repository-Setup findet. Sie können dies im letzten Schritt der Konfiguration der Komponente außer Kraft setzen.

Gründe dafür:

Spart Speicherplatz auf dem Server, das Repository wird nur einmal gespeichert.
Beschleunigt die Aktualisierungen, da nur ein Repository aktualisiert wird.
Es gibt nur ein einziges exportiertes Repository mit Weblate-Übersetzungen (siehe Git-Exporter).
Einige Erweiterungen können mit mehreren Komponenten arbeiten, die sich ein Repository teilen, zum Beispiel Git-Commits zusammenfassen.

HTTPS-Repositorys¶

Siehe auch

GitHub-Repositorys
GitLab-Repositorys

Um auf geschützte HTTPS-Repositorys zuzugreifen, geben Sie den Benutzernamen und das Passwort in der URL an. Keine Sorge, Weblate entfernt diese Informationen, wenn die URL den Benutzern angezeigt wird (wenn sie die URL des Repositorys überhaupt sehen dürfen).

Die GitHub-URL mit hinzugefügter Authentifizierung könnte zum Beispiel so aussehen: https://user:your_access_token@github.com/WeblateOrg/weblate.git.

Wenn Sie in der URL keine Zugangsdaten angeben und das Repository diese verlangt, schlägt Git mit einer Fehlermeldung fehl:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

Geändert in Version 5.10.2: Weblate verwendet eine proaktive Authentifizierung mit Git 2.46.0 und neuer, wenn HTTP-Zugangsdaten angegeben werden.

Dies ermöglicht den Zugriff auf Azure-DevOps-Repositorys und beschleunigt den Zugriff auf authentifizierte Repositorys.

Bemerkung

Wenn Ihr Benutzername oder Ihr Passwort Sonderzeichen enthält, müssen diese URL-kodiert sein, zum Beispiel https://user%40example.com:%24password%23@bitbucket.org/….

Proxy verwenden¶

Wenn Sie auf HTTP/HTTPS-VCS-Repositorys über einen Proxyserver zugreifen müssen, konfigurieren Sie das VCS so, dass es diesen verwendet.

Dies kann mit Hilfe der Umgebungsvariablen http_proxy, https_proxy und all_proxy geschehen (wie in der cURL-Dokumentation beschrieben) oder z. B. in der VCS-Konfiguration erzwungen werden:

git config --global http.proxy http://user:password@proxy.example.com:80

Bemerkung

Die Proxy-Konfiguration muss unter dem Benutzer erfolgen, unter dem Weblate läuft (siehe auch Dateisystemberechtigungen) und mit HOME=$DATA_DIR/home (siehe DATA_DIR), sonst wird Git, das von Weblate ausgeführt wird, es nicht nutzen.

Siehe auch

Git¶

Hinweis

Weblate benötigt Git 2.28 oder neuer.

Siehe auch

Siehe Auf Repositorys zugreifen für Informationen darüber, wie man auf verschiedene Arten von Repositorys zugreifen kann.

Git Push erzwingen¶

Dies verhält sich genau wie Git selbst, mit dem einzigen Unterschied, dass es immer Pushes erzwingt. Dies ist nur für den Fall vorgesehen, dass ein separates Repository für Übersetzungen verwendet wird.

Warnung

Seien Sie vorsichtig, da dies leicht zu verlorenen Commits in Ihrem Upstream-Repository führt.

Git-Konfiguration anpassen¶

Weblate ruft alle VCS-Befehle mit HOME=$DATA_DIR/home auf (siehe DATA_DIR), daher muss das Bearbeiten der Benutzer-Konfiguration in DATA_DIR/home/.git erfolgen.

GitHub-Pull-Requests¶

Dies fügt eine dünne Schicht über Git unter Verwendung der GitHub API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Git pusht Änderungen direkt in ein Repository, während GitHub-Pull-Requests Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.

Damit dies funktioniert, müssen die API-Zugangsdaten (GITHUB_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option GitHub sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

GitLab-Merge-Requests¶

Dies fügt eine dünne Schicht über Git unter Verwendung der GitLab API hinzu, um das Pushen von Übersetzungsänderungen als Merge Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während GitLab-Merge-Requests einen Merge Request erstellt.

Damit dies funktioniert, müssen die API-Zugangsdaten (GITLAB_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option GitLab sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Gitea-Pull-Requests¶

Added in version 4.12.

Dies fügt eine dünne Schicht über Git unter Verwendung der Gitea API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Damit dies funktioniert, müssen die API-Zugangsdaten (GITEA_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Gitea sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Bitbucket-Data-Center-Pull-Requests¶

Added in version 4.16.

Dies fügt eine dünne Schicht über Git unter Verwendung der Bitbucket-Data-Center-API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Warnung

Dies unterstützt die Bitbucket-Cloud-API nicht.

Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen in ein Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Bitbucket-Data-Center-Pull-Requests einen Pull Request erstellt.

Damit dies funktioniert, müssen die API-Zugangsdaten (BITBUCKETSERVER_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Bitbucket Data Center sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Bitbucket-Cloud-Pull-Requests¶

Added in version 5.8.

Dies fügt eine dünne Schicht auf Git unter Verwendung der Bitbucket-Cloud-API hinzu, um das Pushen von Übersetzungsänderungen als Pull-Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Warnung

Dies unterscheidet sich von der Bitbucket-Data-Center-API.

Damit dies funktioniert, müssen die API-Zugangsdaten (BITBUCKETCLOUD_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Bitbucket Cloud sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Pagure-Merge-Requests¶

Added in version 4.3.2.

Dies fügt eine dünne Schicht über Git unter Verwendung der Pagure API hinzu, um das Pushen von Übersetzungsänderungen als Merge Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Pagure-Merge-Requests einen Merge Request erstellt.

Damit dies funktioniert, müssen die API-Zugangsdaten (PAGURE_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Pagure sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Gerrit¶

Dies fügt eine dünne Schicht über Git mit dem Werkzeug git-review hinzu, um das Pushen von Übersetzungsänderungen als Gerrit-Review-Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Die Gerrit-Dokumentation enthält Einzelheiten zur Konfiguration, die für die Einrichtung solcher Repositorys erforderlich ist.

Azure-DevOps-Pull-Requests¶

Dies fügt eine dünne Schicht über Git unter Verwendung der Azure DevOps API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.

Git pusht Änderungen direkt in ein Repository, während Azure-DevOps-Pull-Requests Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.

Damit dies funktioniert, müssen die API-Zugangsdaten (AZURE_DEVOPS_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Azure DevOps sichtbar, wenn Versionsverwaltung ausgewählt wird.

Siehe auch

Mercurial¶

Mercurial ist eine weitere Versionsverwaltung, die Sie direkt in Weblate verwenden können.

Bemerkung

Es sollte mit jeder Mercurial-Version funktionieren, aber es gibt manchmal inkompatible Änderungen an der Befehlszeile, welche die Weblate-Integration stören.

Siehe auch

Siehe Auf Repositorys zugreifen für Informationen darüber, wie man auf verschiedene Arten von Repositorys zugreifen kann.

Subversion¶

Weblate verwendet git-svn zur Interaktion mit subversion-Repositorys. Es handelt sich um ein Perl-Skript, mit dem Subversion von einem Git-Client verwendet werden kann, so dass Benutzer einen vollständigen Klon des internen Repositorys pflegen und lokal Commits durchführen können.

Bemerkung

Weblate versucht, das Layout des Subversion-Repositorys automatisch zu erkennen – es unterstützt sowohl direkte URLs für Branches als auch Repositorys mit Standardlayout (branches/, tags/ und trunk/). Mehr Informationen dazu finden Sie in der git-svn-Dokumentation. Wenn Ihr Repository kein Standardlayout hat und Sie auf Fehler stoßen, versuchen Sie, den Namen des Branches in die Repository-URL aufzunehmen und den Branch leer zu lassen.

Subversion-Zugangsdaten¶

Ihre Weblate-Installation erwartet, dass Sie das Zertifikat (und ggf. Ihre Zugangsdaten) im Voraus akzeptiert haben. Es wird versuchen, sie in das Verzeichnis DATA_DIR einzufügen. Akzeptieren Sie das Zertifikat, indem Sie einmal svn verwenden, wobei die Einsatzumgebungsvariable $HOME auf DATA_DIR gesetzt ist:

# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example

Siehe auch

DATA_DIR

Lokale Dateien¶

Hinweis

Darunter verwendet es Git. Es erfordert die Installation von Git und ermöglicht es Ihnen, Git nativ mit einem vollständigen Verlauf Ihrer Übersetzungen zu verwenden.

Weblate kann auch ohne ein Remote-VCS betrieben werden. Die ersten Übersetzungen werden durch Hochladen importiert. Später können Sie einzelne Dateien durch Dateiupload ersetzen oder Zeichenketten direkt aus Weblate hinzufügen (aktuell nur für einsprachige Übersetzungen verfügbar).

Im Hintergrund erstellt Weblate ein Git-Repository für Sie, in dem alle Änderungen nachverfolgt werden. Falls Sie sich später entscheiden, ein VCS zur Speicherung der Übersetzungen zu verwenden, haben Sie bereits ein Repository in Weblate, auf das Sie Ihre Integration stützen können.