デフォルトの設定で使うだけであれば、プラグインを有効にすれば各エントリーに作成者のプロフィールが表示されます。作成者の画像については、Gravatarが使われますので、Gravatar の使い方などの説明を読んで設定しておくと良いと思います。設定は「プラグイン」から「WP About Author」を選べばどのような場所に出すのかなどの設定を行うことができます。設定項目は大きく別けて「どのような条件で表示するのか」と「どのような形で表示するのか」の2つがあります。日本語での情報が見つからなかったので、以下に簡単に書いておきます。

どのような条件で表示するのか

どのような条件で表示するのかは「Display Settings」で設定します。以下の設定項目があります。

• Display On Front Page / フロントページに表示
• Display In Archives / アーカイブに表示
• Display In Search Results/ 検索結果に表示
• Display On Individual Posts / 個別の投稿に表示
• Display On Individual Pages / 個別の固定ページに表示

なんか特に説明が不要な気がします。個人のウェブサイトであれば「Display On Individual Posts / 個別の投稿に表示」だけを有効にするだけでいいような気はしますね。「Display In Search Results/ 検索結果に表示」は私が検証したときはちゃんと動いていなかった気もしますが、デフォルトのテーマなどでは試していないのでよくわかりません。個人的にはいらないので暇だったら調査するぐらいかなー。

どのような形で表示するのか

どのような形で表示するのかは「Box Settings」で設定します。簡単な設定しかできません。「Box Background Color / ボックスの背景色」ではプロフィールを表示する領域の背景色を設定します。テーマにあわせた適当な色を指定すると良いでしょう。「Box Border / ボックスの縁取り」はプロフィールを表示する領域の縁取りを設定します。「Thick Top Border / 上部に太めの縁取り」「Thin Surrounding Border / 細めの縁取りで囲む」「No Border / 縁取りなし」の3つだけしか設定がありません。まあ、プラグインとしてはこれぐらいに留めておいた方が煩雑になりすぎないので良いのではないかと思います。多少ならばCSSを書き換えれば良いのかもしれないですね。それ以上自分好みにするならばこのプラグインをベースに手を入れるか、テーマ自体にハードコーディングしてしまうか、でしょうか。

日本語化

設定画面はともかく、表示される部分に「More Posts」などとでてしまうので何とかしたいところです。Gettextizeされていないので、せっかくだからGettextizeしようかと思ったのですが、ちょっと時間を割いただけでは残念ながらできませんでした。設定画面側のコードにはGettextizeしようとする意思も感じられたにも関わらず、2011年6月8日現在の最新版のバージョン1.1では実現できていないので何かはまりどころがあるのかもしれません。時間のあるときにでもみてみようということで、とりあえず日本語化だけしておきました。単に日本語を埋め込んだだけです。必要な方は以下のURLからどうぞ。ライセンスはWP About AuthorがGNU GPL version 2なので同じライセンスになっています。

• http://dl.dropbox.com/u/5110926/tmp/wp-about-author-1.1-ja.zip

本家のものが国際化されるまでの暫定のつもりなので、わざわざどこかに置く場所を確保するのは面倒ということでDropboxに投げ込んだだけです。たぶん本家が国際化されるまではそのままですが、本家が国際化されたら削除してしまうかもしれません。

少し触ってみた経験を基に、レポートを書くときに心がけた方がよさそうなことをメモしておきます。参考になれば幸いです。

• 落ち着いて書く
• なるべく簡単な日本語を使う
• 「レポートタイトル」には括弧書きでもいいからだいたいの位置をいれておく
• カテゴリはできるだけ正確に付与する
• URLの紹介の場合でも、「ニュースソース」だけではなく「説明」にそのURLを入れる
• 「説明」はできれば詳しく

緊急時ではありますが、だからこそできるだけ落ち着いてください。

災害に関する情報は日本人だけではなく、あらゆる国籍の方が必要としています。簡単な日本語を使うことで、日本語に不慣れな人にも有意義な情報となり得ます。例えば、阪神大震災のときも、避難所案内の簡単な日本語ポスターが大変役だったという情報もあります。

救助要請のレポートの場合、レポートタイトルを「助けてください」というようなものにするのではなく「助けてください（宮城県○×市△町）」などの位置情報を入れる方が望ましいです。

