dotprojectと格闘する - 辛苦（たしな）みつつ

今日も、dotprojectと格闘していた。今日はなんとか解決したので、少しだけ思い出しながら書こう（思い出しだから確実じゃないよ）。あと、mantisも少し触ってみたのでその説明もしておく。

ガントチャートの国際化

昨日、dotprojectの国際化でも書いたように、英語以外の文字がうまく表示されなかった。例えば、ルーマニア語のşと日本語「あ」を同時に表示できないことだ。この問題だが、以外に早く片付いてしまった。具体的には以下の通りだが、設定の基本方針をまず説明しておく。

国際化の基本方針

まず、ルー語も日本語も扱い面倒なのですべてutf-8で文字コードを利用する。そこで、utf-8に対応したTrueTypeFontを利用する。すべてのutf-8コードに対して使用可能なTrueTypeFontは、arialuni.ttfだ（MSが出しているので使用上の問題はある可能性がある）。

modules/tasks/gantt.phpの修正

具体的には、modules/tasks/gantt.phpファイルの

$name = utf8_decode($name);

の部分をコメントアウト。この関数はiso-8859-1にしか対応していないらしい。日本語などを通すと、入ってきた文字列をiso-8859-1の文字コードとして解釈し、その後utf8に変換するらしい（変換するのではないかも）。入ってきた文字列をiso-8859-1として強制的に扱うなんてひどいなぁ。

lib/jpgraph/src/jpgraph.phpの修正

このファイルはいくつか修正した。以下のファイルで、FF_GOTHICとかなっているところは変数なので、他の文字列でも良い（はず、だしFF_ARIALUNIとかした方がいい。）

DEFINE("FF_GOTHIC",40);
DEFINE("TF_GOTHIC","arialuni.ttf");

として、値が40代のほかのFF_***はすべてコメントアウト。

function TTF()内で、FF_GOTHIC内をすべて、arialuni.ttfを参照するように変更。こんな感じ。この設定は不要かもしれない。

FF_GOTHIC  => array(FS_NORMAL=>'arialuni.ttf',
   FS_BOLD=>'arialuni.ttf',   FS_ITALIC=>'arialuni.ttf',
   FS_BOLDITALIC=>'arialuni.ttf' )

次に、function StrokeTextを修正（２つあるので注意）。こんな感じの場所。

  function StrokeText($x,$y,$txt,
    $dir=0,$paragraph_align="left",$debug=false) {

	$x = round($x);
	$y = round($y);

この部分の直下に以下の内容を追加。

$this->font_family=FF_GOTHIC;
$this->font_file=TTF_DIR.TF_GOTHIC.".ttf";
$this->font_size=8;

font_sizeについては、オプションだ。ガントチャートを表示した際に、文字が大きすぎてうまく表示できなかったので設定した。見つけるのに苦労したよ。

lib/jpgraph/src/jpg-config.incの修正

上記の設定で、うまくいくはずだが、ルーマニア語がうまく表示できない。そこで、このファイルを修正。

DEFINE("CYRILLIC_FROM_WINDOWS",false);

falseにするのがポイント。なんかキリル文字か何かだと勘違いするらしく、キリル文字ではないし、utf8を使うので、falseにした。

/usr/X11R6/lib/X11/fonts/truetype/

このディレクトリにarialuni.ttfファイルを置いておく。

多分、これだけだと思うが、まだ修正点があるかも。修正点あったらコメントお願いします。明日、また環境を再確認してみる予定ではいる。

「はてな」がutf-8対応でいつも助かる。ルーマニア語も日本語も表示できるしね。だが、xoopsは基本的にutf-8対応してないので困る。いまだにeucなんて使ってるし。。。

mantisの設定

これは、バグ管理システムだ。日本語のサイトを検索すると3本の指に入るらしい。一番有名なのは、Bugzillaで、こいつをインストールしようと思ったが、CPAN経由のインストールがうまくいかなかったので、あきらめ。

バグ管理システムの考え方

概念的に言ってしまえば、いつ・どこで・どんなバグ（問題）が発生し、現在どのような解決の段階にいるのか？を把握するシステムだ。品質管理の1分野（だと思う）。

流れとしては以下のような感じだ(括弧内は、mantisの"status")

テスターがテストをしてバグを発見し、レポートを書き、品質管理者に提出。(new)
品質管理者は、バグがあるのを認識し(acknowledged)
バグが具体的にどのようなものであるか確認し、(confirmed)
問題の担当者を決定する（問題を人に割り当てる）(assigned)
担当者は、問題を解決し、テスターに報告する。(--)
テスターは再度テストを行い、解決されたかどうかを確認する。(resolved)
問題が解決されて、他に問題がなければ問題は全面的に解決したとみなす(closed)*1

mantisでのstatus・resolutionの考え方（私見）

mantisを使っていて、混乱させられるのは以下の2点だろう。

statusとresolutionの違い
feedbackの扱い

statusとresolutionについてはようやくわかってきた（と思う）。statusはプロジェクト全体としてバグをどのように認識しているかを示している（プロジェクトとして問題を「確認」したのか、誰に割り当てているか）。resolutionは、解決の手段・状況を見ている（実装したのか、再現不可なのか、以前発生した問題と同じなのか）

feedbackについてはよくわからない。一応日本語の訳を見ていくと、解決担当者（開発者）からテスターへのfeedback（要追加情報）をあらわしているらしい。でもね、テスターが再試験して、開発者にfeedbackという流れもあると思うのだがどうだろうか？まぁ、この辺は、mantisは自由にワークフローが設計できるから対応できると思う。statusかresolutionも項目を増やせた気がするし。それに、割り当ての人を変えればすむ気もするし。

文字コード関連

これは、お手上げです。はぁ、まったくよくわからない。default_language設定してもログイン後の画面では、default_languageの言語になってないし。。。しょうがないし、これは個人的に使おうと思っているだけだから、すべて英語で対応する予定。

*1:このあたりは、人間的だと思う。横並びチェックや他への影響がないことを確認し、品質管理者かプロマネが問題は終了だと判断するのだと思う。