よくある質問

設定

自動化したワークフローを作成する方法は?

Weblate は翻訳に関するすべての作業を半自動的に処理できます。あなたのリポジトリへのプッシュ権限を与えれば、マージの競合が発生しない限り、操作なしで翻訳が反映されます。

  1. 変更があれば Weblate に通知するように Git リポジトリを設定します、方法は 通知フック を確認してください。

  2. Weblate の コンポーネント構成 でプッシュ URL を設定します。これにより、Weblate は変更をリポジトリにプッシュできます。

  3. Weblate の コンポーネント構成コミット時にプッシュする を有効にすると、Weblate で変更が行われるたびに Weblate によりリポジトリに変更がプッシュされます。

SSH 経由でリポジトリに接続する方法は?

SSH 鍵の設定については、リポジトリへの接続 を参照してください。

翻訳のマージの競合を修正する方法は?

マージの競合は、Weblate とアップストリーム リポジトリの両方で翻訳ファイルが同時に変更されたとき、たまに発生します。通常、翻訳ファイルに変更を加える前に(msgmerge を実行する前)Weblate 翻訳をマージすることで、これを回避できます。Weblate に、保留中の翻訳をすべてコミットして(管理 メニューの リポジトリのメンテナンス から操作)、リポジトリをマージするように指示するだけです(自動プッシュが無効のとき)。

マージの競合が既に発生している場合、マシン上のすべての競合をローカルで解決する最も簡単な方法は、Weblate をリモート リポジトリとして追加し、アップストリームにマージして競合を修正することです。変更を元に戻すと、Weblate はそのままでマージされたバージョンを使用できます。

注釈

設定によっては、Weblate リポジトリへの接続には認証が必要となります。Weblate に組み込まれた Git エクスポーター を使用すると、ユーザー名と API キーで認証できます。

# Commit all pending changes in Weblate, you can do this in the UI as well:
wlc commit
# Lock the translation in Weblate, again this can be done in the UI as well:
wlc lock
# Add Weblate as remote:
git remote add weblate https://hosted.weblate.org/git/project/component/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/project/component/

# Update weblate remote:
git remote update weblate

# Merge Weblate changes:
git merge weblate/main

# Resolve conflicts:
edit …
git add …
…
git commit

# Push changes to upstream repository, Weblate will fetch merge from there:
git push

# Open Weblate for translation:
wlc unlock

Weblate で複数のブランチを使用する場合、すべてのブランチに対して同じ操作をする方法:

# Add and update Weblate remotes
git remote add weblate-one https://hosted.weblate.org/git/project/one/
git remote add weblate-second https://hosted.weblate.org/git/project/second/
git remote update weblate-one weblate-second

# Merge QA_4_7 branch:
git checkout QA_4_7
git merge weblate-one/QA_4_7
... # Resolve conflicts
git commit

# Merge main branch:
git checkout main
git merge weblates-second/main
... # Resolve conflicts
git commit

# Push changes to the upstream repository, Weblate will fetch the merge from there:
git push

gettext PO ファイルの場合、競合を半自動でマージする方法:

Weblate Git リポジトリのローカル クローンを取得して保持します。また、アップストリームの Git リポジトリの最新のローカル クローンも取得します(例: 上流の Git リポジトリのコピーが 2 つ必要。最新のコピーと作業用コピー)。操作方法:

# Add remote:
git remote add weblate /path/to/weblate/snapshot/

# Update Weblate remote:
git remote update weblate

# Merge Weblate changes:
git merge weblate/main

# Resolve conflicts in the PO files:
for PO in `find . -name '*.po'` ; do
    msgcat --use-first /path/to/weblate/snapshot/$PO\
               /path/to/upstream/snapshot/$PO -o $PO.merge
    msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
    rm $PO.merge
    git add $PO
done
git commit

# Push changes to the upstream repository, Weblate will fetch merge from there:
git push

複数のブランチを一度に翻訳する方法は?