外部のウェブサイトのURLをアナウンスするレポートも必要ですが、「ニュースソース」にURLが書けるからといって「説明」にURLを書かないということはやめた方がいいです。「説明」だけでURLも判るようにしてください。また、できるだけ詳しく書いた方が閲覧者にとって有意義となるでしょう。

日本語翻訳の結果自体は既に開発者のfroman118さんに送付済みであり、次のリリースで同梱していただける予定になっていますので、My Link Order 2.9.1よりも後のバージョンではプラグインをインストールするだけで設定画面などが日本語で表示されることになるでしょう。このエントリは（なかなか次のバージョンがリリースされないようなので）次のバージョンがリリースされるまでの継ぎとして書いておきます。

手順は次の通り。

1. My Link Order 2.9.1をダウンロードし、いつも通り「wp-content/plugins」以下に展開する
2. http://dl.dropbox.com/u/5110926/mylinkorder/mylinkorder-ja.moから日本語化用のファイルを取得する
3. 取得したファイルを「wp-content/plugins/my-link-order」に「mylinkorder-ja.mo」という名前で配置する

これだけです。とても簡単ですね。

到着したら「GitとHudsonによるきれいなリポジトリの作り方」が丁度終わるところだった。これも聞きたかったけど仕方ない。参加した人のブログエントリみていると、CIなツールいれて、1回テストしてから通ったものだけを中央のリポジトリにいれる感じかな。これだと中央リポジトリのコードはきれい（なはず）になるというやつか。今、いくつかのプロジェクトでは手元にHudson入れてpush前に一応ビルドが走るようにしているんだけども、それをもっとエレガントにした感じなんだろうなー。スライド公開を待とう。Oかもとさんの「Shibuya.trac 分散バージョン管理勉強会に参加しました。」によれば、BazaarのPQMが使えそうということなので時間あるときに調べてみよう。

Oかもとさんの話あたりで会場アンケートとって、BazaarユーザはLTスピーカーのiwataさんだけだったのかな。最近コミット権もらったプロジェクトがBazaarなので使い始めてたんだけども遅刻したから数に入ってない。まあ、使い始めたばかりだけども。

Mercurialはしばらく手を出す暇なさそうなので……。

歴史改変は、試行錯誤な手元の更新をpush前にやるとよかったりするのだろうか。分散型リポジトリでの運用のデファクトスタンダードがよくわからん。なんか適当な書籍買った方がいいんかなあ。bzr pullできなかったときにbzr mergeやったときのコミットログってどんなのがいいの？とかそういうのとかもよくわからん。分散型リポジトリで共同開発やってみるためだけのプロジェクトを作ってみるかなー。

git bisectは便利そうだとは思った。1回使ってみよう。ただ、使いどころが難しいのではないかなあ、という気がしないでもない。単体テストとかでひっかかるものだとCI入れてたら良いだけという気もしたけども……。まあ、そういうので漏れたもの、そういうのでは検出できないものがあった場合に発生時点の調査には非常に強力なんだろうな。チェックのためのコードが書ける場合は人間が見るんじゃなくて機械に任せるべきだろうしね。

Hudson勉強会は参加したい。

• Vine Linux 5.2/i386
• Apache HTTP Server 2.2.14 (apache2-2.2.14-7vl5)
• MySQL 5.1.41 (MySQL-server-5.1.41-1vl5)
• MantisBT 1.2.3
• mod_auth_mysql 3.0.0

MantisBTをみたところ、mantis_user_tableテーブルにユーザ名とパスワードを保持しており、ユーザ名は「username」フィールド、パスワードは「password」フィールドにMD5ハッシュ値で格納するのがデフォルトのよう。だから、それをmod_auth_mysql側の設定で参照させればいいだけ。例えば次のような設定となる。

AuthMySQLEnable On
AuthMySQLSocket /var/lib/mysql/mysql.sock
AuthMySQLHost localhost
AuthMySQLUser mantis
AuthMySQLPassword mantispw
AuthMySQLDB mantisdb
AuthMySQLUserTable mantis_user_table
AuthMySQLNameField username
AuthMySQLPasswordField password
AuthMySQLPwEncryption md5
AuthMySQLNoPasswd Off

