WordPressのthemeを翻訳対応にするときは表示文言をText Domainへまとめる

WordPressのthemeを翻訳対応にするなら、headerやbuttonの文言をPHP fileへ直接書き足してはいけません。theme全体で一つのText Domainを決め、表示文言を翻訳できる文字列としてそろえます。文言の修正と翻訳fileの管理を分けておけば、言語を増やすときもthemeの構造を壊さずに済みます。

WordPress Theme Handbookの公式資料は、themeの文字列を直書きせず、WordPressのlocalization functionへ渡す方法を説明しています。翻訳fileは.poと.moで扱い、themeの翻訳を読み込むにはload_theme_textdomain()を使います。

翻訳対応で最初に困るのは、英語の文字を日本語へ替えることではありません。どの文字がthemeの一部で、どの文字が管理画面から入力したcontentなのかが分からなくなることです。headerに書かれた短い案内、buttonの文言、検索結果がないときの表示、footerのcopyright表記はtheme側で扱うことがあります。会社案内や商品説明の本文までtheme fileに書き始めると、翻訳と更新の担当を分けられません。

Text Domainは、翻訳fileを探すためだけの記号ではありません。誰が見ても、この文字列がどのthemeに属するかを判断できる名前にします。途中で別のText Domainを混ぜると、翻訳が反映されない文字が出たときに、PHP file、翻訳file、読み込み処理のどこを直すべきか分からなくなります。親theme、child theme、pluginの文言は、似ていても同じ管理単位にしません。

表示文言と設計上の値を分ける

翻訳するものは、訪問者や管理者が読む文言です。CSS class名、template file名、URLのslugまで翻訳しようとすると、言語ごとに構造がずれて保守できなくなります。

「送信」のように同じ文字でも使う場所が違えば、訳語も変わることがあります。見た目が同じだからと一つの文字列へ寄せるのではなく、誰がどの場面で読むかを先に分けます。

たとえばformのbuttonにある「送信」と、送信後の案内にある「送信」は、同じ動詞でも役割が違います。前者は操作を促し、後者は完了した状態を伝えます。翻訳する人が画面を見ずに文字列だけを読むと、どちらの意味か判断できないことがあります。表示する場所や前後の文脈を記録しておけば、別の言語へ替えるときに不自然な文を減らせます。

管理画面のoptionへ入力する文言も、themeの固定文言と混ぜません。たとえば電話番号、営業時間、事業名のようにsiteごとに変わる情報は、themeの翻訳fileではなく、siteのcontentまたは設定として管理する方がよい場合があります。反対に、すべてのsiteで同じように出る「続きを読む」や「検索結果」は、themeの表示文言として扱います。どこで直すべき情報かを先に決めます。

Text Domainを途中で増やさない

Text Domainは、themeに属する翻訳を見分ける名前です。親theme、child theme、pluginの文言を混ぜると、どの翻訳fileを直せばよいか分からなくなります。自作themeなら、themeのslugに合わせた一つのText Domainを決め、すべての表示文言に使います。

作業は次の順で進めます。

1. theme内で画面へ出している日本語や英語の文言を探す。
2. themeのText Domainを一つ決める。
3. 各文言をlocalization functionへ渡し、同じText Domainを指定する。
4. functions.phpでload_theme_textdomain()を使い、翻訳fileを読み込む場所を決める。
5. .po fileを作り、翻訳後の.mo fileを用意して表示を確認する。

文言を変える作業と、翻訳fileを更新する作業は別に記録します。日本語の表記を直しただけでも、翻訳fileの元になる文字列が変われば、ほかの言語では未翻訳になります。

既存themeを直すときは、見つけた文字列を一度にすべて置換しません。header、footer、archive、search、404、formのように表示場所を分け、画面で確認しながら進めます。文字列の周囲にはHTML、条件分岐、linkがあるため、表示文言を翻訳対応にした変更でmarkupまで壊すことがあります。まず利用者がよく見る場所から始め、templateごとに表示を確認します。

Text Domainを決めたら、theme fileの各所で同じものを使います。file名やfolder名と、画面上の文言を同じものにする必要はありませんが、themeを引き継ぐ人が追える関係にします。独自の略称だけを使うと、翻訳fileの名前、themeのslug、読み込み処理を見比べる作業が増えます。新しいthemeを作る段階で決めるのが理想ですが、既存themeでも変更の影響範囲を調べてからそろえます。

.po fileは翻訳の元になる文字列を扱い、.mo fileはWordPressが読み込むためのfileです。翻訳文を書き換えたあと、どのfileを更新して確認したかを残します。fileを渡しただけで画面が切り替わらない場合は、翻訳文そのものではなく、Text Domain、fileの置き場所、読み込み処理、現在選ばれているsiteの言語を分けて調べます。表示が変わらない原因を、訳文の良し悪しだけにしません。

language fileだけで表示を直そうとしない

翻訳fileは、themeの表示文言を置き換えるためのものです。menuの構成、headerの導線、画像の中に焼き込んだ文字まで解決するものではありません。特に画像内の文字は翻訳fileで替えられないため、languageごとに画像を分けるのか、HTMLの文字へ置き換えるのかを設計段階で決めます。

画像を言語ごとに分ける場合は、どのpageがどの画像を使うかを管理します。広告用の画像、headerのlogo、説明図のように文字を含む画像を後から差し替えると、翻訳fileだけでは追えません。画像を替える担当とthemeを直す担当が違うなら、対象言語、file名、表示場所を渡します。画像の中の文字をHTMLへ移せるなら、表示の調整と翻訳の責任を分けやすくなります。

menuの項目も、単語を翻訳すれば終わりではありません。短い日本語では一行に収まっていた項目が、別の言語では長くなり、headerの幅やmobileのmenuに影響します。翻訳後は、トップだけでなく、長いpage title、検索結果、formのerror表示を開きます。文字列を読み込めたことと、利用者が画面で読めることは別です。

外部へ翻訳対応を頼むときは、theme fileと翻訳fileのどちらを納品するかだけでは足りません。Text Domain、対象となるtemplate、翻訳する言語、画像内文字の扱い、管理画面から入力するcontentの範囲を決めます。作業後には、追加した文字列、変更した読み込み処理、確認した画面を受け取ります。翻訳を委託しても、何を事業側で更新するかまで曖昧にしないためです。

最初に拾う十個の文字列は、短いものだけに偏らせません。header、button、検索結果、404、formのように利用者が目的を失いやすい場所から選びます。各文字列について、表示場所、Text Domain、翻訳する言語、画面で確認するURLを残せば、小さく始めてもtheme全体へ広げる順番を決められます。

最初の一手は、themeのheader.phpとfooter.phpから表示文言を十個だけ拾うことです。文字列、表示場所、Text Domain、翻訳が必要な言語を書き出せば、どこから直すべきかが見えます。