WordPress のローカライズの基本 WordPress には gettext を利用したローカライゼーション(多言語化、現地語化)の仕組みが組み込まれているので、必要な翻訳ファイルさえ手に入ればわずかな設定で日本語化することが可能です。 簡単に手順をまとめると、 翻訳ファイル(.mo) を入手する。日本語リソースの情報がこちらにまとめられています。 翻訳ファイルを <WP_INSTALL>/wp-includes/languages/ 以下に配置する。languages というディレクトリは最初はないので自分で作る必要があります。 <WP_INSTALL>/wp-config.php の define (‘WPLANG’, ”); の行を翻訳ファイルの名前に合わせて書き換える。日本語なら翻訳ファイルが ja.mo なので define (‘WPLANG’, ‘ja’); とします。WPLANG を変更できない場合はファイル名の方を WPLANG に合わせて変更しても問題ないはずです(ja.mo ⇒ ja_UTF.mo とか)。 ところがこの手順で日本語化できるのは基本的には管理パネルの内容だけで、一般の読者が目にするオモテの部分は対象になりません。なぜかというとオモテの部分はテーマでコントロールされているので、テーマのテンプレートに含まれるテキストの日本語化がされない限りオモテは変わらないのです。プラグインについても同様で、プラグインで制御されるテキストのローカライズは個々のプラグインごとに考慮される必要があります。 それではテーマやプラグインの作者がローカライズのために考慮すべきポイントとは何でしょうか。テーマやプラグインにおいても gettext を使用してローカライズすることには変わりありません。テーマやプラグインではその内部で明示的に翻訳ファイル(.mo) をロードする必要があるわけですが、プラグインが翻訳ファイルをロードするために使うのが load_plugin_textdomain() という関数です。

テーマのディレクトリ(<WP_INSTALL>/wp-content/themes/theme-name/)に置くことができるのはビジュアル・テンプレートだけではありません。ディレクトリ内に functions.php という名前のファイルを作っておくと、それが自動的にインクルードされて実行されます。 functions.php はそれを含むテーマが有効化されている場合に限定してインクルードされます。プラグインで実装されるような機能が functions.php で実現されることも良くあります。 実際の使用例を挙げると、Default テーマ (Kubrick) ではヘッダイメージの色を変更できる追加のサブメニューを導入していますが、このメニューの追加などの処理は functions.php の中で書かれています。このようにテーマ固有の機能性を盛り込むことができます。 これほど大掛かりでなくてもテンプレート内部で複雑なロジックを記述する必要があるような場合は、それらのロジックを functions.php に移動させてテンプレートから関数として呼び出ししたほうが、テンプレートの構造がシンプルでわかりやすくなるでしょう。