WordPress の .po ファイルでファジー翻訳を修正する方法

すべての文字列を翻訳し、ファイルを保存し、.mo ファイルをアップロードしてサイトを更新したとします。それなのに、いくつかのラベルは頑固に英語のままです。そこで .po ファイルを開き、その文字列を探すと、完璧に翻訳されているのがわかります。では、なぜ WordPress はそれを無視するのでしょうか？

その答えは、ほとんどの場合、エントリーの上に隠された小さなフラグ「#, fuzzy」です。ファジー翻訳とは、gettext が「この翻訳は間違っているかもしれないので、まだ信頼しないでください」と伝える方法です。そして重要なことに、WordPress はライブサイトでファジーな文字列を表示することを拒否し、代わりに元の英語に戻します。これは、「翻訳が表示されない」という問題の最も誤解されている原因の一つです。

このガイドでは、ファジー翻訳フラグが具体的に何を意味するのか、なぜそれがカタログに表示され続けるのか、そして Poedit、コマンドライン、さらにはバックログ全体にわたる大規模なファジー文字列の検索とクリア方法を詳しく説明します。この仕組みを理解すれば、翻訳が見つからないという謎は消え去るでしょう。

ファジーフラグの本当の意味とは？

ファジーフラグは、翻訳が不確かであり、人間のレビューが必要であることを示すために gettext が翻訳エントリーに追加するマーカーです。生の .po ファイルでは、文字列の直上に特殊なコメントとして表示されます。

#: includes/cart.php:88
#, fuzzy
msgid "Add to cart"
msgstr "Im Warenkorb"

その #, fuzzy の行は、WordPress を含むすべての gettext 対応ツールに対し、その下にある msgstr が仮のものであることを伝えます。翻訳は存在するものの、gettext はそれを確定されたものとは見なしていません。

WordPress がファジー文字列をスキップする理由

ここで誰もが不意を突かれる挙動があります。WordPress が .mo ファイルをコンパイルまたは読み込む際、ファジーなエントリーは未翻訳として扱われます。文字列は技術的にはファイル内に存在しますが、WordPress は意図的にそれを無視し、代わりに元の msgid を表示します。

したがって、あなたの視点からすると、翻訳は「完了」しており、ファイル内に存在します。しかし、WordPress の視点からすると、その文字列には信頼できる翻訳がないため、英語のソースが表示されます。これが、完了しているように見えるカタログでも、フロントエンドで未翻訳のテキストが表示されるまさにその理由です。

この設計は意図的なものであり、公平に見て理にかなっています。ファジーフラグの目的は、未検証で潜在的に間違った翻訳が密かに公開されるのを防ぐことです。元々「Delete account」と書かれていた文字列が、後に「Deactivate account」に変更されたと想像してください。gettext が古い翻訳を盲目的に保持した場合、ユーザーは実際には無効化するだけの「Delete account」と表示されたボタンを目にするかもしれません。これは危険な不一致です。ファジー文字列を隠すことで、gettext は、翻訳が新しい意味にまだ合致していることを、誰かに到達する前に人間が確認するように強制します。このフラグは安全機構であり、バグではありません。

ファジーフラグが繰り返し表示されるのはなぜですか？

ファジーフラグはランダムではありません。主に2つの状況で gettext ツールによって自動的に生成され、その両方を理解することで、それらを防ぐ方法がわかります。

ソース文字列が変更された場合

最も一般的な原因はソースの更新です。開発者が次のプラグインバージョンで文字列を「Add to cart」から「Add to basket」に変更したと想像してください。新しいテンプレートを既存の翻訳にマージすると、gettext はソースがあなたが元々翻訳したものと一致しなくなったことを認識します。古い翻訳を捨てる代わりに、それを保持しますが、ファジーとしてマークします。これは基本的に「英語が変更されたので、あなたの翻訳がまだ適切かどうかを再確認してください」という意味です。

翻訳メモリと msgmerge による自動マッチング

2番目の原因は、マージ中のファジーマッチングです。msgmerge ツールは、新しいテンプレートに対して古い翻訳ファイルを更新する際、以前の文字列と似ているが同一ではないソース文字列を見つけると、古い翻訳をコピーしてファジーとしてフラグを立てます。

# Merge a new template into an existing translation.
# Similar-but-changed strings get marked #, fuzzy automatically.
msgmerge --update awesome-plugin-de_DE.po awesome-plugin.pot

デスクトップエディタの翻訳メモリも同様に動作します。つまり、近接一致から提案を自動入力する際、結果をファジーとしてマークし、確認を促します。どちらの場合も、フラグはその役割を果たしています。問題は、ファジーなエントリーがレビューされずに放置され、WordPress がそれを密かに隠してしまうことだけです。

知っておくべき3つ目の、より巧妙な原因があります。それは、コピー＆ペーストや一括インポートツールです。一部の翻訳プラットフォームやインポートスクリプトは、保守的な措置として、デフォルトですべてのエントリーをファジーとしてマークし、後で人間が各エントリーを確認することを期待します。他のシステムからカタログをインポートし、すべての文字列が突然ファジーになっていることに気づいた場合、通常これが理由です。翻訳は完璧かもしれませんが、フラグがクリアされるまでは、どれもあなたのサイトには表示されません。フラグの発生源を知ることで、各エントリーを本当にレビューする必要があるのか、または自信を持って一括クリアしても安全なのかがわかります。

