調べてみると、WordPress 3.3 からこの制限は wp-includes/functions.php の wp_allowed_protocols() に書かれています。そこを見てみると、スキーム名を追加するには kses_allowed_protocols というフックを使えばよさそうです。

いま xmpp: というスキームのリンクを記述したいので、テーマの functions.php あたりに

と書きました。これで記事中にxmpp:mako@pasero.net や xmpp:なんでも談話室@muc.step.im?join などのリンクを記述できるようになりました。

手軽に参照しにくいので、ここに要点のみをメモ。

次の場合の「か」はひらがな書きとする。カタカナは使わない。

例:「3 か月」 (「3 ケ月」「3 ヶ月」「3 カ月」「3 ヵ月」としない)

次の場合の「こ」は漢字とする。カタカナは使わない。

例:「5個」 (「5 ケ」「5 コ」としない)

長音符号

まず規準は、平成3年6月28日 内閣告示第2号「外来語の表記」

英語の末尾が -er, -or, -ar のとき、長音符号を付ける

英語の末尾が上記以外(すなわち、-y も)の場合、

カタカナが4字より短い場合(促音「ッ」は1と数える。拗音は数えない)、長音符号を付ける

• 例:「キー」「メニュー」は付ける。「メモリ」「プロシージャ」は付けない
• 英語が接頭語+語幹の場合、語幹で考える。例:「プレ+ビュー」「サブ+ツリー」「インター+フェイス」
• 上記の例外は一覧表を参照

身の周りにある本らしい本を見てみれば、見出はともかく、本文はたいてい明朝 (serif) 系ではないか、という信念で、この自分のページは明朝 (serif) 系で表示するようにしていたのだが、こんな表示では逆効果なのであった。Windows の設定をいろいろいじればもう少し何とかなるのかもしれないが、普段からしっかり使いこなしている訳でもないから、簡単にできることではなさそうだ。きっと大多数のユーザーもそんなものだろう。

さて、ではなるべく多くの人にきれいに見せるにはページの制作側では CSS での font-family をどう設定したものか、と考え始めた。いろいろ探しまわって考えているうちに、もうそういうのはやめて見る側にまかせてしまえばいいや、という気になってきた。

Vista以降の人は見慣れたメイリオで。
XP以前の人は見慣れたMSPゴシックで。
メイリオが気に入った人は、メイリオで。
Macの人はヒラギノ角ゴで。
明朝が好きな人は、明朝で。
へた字とか好きでたまらない特殊なフォントで。

(流儀　font-familyは指定すべきか)

WordPress 関連のページを見る機会が多くデザインを重視する記事をたくさん見ていたのですっかり忘れていたけれど、そもそも HTML というのは、見る側の環境によって違って当たり前なのだった。

「本文は明朝系」という信念の人(私だ)はブラウザのデフォルトを serif に設定しているだろうし、Windows でも自分の好みの表示になるようにがっちり設定している人には、そのフォントで読めるようにしてあげればいいではないか。

という訳で、このページの本文の font-family の指定はやめることにした¹⁾。フォントに限らず横幅も何も、本来は見る側の自由なのだという気にだんだんなってきた。

1. このページは coraline というテーマの子テーマで表示している。親テーマで font-family が指定されているので、子テーマでこれを消去はできず、そこで存在しないであろうフォント名を指定して上書きしている。

   body, input, textarea {
           font-family: undefined;
   }
   

   ↩

日本語入力システム自分史

UNIX 期

Wnn を使い始めたのは学生だった 1991年頃だ。その前には NEC の PC98 で少しのあいだ ATOK を使っていた。確か「一太郎 Ver.3」だったから、いま調べてみると ATOK6 か ATOK7 だったことになる。

そこに Sun SPARCstation 2 というワークステーションが研究室にやってきて、X Window system で日本語を入力するのに Wnn を使い始めた。確か X11R4 や R5 だったので、これもいま調べてみると、それらに標準添付されていた Wnn 4.1 や Wnn 4.2 を使っていたことになる。その頃にあった別の日本語入力システムの Canna や Sj3 は使ったというより試してみた程度だった。