AuthGroupFile /dev/null
AuthName "Auth"
AuthType Basic
require valid-user

設定項目の詳細はhttp://modauthmysql.sourceforge.net/CONFIGUREなどを参照のこと。

とりあえずこれでできることは確認したので、後はmod_auth_mysqlというプロダクト自体の信頼性や安定性などを調査しないとダメかなー。

で、本題。SGMLアプリケーションであるHTML4は、SGML宣言で「OMITTAG YES」とされていたことから、タグの省略が可能となっている。例えばhead要素の終了タグとbody要素の開始タグを省略した次のようなHTML文書は仕様に適合している。

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN"
        "http://www.w3.org/TR/REC-html40/strict.dtd">
<html>
<head>
<title>自明でないと省略できません</title>

<script type="text/javascript">
<!--謎のスクリプト-->
</script>

<p>本文なのですが。</p>
</body>
</html>

で、これがどのような理由で仕様に適合しているのかは結構ややこしい。理由はsatoshiiさんによるRe: SGML の省略タグ機構に詳しい。

ここでHTML5に話を移す。HTML5では、SGMLアプリケーションだったHTML4とは異なり、SGMLアプリケーションではないという道を選んだ。このことにより、HTML5では仕様自体にタグの省略についての取り決めも盛り込むことになった。W3C Working Draft 25 August 2009では9.1.2.4 Optional tagsの箇所である。

HTML5の仕様では、HTML4よりもタグの省略に関しては結構限定されてしまっているとも言えるが、省略可能な状況をすべて列挙しているため、とても解しやすくなっている。

最近、一部で話題となっているhttp://html5.us/のHTML文書は、執筆時点では次のようになっている。

<!DOCTYPE html>
<title>html5.us</title>
<style>pre{font-family:courier,monospace;font-size:48px;margin:5% auto;text-align:center;width:50%;}</style>
<pre><code>&lt;!doctype html&gt;</code></pre>

これは、先に例示したHTML4のコードと結構似ている構造だが、これが仕様に適合しているというのは、仕様を軽く読むだけで容易に理解可能となっている。

このような仕様になった議論は全然調べてないけど、列挙してしまうというのはかなり思い切った方針だと思うし、列挙しているそれぞれの条件についても読んでみると結構考えられているように思う。すごいなあ。

リポジトリの話で言うと、コンテンツは見られるべき場所においてこそコンテンツなんだと思うな。

正直、《リポジトリの話で言うと》という部分とその後の部分との関連はまったく解っていない。だから、コンテンツの見せ方についてのみ、私の考えを書いてみる。

まず、Japanized Perl Resources Project (以下、JPRP)というものがどの範囲を示すのかというのは明確な定義はこれまでもなされていないような気はしている。ただ、sourceforge.jpに作成されたプロジェクトと、それに先行して作成されたPerlドキュメント日本語訳MLぐらいがJPRPなのだろうと私は考えている。

Perlドキュメント日本語訳MLが発足したのは井上さんによる2002年5月17日の[perldocjp:0001] Perlドキュメント日本語訳ML発足である。翻訳物の見せ方については、同日に菅原さんから[perldocjp:0003]で問題提起されている。その後、2002年7月20日に宮川さんが[perldocjp:0214] perldoc.jpにて、http://perldoc.jpの試験稼動がアナウンスされ、今に至るという状況である。このhttp://perldoc.jpがJPRPの一部であるか否かについては、ドメイン取得やサーバの構築、維持管理などを踏まえても、JPRPメンバーでもある宮川さんや、その後、ドメインを委譲された大沢さんら個人の力で運営されているものと考えることが妥当であろう。関係者各位にはどれだけ感謝しても足りないぐらいだと思う。

しかし、このことによりJPRPは、プロジェクトとしてはPerlユーザに対して翻訳物を提供する手段を考えることはなくなったとも言える。もちろん、複数のウェブサイトで、同じものを提供する意味は乏しいのだから当たり前といえば当たり前の結果であろう。

