バージョン管理との連携¶
Weblate currently supports Git (with extended support for GitHub プルリクエスト, GitLab マージリクエスト, Gitea プルリクエスト, Gerrit review requests, Subversion, Bitbucket Cloud のプルリクエスト, Bitbucket Data Center のプルリクエスト, and Azure DevOps プル リクエスト) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see コードホスティング統合.
リポジトリへの接続¶
使用する VCS リポジトリに Weblate から接続することが必要です。公開されているリポジトリの場合は、正しい URL（例: https://github.com/WeblateOrg/weblate.git）を入力するだけですが、プライベートなリポジトリやプッシュ URL の場合は、設定がより複雑になり、認証が必要です。
Troubleshooting repository URLs¶
Weblate validates repository and push URLs before connecting. HTTPS and SSH
are permitted by default; instance administrators can adjust this using
VCS_ALLOW_SCHEMES.
Repository hostnames have to resolve from the Weblate server. When
VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations
which resolve to internal or otherwise non-public addresses. Use a publicly
reachable repository URL where possible. For an intentionally private
repository on a trusted network, ask the instance administrator to add its
hostname to VCS_ALLOW_HOSTS.
Git over HTTPS and SSH can bind connections to addresses approved during
validation. Backends which cannot do this safely, including Mercurial and
Subversion, require the trusted repository hostname in
VCS_ALLOW_HOSTS while private-address restrictions are enabled.
Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.
Hosted Weblate からリポジトリへの接続¶
注釈
このセクションは hosted.weblate.org の Hosted Weblate のみ に適用されます。独自に Weblate をホストしている場合は、代わりに 次のセクション を参照してください。
For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate's Connect GitHub account flow whenever possible. The App grants repository access, receives incoming notifications, pushes translation branches, and creates pull requests without inviting the Hosted Weblate weblate user. See GitHub リポジトリアクセス for the full setup.
For direct SSH access outside the GitHub App workflow, and for Bitbucket,
Codeberg, and GitLab repositories, Hosted Weblate has a dedicated push user
(with the username weblate, e-mail hosted@weblate.org, and a
name or profile description Weblate push user).
ヒント
プラットフォーム上には、他の Weblate インスタンス用に指定された、多くの Weblate ユーザーが存在します。Hosted Weblate の正しいユーザーを見つけるには、メールアドレス hosted@weblate.org で検索してください。
このユーザーをコラボレーターとして追加し、リポジトリに適切な権限を与えてください（クローンは読み取り権限で十分、プッシュは書き込み権限が必須）。サービスとユーザーの組織の設定によって、すぐに反映されるか、Weblate 側で確認が必要です。
The weblate user on GitHub accepts invitations automatically within five minutes when you intentionally use direct SSH access there. Manual processing might be needed on the other services, so please be patient.
For this direct SSH-user setup, once the weblate user is added to
your repository, you can configure ソースコードのリポジトリ and
リポジトリの送信先 URL using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, ...)¶
注釈
このセクションは 自己ホスト型 の Weblate インスタンスに適用されます。Hosted Weblate（hosted.weblate.org）を使用している場合は、代わりに Hosted Weblate からリポジトリへの接続 を確認してください。
For self-hosted Weblate, a single private repository is often easiest to set up using an HTTPS repository URL with an access token, see コードホスティング統合.
For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Weblate SSH 鍵). This way you associate Weblate SSH key with a single user, because platforms frequently enforce single use of an SSH key. Grant this user access to the repositories, and use SSH URLs to access them (see SSH リポジトリ).
SSH リポジトリ¶
One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate SSH 鍵) to access the upstream repository this way.
警告
On GitHub, each key can only be used once, see GitHub リポジトリアクセス and Hosted Weblate からリポジトリへの接続.
また、Weblate は最初の接続時にホスト鍵のフィンガープリントを保存し、後で変更した場合にはホストに接続できません（参照: SSH ホスト認証鍵の承認）。
変更が必要な場合は、Weblate 管理インタフェースから設定します。
Weblate SSH 鍵¶
バージョン 4.17 で変更: Weblate は、RSA と Ed25519 の両方の SSH 鍵を生成できるようになりました。新規セットアップでは Ed25519 の使用を推奨します。
Weblate 公開鍵は、About ページを閲覧するすべてのユーザーに表示されます。
管理者は、管理画面のランディング ページ内の接続（ラベル SSH 鍵）で Weblate が現在使用している公開鍵を生成または表示できます。
注釈
対応するプライベート SSH 鍵は現在パスワードを設定できないため、適切に保護されているか確認してください。
ヒント
生成されたプライベートな Weblate の SSH 鍵のバックアップを作成します。
SSH ホスト認証鍵の承認¶
Weblate は、次回からの接続のために、最初の接続時に SSH ホスト認証鍵を自動的に記録します。
When VCS_RESTRICT_PRIVATE is enabled, Weblate resolves and validates
the repository host before scanning its key and connects ssh-keyscan only
to the approved addresses. The stored key remains associated with the original
hostname.
For Git connections, Weblate also applies HostName and Port from
DATA_DIR/ssh/config before validating and pinning the effective
destination. SSH configuration and SSH_EXTRA_ARGS are trusted
administrator-controlled inputs. They can alter connection routing, and
SSH_EXTRA_ARGS can override Weblate's address pinning;
administrators are responsible for their effects.
リポジトリに接続する前に公開鍵の指紋を確認する場合は、管理画面の同じセクションから ホスト鍵の追加 で接続するサーバーの SSH ホスト認証鍵を追加してください。接続するホスト名（例: gitlab.com）を入力し、送信 を押します。公開鍵の指紋が追加したサーバーと一致しているかどうかを確認します。
確認メッセージに表示される、追加した公開鍵の指紋:
従来の SSH サーバーへの接続¶
Weblate suppresses the OpenSSH warning about connections without post-quantum key exchange so that it does not obscure repository errors. This does not change algorithm negotiation: post-quantum key exchange is still used when supported by both the client and server. Other SSH warnings remain enabled. Upgrade or configure the SSH server to support post-quantum key exchange to protect against "store now, decrypt later" attacks.
最近の OpenSSH リリース（たとえば Weblate Docker コンテナで使用されているもの）では、デフォルトで SHA-1 ハッシュ アルゴリズムを使用した RSA 署名が無効になっています。この変更は、SHA-1 ハッシュ アルゴリズムが暗号学的に破られているため、選択したプレフィックスのハッシュ衝突を <USD $50K で作成できることが可能であるために行われました。
ほとんどのユーザーにとって、この変更は目立たず、ssh-rsa 鍵を置き換える必要はありません。OpenSSH は、リリース 7.2 以降、RFC8332 RSA/SHA-256/512 署名に対応しており、既存の ssh-rsa 鍵は、可能な限り強力なアルゴリズムを自動的に使用します。
非互換性は、アップグレードされていない古い SSH 実装や、SSH プロトコルの改善を綿密に追跡していない古い SSH 実装に接続する場合に発生する可能性が高くなります。このようなサーバーへの接続に失敗する SSH 接続:
no matching host key type found. Their offer: ssh-rsa
このような場合、HostkeyAlgorithms および PubkeyAcceptedAlgorithms オプションを使用して、接続および/またはユーザー認証のために RSA/SHA1 を選択的に再有効化する必要があります。たとえば、DATA_DIR/ssh/config の次のスタンザは、単一の宛先ホストに対してホストおよびユーザー認証用の RSA/SHA1 を有効化します。
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
従来の実装をアップグレードしたり、別の鍵タイプ（ECDSA や Ed25519 など）に再構成したりできるまで、RSA/SHA1 を有効にするのは一時的な措置としてのみ推奨します。
GitHub リポジトリ¶
Detailed GitHub repository access is covered in GitHub リポジトリアクセス.
GitHub リポジトリ¶
Detailed GitLab repository access is covered in GitHub リポジトリアクセス.
Weblate の内部 URL¶
複数のコンポーネント間で 1 つのリポジトリ設定を共有するには、他の（リンクされた）コンポーネントから weblate://project/component の形式で参照します。これにより、リンクされたコンポーネントは、参照元となるメイン コンポーネントの VCS リポジトリ設定を使用します。
警告
メイン コンポーネントを削除すると、リンクされているコンポーネントも削除されます。
Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component's repository configuration.
Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.
Weblate は、コンポーネントの作成時に、リポジトリ設定が一致するコンポーネントを見つけると、自動的にリポジトリの URL を修正します。URL は、コンポーネント設定の最後の段階で上書きできます。
使用理由:
サーバーのディスク容量を節約。リポジトリは一度だけ保存される。
更新を高速化する。リポジトリは 1 つだけ更新される。
Weblate 翻訳を使用してエクスポートするリポジトリは 1 つだけ（参照: Git エクスポーター）。
一部のアドオンでは、単一のリポジトリを共有する複数のコンポーネント上で動作するものもあります。例: Git コミットのスカッシュ。
HTTPS リポジトリ¶
保護された HTTPS リポジトリに接続するには、URL にユーザー名とパスワードを含めます。心配は無用です、URL がユーザーに表示されるときに、Weblate はこの情報を削除します（リポジトリ URL の表示を許可していても）。
例えば、認証を追加した GitHub URL は次のようになります: https://user:your_access_token@github.com/WeblateOrg/weblate.git。
URL に認証情報を含めず、かつリポジトリが認証を必要とする場合に Git が出力するエラー:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
バージョン 5.10.2 で変更: Weblate は、HTTP 認証情報が提供された場合、Git 2.46.0 以降でプロアクティブ認証を使用します。
これにより Azure DevOps のリポジトリへ接続が可能になり、認証が必要なリポジトリへの接続も高速化されます。
注釈
ユーザー名やパスワードに特殊文字を含む場合は、URL をエンコードすることが必要です https://user%40example.com:%24password%23@bitbucket.org/…。
プロキシの使用¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in HTTP プロキシ.
Version control parameters¶
Added in version 2026.9.
Version control parameters tune how a component interacts with its repository without having to choose a different version control system. They are configured per component in Version control parameters, and only the parameters applicable to the selected バージョン管理システム are offered.
List of version control parameters¶
パラメータ名 |
Version control systems |
ラベル |
説明 |
|---|---|---|---|
create_merge_request |
|
Create merge requests |
Open a pull or merge request for the translation changes. When turned off, Weblate pushes to the translated branch directly, which requires write access to it. |
git_force_push |
|
Force push |
Overwrite the remote branch instead of refusing to push non-fast-forward changes. Only use this with a repository dedicated to translations, as it discards upstream commits which are not present in Weblate. |
merge_request_assign_acting_user |
|
Assign pull requests to acting user |
Also assign the GitHub account linked to the Weblate user who starts the push, when available. |
merge_request_assignee |
|
Pull request assignee |
GitHub username to assign to pull requests created by Weblate. |
merge_request_automerge |
|
Merge pull requests automatically |
Turn on GitHub auto-merge for pull requests created by Weblate, so that they are merged once the required checks pass. Pull requests with nothing to wait for are merged right away. |
merge_request_labels |
|
Pull request labels |
Comma-separated names of labels to add to pull requests created by Weblate. Existing labels are kept. |
merge_request_merge_method |
|
マージ方法 |
Method used when merging pull requests automatically. The repository has to allow it. 設定できる値:
|
Git¶
ヒント
Weblate needs Git 2.46 or newer.
注釈
Weblate validates permanent HTTP redirects which stay on the repository hostname and automatically stores the canonical repository URL. The change is recorded in the component history as repository maintenance. Redirects to another hostname have to be configured manually.
参考
さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。
Git LFS¶
Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.
A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.
For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.
Git submodules¶
Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.
If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.
Force pushing¶
Turn on the git_force_push version control parameter to
make Weblate always force push. This is intended only in the case of using a
separate repository for translations.
警告
上流のリポジトリではコミットが失われやすいので、注意して使用してください。
バージョン 2026.9 で変更: This used to be a separate Git with force push version control
system. Existing components were migrated to Git with the git_force_push
parameter turned on.
Git 設定のカスタマイズ¶
Weblate は、すべての VCS コマンドを HOME=$DATA_DIR/home （参照: DATA_DIR）で実行します。したがって、ユーザー設定の編集は DATA_DIR/home/.git で行うことが必要です。
GitHub プルリクエスト¶
Detailed GitHub pull request setup is covered in GitHub プルリクエスト.
GitLab マージリクエスト¶
Detailed GitLab merge request setup is covered in GitLab マージリクエスト.
Gitea プルリクエスト¶
Detailed Gitea pull request setup is covered in Gitea プルリクエスト.
Bitbucket Data Center のプルリクエスト¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket Data Center のプルリクエスト.
Bitbucket Cloud のプルリクエスト¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket Cloud のプルリクエスト.
Pagure マージリクエスト¶
Detailed Pagure merge request setup is covered in Pagure マージリクエスト.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure DevOps プル リクエスト¶
Detailed Azure DevOps pull request setup is covered in Azure DevOps プル リクエスト.
Mercurial¶
Mercurial は、Weblate で直接使用できるもう 1 つの VCS です。
Mercurial subrepositories are disabled for all repository operations. A revision
which uses .hgsub can fail to clone, update, or commit. Convert these
repositories to avoid subrepositories, or manage their contents outside Weblate.
When accessing an existing Mercurial checkout, Weblate removes nested
.hg and .git metadata under the repository lock. It preserves the
main .hg directory and working files. Project backups omit nested VCS
metadata as well.
注釈
Mercurial のどのバージョンでも動作するはずですが、コマンドライン インタフェースに互換性のない変更が追加されたので、Weblate との連携ができないことがあります。
参考
さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。
Subversion¶
Weblate は git-svn を使用して subversion リポジトリと通信します。これは、Git クライアントで Subversion を使用できる Perl スクリプトで、ユーザーは内部リポジトリの完全なクローンを維持し、ローカルでコミットできるようにします。
注釈
Weblate は Subversion リポジトリ レイアウトを自動的に検出しようとします ー ブランチの直接の URL と標準レイアウトのリポジトリ（branches/、tags/、および trunk/）の両方に対応しています。詳細は git-svn documentation を確認してください。標準レイアウトではないリポジトリでエラーが発生した場合は、リポジトリ URL にブランチ名を含め、ブランチを空のままにしてください。
Subversion 認証情報¶
Weblate では、証明書を事前に受け入れることを想定しています（必要であれば認証情報も）。これは、DATA_DIR ディレクトリに保存されます。'svn' を使用して 、'$HOME' 環境変数を 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
参考
ローカル ファイル¶
ヒント
内部では、Git を使用しています。Git がインストールされていることが前提ですが、Git をネイティブに使用するように切り替えて、翻訳の完全な履歴を残すことができます。
Weblate は、リモート VCS がなくても動作します。最初の翻訳は、アップロードするとインポートされます。あとで、個々のファイルをファイル アップロードで置き換えるか、Weblate から直接、翻訳文字列を追加できます（現在、モノリンガル翻訳でのみ使用できます）。
Weblate はバックグラウンドで Git リポジトリを作成し、すべての変更を記録します。後で VCS を使用して翻訳を保存する場合は、すでに Weblate 内に統合のベースとなるリポジトリがあります。