カテゴリー: WordPress

WordPress 3.6 日本語版がリリースされました。

今回リリースリーダーを担当しました。3月の下旬、そろそろ 3.6 に向けて動き出すよという雰囲気になって以降、beta 版が4回もあるなどリリースまで時間がかかりました。関わった皆さん、ありがとうございました。また、担当は次の 3.7 がリリースされるまで続きます。もうしばらくよろしくお願いします。

実際の翻訳作業は GlotPress という仕組みを使って、多くの皆さんが協力してやってくださるので、リリースリーダーといってもその主な任務はパッケージを作ることです。3.6 正式版の前に beta 版を4回、RC 版を2回、パッケージを作って公開しました。

この手順を、RC2 のときを例にして、ちょっとご紹介しましょう。

と、その前に、日本語版パッケージは何からできているのか、をおさらいしておきます。大元は WordPress 英語版です。それにメッセージの日本語リソースです。それと、その日本語リソースではカバーできない、直接翻訳するしかないファイル(現在のバージョンでは readme.html と wp-config.sample.php くらいです)と WP Multibyte Patch です。この3つを混ぜ合わせて、日本語パッケージは作られています。

はじまりは

あらら WordPress 3.6 Release Candidate 2 http://t.co/olZrQNcY4G

— Mako (@mako0901) July 24, 2013

と、英語版のリリース情報を知るところからです。だいたい WordPress News を見ていますが、うっかりしていて誰かの tweet やほかの言語の人たちの様子で知ることもあります。

そこでパッケージ作成の作業に入ります。まず翻訳状況を確認します。翻訳作業は GlotPress で行われていて、日本語なら Japanese というところを見ると、未翻訳の数などがわかります。

昨日まで未訳20以上残っていたのがほどんど解消してた。ありがとう、ありがとう。

— Mako (@mako0901) July 24, 2013

前日にちらっと見たら未翻訳が残っていて、やらなきゃなあと思いながらも手を付けられずにいたのですが、夜が明けたらあら不思議、その分はもう誰かがやってくれていたのでした。

さらに追加されて増えていた未訳もやっつけた。

— Mako (@mako0901) July 24, 2013

英語版でメッセージ文が追加されたり変更されたりすると、未翻訳の数が増えます。今回はそう面倒なものでもなかったので、なんとかやり終えました。beta や RC の場合は未翻訳が多少残っていてもその状態でパッケージ作成、公開することもあります。何しろテスターに見てもらうことが目的ですからね。

ここで、元になる英語版ソースのリビジョンをチェックします。

r24794 ですな。http://t.co/AwVZ9jKxl4

— Mako (@mako0901) July 24, 2013

ソースの状況は Trac で公開されているので、そのコミット記録を見て、「RC2」と印が付けられたのはいつか、を調べてこの数字をメモしておきます。

直接翻訳ファイルは、この例の RC2 の前後では変化がなかったので、作業はありませんでした。もし英語版に変更があれば、それに合わせて日本語版のファイルを書き換える作業をします。

で、いよいよパッケージの作成です。wordpress.org のどこか(秘密です)にログインします。そこで「作成」ボタンをクリックすると、英語版ソース(メモしておいたリビジョンを指定します)に、GlotPress から日本語リソースを自動的に取ってきて、さらに直接翻訳ファイルも別のところから自動的に取ってきて、これらを混ぜ合わせて日本語版パッケージを作成してくれます。

この時点のパッケージの URL は一般には公開されません。

WP3.6RC2 日本語パッケージ作りました。関係者のみなさま、チェックお願いします。リリースはもうしばらく後。

— Mako (@mako0901) July 24, 2013

日本語作成チームの皆さんには別の方法で通知しているので、何も tweet しなくてもいいのですが。

チームの皆さんがいくつかの点についてチェックし、問題なさそうだという返事を受けて、公開します。秘密のページで「公開」をクリックすると beta や RC の場合は、「ベータ & RC バージョン」の表に載ります。

最後は告知です。「WordPress｜日本語」でお知らせします。beta や RC の場合は、英語版の告知に追記してお知らせすることが多いです。