その後使った HP のワークステーションの HP-UX に VJE だか ATOK だかが付属していたと思うが、このワークステーションはほとんどリモートで使っていたので、日本語入力システムに触れることは滅多になかった (もう当時のバージョンがいくつだかも忘れてしまった)。

Wnn 4.2 の頃はいろいろと情報が出回っていて、辞書を追加したりパラメータを調整することで、標準の状態よりかなり変換精度を上げることができた。

世間で Windows 3.1 や Windows 95 が大流行している頃、私は Sun SPARCclassic を独占してデスクトップで使えるという環境にあったため、その時期を Windows と無縁で過ごした。その後ノート型を含め、いわゆる PC/AT 互換機も使うようになった頃には既に Linux が入手できたため、そこでも Windows を使わずにすんだ。そんな職場を離れたあとも今日に至るまで、トータルで 20 年以上もコンピュータを毎日使っていながら Windows も Mac も常用したことがないという、たぶんかなり珍しい部類の人となった。

Linux-Wnn 期

1997 年、Wnn 6 for Linux/BSD が発売されるとすぐに購入した。UNIX 版はその前に出ていたが普通に買える価格ではなかったし、その頃には Sun SPARCclassic は既にサーバーとして裏にまわり、Debian をインストールした PC をデスクトップで使っていた。

Wnn 6 は、それまでのバージョンがフリーソフトだったのに対し、商用ソフトであった。「Ｗｎｎについての基礎知識」のページの中ほど、「＊Wnn6 で強化された機能とは」の項にあるように、20万語のシステム辞書、「フレキシブル・インテリジェンス(Flexible Intelligence)機能」により、変換精度は格段によくなった。

2001年、Wnn 7 for Linux/BSD が発売になり、これもすぐに購入した。

ATOK 期

2005年に Wnn 8 が発売になった際には、Wnn 7 で十分満足していたので購入を見送った。UTF-8 への対応というのが大きな変化だったが、その頃はまだ EUC-JP で使い続けていたので、その必要性も感じなかったのだ。その後 2009年に、別の会社から、その時点の ubuntu に対応したという Wnn8 for ubuntu というものが発売されたが、ほぼ1年で販売を止めてしまったようだ。

これらを購入しなかったことを後悔する時がやってきた。2010年頃には、(1) OS のライブラリが新しくなり、依存関係を改変しないとインストールもできなくなってきた。いつか本当に起動しなくなるかもしれない。(2) 最近は UTF-8 でしか動かないアプリケーションがいくつか出てきたが、Wnn 7 (xwnmo) は locale を EUC-JP にしなければならないため、日本語を入力できない。(3) 開発元の情報を見ても、この先、新しいバージョンが出る気配がない。という状況になってしまった。

OSS の Anthy を試してみたものの、あまりの使い勝手の悪さに 1週間ほどで嫌になってしまった。

そこで思い切って ATOK X3 を購入することにした。ATOK X3 は 2007年の製品で、既に時代遅れぎみだが、こちらも次がいつ出るのか(そもそも次はあるのか)見えないので、思い切ることにした。

ATOK X3 が悪いとは言わないが、何しろこちらが Wnn に慣れきっているため、不満に思ってしまう点はいくつかあった。

変換精度が思ったほど高くないと感じるのは、長いあいだ学習させてきた Wnn7 と比較しているからだろうか。それを割り引いても 2001年の製品である Wnn7 のほうが「賢い」ように感じられた。

それに、異体字(いわゆる旧字)を簡単に出せない。Windows 用の新しい ATOK には異体字変換があるようだが、Linux 版 の ATOK X3 にはその機能がない。Wnn7 には標準で「異形字変換辞書」を持っており、いったん仮名から漢字に変換したあと(たとえば「けいざい」→「経済」)、漢字から異形字(「経」→「經」、「済」→「濟」)に変換する、単漢字変換の一種ともいえる機能があった。とりあえず「正字正假名辭書」を追加してしのぐことにしたが、これは単語レベルの辞書なので、登録されていない単語(人名など)で旧字を出したいときにはやはり苦労する。

