Integration der Versionsverwaltung

Weblate currently supports Git (with extended support for GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Gerrit, Subversion and Bitbucket-Server-Pull-Request) and Mercurial as version control back-ends.

Zugriff auf Repositorys

The VCS repository you want to use has to be accessible to Weblate. With a publicly available repository you just need to enter the correct URL (for example https://github.com/WeblateOrg/weblate.git), but for private repositories or for push URLs the setup is more complex and requires authentication.

Zugriff auf Repositorys von Hosted Weblate aus

For Hosted Weblate there is a dedicated push user registered on GitHub, Bitbucket, Codeberg and GitLab (with the username weblate, e-mail hosted@weblate.org and, named Weblate push user). You need to add this user as a collaborator and give it appropriate permission to your repository (read-only is okay for cloning, write is required for pushing). Depending on service and your organization settings, this happens immediately, or requires confirmation on the Weblate side.

The weblate user on GitHub accepts invitations automatically within five minutes. Manual processing might be needed on the other services, so please be patient.

Once the weblate user is added, you can configure Quellcode-Repository and Push-URL für Repository using the SSH protocol (for example git@github.com:WeblateOrg/weblate.git).

SSH-Repositorys

The most frequently used method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate-SSH-Schlüssel) to access the upstream repository this way.

Warnung

On GitHub, each key can only be used once, see GitHub-Repositorys and Zugriff auf Repositorys von Hosted Weblate aus.

Weblate also stores the host key fingerprint upon first connection, and fails to connect to the host should it be changed later (see Verifying SSH host keys).

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

_images/ssh-keys.png

Weblate-SSH-Schlüssel

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

Admins can generate or display the public key currently used by Weblate in the connection (from SSH keys) on the admin interface landing page.

Bemerkung

The corresponding private SSH key can not currently have a password, so make sure it is well protected.

Hinweis

Make a backup of the generated private Weblate SSH key.

Verifying SSH host keys

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

In case you want to verify the key fingerprint before connecting to the repository, add the SSH host keys of the servers you are going to access in Add host key, from the same section of the admin interface. Enter the hostname you are going to access (e.g. gitlab.com), and press Submit. Verify its fingerprint matches the server you added.

The added keys with fingerprints are shown in the confirmation message:

_images/ssh-keys-added.png

GitHub-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 GitHub-Beschränkung für die Verwendung von SSH-Schlüsseln (da jeder Schlüssel nur einmal verwendet werden kann).

In case the Push Branch is not set, the project is forked and changes pushed through a fork. In case it is set, changes are pushed to the upstream repository and chosen branch.

For smaller deployments, use HTTPS authentication with a personal access token and your GitHub account, see Creating an access token for command-line use.

For bigger setups, it is usually better to create a dedicated user for Weblate, assign it the public SSH key generated in Weblate (see Weblate-SSH-Schlüssel) and grant it access to all the repositories you want to translate. This approach is also used for Hosted Weblate, there is dedicated weblate user for that.

Weblate-interne URLs

Teilen Sie ein Repository-Setup zwischen verschiedenen Komponenten, indem Sie auf seine Platzierung als weblate://project/component in anderen (verknüpften) Komponenten verweisen. Auf diese Weise verwenden verknüpfte Komponenten die VCS-Repository-Konfiguration der Haupt(referenzierten) Komponente.

Warnung

Beim Entfernen der Hauptkomponente werden auch die verknüpften Komponenten entfernt.

Weblate automatically adjusts the repository URL when creating a component if it finds a component with a matching repository setup. You can override this in the last step of the component configuration.

Reasons to use this:

  • Saves disk space on the server, the repository is stored just once.

  • Makes the updates faster, only one repository is updated.

  • There is just single exported repository with Weblate translations (see Git-Exporter).

  • Einige Erweiterungen können mit mehreren Komponenten arbeiten, die sich ein Repository teilen, zum Beispiel Git-Commits zusammenfassen.

HTTPS-Repositorys

To access protected HTTPS repositories, include the username and password in the URL. Don’t worry, Weblate will strip this info when the URL is shown to users (if even allowed to see the repository URL at all).

For example the GitHub URL with authentication added might look like: https://user:your_access_token@github.com/WeblateOrg/weblate.git.

Bemerkung

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

Verwendung eines Proxys

If you need to access HTTP/HTTPS VCS repositories using a proxy server, configure the VCS to use it.

This can be done using the http_proxy, https_proxy, and all_proxy environment variables, (as described in the cURL documentation) or by enforcing it in the VCS configuration, for example:

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

Bemerkung

The proxy configuration needs to be done under user running Weblate (see also Dateisystemberechtigungen) and with HOME=$DATA_DIR/home (see DATA_DIR), otherwise Git executed by Weblate will not use it.

Git

Hinweis

Weblate benötigt Git 2.12 oder neuer.

Siehe auch

