版本控制集成

Weblate 当前支持 vcs-git`(扩展支持 :ref:`vcs-githubGerritSubversion)和 Mercurial 为版本控制后端。

Accessing repositories

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.

Accessing repositories from Hosted Weblate

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 源代码库 and 代码库推送 URL using the SSH protocol (for example git@github.com:WeblateOrg/weblate.git).

SSH 仓库

访问私有仓库的最常用方法是基于 SSH。授权公共 Weblate SSH 密钥(请参阅 Weblate SSH 密钥)以这种方式访问上游仓库。

警告

在 Github 上,每个密钥只能用一次,见 GitHub 仓库Accessing repositories from Hosted Weblate

Weblate 还会在首次连接时存储主机密钥指纹,并且在以后进行更改时将无法连接到主机(请参阅 验证 SSH 主机密钥)。

如果需要调整,请从 Weblate 管理界面进行:

_images/ssh-keys.png

Weblate SSH 密钥

Weblate 公钥对浏览 About 页面的所有用户可见。

管理员可以在管理界面登录页面的连接部分(从 SSH keys)生成或显示 Weblate 当前使用的公共密钥。

注解

相应的私有 SSH 密钥当前无法使用密码,因此请确保已受到良好的保护。

提示

对生成的私有 Weblate SSH 密钥进行备份。

验证 SSH 主机密钥

Weblate 在第一次访问时自动存储SSH主机密钥,并记住它们以备将来使用。

如果要在连接到仓库之前对密钥指纹进行验证,请从管理界面的同一部分 :guilabel: ‘ add host key ‘ 添加你要访问的服务器的 SSH 主机密钥。输入您要访问的主机名(例如 gitlab.com),然后按 Submit。验证其指纹与您添加的服务器匹配。

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

_images/ssh-keys-added.png

GitHub 仓库

Access via SSH is possible (see SSH 仓库), but in case you need to access more than one repository, you will hit a GitHub limitation on allowed SSH key usage (since each key can be used only once).

In case the 推送分支 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 密钥) 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 internal URLs

Share one repository setup between different components by referring to its placement as weblate://project/component in other(linked) components. This way linked components use the VCS repository configuration of the main(referenced) component.

警告

Removing main component also removes linked components.

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 导出器).

  • Some addons can operate on multiple components sharing one repository, for example 压缩(Squash) Git 提交.

HTTPS repositories

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.

注解

如果你的用户名和密码包含特殊字符,需要对URL进行encode编码,例如 https://user%40example.com:%24password%23@bitbucket.org/…

使用代理

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

注解

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

Git

提示

Weblate 需要 Git 2.12 或更新版本。

参见

See Accessing repositories for info on how to access different kinds of repositories.

Git 强制推送

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.

警告

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

警告

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

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 pushes changes directly to a repository, while GitHub creates pull requests. The latter is not needed for merely accessing Git repositories.

Pushing changes to GitHub as pull requests

If not wanting to push translations to a GitHub repository, they can be sent as either one or many pull requests instead.

你需要配置API凭证以使其生效。

GitLab

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.

There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while GitLab creates merge request.

Pushing changes to GitLab as merge requests

If not wanting to push translations to a GitLab repository, they can be sent as either one or many merge requests instead.

你需要配置API凭证以使其生效。

Pagure

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.

There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Pagure creates merge request.

将作为合并请求的更改推送到Pagure

If not wanting to push translations to a Pagure repository, they can be sent as either one or many merge requests instead.

你需要配置API凭证以使其生效。

Gerrit

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.

The Gerrit documentation has the details on the configuration necessary to set up such repositories.

Mercurial

2.1 新版功能.

Mercurial is another VCS you can use directly in Weblate.

注解

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

参见

See Accessing repositories for info on how to access different kinds of repositories.

Subversion

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.

注解

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.

在 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

参见

DATA_DIR

本地文件

Git

提示

Underneath, this uses Git. It requires Git installed and allows you to switch to using Git natively with full history of your translations.

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.