バージョン管理との連携¶
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 Code hosting integrations.
リポジトリへの接続¶
使用する 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 側で確認が必要です。
On GitHub, you need to add or invite the Hosted Weblate weblate user with write access even when you use the Hosted Weblate GitHub app. The app handles incoming notifications from GitHub, but pushing changes back still uses the Hosted Weblate weblate user.
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 からリポジトリへの接続 を確認してください。
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate SSH 鍵). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of an SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH リポジトリ).
SSH リポジトリ¶
プライベート リポジトリに接続するために最もよく使用される方法は、SSH による接続です。SSH で上流リポジトリに接続するために、Weblate SSH 公開鍵（参照: Weblate SSH 鍵）を承認します。
警告
On GitHub, each key can only be used once, see GitHub repository access 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 ホスト認証鍵を自動的に記録します。
リポジトリに接続する前に公開鍵の指紋を確認する場合は、管理画面の同じセクションから ホスト鍵の追加 で接続するサーバーの 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 リポジトリ¶
Detailed GitHub repository access is covered in GitHub repository access.
GitHub リポジトリ¶
Detailed GitLab repository access is covered in GitLab repository access.
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 プルリクエスト¶
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 のどのバージョンでも動作するはずですが、コマンドライン インタフェースに互換性のない変更が追加されたので、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 内に統合のベースとなるリポジトリがあります。