Sep 1, 2004

Movable Type 3.1 and a temporary Japanized patch

予定通りMovable Type 3.1Plugin packがリリースされました。ベータテストに参加していて間に合わないような感触だったので遅れるのではないかと思っていました。

Six Apart Professional Networkというのも立ち上がっており、登録するとNetwork Member License(確か5ユーザー利用可能な商用ライセンス?)が手に入ります。ちなみに手続きは無闇に面倒ですので気力があるときにトライしましょう。ついでにProfessional Networkのメーリングリストに入ると、Movable Typeでどうやって金儲けするとかいった話(そ、そっちの「プロ」のネットワークだったのか?)が聞けます。

ところで、とりあえず(概ね3.01D日本語版と同等の機能を追加する)日本語化パッチをでっち上げました。手元で「テンプレートごとに管理可能なダイナミックPHPページ生成」の動作環境が用意できていないの十分テストできていないのですが、見切り発車で公開してしまいます。駄目だったら駄目で修正すればいいやという方針です…。

MT-3.11-en_us-jpatch02.zip (36,279bytes)
jpatch01に加え、MTCommentFieldsへの比較的大きな変更を行ったパッチ

MT-3.11-en_us-jpatch01.zip (34,029bytes)
MT3.11英語版に日本語版として動作するように変更を行ったパッチ

MT-3.1-en_us-jpatch01.zip (34,049bytes)
MT3.1英語版に日本語版として動作するように変更を行ったパッチ

Release Notes
2004.09.08: MTCommentFieldsのはくコードを見ていたら腹が立ってきたので修正してパッチファイルを更新しました。
2004.09.04: 3.11がリリースされたので対応しました。3.12がすぐ出そうな悪寒。
2004.09.02: 最初のリリース。概ね3.01D日本語版と同等の機能を実現しています。つまり、MT3英語版の文字化け等の不具合の解消、ユーザインタフェースのより完全な日本語化などがパッチパッケージの主な機能です。

前準備

前準備として、英語版で不足しているいくつかのファイルを日本語版からコピーしてやる必要があります。

まず、Movable Type 3.01D日本語版と3.11英語版を用意し、それぞれアーカイブを展開します。以下ではそれぞれのディレクトリを<MT3J_DIR>、<MT31E_DIR>と呼ぶことにします。

  • <MT3J_DIR>/extlibを<MT31E_DIR>/extlibにコピーします。上書きが面倒な場合はあらかじめ<MT31E_DIR>/extlibを削除しておくとよいでしょう。
  • <MT3J_DIR>/lib/MT/I18N.pmを<MT31E_DIR>/lib/MTにコピーします。
  • <MT3J_DIR>/lib/MT/L10N/ja.pmを<MT31E_DIR>/lib/MT/L10Nにコピーします。

こうやって作った<MT31E_DIR>を用意しておいてください。また、適当な名前でアーカイブにしておくことをお勧めします。

パッチの適用

UNIX汎用パッチ
<MT31E_DIR>ディレクトリに、上記のZipファイルに含まれているMT-3.11-en_us-jpatch02.diffをコピーして、以下の要領でパッチを当ててください。
patch -p1 < MT-3.11-en_us-jpatch02.diff
Windows用パッチ
<MT31E_DIR>ディレクトリに、上記のZipファイルに含まれているMT-3.11-en_us-jpatch02.EXEをコピーし、ダブルクリックして実行してください。

あとは通常通りWebサーバーにファイルをアップロードして設定するだけです。

MTCommentFieldsに関する補足

jpatch02は、あるべきMTCommentFieldsの参照実装を与えることを意図した修正を含んでいますので、オリジナルのMTCommentFieldsとは非互換性があります。非互換性を避けたい場合にはjpatch01をご利用ください。

具体的にはオリジナルには以下のような問題があります。

  • Templateですでに含まれているため不要であるにも関わらず、getCookie用のJavascriptを生成する。
  • しかも、getCookieは生成するが、rememberMe、forgetMeは生成しない。
  • Author, E-mail, URLなどのフィールドを必ずクッキーから読み込むJavascriptが生成される。例えば、URL欄をblankにしたいと思ってもクッキーから自動的にフィルされてしまう。
  • コードが汚い。

そこでjpatch02では一部整理しました。

  • 不要なJavascriptは生成しない。生成するならdefault-templates.plの変更と併せて。
  • preview="1" (Comment Preview, Comment Error)のときは、クッキーからフィルするのはYes/Noラジオボタンのみとする。preview="0" (Comment Listing)のときは、すべてのフィールドをクッキーからフィルする。
  • コードを少々クリーンアップ。

配布の条件など

まず、このパッチパッケージはSixApart Japan社製「Movable Type 3.01D日本語版」の派生的作品です。私はこのパッチパッケージの大部分に関して知的所有権を有しませんし、それ以外の部分に関してもSixApart Japanにdonateします。したがってパッチパッケージの配布の条件もSixApart Japanの意思に従うものであり、以下に記載する配布条件は変更されるべきときには変更されます。

このパッチパッケージは自己責任で使用してください。このエントリの引用・リンクなどはもちろん自由に行っていただいて構いませんが、このエントリに含まれるパッチパッケージを再配布すること、またこのエントリに含まれることを明記せずにパッチパッケージに直接リンクすることはお控えください。その必要がある場合にはコメント欄などでご連絡ください。

リリースにあたってのコメント

このパッチを含めて従来の日本語版の日本語化方法はダメダメだなー、と私は随分以前から思っています。簡単に言うと、現状の日本語版は、PublishCharsetで設定したcharsetでユーザーインタフェースの入出力表現と内部表現が統一されてしまいます。単にPublishCharsetと言辞矛盾があるというだけではなく、考えてみれば実害もあります。実際、特定のcharsetでだけ生じる問題にad hocに対処する必要が生じましたし、冗長なコード変換操作も多いはずです。また、日本語以外のcharsetへの対応は誰か真面目に考えたでしょうか。

より良い、より広範な言語に対応できる実装とは次のようなものです。何らかの内部表現を一つ決めます。日本人にとってはEUC-JPやShift_JISでもいいですが、中文化・ハングル化を含めたI18N化を考えるなら内部表現はUTF-8にしておくのは決して悪くない選択です。ユーザインタフェースや(Rebuildを含む)ビューを生成する際には内部表現からPublishCharsetへの変換を行い、逆に入力は必ずPublishCharsetから内部表現に変換してDBに保持します。TrackbackやXMLRPCの入出力インタフェースは、特例としてPublishCharsetに従うのではなく内部表現(=UTF-8)で行えばよいわけです。

問題はUTF-8と各charset間の相互変換を実現し、かつPerl 5.004でも動作する(Pure)Perl Moduleがないということですね。Encode.pm + Perl 5.8がある今となっては誰も実装したいとは思わないでしょうし…。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com