よくある質問#

設定#

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

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

# Rebase changes (if Weblate is configured to do rebases)
git rebase origin/main

# 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) アドオンをインストールしてください。

How to handle renaming translation files?#

When renaming files in the repository, it can happen that Weblate sees this as removal and adding of the files. This can lead to losing strings history, comments and suggestions.

To avoid that, perform renaming in following steps:

  1. Lock the translation component in バージョン コントロール リポジトリの管理.

  2. Commit pending changes in バージョン コントロール リポジトリの管理.

  3. Merge Weblate changes to the upstream repository.

  4. Disable receiving updates via hooks using フックの有効化.

  5. Perform the renaming of the files in the repository.

  6. Update the component configuration to match new file names.

  7. Enable update hooks and unlock the component.

問題解決方法#

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

これは、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)、または 原文の品質ゲートウェイ を使用できます。

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

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

ヒント

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

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

機能#

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

現在 Weblate は、 GitGitHub プルリクエストGerrit および 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 スタイルの言語コードです。詳細については、 言語の定義 を確認してください。