WordPress 4.6のlanguage packはthemeとpluginのText Domainを確認してから更新する

WordPress 4.6では、WordPress.orgのdirectoryにあるthemeとpluginでlanguage packを使う場合、translationの読み込み方が変わります。更新前に確認するのは、画面が日本語かどうかだけではありません。themeまたはpluginがどのText Domainを使っているか、独自に置いたtranslation fileがあるか、更新後にどの文章が変わるかを分けます。

4.6では、language packを使うdirectoryのthemeとpluginについて、Text Domainを手動で読み込む必要がなくなります。一方、独自配布のthemeやplugin、独自のtranslation file、unload_textdomain()を使う構成まで、自動で同じように扱われるとは決めません。翻訳を更新する作業と、site固有の文章を守る作業は別です。

更新後に管理画面が日本語で読めても、公開siteの案内文が正しいとは限りません。themeが用意した「Read more」のような一般文言と、事業者が書いた「受付時間」「価格」「問い合わせ先」は、出所も直す人も違います。表示が変わったときに、どのfileを探すか、誰へ確認するかを決めるために、文章の種類を先に分けます。

WordPress本体の表示とthemeの文章を分ける

管理画面の言語が変わっていなくても、themeやpluginの文章が期待どおりに表示されるとは限りません。

説明用の仮例として、theme内の「Contact」「Read more」をtranslation fileで日本語化し、会社名やservice名も同じfileへ書いているsiteを考えます。language packの更新で一般文言が変わることはありますが、固有名や案内条件まで自動で正しい文章になるわけではありません。更新前に独自の文章をどこで管理しているかを分けます。

たとえば、themeのbuttonに「Contact」と表示され、独自translation fileで「お問い合わせ」としている場合を考えます。この翻訳は一般的な表示文です。一方で、そのbuttonのlink先に置く電話番号や受付時間は、翻訳を読み込む仕組みとは別に管理します。language packが更新されたことを理由に、link先や営業時間を見直さないままにすると、画面の一部だけ新しくなり、肝心の案内が古いまま残ります。

会社名や商品名をtranslation fileへ入れている場合は、更新時に上書きされないかを確認します。一般文言と固有名を一つのfileへ混ぜると、language packを取り込む作業と、事業の表記を直す作業が切り分けにくくなります。固有の文言をどこへ置くかは、翻訳の見栄えの問題だけではありません。誰が確認し、変更の履歴をどこに残すかという運用の問題です。

pluginの設定画面も同じように分けます。問い合わせformの送信button、メールの件名、入力エラーの文言は、pluginが用意した翻訳か、site側の設定かを確かめます。送信buttonだけが日本語になっても、送信後の案内やメールの宛先が正しいとは限りません。管理画面の翻訳と、利用者へ渡る文章を一度に良し悪しで判断しません。

更新前にText Domainとfileの置き場所を確認する

4.6へ更新する前に、次の順で確認します。最初に配布元を分ける理由は、更新されるfileと守るべきfileが違うからです。directoryから入れたthemeとpluginはlanguage packの仕組みを使いますが、制作会社が渡したthemeや社内で作ったpluginは、同じ場所から更新されるとは限りません。名前が似ていても、由来を確認せずに同じ手順を当てはめません。

1. 使っているthemeとpluginがWordPress.orgのdirectory由来か、独自配布かを分ける。
2. themeとpluginのheaderに書かれたText Domainを確認する。
3. load_plugin_textdomain()や独自のtranslation読み込みを使っている箇所を探す。
4. 独自translation fileの保存場所と、更新後に上書きされる可能性を記録する。
5. test siteで管理画面、公開page、問い合わせformの文言を確認する。

説明用の仮例として、独自themeがload_theme_textdomain()で翻訳を読み込み、pluginがload_plugin_textdomain()で別の翻訳を読み込む構成を考えます。両方が日本語に見えていても、Text Domainは同じとは限りません。themeのfileだけを確認してpluginのText Domainを見なければ、更新後に設定画面の一部だけ英語へ戻った理由を追えません。themeとpluginを別の行にし、Text Domain、fileの場所、表示する画面を記録します。

unload_textdomain()を使っている場合は、いったん翻訳を外したあと、必要なら改めて読み込む必要があります。関数名だけを見て不要と判断せず、どの画面で何のText Domainを外しているかを確認します。特定の画面だけ表示を替えるために外しているなら、4.6へ更新したあとにその画面と通常の画面を比べます。管理画面全体を一度見るだけでは、条件付きの読み込みを確認できません。

fileの置き場所を確認するときは、更新対象のdirectoryと、独自に保管した翻訳fileを同じ場所として扱いません。更新で置き換わる可能性がある場所に手で直したfileを置くと、次の更新で変更が消えることがあります。逆に、独自のfileを別の場所に置いているなら、誰がそのfileを更新するかを引継ぎ資料へ残します。更新前にbackupを取ることと、どのfileが必要かを理解することは別です。

test siteでは、管理画面のmenuだけでなく、公開page、form、送信後の案内、404 pageなど、themeとpluginの文言が出る場所を開きます。確認するpageを三つに絞る場合も、同じ種類のpageだけを選びません。通常の固定page、問い合わせの画面、pluginが出す画面のように、翻訳の出所が違うものを選びます。更新後の違いを見つけたら、表示が変わっただけか、案内内容の確認が必要かを分けます。

翻訳の更新と案内内容の承認を分ける

translation fileの更新を制作側へ頼めます。しかし、料金、営業時間、会社名、service名、問い合わせの案内が正しいかを確認する責任まで移りません。language packは一般的な表示文を扱う仕組みで、事業情報の承認を代わりに行うものではありません。翻訳のtechnicalな修正と、顧客へ出す条件の承認を同じ担当へ曖昧に渡さないことが必要です。

制作側へ頼むときは、themeとpluginの配布元、Text Domain、独自fileの場所、test siteで開くpage、更新後に確認する文言を渡します。制作側はtranslationの読み込みと画面表示を確認します。事業側は、会社名、商品名、価格、受付条件、問い合わせ先を確認します。一般文言が変わらなくても、問い合わせ先が古いなら公開できる状態とは言えません。

最初の一手は、公開siteから三つのpageを選び、WordPress本体の表示、themeの一般文言、pluginの一般文言、事業固有の文章を別の欄に書くことです。各欄に、Text Domainまたは管理する場所、確認する人、更新後に開くURLを添えます。どの文章がどこから出ているかを分けてから更新します。WordPress 4.6への対応は、日本語表示を増やす作業ではなく、変更後も事業の案内を正しい状態に保つ作業です。