WordPressの言語ファイルを正しく読み込む

WordPress のローカライゼーション機能を使用すると、WordPress 言語ファイル（po/mo ファイル）を通じてプラグインやテーマを簡単に翻訳可能にすることができます。

これは特に WordPress 3.7 以降に当てはまり、 WordPress 4.6.

WordPress の翻訳システム全体に多くの改善が加えられたため、改めて記事を書く必要があると感じました。

WordPress 言語ファイル – 混乱の整理（開発者編）

開発者にとっての課題は、翻訳ファイルの存在を WordPress に正しく伝える方法です。

開発者として、"load_plugin_textdomain()" を使用し、プラグインフォルダー内の言語ファイルを指定するよう言われてきました。

しかし以前は、WordPress がファイルを探す場所はそこだけであり、 ユーザーが独自の言語ファイルをそこに追加しても、次のアップデート時に消えてしまっていました！

以前、Web 上の記事で "load_textdomain()" 関数を使って WP 言語フォルダー内のファイルを指定する 2 回目の呼び出しを使用する方法が紹介されており、多くの人（私たちを含む）がその方法を採用しました。

これにより、ユーザーは WP 言語フォルダー内の所定の場所に言語ファイルを配置でき、プラグインのアップデート時に翻訳が失われることがなくなりました。

WordPress 言語ファイル – 混乱の整理（ユーザー編）

ユーザーはプラグイン／テーマのカスタム翻訳をどこに置けばよいかを知る必要がありますが、以前はその場所が複数存在していたため、問題が生じていました。

WP のドキュメントでは、プラグインフォルダー内の「languages」というフォルダーにリンクするよう開発者に案内していますが、開発者によっては「lang」というフォルダーを使用している場合があり、 さらに、プラグイン／テーマが更新されるとその設定が失われてしまいます。

開発者によっては、独自に選んだ場所に2つ目のチェックを追加することもありましたが、多くの場合は WP の languages フォルダー内のカスタム名フォルダーに配置されていました。

そのため、カスタム翻訳ファイルを安全に置く場所をユーザーが一貫して把握する方法がありませんでした。

正しい方法で言語ファイルを読み込む（2017年）

WP 4.6 以降、ユーザーにとっても開発者にとっても、この作業は格段に簡単になりました！

開発者としては、以下の WP ドキュメントに従い、言語ファイルを正しく読み込んでいることを確認するだけで済みます。

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />

'init' および 'after_setup_theme' フックでこれらを実行していることに注意してください。こうすることで、すべてがスムーズに読み込まれるはずです。

直接実行したり、それぞれのフックより前に実行したりすると、一部の文字列が翻訳されないといった問題が発生したり、WPML などの翻訳操作や多言語サイト作成用プラグインがまったく機能しなくなる場合があります。

ユーザーとしては、言語ファイルを置くための便利で一貫した名前の場所が用意されるようになりました。

• プラグインの場合： /wp-content/languages/plugins/my-plugin-en_US.mo
• テーマの場合： /wp-content/languages/themes/my-theme-en_US.mo

「my-plugin」と「my-theme」はプラグイン／テーマのテキストドメインです（通常、プラグインの readme.txt またはテーマの style.css の先頭に記載されています）。

これは従来の方法から大きく改善されており、ほとんどの場合、更新時に翻訳が失われるのを防ぐことができます。

場合によっては、wp.org に保存されているあなたの言語の新しい翻訳がプラグイン／テーマにすでに含まれていることがあり、その場合は .mo ファイルが上書きされる可能性がありますが、ほとんどの場合それは意図した動作です。

プラグインが wp.org でホストされている場合は翻訳に貢献することができます。プレミアムプラグインの場合は、上書きされる可能性はほとんどありません。

ボーナス情報

WordPress は、テキストドメイン「my-plugin」を持つプラグインの言語ファイルをいくつかの場所から探します。まず最初にここを確認します：

/wp-content/languages/plugins/my-plugin-en_US.mo

そこに翻訳が見つからず、プラグインがローカルのパスを指定している場合は、そちらを確認します：

/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo

プラグインがパスを指定していない場合、WordPress は代わりにここを確認します：

/wp-content/languages/my-plugin-en_US.mo

WordPress のドキュメントに従うことが推奨されますが、実際のところ WP 4.6 以降では、翻訳ファイルをローカルに含めない場合（wp.org リポジトリに保存されている場合）、ローカルファイルを指定する必要すらありません。次のように追加するだけで大丈夫です：

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin');<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme');<br />
}<br />

これで翻訳についての理解が少し深まれば幸いです。ご質問や追加したいことがあれば、ぜひ下のコメント欄にお書きください。