[debian-devel:00388] Re: How to use gettext (Re: dpkg_1.4.0.5-jp uploaded)

[yochi@xxxxxxxxxxx]

やなぎはらです。

yosshy> 　吉山＠神戸大です。
yosshy> 
yosshy> + 仕事上 SVR4 関係の gettext は良く分かるんですが、GNU のは、
yosshy> + ちょっと変わっていますね。
yosshy> + 
yosshy> + ちょっと、textutils パッケージのソースを覗いてみたら、つぎのような事が
yosshy> + わかりました。
yosshy> 	（中略）
yosshy> + gettext に関する詳しい説明、GNU utilities での使用例などは
yosshy> + gettext パッケージについています。ドキュメントはパッケージの
yosshy> + インストール後、info で参照できます。
yosshy> + ほとんどダイジェストのような説明ですが、参考になるでしょうか？
yosshy> 
yosshy> 　もう、感謝感激です！。
yosshy> 　親切に説明して頂きまして、本当にありがとうございます。_(_)_　早速
yosshy> プリントアウトして家に持って帰ります。

いや〜、参考になったようで、よかったです。
ただ、私が会社で使っている Bo 環境の gettext_0.10.26-0 パッケージの
libintl.a はシンボルがないと怒られてしまいました。

仕方がないので、お手軽にtextutilsパッケージのソースをmakeして出来上がっ
たライブラリを使用しました。まぁ、gettext のパッケージには、ライブラリ
を作成するためのソースが/usr/share/gettext/intlに一式入っているので、
これをdpkgのソースに取り込んでしまえばＯＫだと思います。

その時は、configure.in をちょっといじる必要があるかも知れません。

intl 配下のソースは、configure で Makefile を作成する事を前提にしてい
るからです。

yosshy> 　概念的には、私が今やっている日本語化の延長でいけそうです。近い内に
yosshy> gettext 化した dpkg を用意できると思います。(^-^　

よろしくお願い致します。
メッセージだけの日本語化なら結構できると思います。

yosshy> # 何せ、sharutilsのソースを見たのですが、どうやっていいものかほとんど
yosshy> # 参考にならなかったもので…）

info を見ると、 GNU Utility では、
textdomain() とかに渡す引数(PACKAGE, LOCALEDIR)は、
コンパイルオプション -DPACKAGE=\"...\" -DLOCALEDIR=\"...\" という形で
定義し、gettext() は、_() で 記述するようにして、

#if ENABLE_NLS
# define _(Text) gettext (Text)
#else
# define bindtextdomain(Domain, Directory) /* empty */
# define textdomain(Domain) /* empty */
# define _(Text) Text
#endif

というようにすると書いてありました。

yosshy> 　それはそうと、一箇所質問です。テキスト記述ファイルの "" で囲んだ部分
yosshy> は特に場所を指定する必要はないのでしょうか？説明を見る限りでは、オリジ
yosshy> ナルが msgid で指定されているだけで、勝手にツールがパターンマッチング
yosshy> して適当にやってくれるように見えましたが…

msgfmt がメッセージファイルの先頭にINDEX部分を作成してくれます。
gettext()がINDEX部分を用いてパターンマッチングし、実際表示べき文字列の
位置をとりだすようになっているようです。

もし、該当するメッセージがなければ gettext() で書かれた文字列がそのま
ま表示されるはずです。

SVR4 では、gettext の引数にメッセージ番号を指定します。
メッセージファイルは、１行(改行まで)１メッセージという感じで記述し、
gettext の引数のメッセージ番号と行数が対応するようになります。
SVR4 でも、mkmsgs というコマンドで、テキスト形式のメッセージファ
イルをINDEX付きのバイナリファイルに変換します。

まぁ、雰囲気は似ていますが、GNUの実装の方がいいですね。
SVR4 では、メッセージファイルの行がずれるととっても悲惨な事になります
から。

yosshy> # きちんとドキュメントを読めば良いのでしょうね、きっと。

#ええ、たぶん... (^^;

yosshy>   ... という訳で、期待して待っていて下さい。(^-^

はい！

yosshy> 　ちなみに、libc-5.4.17 が出ましたね。売りが Locale という事ですが、
yosshy> 型の定義はマトモになっていても、実は只単にキャストしているだけという、
yosshy> 未完成な実装になっています。さしあたって、 mbtowc(), wctomb(),
yosshy> mbstowcs(), wcstombs() などの関数で、日本の JIS, EUC, SJIS 等をすぐに
yosshy> 使いたい方はおられますか？（今なら比較的楽に実装できます）どれぐらい
yosshy> 需要があるか知りたいのですが…

Bo (Debian-1.3)では、libc は 5.4.17 になっています。
Rex(1.2.x) では、5.4.13 ですよね。

libc のバージョンが違ってしまっているので、パッケージ作成が
面倒な事になっています。(あ、まえから言ってましたよね。)

＃会社 Bo (超最新の追っかけ)
＃自宅 Bo (超最新の追っかけ)
＃現在、純粋な Rex 環境の構築を 自宅で行う *予定* です。


---------------
話が、ちょっと変わってしまうのですが、
Debian-1.3 では、binary-i386 配下がちょっと変わってしまいした。
あらたに、interpreters, libs, otherosfs, utils, web サブディレクトリが
加わり、既に登録済のパッケージも大きく置き場所が変わってしまいした。

で、ftp.linux.or.jp の jp-devel 配下ですが、
今提出されている unstable ディレクトリを Debian-1.2-jp とかに
変更し、unstable というのはなくしてしまいましょう。

まだ、本家にcontribしたパッケージはありませんが、
もし、contrib するとすると、対象は Bo になりますから、
本家にcontribしたものが出て来れば、unstable ないし、bo-jp と
いうディレクトリを構築すると言う事でどうでしょうか？

+---------------------------------------------------------+
 Yoshiaki Yanagihara		E-mail: yochi@xxxxxxxxxxx           
					yosiaki@debian.org
 Debian JP Project
 [Japanese] http://www.linux.or.jp/~yochi/debian-jp.html
 [English ] http://www.linux.or.jp/~yochi/debian-jp-e.html