今回、mattnさんからの《コンテンツは見られるべき場所においてこそコンテンツなんだと思うな》というコメントは、金田さんの[perldocjp:1121]の発言を受けて私が[perldocjp:1123]にて『Japanized Perl Resources Projectとしては構わないんじゃないでしょうか。perldoc.jpの人が構うかどうかは知らないけれども。でも、それは我々Japanized Perl Resources Projectが気にするところではない。』と発言したことへのコメントであると推察する。もちろん、http://perldoc.jpから参照されなくなった状態で、CVSリポジトリに格納していくだけの作業をやってもあまり意味はないということは理解できる。しかし、金田さんによる[perldocjp:1121]では《んじゃ特に問題ないですね。perldoc.jpが置き換わった時にはCVSリポジトリの内容とperldoc.jpの内容が食い違ってくると思いますがそれは構いませんか？》と問われているときに「いや、それはダメだ。食い違うようにすべきではないのでhttp://perldoc.jp側でなんとかしろ」というような発言はできないことは推察して欲しい。そして、[perldocjp:1123]では同時に『今後、Japanized Perl Resources Projectの成果物がperldoc.jpから参照されなくなった場合にどうするのかは我々Japanized Perl Resources Projectの課題なのでしょう』と発言しているように、仮にそのような状況になった場合は何らかの対処が必要であるという認識も持っている。

ま、私としてはhttp://perldoc.jpがJPRPのCVSリポジトリを見なくなる可能性は極めて低いというようには思っているけどね。しかし、まあ、以前よりJPRPとしてできることをいくつか考えているので、年内にでも何かを見せることができるレベルまで持って行きたいと思う。こう書いてしまうことでやらざるを得なくなるというメソッド。

あと、lestrratさんにPerldocJp-Webってのを書いていただいたので、これをとりあえずローカルで動かしてみることもやってみようかなー。

以下、Japanized Perl Resources ProjectはJPRPと略す。

これまでの流れ

2009年12月8日21時 (UTC+9) ぐらいまでの流れ。細かい議論が知りたい人はログをどうぞ。

