版本控制集成¶
Weblate 当前支持 Git （扩展支持 GitHub 拉取请求、GitLab 合并请求、Gitea 拉取请求、Gerrit、Subversion、 Bitbucket 服务器拉取请求 及 Azure DevOps 拉取请求）和 Mercurial 作为版本控制后端。
访问仓库¶
您要使用的版本控制系统仓库必须可供 Weblate 访问。对于公开可用的仓库，您只需要输入正确的 URL（例如 https://github.com/WeblateOrg/weblate.git），但对于私有仓库或推送 URL，设置更加复杂并且需要验证。
从 Hosted Weblate 访问仓库¶
Hosted Weblate 在 GitHub、Bitbucket、Codeberg 和 GitLab 上注册有一个专门的推送用户（用户名 weblate、电子邮箱 hosted@weblate.org 以及名称或个人资料描述 Weblate push user）。
提示
这些平台上可以有更多这样的 Weblate 用户，由其他 Weblate 实例所指定。建议搜索电子邮箱 hosted@weblate.org 以找到正确的 Hosted Weblate 推送用户。
您需要将此用户添加为协作者并为其授予对您的仓库的适当权限（克隆可以只读，推送需要写入）。根据服务和您组织的设置，这会立即发生，或者需要在 Weblate 端进行确认。
GitHub 上的 weblate 用户会在五分钟内自动接受邀请。其他服务可能需要人工处理，请耐心等待。
一旦 weblate 用户被添加到你的仓库，你可以使用SSH协议（例如 git@github.com:WeblateOrg/weblate.git）配置 源代码仓库 和 仓库推送 URL 。
访问代码托管站点（GitHub, GitLab, Bitbucket, Azure DevOps, …）上的仓库¶
访问代码托管站点上的仓库通常是通过创建和 Weblate SSH 密钥相关联的专门用户实现的（见 Weblate SSH 密钥）。这样做，你将 Weblate SSH 密钥与单一用户相关联（代码平台经常强制这么做）并授予此用户访问仓库的权限。关联后，你可以使用 SSH URL 来访问仓库（见 SSH 仓库）。
提示
在 Hosted Weblate 上，这对多数公开站点是预先配置好的，请见 从 Hosted Weblate 访问仓库。
SSH 仓库¶
访问私有仓库的最常用方法是基于 SSH。授权公共 Weblate SSH 密钥（请参阅 Weblate SSH 密钥）以这种方式访问上游仓库。
警告
在 Github 上，每个密钥只能用一次，见 GitHub 仓库 和 从 Hosted Weblate 访问仓库。
Weblate 还会在首次连接时存储主机密钥指纹，并且在以后进行更改时将无法连接到主机（请参阅 验证 SSH 主机密钥）。
如果需要调整，请从 Weblate 管理界面进行：
Weblate SSH 密钥¶
在 4.17 版本发生变更: Weblate 现在生成 RSA 和 Ed25519 SSH 密钥。新安装建议使用 Ed25519。
Weblate 公钥对浏览 关于 页面的所有用户可见。
管理员可以在管理界面着陆页的连接部分（从 SSH 密钥）生成或显示 Weblate 当前使用的公共密钥。
备注
相应的 SSH 私钥当前无法使用密码，因此请确保其受到良好的保护。
提示
对生成的私有 Weblate SSH 密钥进行备份。
验证 SSH 主机密钥¶
Weblate 在第一次访问时自动存储SSH主机密钥，并记住它们以备将来使用。
如果你想在连接到仓库之前验证密钥指纹，在管理界面的同一区域，在 添加主机密钥 中添加你要访问的服务器的SSH主机密钥。输入你要访问的主机名（例如： gitlab.com ），然后点击 提交 。确认其指纹与你添加的服务器相匹配。
添加的带指纹的密钥显示在确认消息中：
连接到旧式 SSH 服务器¶
最近的 OpenSSH 发行版（比如用于 Weblate Docker 容器中的 OpenSSH) 默认禁用了使用 SHA-1 哈希算法的 RSA 签名。做出此变化是因为 SHA-1 哈希算法存在密码学缺陷，存在以不到 50 K 美元的成本创建指定前缀哈希碰撞的可能性。
多数用户应该不会注意到这一变化，也无需替换 ssh-rsa 密钥。自 7.2 版本起，OpenSSH便已支持 RFC8332 RSA/SHA-256/512 签名，现有的 ssh-rsa 密钥会在可能的地方自动使用更强的算法。
当连接到尚未升级或尚未密切跟踪 SSH 协议改进的旧 SSH 实现时更有可能发生不兼容。到此类服务器的 SSH 连接会失败，错误为：
no matching host key type found. Their offer: ssh-rsa
对于这些情况，可能需要有选择地重新启用 RSA/SHA1 以允许通过 HostkeyAlgorithms 和 PubkeyAcceptedAlgorithms 选项来允许连接和/或用户身份验证。比如，文件 DATA_DIR/ssh/config 中的下列段落会为单一目标主机的主机和用户身份验证启用 RSA/SHA1:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
我们建议将启用 RSA/SHA1 仅作为可以升级旧实现或使用另一密钥类型（比如 ECDSA 或 Ed25519）前的权宜之计。
GitHub 仓库¶
可以通过 SSH 访问（请参阅 SSH 仓库 ），但如果您需要访问多个仓库，您将遇到 GitHub 对允许使用的 SSH 密钥的限制（因为每个密钥只能使用一次） .
如果 推送分支 未设置，则项目将被分叉并通过分叉推送更改。如果已设置，更改将推送到上游仓库和选择的分支。
对于较小的部署，使用带有个人访问令牌和您的 GitHub 账户的 HTTPS 身份验证，请参阅 创建用于命令行使用的访问令牌 。
对于更大的设置，通常最好为 Weblate 创建一个专用用户，为其分配在 Weblate 中生成的公共 SSH 密钥（请参阅 Weblate SSH 密钥）并授予它访问您要翻译的所有仓库的权限。这种方法也用于 Hosted Weblate，有专门的 weblate 用户。
Weblate 内部网址¶
通过在其他（链接）组件中将其位置称为“weblate://project/component”，在不同组件之间共享一个仓库设置。这样，链接的组件使用主（引用）组件的版本控制系统仓库配置。
警告
删除主部件也会删除链接的部件。
如果 Weblate 找到具有匹配的仓库设置的部件，则在创建组件时会自动调整仓库 URL。您可以在部件配置的最后一步中覆盖它。
使用这个的原因：
HTTPS 仓库¶
要访问受保护的 HTTPS 仓库，请在 URL 中包含用户名和密码。不用担心，当 URL 显示给用户时，Weblate 会删除此信息（如果甚至允许查看仓库 URL）。
例如，添加了身份验证的 GitHub URL 可能如下所示：https://user:your_access_token@github.com/WeblateOrg/weblate.git。
备注
如果你的用户名和密码包含特殊字符，需要对URL进行encode编码，例如 https://user%40example.com:%24password%23@bitbucket.org/…。
使用代理¶
如果需要使用代理服务器访问 HTTP/HTTPS VCS 仓库，请将 VCS 配置为使用它。
这可以使用 http_proxy 、 https_proxy 和 all_proxy 环境变量来完成（如 cURL 文档 中所述）或通过在版本控制系统配置中强制执行，例如：
git config --global http.proxy http://user:password@proxy.example.com:80
Git¶
提示
Weblate 需要 Git 2.12 或更新版本。
参见
有关如何访问不同类型的仓库的信息，请参阅 访问仓库 。
Git 强制推送¶
这与 Git 本身的行为完全一样，唯一的区别是它总是强制推送。这仅适用于使用单独的翻译仓库的情况。
警告
请谨慎使用，因为这很容易导致上游仓库中的提交丢失。
自定义 Git 配置¶
Weblate 使用 HOME=$DATA_DIR/home 调用所有 VCS 命令（请参阅 DATA_DIR），因此需要在 DATA_DIR/home/.git 中完成编辑用户配置。
Git 远程帮助程序¶
您还可以使用 Git 远程帮助程序 来额外支持其他版本控制系统，但要准备好调试这可能导致的问题。
目前，Bazaar 和 Mercurial 的助手可在 GitHub 上的单独仓库中使用：git-remote-hg 和 git-remote-bzr 。手动下载它们并将它们放在搜索路径中的某个位置（例如 ~/bin ）。确保您安装了相应的版本控制系统。
一旦你安装了这些，这些远程可以用来在 Weblate 中指定一个仓库。
使用 Bazaar 从 Launchpad 克隆 gnuhello 项目:
bzr::lp:gnuhello
对于来自 selenic.com 的 hello 仓库使用 Mercurial:
hg::http://selenic.com/repo/hello
警告
使用 Git 远程助手的不便之处在于 Mercurial，远程帮助程序有时会在推送更改时创建新的提示。
GitHub 拉取请求¶
这在 Git 顶部添加了一个薄层，使用 GitHub API 允许将翻译更改作为拉取请求推送，而不是直接推送到仓库。
Git 将更改直接推送到仓库，而 GitHub 拉取请求 创建拉取请求。仅访问 Git 仓库不需要后者。
您需要在 Weblate 设置中配置 API 凭据 (GITHUB_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 GitHub 选项。
GitLab 合并请求¶
这只是使用 GitLab API 在 Git 上添加了一个薄层，以允许将翻译更改作为合并请求推送，而不是直接推送到仓库。
不需要使用它来访问 Git 仓库，普通的 Git 工作方式相同，唯一的区别是如何处理推送到仓库。使用 Git 将更改直接推送到仓库，而 GitLab 合并请求 创建合并请求。
您需要在 Weblate 设置中配置 API 凭据 (GITLAB_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 GitLab 选项。
Gitea 拉取请求¶
Added in version 4.12.
这只是使用 Gitea API 在 Git 上添加了一个薄层，以允许将翻译更改作为拉取请求推送，而不是直接推送到仓库。
不需要使用它来访问 Git 仓库，普通的 Git 工作方式相同，唯一的区别是如何处理推送到仓库。使用 Git 将更改直接推送到仓库，而 Gitea 拉取请求 创建拉取请求。
您需要在 Weblate 设置中配置 API 凭据 (GITEA_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 Gitea 选项。
Bitbucket 服务器拉取请求¶
Added in version 4.16.
这只是使用 Bitbucket Server API 在 Git 上添加了一个薄层，以允许将翻译更改作为拉取请求推送，而不是直接推送到仓库。
警告
这不支持 Bitbucket Cloud API。
不需要使用它来访问 Git 仓库，普通的 Git 工作方式相同，唯一的区别是如何处理推送到仓库。使用 Git 将更改直接推送到仓库，而 Bitbucket 服务器拉取请求 创建拉取请求。
您需要在 Weblate 设置中配置 API 凭据 (BITBUCKETSERVER_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 Bitbucket Server 选项。
Pagure 合并请求¶
Added in version 4.3.2.
这只是使用 Pagure API 在 Git 上添加了一个薄层，以允许将翻译更改作为合并请求推送，而不是直接推送到仓库。
不需要使用它来访问 Git 仓库，普通的 Git 工作方式相同，唯一的区别是如何处理推送到仓库。使用 Git 将更改直接推送到仓库，而 Pagure 合并请求 创建合并请求。
您需要在 Weblate 设置中配置 API 凭据 (PAGURE_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 Pagure 选项。
Gerrit¶
使用 git-review 工具在 Git 上添加一个薄层，以允许将翻译更改作为 Gerrit 审查请求推送，而不是将它们直接推送到仓库。
Gerrit 文档详细介绍了设置此类仓库所需的配置。
Azure DevOps 拉取请求¶
这在 Git 顶部添加了一个薄层，使用 Azure DevOps API 允许将翻译更改作为拉取请求推送，而不是直接推送到仓库。
Git 将更改直接推送到仓库，而 Azure DevOps 拉取请求 创建拉取请求。仅访问 Git 仓库不需要后者。
您需要在 Weblate 设置中配置 API 凭据 (AZURE_DEVOPS_CREDENTIALS) 才能使其工作。配置完成后，您将在选择 版本控制系统 时看到 Azure DevOps 选项。
Mercurial¶
Mercurial 是另一个可以在 Weblate 中直接使用的版本控制系统。
备注
它应该适用于任何 Mercurial 版本，但有时对命令行界面的不兼容更改会破坏 Weblate 集成。
参见
有关如何访问不同类型的仓库的信息，请参阅 访问仓库 。
Subversion¶
Weblate 使用 git-svn 与 subversion 仓库交互。它是一个 Perl 脚本，允许 Git 客户端使用 subversion，使用户能够维护内部仓库的完整克隆并在本地提交。
备注
Weblate 尝试自动检测 Subversion 仓库布局 - 它支持分支的直接 URL 或具有标准布局的仓库（分支/、标签/和主干/）。有关这方面的更多信息，请参阅 git-svn 文档 。如果您的仓库没有标准布局并且遇到错误，请尝试在仓库 URL 中包含分支名称并将分支留空。
Subversion 凭据¶
Weblate 希望您预先接受证书（如果需要，还需要您的凭据）。它会将它们插入到 DATA_DIR 目录中。在 $HOME 环境变量设置为 DATA_DIR 的情况下使用 svn 接受证书：
# 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
参见
本地文件¶
提示
下面，它使用 Git。它需要安装 Git，并允许您切换到本机使用 Git，并提供完整的翻译历史记录。
Weblate 也可以在没有远程 VCS 的情况下运行。初始翻译是通过上传来导入的。稍后您可以通过文件上传替换单个文件，或直接从 Weblate 添加翻译字符串（目前仅适用于单语翻译）。
在后台 Weblate 为您创建一个 Git 仓库并跟踪所有更改。如果您以后决定使用 版本控制系统来存储翻译，您已经在 Weblate 中有一个仓库可以作为您的集成的基础。