発売直後から指摘されている不具合が未だ放置されているなど、開発元のやる気のなさも心配だったのだが、前の記事にも書いたように、たった1年ほどで終わりの時が近づいてきたようだ。

結局、20年ほどの日本語入力システム自分史を振り返ってみると、最近1年の ATOK X3 を除いて、なんと19年が Wnn (そのうち10年ほどが Wnn7) というものであった。

この項さらに続く(たぶん)。

意図してる使い方は次のようなものです。

• 固定ページに位置情報を持たせる。その固定ページにマップが表示される
• それらのインデックスとなるような、上記の各ページにリンクされたマークが表示された全体図が、別の固定ページがある

たとえば、会社案内のサイトで各支店ごとに固定ページを作り、それぞれに案内地図を掲載し、「支店一覧」の全体図が別にもうひとつある、というイメージです。Lightweight Google Maps はほぼ条件を満たしていますが、その便利な機能がこちらの思惑には合いませんでした。

ざっと探してみましたが、「固定ページに位置情報」というものはなかなかありません。そこで、固定ページではなく投稿に、というプラグイン RomeLuv Google Maps for WordPress を見つけたので、それを改変することにしました。

RomeLuv Google Maps for WordPress を改変

改変の内容は、

• 固定ページの作成画面にも「Maps」の入力欄を表示する
• 全体図の出力の際に固定ページも対象にする
• 全体図を出力するショートコード [GLOBALMAP] に、オプションcat を追加する

です。この最後の項目は次のような事情です。

このプラグインのオリジナル版では、全体図を表示させるには、固定ページでショートコード [GLOBALMAP] を用います。特定のカテゴリーに属する投稿だけを全体図に表示するという絞り込みができます。その方法は、カテゴリーの ID をパラメータで付加して、http://www.example.com/map?cat=6 のような形で、全体図のページを呼ぶようにします。

