■ [tDiary] tDiary-FAQ

昨日のプラグインを書くときのTipsはtDiary-FAQに全部登録してみた。ついでにいくつかTipsを追加して置いたので、プラグインを書く人は参考にしてください、つーか、添削してちょ。どうも、最近のオレはプログラムもドキュメントも仕事も私生活もバグが多いらしいんで(T_T)。

■ [Misc] Linuxビボ〜ろく

なんか、連休に入って異様にカウンタのアクセス数があがってる気がするんだが、これはアクセスカウンタ表示プラグインのバグか....？ 手元のブラウザとかtelnetでHEADアクセスとかで確認してもうまくいってるような気がするのだが....不安だ(^^;)。

■ というわけで、XREAが提供するカウンタがちょうど似たような仕様だったので入れてみた。明日から確認できるだろう。一応、XREA版の方がちょっとだけ多くカウントされる....はず。

■ [tDiary] アンカー自動生成プラグイン

なんか古いファイルをアップしてしまったみたいなので再度アップし直し。すまそ。

■ [Hiki] rd+ style

あれからイロイロといじりまして、入力間違い等のエラーに細かく対応しました。例えば、プラグインエラーが発生したときにどのプラグインでエラーが起こったのか簡単にわかるようになりました（さらに、hikiconf.rbに$plugin_debug = trueと書くとプラグイン自体のスタックトレースも出力されるようになりました）。

CVSの最新版で試せますので、興味のある方はどうぞ。

■ [Hiki][tDiary]多国籍化part2

shiroさんのコメントを読んでgettext的なアプローチを考えてみた。Ruby-GetText-Packageをそのまま使うこともできるけど、今のRuby-GetText-PackageはCGIに適用するにはオーバースペックな気がするのであくまでも、gettext的なアプローチを自前で用意することを考えた（って、Ruby-GetText-Packageのメンテナの発言としてはちとイカンな(^^;)）。

いろいろ、試行錯誤したのだが、長くなったので現時点で自分が到達した案のみ。

■ まず、Pluginクラスに以下のメソッドを追加する。

class Plugin
  def initialize
    :
    :
    @mo = plugin/#{lang}/*.resourceを読み込みHash化(ここでは後述のja/show_referer.resource)。
  end
  
  def _(msgid)
    @mo[msgid] ? @mo[msgid] : msgid
  end
end

■ 次に、例として昨日のshow_refererで考える。

show_referer自体は以下のような感じ。英語（らしき何か）はわざと前回例より長文にしてる。

  def show_referer(db)
    s = %Q[<div class="referer">#{_ "The referers for this page."}<ul>]
 
    referers(db).each do |ref|
      disp = replace_url(ref[0].unescape).escapeHTML
       s << %!<li>#{ref[1]} <a href="#{ref[0]}">#{disp}</a>!
    end
 
    s << '</ul></div>'
  end

■ この案のポイントとしては、_()というメソッドを用意するところだ（別にメソッド名はgettext()でも良いけど）。

これで、shiroさんの指摘されている「メッセージ文字列とその使う場所が離れないで済む」ということをクリアしている。

■ それから、plugin/ja/show_referer.resourceは以下のような感じ。形式は別形式（CVS等）でも良いし、文字列のエスケープの仕方とかは別途考えないといけないかな。

上記例ではキーとして英語を使っている。デフォルトは英語という考え方だ。したがって日本語のリソースファイルは必須となる。

  "The referers for this page." = "このページへのリンク元"

■ ここでは、"The referers for this page."という英語をキー項目としている。これをあえて日本語ではなく英語にしたのは、日本語をキー項目に使ってしまうと日本語を読めない人（や日本語を表示できないエディタを使っている人）にはリソースファイルを作ることすらままならないからだ。

そうすると、逆に日本人が主体のプロジェクトできたさんも心配しているように英語を使うことに抵抗感のある人が多いプロジェクトだと、プラグイン作成自体が敬遠されそうになってしまいそうな気がする。

■ というわけで、オレ的には昨日の案の方が（日本人から見ると）やりやすいかなという気がする。対応する必要のある文字列っていったってたかが知れてるしね。

ただ、今後、もし、Hikiが将来本当に多国籍で使われるようになって、英語やそれ以外の言語の人がプラグインを作ったときに、ソースファイルに入れる言語を何語にするかということを悩んでしまうのを避けたいのであれば、最初から英語にしてしまうというのは手ではある。I18N的に考えてもgettext的なアプローチな方がきれいだろう。

■ 蛇足だけど、上記案では、プラグイン単位で文字列（キー項目）を指定することはできない。一つの文字列に複数の意味を持たせる必要を感じなかったのでそのようにしたが、プラグイン単位で厳密に指定しようと思うと結構実装が面倒くさそう。

それから、上記の書き方だとshiroさんの指摘されている２つ目「本体に変更があった時に翻訳を変えるべき場所が自動抽出できること」はクリアできていない。ここまでやるなら、まじめにRuby-GetText-PackageとGNU GetText付属のツール(msgmerge等)を組み合わせて使った方が良いだろうな（と密かに宣伝）。

■ [Misc] WiLiKi

shiroさんのWiLikiはSchemeベースのWiki。もともと、多国語への対応を設計目標としてデザインしてある。っていうか、設計目標がきちんと最初に定義してあること自体がゴイスー。