Weblateは、1 つの プロジェクトの設定 内での変更された翻訳の反映に対応しています。 コンポーネント構成 が有効(デフォルトの動作)のコンポーネント間では、行われた変更は自動的に他に反映されます。このようにすると、ブランチ自体がすでにかなり分岐していて、ブランチ間で翻訳の変更が単純にマージできない場合でも翻訳の一貫性が維持されます。

Weblate からの変更をマージしたら、(開発ワークフローに応じて)これらの分岐をマージして、違いを破棄してください。操作方法:

git merge -s ours origin/maintenance

マルチ プラットフォームプロジェクトを翻訳する方法は?

Weblate は、多くのファイル形式(参照: see 対応するファイル形式)に対応しています。最も簡単な方法は、各プラットフォームの本来のファイル形式を使用することです。

すべてのプラットフォーム翻訳ファイルを、1 つのプロジェクト(参照: 翻訳プロジェクトとコンポーネントの追加)のコンポーネントとして追加すると、翻訳の反映機能(デフォルトで有効、無効化するには コンポーネント構成 から)を使用して、すべてのプラットフォームの文字列を一度に翻訳します。

Weblate が使用する Git リポジトリをエクスポートする方法は?

リポジトリについて特別なことは何もありません、リポジトリは、ファイル名 vcs/<project>/<component>/ として DATA_DIR ディレクトリの下にあります。このサーバーへの SSH アクセス権がある場合は、リポジトリを直接操作できます。

匿名でアクセスするには、Git サーバーを起動してリポジトリを外部に公開してください。

または、これを自動化するために、Weblate 内部の Git エクスポーター を使用できます。

変更を上流にプッシュする方法の種類は?

これは、Weblate の構成にもよりますが、Weblate は非常に柔軟に対応できます。Weblate で使用するワークフローの例:

  • Weblate に、変更を自動的にプッシュおよびマージさせる(参照: 自動化したワークフローを作成する方法は?)。

  • プッシュを Weblate に手動で指示する(上流リポジトリへのプッシュ アクセス権が必要)。

  • 誰かに、手動で Weblate の git リポジトリから上流リポジトリに変更をマージさせる。

  • 誰かに手動で、Weblate が生成した履歴を書き換えさせ(マージ コミットを削除するなど)、変更をマージし、Weblate が上流リポジトリのコンテンツをリセットするように操作させる。

もちろん、これらすべてを自由に組み合わせてもかまいません。

Weblate からのアクセスを翻訳のみに制限し、ソースコードを見せないようにする方法は?

git submodule を使用すると、バージョン管理下に置いたままソースコードから翻訳を分離できます。

  1. 翻訳ファイルを含むリポジトリを作成する。

  2. これをサブモジュールとしてコードに追加する。設定方法:

    git submodule add git@example.com:project-translations.git path/to/translations
    
  3. このリポジトリに Weblate をリンクすると、ソースコードを含むリポジトリへのアクセスは必要ありません。

  4. Weblate での翻訳を使用して、メイン リポジトリを更新する方法:

    git submodule update --remote path/to/translations
    

詳細については、git submodule を確認してください。

Weblate が正しく設定されているかどうかを確認する方法は?

Weblate には、管理画面から確認できる設定検査の機能があります。管理画面の 性能レポート リンクからたどるか、/manage/performance/ の URL を直接開いてください。

なぜすべてのコミットが、Weblate <noreply@weblate.org> でコミットされるのですか?

これは DEFAULT_COMMITER_EMAIL および DEFAULT_COMMITER_NAME で設定したデフォルトのコミッター名です。

すべてのコミットの著者(使っている VCS が対応している場合)は、翻訳をしたユーザーとして正しく記録されます。

翻訳者の情報がない場合(例えば匿名の提案や機械翻訳の結果)のコミットでは、著者は匿名ユーザーになります(参照: ANONYMOUS_USER_NAME)。管理画面で名前とメールアドレスを変更できます。

リポジトリ内のファイルの移動を、Weblate の履歴を失わずにする方法は?

ファイルの場所を変更した後に、文字列にリンクされた履歴、コメント、またはスクリーンショットを保持するには、これらの文字列が Weblate で削除されないようにすることが必要です。もし、コンポーネントの構成が、以前の古いファイルを指し示している場合は、Weblate のリポジトリの更新時に削除されます。その場合、Weblate はすべての翻訳の削除が必要だと判断します。