ファジー文字列の検索と修正方法

ファジー文字列をクリアするとは、それぞれをレビューし、翻訳が正しいことを確認したらフラグを削除することです。作業の規模に応じて、これを行うには3つの実用的な方法があります。

Poedit でファジー文字列を修正する

Poedit はこれを最も簡単にします。.po ファイルを開き、検索およびフィルターコントロールを使用してファジーなエントリーのみを表示します。これらは色分けされており（通常はオレンジ色）、すぐに目立ちます。それぞれをクリックし、翻訳を確認または修正した後、キーボードショートカット（編集メニューの「Translation is Fuzzy」、またはメニューに表示されているショートカット）でファジー状態をオフにします。保存すると、Poedit はクリーンな .mo ファイルを再コンパイルし、これで確定された文字列があなたのサイトに表示されるようになります。このエディタを初めて使用する場合は、Poedit 完全ガイドでフィルターとレビューのワークフローについて詳しく説明されています。

コマンドラインでファジー文字列を修正する

自動化や大規模なカタログの場合、コマンドラインの方が高速です。ファジーなエントリーを数え、一括で確認した後、フラグを削除して WordPress がそれらを読み込むようにすることができます。

# Count how many fuzzy strings remain
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po | grep -c "msgid"

# Clear all fuzzy flags (only after you trust the translations)
msgattrib --clear-fuzzy --empty awesome-plugin-de_DE.po \
  --output-file=awesome-plugin-de_DE.po

一括クリアには注意してください。翻訳をレビューせずにファジーフラグを削除することは、フラグの目的を台無しにし、ユーザーに本当に間違ったテキストを届ける可能性があります。翻訳のソースを信頼できる場合はコマンドラインアプローチを、そうでない場合は手動の Poedit ルートを使用してください。

安全な中間策は、ファジーな文字列を別のファイルにエクスポートし、それらだけをレビューしてから元に戻すことです。これにより、本当に注意が必要なエントリーだけに集中しながら、確定された翻訳はそのまま保たれます。

# Extract only the fuzzy entries for focused review
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po \
  --output-file=fuzzy-only.po

隔離された50個の文字列をレビューする方が、オレンジ色の行を探して千行のカタログをスクロールするよりもはるかにエラーが少なく、最後の更新で何が変更されたかを正確にクリーンな記録として残せます。

フラグをクリアした後、必ず .mo ファイルを再保存または再コンパイルしてください。ファジー状態は .po ファイルにありますが、WordPress はバイナリの .mo ファイルを読み込むため、再生成しない限り、.po ファイルがクリーンに見えてもフロントエンドには英語が表示され続けます。Poedit は保存時に自動的に再コンパイルします。コマンドラインでは msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo を実行します。この最終的なコンパイル手順を忘れることは、新しくファジー状態を解除したカタログが表示されない最も一般的な理由の1つです。翻訳はソースファイルで確定されていますが、サイトが実際に読み込むバイナリが古くなっているためです。

ファジーなエントリーは、複数形文字列とともに出現することが多く、変更された msgid_plural が複数形ブロック全体をファジーとしてマークすることがあることに注意してください。もしあなたのファジーなバックログが数や量に偏っているなら、Gettext の複数形と複雑な複数化に関するガイドで、なぜそれらのエントリーがマージ中に特に脆弱なのかを説明しています。

大規模なファジーバックログをクリアする

1つのファジー文字列は30秒で修正できますが、主要なプラグイン更新後に400個のファジー文字列を含むカタログは別の問題であり、それが数十の言語にわたると真のボトルネックになります。レビューなしでフラグを一括クリアしたくなる誘惑は、まさに壊れた翻訳が本番環境に到達する原因となります。

よりクリーンな解決策は、古い一致に承認のハンコを押すのではなく、ファジーなエントリーを新たに翻訳し直すことです。SimplePoTranslate を通してカタログを実行すると、コンテキストを認識するAI が変更されたすべての文字列に対して現在適用可能な確定済みの翻訳を生成するため、警告フラグを削除するだけでなく、不確かな一致を実際の翻訳に置き換えることになります。構文ロックは、処理中にすべての %s、%1$s、{count}、および HTML タグをそのまま維持し、スマートバッチ処理により、大規模な更新後カタログを一度に処理します。あなたは、.po、.mo、.json、.php、および .xliff を含むクリーンな ZIP を受け取ります。ファジーなバックログは残っておらず、クラウドからデプロイする準備ができています。

これは、そもそも翻訳が表示されない一般的な問題とは区別して考える価値があります。ファジーフラグは特定の原因の一つですが、.mo ファイルの欠落、間違ったファイル名、ロケールの不一致も同じ症状を引き起こします。完全な診断チェックリストについては、ファジー文字列をより大きなリストの項目の一つとして扱う、WordPress で翻訳が表示されない場合のトラブルシューティングガイドをご覧ください。

ファジーなバックログ全体をクリアし、すべての文字列をサイトに表示させる準備はできていますか？SimplePoTranslate を無料で試す — クレジットカードは不要です。無料ティアでは、あなたの .po ファイルを新たに翻訳し直し、不確かなファジーな一致をクリーンで確定済みの翻訳に置き換えます。