たまたまフォーラムのトピックで見かけて、WordPress のバージョン 2.8 よりヘッダにサイトナビゲーションが出力されることを知りました。
出力されるソースを見てみると、記事の single の表示のときはいいのですが、single ではないときには next や prev は付かないようです。
以前、簡単に作ったプラグインがあったので、2.8 本体の出力と重複する部分は出力しないように変更して、使い続けることにしました。
たまたまフォーラムのトピックで見かけて、WordPress のバージョン 2.8 よりヘッダにサイトナビゲーションが出力されることを知りました。
出力されるソースを見てみると、記事の single の表示のときはいいのですが、single ではないときには next や prev は付かないようです。
以前、簡単に作ったプラグインがあったので、2.8 本体の出力と重複する部分は出力しないように変更して、使い続けることにしました。
「WordPress ja “非公式” IRC チャンネル」について、先日書きました。
それ以来、PC の前にいるときは接続しているようにしているのですが、ほとんど誰もいませんね。時間帯が合わないのでしょうか。
随分前の「WordPress交流会」のときには Chatzilla を使いました。その頃 Pidgin はまだ Gaim という名前でしたが、日本語を使おうとするといろいろ問題があったのです。今は普通に使う分には問題ありません。
Pidginは多くのプロトコルに対応していて、普段から Jabber/XMPP のクライアントとして使っていたので、そこに IRC のアカウントを追加したのでした。
数日前から Firefox (Debian では Iceweasel) のサイドバーに
asahi.comのネットスケープ用サイドバーは、2009年6月5日で終了します。RSS、ツールバーなどをご利用ください。
と表示されるようになりました。
サイドバーは確か Netscape 6 からだったでしょうか。その後 Firefox には引き継がれず、衰退してしまいました。私は拡張機能のイージーSidebarを利用しています。asahi.com のサービスがなくなれば、購読しているまともなサイドバー対応のサービスはスラッシュドットジャパンくらいです。
しかしサイドバーは、携帯サイトを表示させればちょうどいいサイズです。便利に使っているのは河川情報の「レーダー雨量」の履歴動画です。
1年ほど前にマイクロソフト社の方針変更で話題になったものですが、今ごろになって書いてみます。
検索してみると、これについて論じているページはたくさん出てきます。
そもそもカタカナ表記はどうしても元の発音を表現できないので長音をつけてもつけなくても五十歩百歩(例えば、「カタカナ語の長音表記」について)という主張は、そのとおりだと思います。
例えば「コンピュータ」と「コンピューター」を(これが英語の computer のことだという知識があると難しいのですが、その発音を思い起こしてしまわないように注意しながら、単純に日本語のカタカナだと思って)発音して比べてみると、後者のほうが「タ」のアクセントが強くなります。たぶん私だけでなく一般的にそうだと言ってもいいと思います。英語ではありませんが、「イタリア語では長音を区別しないが、単語を単体で発音するとアクセント位置が長くなる(単子音の場合は顕著)ので」長音を使うとしている場合もあります。つまり逆に考えると、カタカナに長音があるとそこにアクセントが置かれやすいことの現れです。
私は素人なのでこれ以上詳しく述べることはできませんが、検索しても英語のカタカナ表記の長音とアクセントについて言及しているものがあまり多くは見つからないのは意外でした。
私自身は、五十歩百歩とはいえ少しでも隔たりの小さいほうがまし、という考えで、不要なアクセントを作ってしまう語末の長音には賛成しません。
今ごろ「WordPress ja “非公式” IRC チャンネル」の記事に気がつきました。この記事は4月2日となっていますから、1ヵ月以上前です。
なんで “非公式”なんでしょう? まあ誰でも勝手にチャンネルは作れるから公式も非公式もないという気もします。
昨日今日とパソコンの前にいる間は入ってみていたのですが、閑散としていました。やはり平日の昼間は誰もいないのかなあ。
日本語入力システムにWnn7を使うために環境変数 LANG を ja_JP.eucJP にしなければならないのだが、いくつか問題が出てきた。
そのうちのひとつ、emacs で subversion のコミットをする際のログを日本語で書こうとするとエラーを起こす。しばらく放っておいたのだが、やはりログは日本語で書いたほうがささっと書ける1)。
.emacs に
を加えて解決した。
このページの設置場所を変更した。
URLは、元はレンタルサーバ会社の所有のドメイン名を使ったものだったので、移転に伴って変更せざるを得ない。そこで現在のURLと相成った。メールアドレスも(ここには書かないが)変更となった。
WordPressの移転は「WordPressサーバ移転まとめ」を参考に。今回はURLが変更になるので、mysqldump した SQL で、ドメイン名の部分を一括変換して新サーバで読み込ませた。
半月記どころか半年記になりつつあるこのページ、存在意義そのものがあやしくなりつつある。この先どうなることやら。
ハードディスクが飛んでしまい、これを機会に Debian の新しいバージョンをすっかりはじめからインストールした。随分楽になったものだ。さてここでシステムの locale を最近の流行りにしたがって ja_JP.UTF-8 にしたのだが、これが後で問題となった。
sid (unstable) に入れ替えつつ、さらに必要なものを少しづつインストールして、クラッシュ直前の使い勝手に近づいてきたのだが、常用していた debian 外の日本語入力システム Wnn7 はライブラリの依存の問題でインストールすることができなかった1) 。商用ソフトでしかも2001年発表というものなので、しかたないかもしれない。Wnn8 ならインストールできるかもしれないが、これですら2005年発表なので今さら買う気にもなれない。
1ヵ月ほど Anthy を使ってみたものの、20年近くも Wnn を使い続けてきた感覚のためか、どうにもストレスを感じて仕方がない。特に Wnn7 の「異体字変換」機能に相当するものを Anthy に見つけることができなかったところで、とうとう我慢ができなくなった。
というわけで、Wnn7 を2009年1月現在の debian sid にインストールしてみることにした。アップデートセンター から(当時の debian に対応した) deb パッケージが手にはいる。
そのままではインストールはできるが libc6 のバージョンが合わず起動しない。ここでは強引な方法で解決した。上記のアップデートセンターの「ライセンスサーバー」の項を見ると「glibc2.3 対応版」が出ていることがわかる(ただし rpm のみ)。この中から実行ファイルのみ(2つ)を取り出して、これに差し換えた deb を作り直してインストールすることにした。
ネットで検索すると、chroot 環境に古い libc6 (libc6_2.3.2.ds1-22_i386.deb) を飼うという解決法が見つかる。さらに将来を考えるとこのほうがいいのかもしれない。
wnn7-utils, maindic, optiondic は特に問題なくインストールできる。
で開梱し、DEBIAN/control の Depends の行にある古いライブラリを現在のものに書き換える。 libglib1.2 は libglib1.2ldbl に、またxlib6g はなくなってしまったので、個々のライブラリにする。したがって depand の行は
とした。libgtk1.2 は辛うじて現在の debian にも残っているのでよかった。
開梱したものを
のようにして再びパッケージ化して、インストールした。
Depends に Emacs のバージョンが固定的に書かれているので、新しいEmacs でも大丈夫なように、先ほどと同様に、emacsen と書き加える。
また、usr/lib/emacsen-common/packages/*/wnn7-elisp の中の case 文にもバージョンが固定的に書かれているので、ここに新しいバージョンを加える。
ここまでで、dpkeystat で ライセンスサーバが起動していることを確認でき、wnnstat で変換サーバが起動していることを確認できる。そして Emacs をクライアントとして正しく日本語入力と変換ができることを確認できる。
最後に、xwnmo の含まれるこのパッケージも、同様に Depends の行を書き換える。
とした。
はじめに書いたようにシステムの locale を UTF-8 にしたのだが、これが原因で xwnmo が機能しなかった。ユーザーの .bash_profile で、LANG=ja_JP.eucJP と設定することにした。他のアプリケーションでそのうち困ることが出てくるかもしれないが。
そのほかの環境変数は、Wnn7 をインストールするより前に Anthy を入れた関係で im-switch もインストールしていたので、この際その流儀に合わせることにした。/etc/X11/xinit/xinput.d/ の default-xim を xim-wnn7 という名前でコピーして
とした(XIM_ARGSはご自由に)。あとは im-switch -s xim-wnn7 で切り替えておく。
相当長いこと間があいてしまった。
いきなり、出たばかりの(しかもbetaの)WordPress 2.7beta3-jaに入れ替えてみた。今回はまったくお手伝いできなかった。
特に問題はなさそう。しかし管理画面のデザインは以前のバージョンから変わりすぎ。複数の著者で使っている某所をこれに入れ替えたら、ついてこれない人が出そうだ。
バックエンドに PostgreSQL を使っているのは、自前のデータベースのほかに Trac と MediaWiki だ。バージョン 8.3 が出てから1ヵ月以上経つし、MediaWiki の 1.12.0rc1 で PostgreSQL 8.3 対応の文字が見えてきたのでそろそろ大丈夫だろうとバージョンアップしてみた。
debian の場合 pg_upgradecluster で簡単にデータの移行ができる……はずだったのだが一筋縄ではいかなかったのだった。きっと数ヵ月後には根本的に解決されていて役に立たない情報になるだろうが、記録しておく。
PostgreSQL の contrib に含まれている isn.sql1)を利用している。この isn.sql も 8.2 と 8.3 で若干違っているようで、pg_dump したものを読み込ませてもうまくいかなかった。
しかたがないので、pg_dump したものを isn.sql 関連の定義前の部分、isn.sql による部分、その後の部分の3つに分け、前の部分を読み込ませた後、contrib の isn.sql を読み込ませ、それから後の部分を読み込ませることで、ようやくデータの移行ができた。
自前で書いていたフロントエンドは特に問題なしと思ったら、
互換性のない変更点
- 文字でない型 (日付型など) を自動的に text 型に変換しないようにしました。
- 今までは text 型入力を受けとる演算子や関数に文字でない値が渡されると、自動的に text 型にキャストしていました。 これからは text 型でないデータを渡したい場合には text 型への明示的なキャストが必要になります。
に引っかかるところが数ヵ所見つかった。演算子 ~ はテキスト型にしか使えないとのこと。暗黙のルールは使わないようにしているつもりでもうっかり使っているのものだなと思った。
データの移行はすんなりとできた。が、使ってみるとエラーが出る。上と同様、キャストに関わる問題のようだ。検索して、6416と6512の変更を加えて、うまく動くようになった。
MediaWiki で使っている tsearch2 は PostgreSQL 8.2 では contrib だったのが 8.3 では本体に組み込まれた。と言っても関数名等の互換性を取るために 8.3 でも contrib の tsearch2.sql を読み込ませる必要がある。上述したのと同じように dump を分割してデータを移行した。
これで大丈夫と思ったら、記事を書き換えようとした際にエラーが出た。ts2_page_text() で tsvectorの引数の 'default' は存在しないというもの(すみません、メッセージを正確に記録していませんでした)。
maintenance/postgres/tables.sql の 当該関数の定義箇所を見てみると
とのコメントがある。1.12.0rc1 ではまだ対応されていないのだった。新しい版を見るとコメントがつけ加えられていて、patch-tsearch2funcs.sqlの存在を教えてくれた。これを適用して、問題なく動くようになった。