1. おさかなラボ – Perlの日本語ドキュメントポータルは速やかに刷新すべきという金田さんのエントリ
2. Perlドキュメント日本語訳 MLへの参加承認がされないとか勘違いだったとかいろいろ
3. [perldocjp:1026] 金田さんがテストメールを兼ねて問題意識の提示と新オーナーにしてくれという表明
4. [perldocjp:1027] 現MLオーナーの川合さんから「オーナーと言ってもMLの管理者というだけですけど、大改革前提でいきなり代われって言われても代わり辛い。MLオーナーでなくてもできることだからまずは動いてみたら？」というメールを投げる。
5. いろいろ
6. [perldocjp:1036] Googleグループへの参加のお願い 金田さんが新・Perl日本語ポータルプロジェクト ( http://groups.google.co.jp/group/new_perldocjp ) の案内。曰く《perldoc.jpにあるドキュメントの管理、翻訳作業の効率化なども含むので、興味のある方はぜひ参加してください。》とのこと。
7. [perldocjp:1038] 大前さん初投稿。Wiki化の提案。
8. [perldocjp:1039] 岩井が大前さんのコメントへ返信。《「このソフトウェアを使ってこういう仕組みを構築すればこのようなことが実現できる」というような話にしていただいた方が現実的かと思います》とした上でスパムやいたずらの問題とかいろいろ。
9. [perldocjp:1043] 上京します。会合を開きたいと思っています。 金田さん《新perldocjpの方に投げたものをそのままCc:します》として、関東でオフラインでの会合の案内。
10. [perldocjp:1049] 大前さんからWikiの実装を調査した話とかスパムなどへの対応方針とか。
11. [perldocjp:1050] 大前さんからみんな意見くれよという話とか、Git使えばJPAが訳したMooseのドキュメントをマージしてきてHTML化してみれるよ！とか。たぶんperldoc.jpの運営者とJPRPを勘違い。
12. [perldocjp:1078] コミッタ申し込み 金田さんがJPRPのコミット権を申請。その後岩井により権限をフルに付与。
13. [perldocjp:1085] wiki の話 大前さんが新スレッドを。以降議論中。
14. [perldocjp:1108] まとめ 金田さんが自分の考えとかをまとめる。
15. [perldocjp:1111] Re: まとめ 白方さんが《とりあえずgithubにプロジェクトを作って、perldocjp.sourceforge.jpのデータをインポートして運用を開始してしまえばよいと思います》。
16. [perldocjp:1119] Re: まとめ 加藤さんが「今、誤訳とかの反映が遅いのは人が動けてないだけなのでGit化だけではまったく意味がない」という指摘とか、金田さんの誤解部分を指摘とか。
17. [perldocjp:1120] Re: まとめ 岩井《白方さんや我々が、今のCVSリポジトリをそのまま使えるなら私としては問題ないです。》
18. [perldocjp:1121] Re: まとめ 金田さんが岩井の[perldocjp:11120]の発言を受けて《んじゃ特に問題ないですね。perldoc.jpが置き換わった時にはCVSリポジトリの内容とperldoc.jpの内容が食い違ってくると思いますがそれは構いませんか？》と質問。
19. [perldocjp:1123] Re: まとめ 岩井が金田さんの[perldocjp:1121]の発言を受けて《Japanized Perl Resources Projectとしては構わないんじゃないでしょうか。perldoc.jpの人が構うかどうかは知らないけれども。でも、それは我々Japanized Perl Resources Projectが気にするところではない。》や《今後、Japanized Perl Resources Projectの成果物がperldoc.jpから参照されなくなった場合にどうするのかは我々Japanized Perl Resources Projectの課題なのでしょう。》など。
20. [perldocjp:1124] Re: まとめ 川合さんが《いずれにしても新しい方式で立ち上げてみて実績があがれば、自然と古いものを吸収する方向に動くんじゃないでしょうか。もちろんその逆もありうるでしょうし、まったく違う動きになるのかもしれません。》とか《意欲を持った人が新しい方式で翻訳をするのも、公開するのも大いに結構だし喜ばしいことだと考えています。ただいくらその人がいいと思っていても「こうあらねばならぬ」と他人に強要するのは感心しませんし、まったくPerlらしからぬことだと考えています。》とか。

岩井の今の感想

まず、金田さんの立ち位置が全然理解できていない。どういう立場で発言しているのかとかが。現在のhttp://perldoc.jpを置き換えるものを作ろうというドキュメントプロジェクトの立場なのか、それとも翻訳の仕組み自体を改革しようという立場なのか。

翻訳を実施しているプロジェクトであるJPRPのリポジトリのGit化については、正直言って翻訳プロジェクトで分散型リポジトリを採用するメリットが理解できていない。マスターとなるリポジトリのメンテナンスを継続的にできるだけの体制が作れるならばもしかしたらありなのかも知れないが、これまでのJPRPの状況を考えるとpushされてきてもpullされないままになりそうな可能性は十分に高い。それならば、まだ、集中型リポジトリでコミット権を持っていただく方がプロジェクトが回るだろうと判断。

フロントエンドをWiki化する案はまだまだ議論中なのだが、スパムやいたずらを排除できるだけの仕組みがかなり難しいのではなかろうか。手動で発行されたユーザIDからのみ受け付けるという仕組みを採用するのならば、今、Wiki化する場合に享受できると主張されているメリットはなくなってしまう。ま、引き続き議論なんだろうな。

JPRPのリポジトリがCVSなことについては、今の若い人なんかはCVSなんかは使ったことがないという現状はあるのかもしれないなぁ、と想像している。Subversionの時代から使い始めたとか。そのあたりについてはいろいろ意見が欲しいなぁ。Perlドキュメント日本語訳 MLへくれるのがベストだけど、ブックマークコメントとかそういうのでもOKです。よろしくお願いします。

<body>
<article>
<header>
<hgroup>
<h1><a href="http://iwaim.beering.be/blog/">行動記録</a></h1>
<h2>再開</h2>
</hgroup>

これだと当然無名なセクションが作られてしまう。例えばHTML 5 Outlinerを使うと次のように表示される。

<ol><li><i>Untitled Section</i><ol><li>行動記録</li></ol></li></ol> 

無名セクションを作ってしまわないためには、このようにマークアップしないとまずい。

<body>
<header>
<h1><a href="http://iwaim.beering.be/blog/">行動記録</a></h1>
</header>
<article>
<header>
<h2>再開</h2> 

慣れるまで忘れがちなので、戒めのために記録しておく。