バージョン管理との連携¶
Weblate は現在、バージョン管理のバックエンドとして Git （さらに GitHub プルリクエスト、GitLab マージリクエスト、Gitea プルリクエスト、Gerrit、Subversion、Bitbucket Cloud のプルリクエスト、Bitbucket Data Center のプルリクエスト、および Azure DevOps プル リクエスト への追加機能を含む）および Mercurial に対応しています。
リポジトリへの接続¶
使用する VCS リポジトリに Weblate から接続することが必要です。公開されているリポジトリの場合は、正しい URL（例: https://github.com/WeblateOrg/weblate.git）を入力するだけですが、プライベートなリポジトリやプッシュ URL の場合は、設定がより複雑になり、認証が必要です。
Hosted Weblate からリポジトリへの接続¶
注釈
このセクションは hosted.weblate.org の Hosted Weblate のみ に適用されます。独自に Weblate をホストしている場合は、代わりに 次のセクション を参照してください。
Hosted Weblate の場合、GitHub、Bitbucket、Codeberg、GitLab に Weblate 専用のプッシュ ユーザーを登録しています（ユーザー名 weblate、メールアドレス hosted@weblate.org、および名前またはプロフィールの説明は Weblate プッシュ ユーザー）。
ヒント
プラットフォーム上には、他の Weblate インスタンス用に指定された、多くの Weblate ユーザーが存在します。Hosted Weblate の正しいユーザーを見つけるには、メールアドレス hosted@weblate.org で検索してください。
このユーザーをコラボレーターとして追加し、リポジトリに適切な権限を与えてください（クローンは読み取り権限で十分、プッシュは書き込み権限が必須）。サービスとユーザーの組織の設定によって、すぐに反映されるか、Weblate 側で確認が必要です。
GitHub の weblate ユーザーは、5 分以内に自動的に招待が承認されます。他のサービスでは手動での処理が必要なことがありますが、我慢してください。
自分のリポジトリに weblate ユーザーを追加すると、SSH プロトコル（例: git@github.com:WeblateOrg/weblate.git）を使用して ソースコードのリポジトリ と リポジトリの送信先 URL を設定できます。
コード ホスティング サイト (GitHub、GitLab、Bitbucket、Azure DevOps など) のリポジトリへの接続¶
注釈
このセクションは 自己ホスト型 の Weblate インスタンスに適用されます。Hosted Weblate（hosted.weblate.org）を使用している場合は、代わりに Hosted Weblate からリポジトリへの接続 を確認してください。
自己ホスト型の Weblate では、コード ホスティング サイトのリポジトリに接続するには、通常は Weblate の SSH 鍵に関連付けた専用ユーザーを作成して接続します（参照: Weblate SSH 鍵）。こうすることで、Weblate の SSH 鍵を単一のユーザーに紐づけ（多くのプラットフォームでは SSH 鍵の単一利用を強制される）、そのユーザーにリポジトリへのアクセス権を付与します。その後、SSH URL を使用してリポジトリに接続できます（参照: SSH リポジトリ）。
SSH リポジトリ¶
プライベート リポジトリに接続するために最もよく使用される方法は、SSH による接続です。SSH で上流リポジトリに接続するために、Weblate SSH 公開鍵（参照: Weblate SSH 鍵）を承認します。
警告
GitHub では、各キーは 1 度しか使用できません。参照: GitHub リポジトリ および Hosted Weblate からリポジトリへの接続。
また、Weblate は最初の接続時にホスト鍵のフィンガープリントを保存し、後で変更した場合にはホストに接続できません（参照: SSH ホスト認証鍵の承認）。
変更が必要な場合は、Weblate 管理インタフェースから設定します。
Weblate SSH 鍵¶
バージョン 4.17 で変更: Weblate は、RSA と Ed25519 の両方の SSH 鍵を生成できるようになりました。新規セットアップでは Ed25519 の使用を推奨します。
Weblate 公開鍵は、About ページを閲覧するすべてのユーザーに表示されます。
管理者は、管理画面のランディング ページ内の接続（ラベル SSH 鍵）で Weblate が現在使用している公開鍵を生成または表示できます。
注釈
対応するプライベート SSH 鍵は現在パスワードを設定できないため、適切に保護されているか確認してください。
ヒント
生成されたプライベートな Weblate の SSH 鍵のバックアップを作成します。
SSH ホスト認証鍵の承認¶
Weblate は、次回からの接続のために、最初の接続時に SSH ホスト認証鍵を自動的に記録します。
リポジトリに接続する前に公開鍵の指紋を確認する場合は、管理画面の同じセクションから ホスト鍵の追加 で接続するサーバーの SSH ホスト認証鍵を追加してください。接続するホスト名（例: gitlab.com）を入力し、送信 を押します。公開鍵の指紋が追加したサーバーと一致しているかどうかを確認します。
確認メッセージに表示される、追加した公開鍵の指紋:
従来の SSH サーバーへの接続¶
最近の 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 リポジトリ¶
主に 2 つある、Weblate から GitHub リポジトリへ接続する方法:
オプション 1：HTTPS と個人アクセス トークン（導入が簡単）
GitHub アカウントと個人アクセストークンを使って HTTPS 認証を行います。これは読み取り専用アクセス（クローン）にも、書き込みアクセス（変更のプッシュやプルリクエストの作成）にも使用します。
この方法を使用する手順:
コマンドラインで使用するためのアクセス トークンの作成 に記載されている手順に従って、個人アクセス トークンを作成します。
リポジトリに含めるトークンの URL：
https://username:token@github.com/owner/repo.git
これは、Weblate を使い始めたばかりの場合や、単一のリポジトリで作業している場合に適した方法です。
オプション 2：専用ユーザーによる SSH 接続（複数リポジトリの場合に推奨）
複数のリポジトリを扱う設定では、Weblate 専用のユーザーを作成することが推奨されます。これにより、各 SSH 鍵をプラットフォーム上で 1 回しか使用できないという GitHub の制限を回避できます。
この方法を使用する手順:
専用の GitHub ユーザーアカウント（例:
weblate-bot）を作成します。このユーザーに Weblate の公開 SSH 鍵を追加します（参照: Weblate SSH 鍵。
翻訳したいすべてのリポジトリに、このユーザーへのアクセス権を付与します。
リポジトリに使用する SSH の URL：
git@github.com:owner/repo.git
この方法は Hosted Weblate でも採用されており、そのため専用の weblate ユーザーが用意されています。
注釈
GitHub プルリクエスト を使ってプルリクエストを行う場合、プッシュ先のブランチ の設定内容によって動作が変わります。未設定の場合はプロジェクトがフォークされ、変更はフォーク経由でプッシュされます。設定されている場合は、変更が上流のリポジトリと指定したブランチへ直接プッシュされます。
GitHub リポジトリ¶
SSH 経由での接続もできますが（参照: SSH リポジトリ）、複数のリポジトリに接続することが必要な場合は、許可された SSH 鍵の使用は GitHub の使用回数制限を受けます（各認証鍵の使用は 1 回限り）。
プッシュ先のブランチ を設定していない場合、プロジェクトはフォークされ、変更はフォークを通してプッシュされます。設定されている場合、変更は上流リポジトリと選択したブランチにプッシュされます。
個人アクセス トークンやプロジェクト アクセス トークンを使用することも可能です。リポジトリへ変更をプッシュするには、トークンに write_repository スコープが必要です。また、プロジェクト アクセス トークンでプッシュを行う場合は、Developer ロールが必要となります。
URL にはユーザー名を含めてください。個人アクセストークンの場合は実際のユーザー名を使用します（https://user:personal_access_token@gitlab.com/example/example.git）。プロジェクトアクセストークンの場合は、空でない値を指定します（https://example:project_access_token@gitlab.com/example/example.git）。
注釈
プロジェクト アクセス トークンの利用するルールは GitLab のリリースにより変更されます。現在は「空でない値」を指定することが必須ですが、過去のバージョンでは、プロジェクト名やボットユーザー名を要求するなど、異なる仕様が存在していました。不明な場合は、使用している GitLab バージョンに対応した公式ドキュメントを確認してください。
Weblate の内部 URL¶
複数のコンポーネント間で 1 つのリポジトリ設定を共有するには、他の（リンクされた）コンポーネントから weblate://project/component の形式で参照します。これにより、リンクされたコンポーネントは、参照元となるメイン コンポーネントの VCS リポジトリ設定を使用します。
警告
メイン コンポーネントを削除すると、リンクされているコンポーネントも削除されます。
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/…。
プロキシの使用¶
プロキシー サーバーを使用して HTTP/HTTPS VCS リポジトリに接続することが必要な場合は、VCS の使用を設定します。
これは環境変数（cURL documentation に記載の通り）の http_proxy、 https_proxy、および all_proxy を使用するか、VCS 設定で次のように実行する:
git config --global http.proxy http://user:password@proxy.example.com:80
注釈
プロキシの設定は、Weblate を実行しているユーザー（参照: ファイル システムのアクセス権）と HOME=$DATA_DIR/home （参照: DATA_DIR）を使用して設定することが必要です。他の設定だと、Weblate は Git を実行しません。
Git¶
ヒント
Weblate の実行には Git 2.28 以降が必要です。
参考
さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。
Git に強制プッシュ¶
これは Git 自体とまったく同じように動作しますが、唯一の違いは、常に強制的にプッシュすることです。これは、翻訳に別のリポジトリを使用する場合にのみ使用します。
警告
上流のリポジトリではコミットが失われやすいので、注意して使用してください。
Git 設定のカスタマイズ¶
Weblate は、すべての VCS コマンドを HOME=$DATA_DIR/home （参照: DATA_DIR）で実行します。したがって、ユーザー設定の編集は DATA_DIR/home/.git で行うことが必要です。
GitHub プルリクエスト¶
これにより、リポジトリに直接プッシュするのではなく、GithHub API を使用して 、薄いレイヤーを Git に追加して、変更された翻訳をプルリクエストとしてプッシュできるようになります。
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 Data Center のプルリクエスト¶
Added in version 4.16.
これで Git の上に薄いレイヤーを追加し、Bitbucket Data Center API を使用してリポジトリへ直接プッシュする代わりに、翻訳変更をプルリクエストとしてプッシュできるようになります。
警告
Bitbucket Cloud API には対応していません。
Git リポジトリにアクセスするために、これを使用する必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Bitbucket Data Center のプルリクエスト ではプルリクエストが作成されます。
この機能を使用するには、Weblate の設定で API 認証情報（BITBUCKETSERVER_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に Bitbucket Server オプションが表示されるようになります。
Bitbucket Cloud のプルリクエスト¶
Added in version 5.8.
これで Git の上に薄いレイヤーを追加し、Bitbucket Cloud API を利用してリポジトリへ直接プッシュする代わりに、翻訳変更をプルリクエストとしてプッシュできるようになります。
警告
これは Bitbucket Data Center API とは異なります。
Git リポジトリに接続するために、これを使用する必要はありません。通常の Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Bitbucket Cloud のプルリクエスト ではプルリクエストが作成されます。
この機能を使用するには、Weblate の設定で API 認証情報（BITBUCKETCLOUD_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に Bitbucket Cloud オプションが表示されます。
Pagure マージリクエスト¶
Added in version 4.3.2.
これにより、リポジトリに直接プッシュするのではなく、Pagure API を使用して 、薄いレイヤーを Git に追加するだけで、変更された翻訳をプルリクエストとしてプッシュできます。
Git リポジトリにアクセスするために、これを使う必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Pagure マージリクエスト ではマージリクエストが作成されます。
この機能を使用するには、Weblate の設定で API 認証情報（PAGURE_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に、Pagure オプションが表示されます。
Gerrit¶
git-review ツールを使用して、リポジトリに直接プッシュするのではなく、Gerrit レビュー リクエストとして変更された翻訳をプッシュするために、Git の上に薄いレイヤを追加します。
Gerrit ドキュメントには、このようなリポジトリを設定するために必要な設定の詳細が記載されています。
Azure DevOps プル リクエスト¶
これにより、リポジトリに直接プッシュするのではなく、Azure DevOps API を使用して 、薄いレイヤーを Git に追加して、変更された翻訳をプルリクエストとしてプッシュできるようになります。
Git は変更を直接リポジトリにプッシュしますが、Azure DevOps プル リクエスト はプルリクエストを作成します。後者は Git リポジトリに接続する場合には必要ありません。
この機能を使用するには、Weblate の設定で API 認証情報（AZURE_DEVOPS_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に、Azure DevOps の選択肢が表示されます。
Mercurial¶
Mercurial は、Weblate で直接使用できるもう 1 つの VCS です。
注釈
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 内に統合のベースとなるリポジトリがあります。