しかし、WordPress 標準のメニュー機能でこのような形式のリンクを作る方法が思い浮かびません。そこで、むしろ複数の全体図のページを用意することにして(たとえば http://www.example.com/map1 と http://www.example.com/map6)、それぞれのページでのショートコードにオプションでカテゴリー ID を付けるようにしました(たとえば [GLOBALMAP cat="1"] と [GLOBALMAP cat="6"])

さて、ここでは固定ページに位置情報を付加して、全体図を作ることを想定しています。すると固定ページにもカテゴリーが設定されていないと、上記の絞り込みができません。テーマの functions.php か何かで

とやって、固定ページにもカテゴリーを設定できるようにしておく必要があります。

twentyeleven で Google マップが壊れる

実際に使用してみると、表示される地図が微妙に壊れていました。タイルの継ぎ目が合わずに道や川がずれているような感じになります。はじめ、自分が使っているブラウザか何かの環境のせいかと思って、いろいろ調べましたがわかりません。ようやく、テーマ twentyeleven にすると壊れて、twentyten にすると正常に表示されることに気がつきました。それから今度は twentyeleven のスタイルシートのどの記述が影響しているのか順に見ていき、ついに img に max-width が付いているとこの現象が起こることがわかりました。これだけで随分と時間を費やしました。

このプラグインの影響下の img のみ max-width を解除するため、

をスタイルシートに書いて、解決しました。

検索してみて、もじら組フォーラムから Bug 652914 という情報にたどり着いた。いまだ解決されていないようだ。背景色を白以外に設定していて、かつ、プリンタに印刷することのある人というのはかなり少数なのだろうか。

自分の userContent.css に

@media print {
        * {background-color: white;}
}

と書いたら、とりあえず背景色は印刷されなくなった。この程度で回避できるくらいなら、すぐにも修正されそうな気もするのだが。

そもそも、それまでずっと使っていた日本語入力システム Wnn7 が、やはりライブラリ (や、日本語文字コード) の問題でうまく動かせなくなり、その代わりにしかたなく ATOK X3 を使い始めたのだった。今度もまた本質的ではないと思われるライブラリの問題で使えなくなるとは非常に残念である。このへんが頻繁にバージョンアップのあるオープンソースと、どうしても対応が緩慢 (この場合、緩慢どころかもう停止してるのだろう) になる商用ソフトの相性の悪いところだ。

選択肢がない

日本語を使う者にとって日本語入力システムは必要不可欠だ。ハードウェアがどうとか OS が何であるかよりもっと人間よりのところにあると言ってもいい。キーボードのHappy Hacking Keyboard のページに、

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

［東京大学 和田英一 名誉教授の談話］

という言葉が掲げられているが、この「キーボード」を「日本語入力システム」に置き換えても何ら違和感はない。

それにもかかわらず、Windows 環境下ですら現在では選択の幅がほとんどない。その原因は Windows にバンドルされている MS-IME の寡占につきると思う。しばらく前の Web ブラウザ Internet Explorer 寡占問題と同じだ。このときヨーロッパは 「WindowsとIEの抱き合わせは競争法違反」と異議声明を出した。日本でも MS-IME に対して異議を申し立てるべきだったのだ。それまで多くの日本語入力システムがあって切磋琢磨していたものが、ほとんど姿を消してしまった。

OS のシェアから考えて、Linux 版のみの商用日本語入力システムが開発されるわけもなく、Windows 市場で稼げなければ Linux 版は存在し得ない(もちろん MS-IME の Linux 版が出るわけもないし)。こうして Wnn も Linux 版の ATOK も消えていきつつあるのが現状だ。

長くなってきたので、この項つづく。

WordPress 日本語版パッケージ

配布されているWordPress 日本語版パッケージに含まれているものは

日本語リソース

本体のメッセージを日本語に置き換えて表示するためのもの

WordPress 本体

日本語リソースでカバーできない変更のため、いくつかのファイルを差し替えている

のほかに、オマケとして

テーマ Twenty Eleven

日本語版ではこのテーマのメッセージを日本語に置き換える日本語リソースを同梱している

テーマ Twenty Ten

日本語版ではこのテーマのメッセージを日本語に置き換える日本語リソースを同梱している

プラグイン Hello Dolly

日本語版では、「プラグイン」の一覧で表示される説明文を翻訳している

プラグイン Akismet

日本語版では、「プラグイン」の一覧で表示される説明文を翻訳している

プラグイン WP Multibyte Patch

マルチバイト文字の取り扱いに関する不具合の累積的修正と強化を行うもので、日本語版で独自に同梱しているもの

です。

はじめてのインストールは問題ない

これまで WordPress を使用していなかったところに、はじめて導入する場合は、何も考えることはありません。最新版をダウンロードしてインストールしてください。

自動更新

WordPress 日本語版の新しいバージョンがリリースされると、WordPress の管理画面(ダッシュボード)で、その旨の通知があります。案内に従って手順をすすめれば、新しいバージョンに更新されます。従来(3.2まで)は、この手順でパッケージに含まれるすべて、つまり上述の本体とオマケのすべてがパッケージ内のものに更新されていました。

オマケは更新されなくなった

3.2.1 以降、自動更新では、本体のみが更新され、オマケの部分は自動更新されないことになりました。たとえばテーマ Twenty Eleven のバージョンは、WordPress 3.2 日本語版では 1.1 で、WordPress 3.2.1 日本語版では 1.2 です。もし 3.2 日本語版で運用しているところで、本体の自動更新を行っても Twenty Eleven は 1.1 のままです。

もし、これらのオマケをまったく利用していなければ、以下の話は読み飛ばしてもかまいません。

テーマやプラグインは別途に

オマケのテーマやプラグインに、もし新しいバージョンがリリースされた場合、本体の更新とは別に、個別に「更新」の通知があります。後から独自に導入したテーマやプラグインとまったく同等の扱いになるということです。

オマケのテーマやプラグインであっても、本体のリリースとは無関係に新しいバージョンがリリースされることがあります。

日本語リソースはさらに別途に

テーマやプラグインは、本体とまったく別途に更新できます。しかし、ここで注意することがあります。従来のように本体のオマケとして配布されていたときには、それらの日本語リソースや説明文を翻訳していたものを配布できていました。しかし今後、個別に更新される際には、それらの含まれないオリジナル(英語版)になってしまうのです。

テーマ Twenty Eleven を例にとります。「更新」の通知があったら、まずこの Twenty Eleven を更新します。その状態では日本語リソースは存在しません (1.1 のときに存在していても 1.2 に更新したら消えてしまいます)。そこで、日本語リソースを別途入手して、適切に配置します。現時点での最新の日本語リソースは http://i18n.svn.wordpress.org/ja/branches/3.2/messages/twentyeleven/ja.mo です (この記事をずっと後にご覧になる方はバージョンやテーマ名にご注意ください)。これをダウンロードして、wp-content/themes/twentyeleven/languages/ の下に置き、サーバーが読める状態にしておきます。

同様に、テーマ Twenty Ten の日本語リソースはhttp://i18n.svn.wordpress.org/ja/branches/3.2/messages/twentyten/ja.mo にあります。

プラグイン Akismet や Hello Dolly をもし更新した場合は、「プラグイン」一覧に表示される説明文が日本語ではなく英語になってしまいますが、動作には何ら影響はありません (この説明文はそれぞれの php の冒頭にコメントの形で書かれているものです)。どうしても気になる場合は、やはり日本語版の配布元 (http://i18n.svn.wordpress.org/ja/branches/3.2/dist/wp-content/plugins/ あたりにあります) から、その部分を差し替えたものを入手して、適切に配置してください

WP Multibyte Patch

WP Multibyte Patch は新しいバージョン 1.5 で、この自動更新の振る舞いの変更に対応されました。

WP Multibyte Patch 1.5 をリリースしました。
今回は重要な変更があります。設定ファイル (wpmp-config.php) の設置場所が /wp-content の下に変わりました。設定ファイルをサイトでご利用中の方は、以下配置で再設定を行ってください。

/wp-content/wpmp-config.php

この作業は設定ファイルをご利用中のサイトにおいて 1.5 より古いバージョンから 1.5 以降のバージョンにはじめてアップデートした場合に1度だけ必要となります。設定ファイルをご利用でない場合は作業の必要はありません。

ということですから、注意してください。

Jabber/XMPP については、しばらく前に記事にしました。Jabber/XMPP をはじめるには、アカウント (JID) が必要です (ちょうどメールを使う際にメールアドレスが必要なように)。もし GMail のアカウントや WordPress.com のアカウントをお持ちであれば、それらを JID として使うことができます。これらのアカウントを持っていない、または使いたくない場合はこの STEP.im でアカウントを作ることができます。

また、グループチャット（Multi-user chat, MUC) の談話室をこの STEP.im に開設することができます (STEP.im のアカウントを持っていなくても開設・参加できます)。IRC によく似ていますが、後発なだけに、IRC の欠点を補って使い勝手のいいものです。

数年前から、自分のごく近傍で Jabber/XMPP を利用してきました。なかなか優れていると思うのですが、あまり話題になることがありません (Google トークや Facebook チャットなど、ユーザーに意識させないところで浸透しているようですが)。クライアント Gajimの日本語訳、サーバー ejabberd の日本語訳のお手伝いなども行ってきました。そしてとうとう公開サーバーを運用することにしたのです。

どうぞよろしくお願いいたします。

その記事にあるように、私にとってそもそもなぜこの設定をしたいのかというと、うっかりミスの防止です。ログイン後のメインメニューで、「ログアウト」と隣り合って「シャットダウン」の項目があり、単にログアウトするつもりがシャットダウンしてしまうことがあるのです。

最近の流儀では policykit で設定で行うようです。その方法はdebian-user メーリングリストにあるとおりです。要点を簡単に記すと、

• /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy を書き換えるという回答もあるが、このファイルはそもそも設定ファイルではないし、バージョンアップによって書き換えられる(元に戻ってしまう)ので、よろしくない。
• /etc/polkit-1/localauthority/50-local.d/ に適当な名前(ただし末尾を .pkla にする)のファイルを作り、その中に次のように書く。

  [consolekit]
  Identity=unix-user:*
  Action=org.freedesktop.consolekit.system.*
  ResultAny=no
  ResultInactive=no
  ResultActive=no
  [upower]
  Identity=unix-user:*
  Action=org.freedesktop.upower.*
  ResultAny=no
  ResultInactive=no
  ResultActive=no