[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:14041] 環境変数 LANGUAGE
- From: Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>
- Subject: [debian-devel:14041] 環境変数 LANGUAGE
- Date: Tue, 10 Apr 2001 09:47:23 +0900
- X-ml-info: If you have a question, send e-mail with the body "help" (without quotes) to the address debian-devel-ctl@debian.or.jp; help=<mailto:debian-devel-ctl@debian.or.jp?body=help>
- X-ml-name: debian-devel
- X-mlserver: fml [fml 3.0pl#17]; post only (only members can post)
- Message-id: <87d7alr2xc.wl@xxxxxxxxxxxxxxxxxxxxx>
- X-mail-count: 14041
- User-agent: Wanderlust/1.1.1 (Purple Rain) EMY/1.13.8 (Tastes differ) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)
久保田です。
i18n@xxxxxxxxxxx とか、debian-i18n@org とかでも話題になっていますが、
環境変数 LANGUAGE の扱いについてです。
LANGUAGE は、ロケールを決定するための非標準 (GNU 独自) の環境変数で、
複数の言語をコロン「:」でつないで指定し、第2希望の言語、第3希望の
言語、... を指定できるのが特徴です。
私は、LANGUAGE は LC_MESSAGES ロケールを決定する (かのように動作する)
ものだと思っていたのですが、どうやら、そうなっていないようです。
以下のテストをやってみました。もとのエンコーディングは EUC-JP です。
(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) と同じ結果になる
はずですので、これは説明できません。どうなってるのでしょうか。
(4) は、LANGUAGE が LC_MESSAGES よりも強いという解釈なら、
(2) と同じになるはずです。この動作も、よくわかりません。
(5) を見ると、LANGUAGE が LC_MESSAGES より強いという解釈は
まちがっているということが明らかになりますが、ではどういう
動作なんでしょうか。。。
GNU libc は、いまのところ、OUTPUT_CHARSET がまだ消せていない
など、開発途中っぽいところがあるので、こういう、実装をテストする
ことによって LANGUAGE の意味を理解しようとする試みは、やるべき
ではないのかもしれません。
そこで、ドキュメントにあたってみることにしますと、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 は一切無視されるはずですので、ドキュメントと
実装に相違があります。
ただ、ドキュメントに記述されている動作を目指しているのだと
しても、不都合があるように思います。というのは、LANGUAGE の
利点は、好きな言語を順番に並べることができる点にありますが、
LC_CTYPE カテゴリだけは、現在使用中のターミナルやディスクに
記録されているファイルのエンコーディングによって決定されるので、
固定したいからです。
GNU libc の開発の動向とか、ご存知の方はいらっしゃいますでしょうか?
---
久保田智広 Tomohiro KUBOTA <kubota@debian.org>
http://surfchem0.riken.go.jp/~kubota/
リニューアル中: "Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/