WordPressプラグインを翻訳する方法（ステップバイステップガイド）
プロジェクトにぴったりのWordPressプラグインを見つけました。必要な機能を正確に提供し、レビューも高く評価されています。しかし、有効化した途端、すべてのボタン、ラベル、エラーメッセージが英語であることに気づきます。ドイツ語、フランス語、または日本語を話す訪問者は、読めないテキストの壁にぶつかることになります。
幸いなことに、ほとんどの優れたプラグインは**翻訳対応（translation-ready）**であり、開発者が文字列をGettext関数で囲んでいるため、あなたのような人々が翻訳できるように設計されています。課題は、ファイルがどこにあるのか、翻訳にどのような名前を付けるべきか、そして次のプラグインアップデートで作業が消去されないようにどこに配置すべきかを知ることです。
このガイドでは、WordPressプラグインを最初から最後まで翻訳する方法を説明します。テキストドメインと言語フォルダの特定、.potテンプレートの取得または生成、正しい名前の.poおよび.moファイルの作成、そしてWordPressがそれらを確実に読み込む場所に配置する方法です。また、このアプローチでは完全に翻訳できない種類のプラグインについても説明しますので、不可能なケースと格闘して時間を無駄にすることはありません。
プラグインの翻訳ファイルを見つける方法
翻訳を始める前に、プラグインから2つの情報が必要です。それは、そのテキストドメインと言語フォルダです。テキストドメインは、プラグインが自身の翻訳を識別するために使用する固有の文字列であり、言語フォルダはソーステンプレートが置かれている場所です。
言語フォルダとテキストドメインの特定
wp-content/plugins/your-plugin/にあるプラグインディレクトリを開き、/languagesサブフォルダを探します。通常、その中に翻訳可能なすべての文字列を含む空のテンプレートである.potファイルが見つかります。
テキストドメインを確認するには、プラグインのメインPHPファイルを開き、そのヘッダーブロックを確認します。
/**
* Plugin Name: Awesome Plugin
* Text Domain: awesome-plugin
* Domain Path: /languages
*/
ここで、テキストドメインはawesome-pluginです。この値は非常に重要です。なぜなら、翻訳ファイルにはその名前が含まれている必要があり、そうでなければWordPressはそれらをプラグインと照合しないからです。また、コード内のすべての文字列呼び出しでもこれを見つけることができます。
echo __( 'Settings saved successfully.', 'awesome-plugin' );
2番目の引数awesome-pluginは、再度テキストドメインです。これを使用するすべての文字列は、あなたのカタログによって翻訳できます。プラグインのインターフェース内の文字列にこのラッパーがない場合、たとえば開発者が__()なしでecho 'Save'をハードコーディングした場合、その文字列はまったく翻訳できず、.poファイルでは到達できません。ほとんどの信頼できるプラグインはすべてを正しくラップしていますが、翻訳できない頑固な文字列が1つか2つあることに気づいた場合、ソースにGettextラッパーがないことが原因である可能性が高いです。
プラグインが本当に翻訳対応であるかどうかを判断する簡単な方法は、WordPress.orgディレクトリにあるそのリストを確認することです。そこには翻訳のパーセンテージが表示され、/languagesテンプレートへのリンクがあります。活発な翻訳プロジェクトがあるプラグインは、放棄されたものよりもクリーンで完全にラップされた文字列を持っている可能性がはるかに高いです。
プラグインにPOTファイルがない場合はどうすればよいですか？
一部のプラグインは.potテンプレートなしで出荷されます。/languagesフォルダが空であるか、存在しない場合は、翻訳可能な文字列についてソースコードをスキャンして自分でテンプレートを生成する必要があります。
これに使用される標準ツールはWP-CLIで、すべてのGettext呼び出しを新しい.potに抽出します。
wp i18n make-pot wp-content/plugins/awesome-plugin \
wp-content/plugins/awesome-plugin/languages/awesome-plugin.pot
このコマンドはプラグインのPHPおよびJavaScriptファイルを検索し、すべての__()、_e()、_n()、および関連する呼び出しを見つけて、完全なテンプレートを書き出します。グラフィカルな方法を好む場合は、Poedit Proも同じ方法でソースコードをスキャンできます。いずれにせよ、結果は空の翻訳を含むすべてのソース文字列を含む.potであり、実際の言語ファイルに変換する準備ができています。
独自のテンプレートを生成することには隠れた利点があります。元の開発者が同梱の.potに含めるのを忘れた可能性のある文字列を捕捉できるのです。プラグインは急速に進化するため、バージョン2.1に付属していたテンプレートには2.4で追加された文字列が欠けている可能性があります。現在のソースから再生成することで、カタログが2リリース前の表示ではなく、プラグインが今日実際に表示しているものを確実に反映します。長期にわたってプラグインの翻訳を維持する場合、主要なアップデートごとにmake-potを再実行することは信頼できる習慣です。
正しい名前でPOおよびMOファイルを作成する
プラグインを翻訳する際、最もよくある間違いはファイル名です。WordPressは非常に特定のパターンに一致することでプラグインの翻訳を見つけ、1文字でも間違っていると翻訳は完全に無視されます。
ファイル名の法則
プラグインの翻訳の場合、パターンはtext-domain-localeです。したがって、awesome-pluginテキストドメインをドイツ語に翻訳する場合、ファイルは次のように命名する必要があります。
awesome-plugin-de_DE.po
awesome-plugin-de_DE.mo
ロケールコードはWordPressサイトの言語コードです。ドイツ語はde_DE、フランス語はfr_FR、スペイン語はes_ES、ブラジルポルトガル語はpt_BRです。ロケールを間違えると、WordPressはファイルをサイレントにスキップします。これらは、Poeditのようなエディタで.potテンプレートから作成します。Poeditは保存時にバイナリの.moを自動的にコンパイルします。このエディタを初めて使用する場合は、Poeditの完全ガイドでテンプレートから翻訳を作成する手順が詳細に説明されています。
更新でファイルが消去されないように配置する場所
2つの可能な場所があり、正しい場所を選ぶことが重要です。
# RISKY: inside the plugin — wiped on every plugin update
wp-content/plugins/awesome-plugin/languages/awesome-plugin-de_DE.mo
# SAFE: the global languages override folder — survives updates
wp-content/languages/plugins/awesome-plugin-de_DE.mo
常にwp-content/languages/plugins/を使用してください。WordPressはこの上書きディレクトリを最初にチェックし、プラグインフォルダの外にあるため、プラグインを更新しても翻訳は決して変更されません。プラグイン自身のフォルダ内に配置されたファイルは、新しいバージョンがインストールされた瞬間に上書きされます。
この上書き動作は、WordPressのローカライゼーションにおいて最も有用で、最も知られていない機能の1つです。これにより、サードパーティのプラグインをフォークすることなく、カスタムまたは修正された翻訳を出荷でき、変更は完全に更新安全です。同じプラグインを実行している複数のクライアントサイトを管理している場合でも、単一の上書き.moファイルセットを保持し、ロケールが一致する限り、各サイトが自動的にそれらを取得することを知って、それらすべてに展開することができます。
WordPressが翻訳を読み込む仕組み
翻訳対応プラグインは、初期化中にload_plugin_textdomain()を呼び出すことで、WordPressにそのカタログを読み込むように指示します。
add_action( 'init', function() {
load_plugin_textdomain(
'awesome-plugin',
false,
dirname( plugin_basename( __FILE__ ) ) . '/languages'
);
} );
WordPress 4.6以降のほとんどの最新プラグインでは、これを変更する必要はありません。ファイル名とサイトのロケールが一致している限り、WordPressはwp-content/languages/plugins/から翻訳を自動的に読み込みます。完成した翻訳が表示されない場合、原因はほぼ常にファイル名の不一致、古い.moファイル、またはサイトの言語が間違ったロケールに設定されていることです。WordPressで翻訳が表示されない場合のトラブルシューティングガイドでは、これらのすべての失敗点について説明しています。
データベースに文字列を保存するプラグイン
ここに重要な制限があります。Gettextのアプローチは、プラグインのコード内にある文字列のみを翻訳します。一部のプラグイン、特にフォームビルダー、ページビルダー、Eコマース拡張機能では、WordPressデータベースに保存されるコンテンツ（フォームラベル、製品属性、カスタムメッセージ）を作成できます。これらの文字列はユーザー生成データであり、.potの一部ではないため、.poファイルでは到達できません。データベースコンテンツには、WPMLやPolylangのような多言語プラグイン、またはプラグイン自身の文字列翻訳機能が必要です。特定の文字列がコード内にあるのか、データベース内にあるのかを、.poファイルで解決できると仮定する前に必ずテストしてください。
簡単なテストで、どのような種類の文字列を扱っているかを知ることができます。もしテキストが設定フィールドに入力したもの、作成したフォームラベル、カスタムの感謝メッセージ、製品名である場合、それはデータベースコンテンツであり、.poファイルでは変更できません。もしテキストがプラグインの組み込みインターフェース、ボタンラベル、検証エラー、プラグイン自体に付属する管理通知の一部である場合、それはコード内にあり、.poファイルはまさに適切なツールです。この線を早期に引くことで、何時間ものフラストレーションを避けることができます。なぜなら、完璧な.po編集をいくら行っても、プラグインが実行時にデータベースから取得する文字列を翻訳することはできないからです。
手作業なしで大規模に翻訳する
1つのプラグインを1つの言語に手動で翻訳するのは管理可能です。しかし、それを10の言語に翻訳したり、クライアントサイトのためにプラグインのスタック全体を翻訳したりすると、数日間の繰り返し作業になり、手動での編集は%sや%1$sのようなプレースホルダーを誤って扱って出力が壊れるリスクを伴います。
ここでクラウドワークフローが状況を変えます。プラグインの.poまたは.potファイルをSimplePoTranslateにアップロードし、ターゲット言語を選択すると、コンテキストを認識するAIがカタログ全体を翻訳し、**構文ロック（Syntax Locking）**があらゆるプレースホルダー、HTMLタグ、コードトークンを凍結するため、何も壊れることはありません。**スマートバッチング（Smart Batching）**は大規模なカタログを単一のパスで処理し、正しくフォーマットされ、wp-content/languages/plugins/にドロップする準備ができた.po、.mo、.json、.php、および.xliffを含むZIPをダウンロードできます。すべてがクラウドで実行されるため、デスクトップへのインストールもサイトの肥大化もありません。
プラグインの翻訳は、わずかに異なるフォルダ規則と読み込み関数を使用するテーマの翻訳とは異なります。もしテーマが対象である場合は、代わりに開発者でなくてもWordPressテーマをローカライズする方法に関する専用ガイドに従ってください。
1つのプラグインと1つの言語を扱う場合は手動のパスを使用してください。多くの言語を迅速に、プレースホルダーの安全性を損なうことなく必要とする場合はクラウドを使用してください。
ターゲットオーディエンスが話すすべての言語にWordPressプラグインを翻訳し、変数を壊すことなく準備ができていますか？SimplePoTranslateを無料で試す — クレジットカードは不要です。無料プランでは、最初のプラグインの.poファイルを数分で翻訳でき、すべての文字列にSyntax Lockingが適用されます。