そこで、"mojix":http://mojix.org/ 氏作の"MJSplitter":http://zope.org/Members/mojix/MJSplitter/ を導入します。このプロタクトは、形態素解析器"MeCab":http://chasen.aist-nara.ac.jp/~taku/software/mecab/ を用いて日本語を解析し、カタログ化するZCTextIndexのパーサーとして機能します。

"MJSplitter":http://zope.org/Members/mojix/MJSplitter/ を手順に従ってインストールすると、ZCTextIndexのWord SplitterとしてMJSplistterを選択できるようになります。COREblogフォルダのcontentsタブでlexiconオブジェクトを削除して、lexiconという名前でZCTextIndexを追加後、EntryタブでRecatalogすると日本語を含むカタログが生成されます。

自分の環境は以下ような感じです。

- UTF-8

- "Zope2.7.0":http://zope.org/Products/Zope/2.7.0

- "COREblog0.61b":http://coreblog.org/

- "MeCab0.76":http://chasen.aist-nara.ac.jp/~taku/software/mecab/src/

- "ipadic2.5.1":http://chasen.aist-nara.ac.jp/stable/ipadic/

- "MeCab-python-bindings0.76":http://chasen.aist-nara.ac.jp/~taku/software/mecab/bindings/

- "JapaneseCodec1.4.10":http://www.python.jp/pub/JapaneseCodecs/JapaneseCodecs-1.4.10.tar.gz

OperaはmetaタグよりもResponseHeaderを優先するので、Operaユーザーとしては見過ごせません。というかResponseHeaderとmetaタグの記述が一致してないという方が問題ですが。

そこで、Zopeのソースを眺めたり、ZWikiのソースを眺めたり、Zope-MLの過去ログを漁ったり‥‥と色々と調べてみた結果、よく分かりませんでした（笑）。そこでふと思ったのが、「apacheが何かしてるんじゃないか？」という事でした。そういえばサーバー移行のときに *ついでに* FrontEndにapache2を配置したような‥‥。

さっそくapacheのhttpd.confを修正したところ無事問題解決。１時間くらい悩んでしまいました‥‥。

変更部分::

#AddDefaultCharset ISO-8859-1
AddDefaultCharset UTF-8

ZWiki以外はContent-TypeをResponseHeaderに入れるようにしているので、省略時にDefault値をapache2が入れていた事が原因のようです。

# それはそれとして、そろそろZWikiコンテンツの内容更新しないと‥‥

これについてもResponseHeaderのContent-Typeを調べたとき同様パケットキャプチャーしてみたところ、POSTメソッドでコメント追加を行った後で以下のような応答がサーバーからありました::

HTTP/1.1 302 Moved Temporarily
Date: Sat, 24 Apr 2004 06:56:13 GMT
Content-Length: 0
Etag:
Location: http://www.freia.jp/taka/test/zwiki28/X_e5_ae_9f_e9_a8_93_e7_94_a8#bottom
Content-Type: text/plain; charset=UTF-8

また、ZWiki以外の掲示板ではどうなるのかな、と思って、COREblogのコメント追加で実験してみました::

HTTP/1.1 302 Moved Temporarily
Date: Sat, 24 Apr 2004 08:02:07 GMT
Content-Length: 36
Etag:
Content-Type: text/plain; charset=UTF-8
Location: http://www.freia.jp/taka/test/blog/4
X-Pad: avoid browser bug

http://www.freia.jp/taka/test/blog/4

一番の違いは、後者には本文にLocationと同じURIがあることです。もしかしたらこれが原因？と思い、"RFC2616":http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html を読んでみましたが‥‥よく分かりませんでした(^^;; ZWiki改造して本文にもURI書いたら直るかなぁ‥‥

#実はX-Padの方が原因だったりして。

IssueTrackerを使えるようにするためには、以下のようにURLを入力します。

- http://..../FrontPage/setupTracker

しかし、これではカスタマイズ可能にはなりません。カスタマイズするためにはIssueTrackerページをコンテンツとしてコピーしてこなければいけないのです。そのためには、以下のようにします。

- ZWikiのFolderに'allow_dtml'というAttributeをbooleanで追加し、Trueに設定。

- http://..../FrontPage/setupTracker?pages=1

これで、コンテンツにIssueTracker,FilterIssueが追加されます。

原因はUtils.pyでURLを決定する部分が間違っているため。pageUrl()を使うべきところでdefaultPageUrl()を使っているため、現在のページではなく常にFrontPageが使われてしまうのでした。

とりあえず、 ZWiki.orgのIssueTrackerに "レポート":http://zwiki.org/IssueNo0809 を上げておきましたが、この調査をしていて気づいたことが。

Default.pyに入っているデフォルト設定を変更すると色々カスタマイズ出来るんですね。今回はとりあえず SCROLL_CONTENTS=1に変更して、目次表示時に現在のページ部分までジャンプするようにしてみました。（こうするとUtils.pyをいじらなくても問題がない‥‥明らかにバグですね）

Default.py には他にもJavaScriptの許可・ページ名変更時の旧ページ保存の可否等がありました。

Windows版、楽でイイですね。やっぱり最初の1ステップは楽な方が人に勧めるのに 抵抗がなくて良いと思います。

それはさておき、とりあえずデフォルトのトップページを日本語にしてみよう、と 思って:

  "沖縄ITポータル":http://okiit.okihawk.org/

と書いてみたのですが、リンクになってくれません。しかし、 先日の件 もあり、すぐに ZopeのStructuredTextが腐っ てるんだ！と思いつき、さくっと対応できました。

パッチは ここ のを当てて、修正したpyファイルを手動で再コンパイル。再コンパイルの方法は、 pythonのMLで教えてもらった方法で手軽に(?)行いました:

  > cd (ploneインストールフォルダ)\Zope\lib\python\StructuredText
  > (ploneインストールフォルダ)\python\python.exe
  --python起動--
  >>> import DocumentClass
  >>> import STletters
  >>> (Ctrl-Zで終了)

ところで、このコンパイル方法って本当に手軽なのでしょうか？pycが無い場合は自 動的にコンパイルして生成してくれる方法がありそうな気がします。