これに対する解決策として、Weblate と同期して操作を実行する方法:

  1. 影響を受けるコンポーネントを Weblate でロックする。

  2. 保留中の変更をコミットし、上流リポジトリにマージする。

  3. プロジェクトの設定 で Web フックを無効にする。これにより、リポジトリ内の変更がすぐに反映されなくなります。

  4. リポジトリに必要な変更を加える(例: git mv の使用); 変更を上流のリポジトリにプッシュします。

  5. 新しい設定に合わせて コンポーネント構成 を変更する。設定を変更すると、Weblate は更新されたリポジトリを取得し、移動した場所を認識して既存の文字列を維持します。

  6. コンポーネントのロックを解除し、プロジェクトの設定からフックを再度有効化する。

使用方法

他の人の翻訳を確認する方法は?

  • Weblate では、査読のためのワークフローを複数用意しています。参照: 翻訳ワークフロー

  • 通知 を使用して、翻訳文の変更および他の作業をメールで随時確認します。

  • 翻訳画面の下部にある査読ツールを使用して、指定した日付以降に他の翻訳者がした翻訳を確認します。

原文についてのフィードバックの方法は?

翻訳の直下に、翻訳情報のタブが並んでいます。コメント タブの中で、原文についてフィードバックを送ったり、他の翻訳者と話し合ったりできます。

翻訳中に既存の翻訳を使用する方法は?

  • Weblate 内のすべての翻訳は、共有翻訳メモリを使用します。

  • 既存の翻訳メモリ ファイルを Weblate にインポートできます。

  • インポート機能を使用して、翻訳の概要、提案または査読が必要な翻訳を取り込みます。これは、概要または類似の翻訳データベースを使用した 1 回限りの翻訳に最適な方法です。

  • 所有しているすべてのデータベースに tmserver を導入し、Weblate から使用します。翻訳中に何度も使用する場合に適しています。

  • 他の方法として、関連するすべてのプロジェクトの翻訳を 1 つの Weblate で行うと、自動的に他のプロジェクトからも翻訳を使用できます。

Weblate は翻訳以外の翻訳ファイルを更新しますか?

Weblate は、翻訳ファイルの変更を最小限に抑えようとします。一部のファイル形式では、ファイルを再構築します。ファイルの状態を維持させたい場合は、pre-commit フックを使用してください。

言語の定義はどこにあり、独自の言語の追加方法は?

基本的な言語の定義は、Weblate および 翻訳ツールキットに含まれています。翻訳ツールキットには、150 以上の言語と、複数形やテキストの方向についての情報が含まれています。

管理画面から、独自の言語を自由に定義できます。必要な情報を入力するだけです。

Weblate は、あいまいな文字列の変化を強調表示できますか?

Weblate では、この機能に対応していますが、違いを示すデータが必要です。

Gettext PO ファイルの場合は、PO ファイルの更新時に、--previous パラメーターを msgmerge に渡すことが必要です。更新の例:

msgmerge --previous -U po/cs.po po/phpmyadmin.pot

モノリンガル翻訳の場合、Weblate は以前の文字列を ID で検索するため、違いが自動的に表示されます。

テンプレートを更新しても、Weblate に以前の翻訳文が表示されるのはなぜですか?

Weblate は、翻訳者に翻訳を許可する以外の方法では、翻訳ファイルを操作しません。したがって、テンプレートまたはソースコードを変更しても、翻訳可能なファイルは更新されません。変更を手動でリポジトリにプッシュするだけで、Weblate が変更を自動的に取得します。

注釈

通常は、翻訳ファイルを更新する前に、Weblate で行った変更をマージしてください。そうしなければ、通常、マージすると競合が発生します。

msgmerge ツールを使用して、gettext PO ファイルの翻訳ファイルを更新する方法:

msgmerge -U locale/cs/LC_MESSAGES/django.mo locale/django.pot

自動的に更新をさせたい場合は、POT に合わせて PO ファイルを更新 (msgmerge) アドオンをインストールしてください。

