バージョン管理との連携#

Weblate は現在、バージョン管理のバックエンドとして Git （GitHub プルリクエスト、GitLab マージリクエスト、Gitea プルリクエスト、Gerrit、Subversion、および Bitbucket Server プルリクエスト の拡張サポート付き）および Mercurial に対応しています。

リポジトリへの接続#

使用する VCS リポジトリに 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 側で確認する必要がある場合があります。

GitHub の weblate ユーザーは、5 分以内に自動的に招待が承認されます。他のサービスでは手動での処理が必要なことがありますが、我慢してください。

weblate ユーザーを追加すると、SSH プロトコル（例: git@github.com:WeblateOrg/weblate.git）を使用して ソースコードのリポジトリ と リポジトリの送信先 URL を設定できます。

SSH リポジトリ#

プライベート リポジトリに接続するために最もよく使用される方法は、SSH による接続です。SSH で上流リポジトリに接続するために、Weblate SSH 公開鍵（参照: Weblate SSH 鍵）を承認します。

警告

GitHub では、各キーは 1 度しか使用できません。参照: GitHub リポジトリ および Hosted Weblate からリポジトリへの接続。

また、Weblate は最初の接続時にホスト鍵のフィンガープリントを保存し、後で変更した場合にはホストに接続できません（参照: SSH ホスト認証鍵の承認）。

変更が必要な場合は、Weblate 管理インタフェースから設定します。

_images/ssh-keys.webp

Weblate SSH 鍵#

バージョン 4.17 で変更: Weblate は、RSA と Ed25519 の両方の SSH 鍵を生成できるようになりました。新規セットアップでは Ed25519 の使用を推奨します。

Weblate 公開鍵は、About ページを閲覧するすべてのユーザーに表示されます。

管理者は、管理画面のランディング ページ内の接続（ラベル SSH 鍵）で Weblate が現在使用している公開鍵を生成または表示できます。

注釈

対応するプライベート SSH 認証鍵は現在パスワードを設定できないため、適切に保護されているか確認してください。

ヒント

生成されたプライベートな Weblate の SSH 認証鍵のバックアップを作成します。

SSH ホスト認証鍵の承認#

Weblate は、次回からの接続のために、最初の接続時に SSH ホスト認証鍵を自動的に記録します。

リポジトリに接続する前に公開鍵の指紋を確認する場合は、管理画面の同じセクションから ホスト鍵の追加 で接続するサーバーの SSH ホスト認証鍵を追加してください。接続するホスト名（例: gitlab.com）を入力し、送信 を押します。公開鍵の指紋が追加したサーバーと一致しているかどうかを確認します。

確認メッセージに表示される、追加した公開鍵の指紋:

_images/ssh-keys-added.webp

GitHub リポジトリ#

SSH 経由での接続もできますが（参照: SSH リポジトリ）、複数のリポジトリに接続することが必要な場合は、許可された SSH 認証鍵の使用は GitHub の制限を受けます（各認証鍵の使用は 1 度のみ）。

プッシュ先のブランチ を設定していない場合、プロジェクトはフォークされ、変更はフォークを通してプッシュされます。設定されている場合、変更は上流リポジトリと選択したブランチにプッシュされます。

小規模な設置の場合は、HTTPS 認証で個人用アクセス トークンと GitHub アカウントを使用します。参照: Creating an access token for command-line use 。

大規模な設置の場合は、通常、Weblate 専用のユーザーを作成し、そこに Weblate で生成した公開 SSH 認証鍵（参照: Weblate SSH 鍵）を割り当て、翻訳したいすべてのリポジトリへの接続を許可することを推奨します。このアプローチは Hosted Weblate にも適用され、専用の weblate ユーザーが存在します。

参考

Hosted 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 を実行しません。

参考

The cURL manpage 、Git config documentation

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 オプションが表示されます。

参考

変更点を Weblate からプッシュ、GITHUB_CREDENTIALS

GitLab マージリクエスト#

これにより、リポジトリに直接プッシュするのではなく、GitLab API を使用して 、薄いレイヤーを Git に追加して、変更された翻訳をプルリクエストとしてプッシュできるようになります。

Gitリポジトリにアクセスするためにこれを使う必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、GitLab マージリクエスト ではマージリクエストが作成されます。

この機能を使用するには、Weblate の設定で API 資格情報（GITLAB_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に、GitLab オプションが表示されます。

参考

変更点を Weblate からプッシュ、GITLAB_CREDENTIALS

Gitea プルリクエスト#

バージョン 4.12 で追加.

これは、Gitea API を使用して Git の上に薄いレイヤーを追加するだけで、リポジトリに直接プッシュするのではなく、翻訳の変更をプルリクエストとしてプッシュできます。

Git リポジトリにアクセスするために、これを使用する必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Gitea プルリクエスト ではプルリクエストが作成されます。

この機能を使用するには、Weblate の設定で API 資格情報（GITEA_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に Gitea オプションが表示されます。

参考

変更点を Weblate からプッシュ、GITEA_CREDENTIALS

Bitbucket Server プルリクエスト#

バージョン 4.16 で追加.

これは、Bitbucket Server API を使用して Git の上に薄いレイヤーを追加するだけで、リポジトリに直接プッシュするのではなく、翻訳の変更をプルリクエストとしてプッシュできます。

警告

Bitbucket Cloud API には対応していません。

Git リポジトリにアクセスするために、これを使用する必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Bitbucket Server プルリクエスト ではプルリクエストが作成されます。

この機能を使用するには、Weblate の設定で API 資格情報（BITBUCKETSERVER_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に Bitbucket Server オプションが表示されます。

参考

変更点を Weblate からプッシュ、BITBUCKETSERVER_CREDENTIALS

Pagure マージリクエスト#

バージョン 4.3.2 で追加.

これにより、リポジトリに直接プッシュするのではなく、Pagure API を使用して 、薄いレイヤーを Git に追加するだけで、変更された翻訳をプルリクエストとしてプッシュできます。

Git リポジトリにアクセスするために、これを使う必要はありません。通常 Git は同じように動作しますが、唯一の違いはリポジトリへのプッシュの扱い方です。Git では、変更はリポジトリに直接プッシュされますが、Pagure マージリクエスト ではマージリクエストが作成されます。

この機能を使用するには、Weblate の設定で API 認証情報（PAGURE_CREDENTIALS）の設定が必要です。設定すると、バージョン管理システム の選択時に、Pagure オプションが表示されます。

参考

変更点を Weblate からプッシュ、PAGURE_CREDENTIALS

Gerrit#

git-review ツールを使用して、リポジトリに直接プッシュするのではなく、Gerrit レビュー リクエストとして変更された翻訳をプッシュするために、Git の上に薄いレイヤを追加します。

Gerrit ドキュメントには、このようなリポジトリを設定するために必要な設定の詳細が記載されています。

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

参考

DATA_DIR

ローカル ファイル#

ヒント

内部では、Git を使用しています。Git がインストールされていることが前提ですが、Git をネイティブに使用するように切り替えて、翻訳の完全な履歴を残すことができます。

Weblate は、リモート VCS がなくても動作します。最初の翻訳は、アップロードするとインポートされます。あとで、個々のファイルをファイル アップロードで置き換えるか、Weblate から直接、翻訳文字列を追加できます（現在、モノリンガル翻訳でのみ使用できます）。

Weblate はバックグラウンドで Git リポジトリを作成し、すべての変更を記録します。後で VCS を使用して翻訳を保存する場合は、すでに Weblate 内に統合のベースとなるリポジトリがあります。