WordPress 4.0はインストール時の言語選択と翻訳更新を分けて管理する

WordPress 4.0の言語選択では、新規インストールの最初に言語を選べます。ただし、ここで決めるのはサイトの管理画面や標準表示に使う言語です。テーマやプラグインを含む言語パックを新しい状態に保つ仕事とは分けて考えます。

言語を選べたから翻訳の保守も終わった、とは限りません。運用を始める前に、サイトの言語、翻訳更新の方法、ファイルを変更できる条件を記録してください。

新規インストールでは最初にサイトの言語を選ぶ

WordPress本体を新しく設置すると、インストール画面の最初に言語の一覧が表示されます。言語を選んでContinueを押すと、対応する言語パックがダウンロードされ、残りのインストールがその言語で進みます。

この選択で、投稿や固定ページの本文が自動翻訳されるわけではありません。管理画面やWordPress本体の表示に使う言語を選び、必要な翻訳ファイルを受け取る操作です。サイトへ掲載する文章の言語と、管理画面の言語を同じ仕事として扱わないでください。

配布済みのローカライズ版パッケージを使う場合は、インストール時の言語一覧を経由しません。また、言語パックの取得に必要なファイル操作で接続情報を求められる環境では、言語一覧が表示されない場合があります。表示されないからといって、インストールの失敗と決め付けることはできません。

既存サイトでは保存されている言語を確認する

単一サイトでは、設定の一般にあるサイトの言語で、使用する言語を確認します。WordPress 4.0はサイトのロケールをデータベースのWPLANGオプションへ保存します。

wp-config.phpへ書くWPLANG定数は非推奨になりました。既存サイトに定数が残っている場合も、ファイルだけを見て使用言語を判断せず、管理画面とデータベース側の設定を確認します。

言語を変更するときは、次の三つを先に分けます。

翻訳更新は言語を選ぶ操作とは別に動く

WordPress 4.0には、古くなった翻訳を非同期で更新する仕組みがあります。テーマやプラグインをインストールまたは更新した後、対応する翻訳が用意されていれば、言語パックも更新されます。

翻訳更新は、サイトの言語を選び直す操作ではありません。選ばれている言語に必要な翻訳ファイルを保つ処理です。テーマやプラグイン本体が正常でも、翻訳ファイルが古ければ、新しい項目だけ原文で表示されることがあります。

自動の翻訳更新を止める必要がある環境では、async_update_translationとauto_update_translationのフィルターを使えます。ただし、停止を先に決めるのではなく、誰が、いつ、どの方法で翻訳を更新するかを決めてから変更します。

バージョン管理システムでファイルを管理しているインストールでは、翻訳の自動更新は実行されません。サーバー上のファイルを自動で変えたくない運用には合いますが、翻訳を更新しなくてよいという意味ではありません。更新担当者が言語パックの差分を確認し、管理しているファイルへ反映します。

言語の設定と更新責任を一枚に記録する

説明用の仮例として、日本語で運用する小規模な会社サイトを考えます。新規設置では日本語を選び、サイトの言語も日本語であることを確認します。さらに、更新方法を次のように記録します。

• WordPress本体、テーマ、プラグインの更新担当者
• 言語パックを自動更新するか、管理ファイルへ取り込むか
• サーバーがファイルを変更できるか
• 翻訳更新後に確認する管理画面と公開画面
• 原文表示が残ったときの連絡先

この記録がなければ、制作者は自動更新を止め、運用担当者は自動で更新されると思い込む、といった食い違いが起きます。設定作業を外部へ任せても、使用言語と更新責任はサイト所有者が確認できる形で残します。

最初の一手は、新規インストールか既存サイトかを分けることです。新規なら最初の言語選択を確認し、既存ならサイトの言語とWPLANGの扱いを確認します。その後で、翻訳を自動更新するか、管理しているファイルへ取り込むかを決めてください。