問題解決方法

リクエストが「開いているファイルが多すぎます」というエラーで失敗する

これは、Git リポジトリが大きくなりすぎて、Git リポジトリの数が増えすぎた場合に発生することがあります。Git リポジトリを圧縮すると、この状況を改善できます。

簡単に Git リポジトリを圧縮する方法:

# Go to DATA_DIR directory
cd data/vcs
# Compress all Git repositories
for d in */* ; do
    pushd $d
    git gc
    popd
done

参考

DATA_DIR

サイトにアクセスすると「Bad Request (400)」エラーが発生する

これは、ALLOWED_HOSTS の設定が不適切である可能性が高いです。設定には、Weblate からアクセスするホスト名をすべて含めてください。設定例:

ALLOWED_HOSTS = ["weblate.example.com", "weblate", "localhost"]

「単一言語用(en)のファイルがさらにあります」 とはどういう意味ですか?

これは通常、原文の言語の翻訳ファイルがある場合に発生します。Weblate は原文を追跡するために原文の言語を予約します。同じ言語の追加ファイルは処理されません。

  • 原文の言語への翻訳が必要な場合は、コンポーネント設定の 原文の言語 を変更してください。原文の言語として English (Developer) ` 、または :ref:`source-quality-gateway を使用できます。

  • 原文の言語の翻訳ファイルが不必要な場合は、リポジトリから削除してください。

  • 原文の言語の翻訳ファイルが必要だが、Weblate で無効にする場合は、言語フィルター で除外を設定してしてください。

ヒント

他の言語でも、同様のエラー メッセージが表示されることがあります。その場合、原因として最も可能性があるのは、複数のファイルが Weblate で単一言語に配置されている場合です。

これは、廃止した言語コードを新しい言語コード(日本語の場合は ja および jp)と一緒に使用したり、国別コードと汎用コード(fr および fr_FR)の両方を含めると発生します。詳細は 言語コードの解析 を確認してください。

機能

Weblate は Git および Mercurial 以外の VCS に対応していますか?

現在、Weblate は、vcs-git`(:ref:`vcs-githubGerrit および Subversion に対する拡張対応付き)および Mercurial 以外のものは公式には対応していませんが、他の VCS 用のバックエンドの作成は可能です。

また、Git の Git リモート ヘルパー を使用して、他の VCS にも接続できます。

また、Weblate は VCS を使用しない運用にも対応しています。

注釈

他の VCS を公式対応するには、Weblate には分散 VCS が必要です。おそらく、Git と Mercurial 以外でも動作するように修正できますが、実現するには誰かが実装しなければなりません。

Weblate の翻訳者のクレジットはどうなっていますか?

Weblate で行ったすべての変更は、翻訳者名で VCS にコミットされます。このようにして、個々の変更には適切に著作者名が入り、一般的な VCS ツールを使用して追跡できます。

また、翻訳ファイル形式で対応している場合は、ファイルヘッダーを更新して翻訳者の名前が挿入されます。

なぜ Weblate は、すべての PO ファイルを強制的に単一の階層に表示させるのですか?

Weblate は、すべての PO ファイルを 1 つのコンポーネントに含めるように設計されています。これは翻訳者にとって有益であり、実際にどの言語に翻訳しているか一目瞭然です。

バージョン 4.2 で変更: 翻訳者は、プロジェクトのすべてのコンポーネントを、含まれているすべての言語に翻訳できます。

なぜ。Weblate は sr_Latn もしくは zh_Hant などの言語コードを使用するのですか?

これは、RFC 5646 によって定義された言語コードです。以前、誤って使用された修飾子(@latin 表記)、もしくは国コード(中国語)の代わりに、実際とは異なる言語であることをより明確にするものです。

Weblate は、従来の言語コードを判別し、それを現在の言語コードに置き換えます。例えば、sr@latinsr_Latn として扱い、zh@CNzh_Hans として扱います。

注釈

Weblate のデフォルトの言語コードは、アンダースコア付きの POSIX スタイルの言語コードです。詳細については、 言語の定義 を確認してください。