メッセージの多国語化のために、 reply_message_nl() FML::Process::Kernel を参照 を使い、 $curproc->reply_message_nl('error.already_member', 'already member', { _arg_address => $address }); のような呼び出し方をします。 この関数は /usr/local/share/fml/message/euc-jp/error/already_member というテンプレートを用いてメッセージを構築します。 メッセージ中の $変数名、例えば、 $_args_address はハッシュリファレンスとして与えられた引数へ展開されます。 また config.cf 中で定義されている変数も同様に展開可能です。 例えば $ml_name はＭＬ名に展開されるようになっています。 適宜、エラーメッセージを送信者に返す必要があります。 それもエラーメッセージは言語依存です。 何らかの形で言語変換をしてから送り出すわけです。 fml 4.0 では Mesg(*e, キーワード, デフォルトのメッセージ, 変換に使う引数); の形で呼び出します。 /usr/local/fml/messages/Japanese/ 以下にあるファイル群に対して、 キーワード検索を行ないます。 各ファイルにはカテゴリごとに分類されたキーワードとメッセージが 定義されています。 つまり各ファイルに複数のキーワードが定義されています。 例えば、キーワードが not_found の場合、 /usr/local/fml/messages/Japanese/kern の not_found という欄が該当します。 一つのファイルに一つのキーワードを持つのと、 カテゴリごとに複数のキーワードを持つのとどちらが カスタマイズしやすいのでしょうか？ 僕には良くわかりません。 XPG (X/Open の規格)を使う場合は catgets(catd, set_id, msg_id, char *s); で、LOCALE_○○ で指定された言語へ変換しています。 ここで s はデフォルトのメッセージとなります。 例えば、次のような使い方をします。 printf(catgets(catd, 30, 4, "%s: Internal match error.\n"), progname); この時、 locale の定義ファイル( 例: /usr/pkg/share/nls/ja_JP.EUC/プログラム名.cat ) の中の se 30、エントリ 4 のメッセージに変換してくれます。 問題の一つは locale に対応するか？という問題です。 makefml を筆頭に、各種コマンド群のエラーメッセージの日本語化 を考えると、 locale を考えておくのも悪くはないのかとも思います。 この場合は locale ぽくするために /usr/local/lib/fml/バージョン/messages/ja_JP.EUC/kern 1: %s は見つかりません 2: %s は %d のエラーです といったものにしておくと後で便利そうです。 逆に、一つのキーワードごとに別のファイルにしておく構成も可能です。 これは特定の一つのキーワードだけ変えたい場合に便利そうです。 もし、後者の方法を試してみることにすると、 FML::Message::ja::キーワード というクラスをじゃんじゃん作るような作り方になるでしょう。 例えば FML::Message::ja::not_found などと2、300個のファイルが作られることになります（まじか？）。 この方法の問題点は ファイルがバラバラになる (逆に長所としてカスタマイズしやすくなる) ファイルがバラバラになることで locale ぽくなくなるが？ locale 対応を考えると面倒じゃないだろうか？ あたりにあるでしょう。 また、各メッセージテンプレートはどのようなものであるべきだろうか？ 後者の場合、 sub not_found { my .. = @_; return <<"_EOF_" $sender はどうーたら _EOF_ } といった関数を一杯作ることもできます。 つまり単なる引数ではなく意味の分かりやすいものにすることを考えたわけです。 しかし、これは本当にカスタマイズしやすいでしょうか？ locale 化を考えるなら、これはこれで面倒な気がするわけですが…