WordPress 4.7の管理画面言語はsiteの表示言語と利用者ごとに分ける

WordPress 4.7では、利用者ごとに管理画面で使う言語を選べるようになります。これは公開siteの表示言語を利用者ごとに変える機能ではありません。公開側はsite全体に設定したlocaleを使い、管理画面は利用者のlocaleを使います。管理画面を読みやすくしても、公開本文の翻訳やURLの設計は変わりません。

複数の言語を使う担当者が同じsiteへ入る場合でも、各利用者は自分が読みやすい管理画面を使えます。目的は翻訳siteを作ることではなく、管理する人が設定、投稿、公開先を取り違えにくくすることです。言語を選べることと、何を公開できるかは別の設定です。

公開siteの言語を替えたい仕事と、管理者が画面を読めるようにする仕事は、依頼する相手も確認する場所も違います。前者では本文、menu、themeの文言、URL、検索から来た人への案内を確認します。後者では投稿編集画面、設定画面、更新時の確認文を確認します。利用者localeを替えたからといって、外国語の記事が増えるわけでも、公開画面の日本語が自動で翻訳されるわけでもありません。

言葉が読めることと、意味を正しく判断できることも別です。海外の制作者が英語の管理画面を使えても、日本語の公開文をそのまま承認できるとは限りません。反対に、日本語で記事を確認できる担当者が、英語のplugin設定を読めないこともあります。作業を分担するなら、誰が技術設定を確認し、誰が公開文と事業上の条件を確認するかを決めます。

どの画面やmailがどの言語を使うかを分ける

説明用の仮例として、日本語の会社siteを海外の制作者が更新する場合を考えます。公開する記事は日本語のままです。制作者は自分の管理画面を別の言語で読み、投稿の内容と公開先を確認します。管理画面の言語を変えても、公開本文を別の言語へ変える権限や、公開の承認手順までは変わりません。

利用者がprofileで言語を選ばなければ、siteのlocaleが使われます。利用者ごとのlocaleはuser metaへ保存されます。管理画面で独自の文言を出すthemeやpluginがあるなら、利用者のlocaleで表示されるかを確認します。標準画面だけが読めても、独自の設定画面だけ別の言語になれば、操作を誤る理由になります。

独自themeやpluginには、翻訳のための文言が用意されていないものもあります。その場合、WordPressの標準画面だけが切り替わり、独自の項目名や説明は元の言語のまま残ります。無理に文言を読み替えたつもりで操作せず、どの設定が何に影響するかを管理メモへ残します。言語設定を替えたあとに、投稿編集、menuの編集、themeの設定、pluginの設定を一つずつ開けば、利用者が実際に使う画面で混在する箇所を見つけられます。

説明用の仮例で、日本語の公開siteを日本語担当者と英語を読む制作担当者が保守する場合を考えます。制作担当者の管理画面を英語にしても、公開する記事のtitleや問い合わせ先を誰が最終確認するかは別に決めます。制作担当者がtemplateを直し、日本語担当者が公開文とlink先を確認するなら、変更した場所と確認したURLを渡します。localeの違いを理由に、公開確認まで省かないことが必要です。

Ajaxとmailは画面表示と別に確認する

管理画面からAjaxで文言を返す処理は、ログインしている利用者のlocaleで返ります。公開側と同じsite localeの文言を返す必要がある処理なら、どちらの言語で返すべきかを決めます。画面で見たときに正しくても、Ajaxで表示する確認メッセージが別の言語になる場合があります。

mailも同じです。利用者へ送る通知は受信者のlocaleへ切り替えられます。一方、管理者mailはsiteのlocaleを使います。誰に送るmailかを決めずに文言だけを直すと、意図しない言語で通知が届くことがあります。mailを外部の担当者が確認するなら、実際の受信者と文面を一通ずつ確かめます。

通知mailを確認するときは、送信したという画面表示だけで終わらせません。どの利用者へ届いたか、件名と本文が読める言語か、返信が必要な場合に誰が受けるかを確かめます。記事の公開通知、passwordの変更通知、管理者への連絡では、受信する人と必要な情報が違います。利用者localeを使う通知とsite localeを使う通知を同じ文面として扱うと、受信者が次に何をすべきか分かりにくくなります。

Ajaxを使う独自画面は、保存成功や入力エラーを画面上で返すことがあります。通常の管理画面が読めるからといって、こうしたメッセージも同じ言語になるとは限りません。投稿を保存する、画像を追加する、独自設定を変更するといった操作を一度ずつ行い、表示される文言と実際の結果を確認します。文言が読めなくても保存は成功している場合があるため、画面上の表示と変更後の状態を分けて見ます。

管理画面の言語を変える前に、誰が記事を作り、誰が公開を承認し、誰がsite全体の言語を管理するかを決めます。管理画面を読めることと、公開内容を決める権限は別です。

最初の一手は、利用者を一人選びます。profileで使う言語と、その人が編集できる投稿の範囲を確認し、公開siteの表示が変わらないことも確かめます。

変更を広げる前に、元へ戻す方法も確認します。利用者が管理画面を読みにくくなったとき、どのprofileで言語を戻せるか、管理者が代わりに確認できるかを決めます。site全体のlocaleを替える作業と違い、利用者localeの変更は個人ごとの作業です。誰の画面を替えたかを残しておけば、別の担当者の画面まで変わったと誤解せずに済みます。