WordPress 3.6 リリース候補2(RC2) の日本語版でました。http://t.co/mgulYJprXJ

— Mako (@mako0901) July 25, 2013

さあ、どうでしたか。あなたも日本語作成チームに参加して、リリースリーダーを担当してみませんか。

検索のしかたがよくなかったのか、日本語での情報をうまく見つけることができませんでした。そこで WordPress Code: Earlier Shortcodes をほぼそのまま訳しつつ、ここに記しておきます。

問題

僕がひっかっかった問題も、そのページのはじめにあるのとほぼ同じでした。すなわち、WordPress のショートコードは優先順位(プライオリティ)が 11 であり、そのため wpautop() や wptexturize() などデフォルトのフィルター群(デフォルトの優先順位は 10)の後に実行されることになります。

たとえば

これは適当な文です。

ここに [foobar]80's pop[/foobar] などと書いたとします。

これはまた適当な文です。

という文章を書いた場合、まず wptexturize() によって 80′s pop と変換されたものが ショートコード foobar に囲まれた内容として渡され、意図しない結果になることがあります。

解決策その1

まず思いついたのはフィルターの優先順位を下げてしまおうというものでした。ちょうど Solution to WordPress adding br and p tags around shortcodes と同じです。ショートコードの処理を書くあたりに

remove_filter( 'the_content', 'wpautop' );
remove_filter( 'the_content', 'wptexturize' );
add_filter( 'the_content', 'wpautop' , 12);
add_filter( 'the_content', 'wptexturize' , 12);

と書いてしまおうというものです。

当面の問題、すなわちショートコード foobar については、これで回避されましたが、ちょっと不安が残ります。WordPress のデフォルトが「ショートコードはフィルターの後」なのですから、他の人がそれを前提に作ったものを使ったときに問題が出るかもしれません^[1]。

解決策その2

そこでもうしばらく検索して、最初に紹介した WordPress Code: Earlier Shortcodes を見つけました。そこにあるサンプルコードを、コメントを適当に訳しながら再掲しますと、

// これは実際には何もしない。ダミー。
add_shortcode( 'foobar', '__return_false' );
 
// ショートコードの実際の処理
function foobar_run_shortcode( $content ) {
    global $shortcode_tags;
 
    // 現在のショートコード群をバックアップをとってから、すべて削除する
    $orig_shortcode_tags = $shortcode_tags;
    remove_all_shortcodes();
 
    add_shortcode( 'foobar', 'shortcode_foobar' );
 
    // ショートコードを実行 (直前の行で加えた当該のショートコードのみ)
    $content = do_shortcode( $content );
 
    // 元のショートコード群を復元する
    $shortcode_tags = $orig_shortcode_tags;
 
    return $content;
}
 
add_filter( 'the_content', 'foobar_run_shortcode', 7 );

解説

この関数は、まず登録されているショートコードの一覧が格納されている変数 $shortcode_tags を大域変数化し、それを別の変数にコピーし(後で復元させるため)、それからそれを空にします。これで登録されているショートコードは何もありません。

ここに当該のショートコードただひとつを登録し、do_shortcode() で 内容(content)に適用します。その後で、先ほど保存しておいたショートコード群を復元して登録し(ここで当該のショートコードは抹消されるので二重に適用されることはありません)ます。そしてdo_shortcode() の返り値の内容(content)を返します。

最後に、wptexturize() より前に実行されるように優先順位をつけて(1から9の値にします。ここでは 7 にします)、フィルターとして上記の関数を登録します。

感想

それにしてもなんだかまわりくどいなあと思いました。今回見つけた記事やそこに多くのコメントがあるように、ショートコードの優先順位を変更したいという需要があるのですから、登録時に自由に優先順位を設定できる関数が WordPress 本体にあってもいいように思います。

参照した記事の最も新しいコメントはつい最近のようですし、サンプルとほぼ同じコードが本体の持っているショートコード embed にも採用されているように、いまでも(いまのところ)、この方法がこの問題の解決策のようです。

1. 丹念に読む気は起きませんが、ショートコードの優先順位を wpautop() より下げた経緯が ticket 6444 あたりにありそうです。↑