バージョン管理との連携¶
Weblate は現在、バージョン管理のバックエンドとして Git （GitHub プルリクエスト、GitLab マージリクエスト、Gitea プルリクエスト、Gerrit、Subversion、Bitbucket Server プルリクエスト、および Azure DevOps プル リクエスト の拡張サポート付き）および Mercurial に対応しています。
リポジトリへの接続¶
使用する VCS リポジトリに Weblate から接続することが必要です。公開されているリポジトリの場合は、正しい URL（例: https://github.com/WeblateOrg/weblate.git）を入力するだけですが、プライベートなリポジトリやプッシュ URL の場合は、設定がより複雑になり、認証が必要です。
Hosted 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 SSH 鍵に関連付けられた専用ユーザーを作成します（参照: Weblate SSH 鍵）。この方法で、Weblate SSH 鍵を単一のユーザーに関連付け（これはプラットフォームによって頻繁に強制されます）、このユーザーにリポジトリへの接続を許可します。その後、SSH URL を使用してリポジトリに接続できます（参照: SSH リポジトリ）。
ヒント
Hosted Weblate では、これはほとんどの公開サイトに対して事前に設定されています。参照: Hosted Weblate からリポジトリへの接続。
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 が現在使用している公開鍵を生成または表示できます。
注釈
The corresponding private SSH key can not currently have a password, so ensure it is well protected.
ヒント
生成されたプライベートな 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 リポジトリ¶
SSH 経由での接続もできますが（参照: SSH リポジトリ）、複数のリポジトリに接続することが必要な場合は、許可された SSH 認証鍵の使用は GitHub の制限を受けます（各認証鍵の使用は 1 度のみ）。
プッシュ先のブランチ を設定していない場合、プロジェクトはフォークされ、変更はフォークを通してプッシュされます。設定されている場合、変更は上流リポジトリと選択したブランチにプッシュされます。
小規模な設置の場合は、HTTPS 認証で個人用アクセス トークンと GitHub アカウントを使用します。参照: Creating an access token for command-line use 。
大規模な設置の場合は、通常、Weblate 専用のユーザーを作成し、そこに Weblate で生成した公開 SSH 認証鍵（参照: Weblate SSH 鍵）を割り当て、翻訳したいすべてのリポジトリへの接続を許可することを推奨します。このアプローチは Hosted Weblate にも適用され、専用の weblate ユーザーが存在します。
Weblate の内部 URL¶
異なるコンポーネント間でリポジトリ設定を共有するには、他の（リンクする）コンポーネントから 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 をエンコードすることが必要です 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.12 以降が必要です。
参考
さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。
Git に強制プッシュ¶
これは Git 自体とまったく同じように動作しますが、唯一の違いは、常に強制的にプッシュすることです。これは、翻訳に別のリポジトリを使用する場合にのみ使用します。
警告
上流のリポジトリではコミットが失われやすいので、注意して使用してください。
Git 設定のカスタマイズ¶
Weblate は、すべての VCS コマンドを HOME=$DATA_DIR/home （参照: DATA_DIR）で実行します。したがって、ユーザー設定の編集は DATA_DIR/home/.git で行うことが必要です。
Git リモート ヘルパー¶
他のバージョン管理システムを追加して対応するために remote helpers を使用できますが、これにより発生する可能性がある問題をデバッグする準備をしてください。
現在のところ、Bazaar と Mercurial のヘルパーは GitHub 上の別々のリポジトリ、GitHub: git-remote-hg と git-remote-bzr で利用できます。手動でダウンロードし、検索パス（例: ~/bin）に配置します。対応するバージョン管理システムがインストールされていることを確認してください。
これらをインストールしたら、このようなリモートを使用して Weblate でリポジトリを設定できます。
Bazaar を使用して Launchpad から gnuhello プロジェクトの複製:
bzr::lp:gnuhello
Mercurial を使用した selenic.com の hello リポジトリの場合:
hg::http://selenic.com/repo/hello
警告
Git のリモート ヘルパーを使う上で不便な点は、例えば Mercurial の場合、変更を元に戻すときにリモート ヘルパーが新しい tip を作成してしまうことがあります。
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 Server プルリクエスト¶
Added in version 4.16.
これは、Bitbucket Server API を使用して Git の上に薄いレイヤーを追加するだけで、リポジトリに直接プッシュするのではなく、翻訳の変更をプルリクエストとしてプッシュできます。
警告
Bitbucket Cloud API には対応していません。
Git リポジトリにアクセスするために、これを使用する必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Bitbucket Server プルリクエスト ではプルリクエストが作成されます。
この機能を使用するには、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 ツールを使用して、リポジトリに直接プッシュするのではなく、Gerrit レビュー リクエストとして変更された翻訳をプッシュするために、Git の上に薄いレイヤを追加します。
Gerrit ドキュメントには、このようなリポジトリを設定するために必要な設定の詳細が記載されています。
Azure DevOps プル リクエスト¶
これにより、リポジトリに直接プッシュするのではなく、Azure DevOps API を使用して 、薄いレイヤーを Git に追加して、変更された翻訳をプルリクエストとしてプッシュできるようになります。
Git は変更を直接リポジトリにプッシュしますが、vcs-azure-devopsthub はプルリクエストを作成します。後者は 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 内に統合のベースとなるリポジトリがあります。