バージョン管理の統合

Weblate は現在、バージョン管理のバックエンドとして GitGitHubGerrit および Subversion の拡張サポート付き)および 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 で upstream リポジトリに接続するために、Weblate SSH 公開鍵(参照: Weblate SSH キー)を承認します。

警告

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

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

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

_images/ssh-keys.png

Weblate SSH キー

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

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

注釈

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

ヒント

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

SSH ホスト認証鍵の承認

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

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

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

_images/ssh-keys-added.png

GitHub リポジトリ

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

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

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

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

Weblate の内部 URL

他の(リンクした)コンポーネント内の 「weblate :// project/component」 として配置を参照することで、異なるコンポーネント間でリポジトリ設定を共有します。このようにして、リンクされたコンポーネントはメイン (参照) コンポーネントのVCSレポジトリ設定を使用します。

警告

Removing main component also removes linked components.

Weblate は、コンポーネントの作成時に、リポジトリ設定が一致するコンポーネントを見つけると、自動的にリポジトリの URL を修正します。URL は、コンポーネント設定の最後の段階で上書きできます。

使用理由:

  • サーバーのディスク容量を節約。リポジトリは一度だけ保存される。

  • 更新を高速化する。リポジトリは 1 つだけ更新される。

  • Weblate 翻訳を使用してエクスポートするリポジトリは 1 つだけ(参照: Git exporter)。

  • 一部のアドオンでは、単一のリポジトリを共有する複数のコンポーネント上で動作するものもあります。例: 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_proxyhttps_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

参考

さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。

Git に強制プッシュ

これは Git 自体とまったく同じように動作しますが、唯一の違いは、常に強制的にプッシュすることです。これは、翻訳に別のリポジトリを使用する場合にのみ使用します。

警告

upstream のリポジトリではコミットが失われやすいので、注意して使用してください。

Git 設定のカスタマイズ

Weblate は、すべての VCS コマンドを HOME=$DATA_DIR/home (参照: DATA_DIR)で実行します。したがって、ユーザー設定の編集は DATA_DIR/home/.git で行うことが必要です。

Git リモート ヘルパー

他のバージョン管理システムを追加して対応するために remote helpers を使用できますが、これにより発生する可能性がある問題をデバッグする準備をしてください。

現時点では、Bazaar と Mercurial のヘルパーは GitHub 上の別々のリポジトリ、GitHub: git-remote-hggit-remote-bzr で利用できます。手動でダウンロードし、検索パス(例: ~/bin)に配置します。対応するバージョン管理システムがインストールされていることを確認してください。

これらをインストールしたら、このようなリモートを使用して Weblate でリポジトリを設定できます。

Bazaar を使用して Launchpad から gnuhello プロジェクトの複製:

bzr::lp:gnuhello

Mercurial を使用した selenic.com の hello リポジトリの場合:

hg::http://selenic.com/repo/hello

警告

Git のリモート ヘルパーを使う上で不便な点は、例えば Mercurial の場合、変更を元に戻すときにリモート ヘルパーが新しい tip を作成してしまうことがあります。

GitHub

バージョン 2.3 で追加.

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

Git は変更を直接リポジトリにプッシュしますが、GitHub はプル リクエストを作成します。後者は Git リポジトリに接続する場合には必要ありません。

プルリクエストとして変更を GitHub にプッシュする

変換を GitHub リポジトリにプッシュしたくない場合は、代わりに 1 つまたは複数のプル リクエストとして送信できます。

この機能の動作には、API 認証情報の設定が必要です。

GitLab

バージョン 3.9 で追加.

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

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

GitLab への変更をマージ リクエストとしてプッシュする

変換を GitLab リポジトリにプッシュしたくない場合は、代わりに 1 つまたは複数のマージ リクエストとして送信できます。

この機能の動作には、API 認証情報の設定が必要です。

Pagure

バージョン 4.3.2 で追加.

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

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

マージ リクエストとして Pagure に変更をプッシュする

翻訳を Pagure リポジトリにプッシュしたくない場合は、代わりに 1 つまたは複数のマージ リクエストとして送信できます。

この機能の動作には、API 認証情報の設定が必要です。

Gerrit

バージョン 2.2 で追加.

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

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

Mercurial

バージョン 2.1 で追加.

Mercurial は、Weblate で直接使用できるもう 1 つの VCS です。

注釈

Mercurial のどのバージョンでも動作するはずですが、コマンドライン インタフェースに互換性のない変更が追加されたので、Weblate との統合ができないことがあります。

参考

さまざまな種類のリポジトリに接続する方法については、リポジトリへの接続 を確認してください。

Subversion

バージョン 2.8 で追加.

Weblate は git-svn を使用して subversion リポジトリと通信します。これは、Git クライアントで Subversion を使用できる Perl スクリプトで、ユーザーは内部リポジトリの完全なクローンを維持し、ローカルでコミットできるようにします。

注釈

Weblate は Subversion リポジトリ レイアウトを自動的に検出しようとします ー ブランチの直接の URL と標準レイアウトのリポジトリの両方をサポートします(branches/、tags/、および trunk/)。詳細は git-svn documentation を確認してください。リポジトリに標準レイアウトがなく、エラーが発生した場合は、リポジトリ URL にブランチ名を含め、ブランチを空のままにします。

バージョン 2.19 で変更: これ以前は、標準レイアウト リポジトリのみに対応してました。

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

ローカル ファイル

バージョン 3.8 で追加.

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

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