See Zugriff auf Repositorys for info on how to access different kinds of repositories.

Git Push erzwingen

This behaves exactly like Git itself, the only difference being that it always force pushes. This is intended only in the case of using a separate repository for translations.

Warnung

Use with caution, as this easily leads to lost commits in your upstream repository.

Customizing Git configuration

Weblate invokes all VCS commands with HOME=$DATA_DIR/home (see DATA_DIR), therefore editing the user configuration needs to be done in DATA_DIR/home/.git.

Git remote helpers

You can also use Git remote helpers for additionally supporting other version control systems, but be prepared to debug problems this may lead to.

At this time, helpers for Bazaar and Mercurial are available within separate repositories on GitHub: git-remote-hg and git-remote-bzr. Download them manually and put somewhere in your search path (for example ~/bin). Make sure you have the corresponding version control systems installed.

Once you have these installed, such remotes can be used to specify a repository in Weblate.

To clone the gnuhello project from Launchpad using Bazaar:

bzr::lp:gnuhello

For the hello repository from selenic.com using Mercurial:

hg::http://selenic.com/repo/hello

Warnung

The inconvenience of using Git remote helpers is for example with Mercurial, the remote helper sometimes creates a new tip when pushing changes back.

GitHub-Pull-Requests

Neu in Version 2.3.

This adds a thin layer atop Git using the GitHub API to allow pushing translation changes as pull requests, instead of pushing directly to the repository.

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.

You need to configure API credentials (GITHUB_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a GitHub option when selecting Versionsverwaltung.

GitLab-Merge-Requests

Neu in Version 3.9.

This just adds a thin layer atop Git using the GitLab API to allow pushing translation changes as merge requests instead of pushing directly to the repository.

Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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.

You need to configure API credentials (GITLAB_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a GitLab option when selecting Versionsverwaltung.

Gitea-Pull-Requests

Neu in Version 4.12.

This just adds a thin layer atop Git using the Gitea API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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 Gitea-Pull-Requests Pull Requests erstellt.

Damit dies funktioniert, müssen Sie die API-Anmeldeinformationen (GITEA_CREDENTIALS) in den Weblate-Einstellungen konfigurieren. Nach der Konfiguration sehen Sie die Option Gitea, wenn Sie Versionsverwaltung auswählen.

Bitbucket-Server-Pull-Request

Neu in Version 4.16.

This just adds a thin layer atop Git using the Bitbucket Server API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

Warnung

This does not support Bitbucket Cloud API.

Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Bitbucket-Server-Pull-Request werden Änderungen direkt in das Repository gepusht, während Gitea-Pull-Requests einen Pull Request erstellt.

Damit dies funktioniert, müssen Sie die API-Anmeldeinformationen (BITBUCKETSERVER_CREDENTIALS) in den Weblate-Einstellungen konfigurieren. Nach der Konfiguration sehen Sie die Option Bitbucket-Server, wenn Sie Versionsverwaltung auswählen.

Pagure-Merge-Requests

Neu in Version 4.3.2.

This just adds a thin layer atop Git using the Pagure API to allow pushing translation changes as merge requests instead of pushing directly to the repository.

Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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.

You need to configure API credentials (PAGURE_CREDENTIALS) in the Weblate settings to make this work. Once configured, you will see a Pagure option when selecting Versionsverwaltung.

Gerrit

Neu in Version 2.2.

Adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

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

Mercurial

Neu in Version 2.1.

Mercurial is another VCS you can use directly in Weblate.

Bemerkung

It should work with any Mercurial version, but there are sometimes incompatible changes to the command-line interface which breaks Weblate integration.

Siehe auch

See Zugriff auf Repositorys for info on how to access different kinds of repositories.

Subversion

Neu in Version 2.8.

Weblate uses git-svn to interact with subversion repositories. It is a Perl script that lets subversion be used by a Git client, enabling users to maintain a full clone of the internal repository and commit locally.

Bemerkung

Weblate tries to detect Subversion repository layout automatically - it supports both direct URLs for branch or repositories with standard layout (branches/, tags/ and trunk/). More info about this is to be found in the git-svn documentation. If your repository does not have a standard layout and you encounter errors, try including the branch name in the repository URL and leaving branch empty.

Geändert in Version 2.19: Before this, only repositories using the standard layout were supported.

Subversion credentials

Weblate expects you to have accepted the certificate up-front (and your credentials if needed). It will look to insert them into the DATA_DIR directory. Accept the certificate by using svn once with the $HOME environment variable set to the DATA_DIR:

# 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

Git

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.

Neu in Version 3.8.

Weblate can also operate without a remote VCS. The initial translations are imported by uploading them. Later you can replace individual files by file upload, or add translation strings directly from Weblate (currently available only for monolingual translations).

In the background Weblate creates a Git repository for you and all changes are tracked in. In case you later decide to use a VCS to store the translations, you already have a repository within Weblate can base your integration on.