.poファイルを.moファイルにコンパイルする方法（4つの方法）
午後のひとときを費やして、ドイツ語の翻訳を完璧に仕上げました。de_DE.poファイル内のすべての文字列は美しく、プレースホルダーは無傷で、複数形も正しく翻訳されています。サイトにアップロードし、言語をドイツ語に切り替えても...何も変わりません。ページはまだ英語のままです。ファイル名、フォルダ、テキストドメインを再確認しても、すべてが正しく見えます。では、なぜWordPressはあなたの翻訳を表示してくれないのでしょうか？
十中八九、答えは同じです。.poファイルを編集したものの、.moファイルにコンパイルしなかったからです。WordPressは実行時に.poファイルを読み込みません。コンパイル済みのバイナリ.moファイルを読み込みます。翻訳を実際に表示させたい場合は、テキストを変更するたびにpoをmoにコンパイルする必要があります。.poは編集可能なソースであり、.moはサイトが提供するものです。
このガイドでは、なぜそのコンパイルステップが必要なのかを説明し、WP-CLI、伝統的なmsgfmtコマンド、Poedit、そして自動的に.moファイルを生成するクラウドツールという4つの信頼できる方法について解説します。また、最も一般的な落とし穴である再コンパイル忘れと、WordPressが現在高速化のために推奨する新しい.l10n.php形式についても触れます。
WordPressはなぜ.poではなく.moを読み込むのか？
WordPressが.moファイルを読み込むのは、それが高速なルックアップのために最適化されたコンパイル済みバイナリであるためです。一方、.poファイルは人間が読み書きするために作られたプレーンテキストです。ページが読み込まれるたびにテキストを解析するのは遅く、事前に構築されたバイナリハッシュテーブルを読み込むのはほぼ瞬時です。
.poファイルは行ベースで人間にとって読みやすい形式です。各エントリは、ソースのmsgidと翻訳されたmsgstrをペアにし、文字列の出所を示すコメントも含まれています。これは編集には優れていますが、パフォーマンスには劣ります。サーバーはリクエストごとにテキストファイル全体を再解析する必要があるからです。
#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"
.moファイルは、これらの文字列のペアを内部ルックアップテーブルを持つバイナリ形式にまとめ、WordPressがテキストをスキャンすることなく直接翻訳にジャンプできるようにします。そのトレードオフとして、.moは人間には読めず、.poが変更されるたびに再生成する必要があります。.poと.moの違いがまだ不明瞭な場合は、.po vs .mo vs .pot ファイルについての解説で、各形式とその関係性について詳しく説明しています。
poをmoにコンパイルする4つの方法
唯一の「正しい」ツールというものはありません。最適な選択肢は、現在どのような作業をしているかによって異なります。以下に、1行のコマンドから完全に自動化されたクラウドワークフローまで、4つの信頼できる方法を紹介します。これら4つの方法はすべて、WordPressが実行時に読み込む同一のバイナリ.moファイルを生成します。
方法1: WP-CLI
最もクリーンな現代的なアプローチはWP-CLIです。これは1つのコマンドで、フォルダ全体にある.poファイルをコンパイルできます。すでにコマンドラインからWordPressを管理している場合、これは自然にワークフローに組み込むことができます。
# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/
# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/
make-moコマンドは対象ディレクトリをスキャンし、見つかった各.poファイルをコンパイルし、その横に一致する.moファイルを書き込みます（または指定した出力先に書き込みます）。これはバッチ処理をスムーズに実行できるため、一度に多くの言語を管理する場合に最適です。WP-CLIをすでに使用しているプロジェクトには推奨されるツールです。
方法2: msgfmt
このタスクのためのオリジナルのGettextユーティリティはmsgfmtで、GNU gettextパッケージの一部です。これは単一の.poファイルを単一の.moファイルにコンパイルし、事実上すべてのLinuxおよびmacOSシステムで利用可能です。
# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo
# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo
# Install it first if missing
# macOS: brew install gettext
# Debian: sudo apt-get install gettext
-oフラグは出力ファイル名を指定します。--statisticsフラグは非常に便利で、翻訳済み、ファジー、またはまだ空の文字列がいくつあるかを表示するため、不完全な翻訳を出荷前に発見できます。一度に1つのファイルをスクリプトで処理する場合、msgfmtは信頼性が高く、余計な機能のない選択肢です。
msgfmtはシンプルなコマンドラインツールなので、自動化にきれいに組み込むことができます。シェルループでラップしてフォルダ全体をコンパイルしたり、CIパイプラインに組み込んで、.poファイルに触れるすべてのコミットが自動的に新しい.moファイルを生成するようにできます。一般的なパターンは、for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; doneで、これはすべての言語を一度にコンパイルします。--checkフラグは検証を追加し、msgidとmsgstr間の書式文字列の不一致が本番環境に到達する前にフラグを立てます。これは、翻訳されたレイアウトを密かに破損させる壊れたプレースホルダーのバグに対する安価な保護策です。
方法3: Poedit（保存時にコンパイル）
グラフィカルエディタで翻訳を編集する場合、Poeditは自動的にコンパイルを行います。.poファイルを保存するたびに、Poeditは一致する.moファイルをそのすぐ隣に書き込みます。別のコマンドも、追加のステップも必要ありません。
これは、コマンドラインに慣れていない翻訳者の間でPoeditが人気を保っている理由の1つです。.poファイルを開き、翻訳を入力し、保存するだけで、両方のファイルが同時に更新されます。Poeditの設定で、保存時の自動.moコンパイルがデフォルトで有効になっていることを確認できます。Poeditや同様のデスクトップツールについては、MacとWindowsでPOファイルを編集・翻訳するための無料ツールベスト5でレビューしています。
デスクトップエディタの難点は、コンパイルが人間がファイルを開いて保存したときにのみ行われることです。これは一人で行うプロジェクトには問題ありませんが、何十もの言語やファイルをやり取りするチームにはスケールしません。誰かが別のツールで.poファイルを編集し、Poeditを開かずにリポジトリにコピーした場合、.moファイルは更新されません。より大規模なプロジェクトや共同プロジェクトでは、コマンドラインやクラウドのような自動化された方法が、保存を押すことを覚えておくという依存性を取り除きます。
方法4: .moファイルを自動生成するクラウドツール
4つ目の選択肢は、コンパイルステップを完全に不要にするものです。翻訳された.poファイルとともにコンパイル済みの.moファイルを返すクラウドサービスを使用します。コマンドを実行したり、ファイルを2回保存したりすることはありません。アップロードするだけで、完成した正しい名前のファイルが返されます。
SimplePoTranslateはまさにこの方法で機能します。.poまたは.potファイルをアップロードすると、コンテキスト認識AIによって文字列が翻訳され、.poと.moが並んで生成された単一のZIPファイルが返されます。これらはすでにコンパイル済みで、テキストドメインとロケールに一致するように名前が付けられています。個別のコンパイルパスは不要で、コンパイル忘れの心配もありません。
また、手動ワークフローを破綻させる詳細も処理します。構文ロックは、翻訳前に%s、%1$s、{name}のようなプレースホルダーやHTMLタグを固定するため、変数が.moファイルに無傷で保持されます。完全なGettext複数形サポートにより、複雑な複数形も正しくコンパイルされます。これは深く理解する価値のあるトピックであり、Gettext複数形の理解で解説しています。そして、クラウドで実行されるため、インストールするプラグインも、保守するビルドツールもありません。
最も一般的な落とし穴：再コンパイルを忘れた
翻訳が表示されない最大の理由は、.poファイルを編集したものの、.moファイルを再コンパイルし忘れることです。WordPressは古いバイナリを読み込み続けるため、新しい翻訳が表示されることはありません。そして、その理由を教えてくれるエラーメッセージもありません。
心に留めておくべきメンタルモデルは、.poはあなたの下書きであり、.moは出荷されるものであるということです。.poファイルへの変更は、.moファイルを再生成するまでWordPressには見えません。編集後は常に再コンパイルを習慣にするか、自動的にコンパイルするツールを使用して、このステップがスキップされないようにしてください。
この落とし穴は、ステージングから本番環境への移行で特に厄介です。開発者がローカルで編集・再コンパイルし、翻訳が機能することを確認した後、.poファイルのみをデプロイして.moファイルを忘れてしまうと、本番環境では古いテキストが密かに保持されてしまいます。翻訳ファイルを環境間で移動する際は、.poファイルと新しくコンパイルされた.moファイルを一緒に移動するか、デプロイステップの一部としてコンパイルすることで、バイナリが常に最新のソースから再構築されるようにしてください。
再コンパイル後も翻訳が表示されない場合、問題は通常、名前の不一致、間違ったフォルダ、または古いファイルを保持しているキャッシュ層にあります。WordPressで翻訳が表示されない理由で完全なチェックリストを確認できます。
新しい.l10n.php形式に関する注意
最近のWordPressバージョンでは、第3のランタイム形式である**.l10n.php**が導入されました。バイナリの.moファイルの代わりに、翻訳はプレーンなPHP配列として保存され、PHPのオペコードキャッシュがメモリに保持できるため、ビジーなサイトでは.moよりもさらに高速なルックアップが可能になります。
<?php
return [
'domain' => 'my-plugin',
'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];
WordPressは、対応する.moファイルが利用可能な場合、.l10n.phpファイルを自動的に生成するため、手動で作成する必要はありません。今のところ、正しい.moファイルをコンパイルすることが基盤であり、パフォーマンス重視の形式はそこから派生します。
まとめ
確実にpoをmoにコンパイルするには、ご自身の作業方法に合った方法を選びましょう。コマンドラインでのバッチ処理にはWP-CLI、統計情報付きの単一ファイルにはmsgfmt、保存時の自動コンパイルにはPoedit、あるいは.moファイルを自動でビルドしてくれるクラウドツールを利用すれば、このステップを飛ばす心配がありません。これら4つの方法はすべて、WordPressが実行時に必要とする同じバイナリを生成します。
どの方法を選んだとしても、黄金律を忘れないでください。.poファイルを編集したら、毎回.moファイルにコンパイルすること。この一つの習慣が、すべてが正しく見えるのにサイトが頑として英語のままという、WordPressで最もイライラする翻訳バグを防ぎます。
手動でのコンパイルステップを永遠にスキップしたいですか？SimplePoTranslateを無料で試す — クレジットカードは不要です。
.poファイルをアップロードし、数分で無料プランでデプロイ準備が整った.po+.moバンドルをダウンロードできます。