翻訳ファイル作成の 3 ステップ 先日、プラグインとテーマのローカライズについて主にプラグインやテーマの開発者の視点に立って書きましたが、今度は翻訳をする人の立場で見てみたいと思います。 gettext の翻訳ファイル作成をサポートするツールはいくつかあるようですが、Windows では poEdit が使えます。poEdit の現時点での最新バージョンは 1.3.4 です。 poEdit を使った翻訳ファイル作成作業の流れは次の各段階に分かれます。 ソースコードから翻訳対象のテキストを自動抜粋、.po ファイルを生成する。 翻訳対象となるテキストは __() と _e() のところなので、poEdit はソースファイルをサーチして自動で収集してくれます。生成される .po ファイルはテキストフォーマットのファイルで、次の翻訳作業で編集に使われます。 .po ファイルを編集、翻訳作業を行なう。 この段階が実際の翻訳作業です。作業は poEdit のインタフェイスから行ないますが、.po ファイルは普通のテキストファイルなので他のエディタで編集することも可能です。 .po ファイルを保存、同時に .mo ファイルが生成される。 編集した .po ファイルを保存すると同時に .mo ファイルが自動生成されます。.po は人間が読み書きするのに適したテキストファイルであるのに対して、.mo…

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 に移動させてテンプレートから関数として呼び出ししたほうが、テンプレートの構造がシンプルでわかりやすくなるでしょう。