[debian-devel:14066] Re: 環境変数 LANGUAGE

[GOTO Masanori <gotom@debian.or.jp>]

At Tue, 10 Apr 2001 09:47:23 +0900,
Tomohiro KUBOTA wrote:
> i18n@xxxxxxxxxxx とか、debian-i18n@org とかでも話題になっていますが、
> 環境変数 LANGUAGE の扱いについてです。

man-db 関連でしたっけ…。
そういえばメールしようとして忘れていた…。

> LANGUAGE は、ロケールを決定するための非標準 (GNU 独自) の環境変数で、
> 複数の言語をコロン「:」でつないで指定し、第2希望の言語、第3希望の
> 言語、... を指定できるのが特徴です。

当初は gettext の設定向けに作成されたと記憶しています。

> 私は、LANGUAGE は LC_MESSAGES ロケールを決定する (かのように動作する)
> ものだと思っていたのですが、どうやら、そうなっていないようです。

glibc 2.2 から gettext がより強固に libc に含まれました。
そのため、動作が少し以前とかわっている可能性はあるはずです。
あと LANGUAGE はあくまでも gettext 向けであって LC_MESSAGES とは
違うかも?

> 以下のテストをやってみました。もとのエンコーディングは EUC-JP です。

LANG やその他の環境関数はどうなっていますか?
C locale の場合、LANGUAGE はみないようになっていますが、
その他の locale の場合最も強い設定変数になります。

> (1)
> ~$ LC_MESSAGES=zh_TW ls foo
> ls: foo: ?????????
> (2)
> ~$ LC_CTYPE=ja_JP.eucJP LC_MESSAGES=zh_TW ls foo
> ls: foo: 沒有此一档案或目録
> (3)
> ~$ LANGUAGE=zh_TW ls foo
> ls: foo: No such file or directory
> (4)
> ~$ LC_CTYPE=ja_JP.eucJP LANGUAGE=zh_TW ls foo
> ls: foo: No such file or directory
> (5)
> ~$ LC_MESSAGES=ja_JP.eucJP LANGUAGE=zh_TW ls foo
> ls: foo: ?????????
> 
> (1) は、まあ仕方がない動作ですね。LC_MESSAGES カテゴリが中国語
> なのに、LC_CTYPE が ASCII なので、中国語を ASCII に変換しようと
> しているのでしょうか。(文字化けするのではなく、変換しようとする
> くらいなら、もうちょっと気をきかせてほしいなと思うところですが)。
> 
> (2) は、なんとすばらしい! 中国語が EUC-JP で表示されています。
> もちろん、限界はあるでしょうが。(「档」と「録」は Unicode
> で統合されていない文字、それ以外は統合されている文字です)。
> 
> (3) のあたりから、あやしくなってきます。LANGUAGE がたんに
> LC_MESSAGES よりも強い、という解釈では、(1) と同じ結果になる
> はずですので、これは説明できません。どうなってるのでしょうか。

C locale だからではないでしょうか。
See; libc intl/dcigettext.c:1131.

> (4) は、LANGUAGE が LC_MESSAGES よりも強いという解釈なら、
> (2) と同じになるはずです。この動作も、よくわかりません。
> 
> (5) を見ると、LANGUAGE が LC_MESSAGES より強いという解釈は
> まちがっているということが明らかになりますが、ではどういう
> 動作なんでしょうか。。。


> GNU libc は、いまのところ、OUTPUT_CHARSET がまだ消せていない
> など、開発途中っぽいところがあるので、こういう、実装をテストする
> ことによって LANGUAGE の意味を理解しようとする試みは、やるべき
> ではないのかもしれません。

?? OUTPUT_CHARSET が消せないとはどういうことでしょうか。
個人的には OUTPUT_CHARSET はもはや設定する必要のない
変数だと思います。

もし文字が化けるような software があれば、早急に
setlocale() をするなどの対処を行うべきですし。

それから、glibc-2.2.3 から、少なくとも SUSv2, POSIX
の定める i18n には完全対応したはずです。
(最後まで残っていた regexp i18n が完成したためです)。
もはや開発途中とは思いません。

> そこで、ドキュメントにあたってみることにしますと、GNU libc の
> info ページに、LANGUAGE の記述があります。
> 
> >  In detail, for the category `LC_xxx' the following
> > variables in this order are examined:
> > `LANGUAGE'
> > `LC_ALL'
> > `LC_xxx'
> > `LANG'
> 
> これを見ると、LANGUAGE はすべてのロケールカテゴリに影響する
> ように読めます。これだと、LANGUAGE が設定されていたらその他の
> LC_* や LANG は一切無視されるはずですので、ドキュメントと
> 実装に相違があります。

C locale のときのことは書いてませんね。
書き忘れなら書き足した patch を送りますので、
C locale のときのテストがどうか確認していただけますか。

> ただ、ドキュメントに記述されている動作を目指しているのだと
> しても、不都合があるように思います。というのは、LANGUAGE の
> 利点は、好きな言語を順番に並べることができる点にありますが、
> LC_CTYPE カテゴリだけは、現在使用中のターミナルやディスクに
> 記録されているファイルのエンコーディングによって決定されるので、
> 固定したいからです。

LANGUAGE を : で区切って拡張するということに関して
述べられているドキュメントってご存じでしょうか。
# or LANGUAGE の正確な定義でも。

個人的には : で区切って拡張することには興味がありますが、
LC_CTYPE との関係を考えると安易に好きな言語を並べるのは
難しいと思っています。

--
後藤 正徳