[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:13094] Re: glibc-2.1.94-2 status (Re:[debian-users:24171] glibc-2.1.94 is now installed in woody. pleaseattention!)
佐野＠浜松です。
In <20001017094322I.kgh12351@xxxxxxxxxxxxxxxxxxxx>,
on "Tue, 17 Oct 2000 10:15:18 +0900", I wrote:
> > > * ln -s /usr/lib/locale/ja_JP.eucjp /usr/lib/loacle/ja_JP.eucJP
> > > をしないと GNOME, X系の app で日本語が駄目です。
> > > この symlink をしておけば LANG=ja_JP.eucJP で ok です。
> > > (ちなみに symlink がないと LANG=ja_JP.eucjp でも ダメ)
> > >
> > > なお LANG=ja_JP.ujis はありません。
> > > symlink がなくても libc の locale は LANG=ja_JP.eucJP で ok です。
> >
> > これは、
> > mv /usr/lib/locale/ja_JP.eucjp /usr/lib/locale/ja_JP.eucJP
> > にしたほうが良いでしょうね…。
> > また後方互換性のために ja_JP.ujis も symlink して欲しいですね。
> >
> > この2つは BTS しておきました。
>
> さっき BTS チェックしたら 2.1.95.1 で close されちゃいましたね。
>
> BTS に reopen 72686 すべきですね。
>
> # 同様なレポートとして #74362 があることも指摘すべきか ?
>
> あとで BTS report しておくつもりです。
Changwoo からコメントがあったので、回覧しておきます。
In <87og0jjyuw.fsf@xxxxxxxxxxxxxxxxxxxx>, on "18 Oct 2000 00:01:27 +0900", titled
"Re: reopen #72686 (Re: /usr/lib/locale/ja_JP.eucjp should be changed to ja_JP.eucJP)",
Changwoo Ryu <cwryu@debian.org> さん wrote:
cwryu> Taketoshi Sano <sano@debian.org> writes:
cwryu>
cwryu> > Changwoo Ryu <cwryu@debian.org> wrote as the comment on #72686
cwryu> >
cwryu> > | In glibc, the charset name in a locale name should be lowercase.
cwryu> > |
cwryu> > | You can still set $LANG as ja_JA.eucJP, ja_JA.euc-jp, or ja_JA.EUC-JP.
cwryu> > | setlocale() automatically converts the charset name into lowercases
cwryu> > | and deletes non-alphabets-or-numbers.
cwryu> >
cwryu> > But hey, there are X/Gnome applications which use the X11 style scheme
cwryu> > of internationalization.
cwryu> >
cwryu> > Changwoo, do you remember that you once wrote me:
cwryu> >
cwryu> > | But xcalendar-ja is never a Japanese-only diversion of xcalendar,
cwryu> > | except the Japanese X resource. It's a well-written internationalized
cwryu> > | (in a sense of X Window) patch for xcalendar. Works very well in my
cwryu> > | Korean X environment! :)
cwryu> >
cwryu> > So I rename the package to xcalendar-i18n, and has maintained it.
cwryu> > Now without ja_JP.eucJP or ja_JP.ujis symlinks, it would not work
cwryu> > at all in these locale settings. Maybe you (Changwoo) can check
cwryu> > if it can work with kr_KR.eucKR locale (Please refer the Bug#74362).
cwryu> >
cwryu> [snipped experiments]
cwryu>
cwryu> Yes, I know the problem. Of course I know the symlink resolves it.
cwryu> But see the point; it's xlib's problem. Why does it work with
cwryu> ko_KR.eucKR? Why not with ko_KR.euckr, which is a valid locale? I
cwryu> couldn't found what causes this yet.
どっちが「正しい locale なのか ?」ってことなんでしょうか ?
これは Li18nux の出番かな。
ふぅむ、、、 FHS 2.0 を見ると
This naming of language subdirectories of /usr/share/man is based on
Appendix E of the POSIX 1003.1 standard which describes the locale
identification string -- the most well-accepted method to describe a
cultural environment. The <locale> string is:
<language>[_<territory>][.<character-set>][,<version>]
The <language> field shall be taken from ISO 639 (a code for the
representation of names of languages). It shall be two characters wide
and specified with lowercase letters only.
The <territory> field shall be the two-letter code of ISO 3166 (a
specification of representations of countries), if possible. (Most
people are familiar with the two-letter codes used for the country codes
in email addresses.1) It shall be two characters wide and specified with
uppercase letters only.
The <character-set> field should represent the standard describing the
character set. If the <character-set> field is just a numeric
specification, the number represents the number of the international
standard describing the character set. It is recommended that this be a
numeric representation if possible (ISO standards, especially), not
include additional punctuation symbols, and that any letters be in
lowercase.
A parameter specifying a <version> of the profile may be placed after
the <character-set> field, delimited by a comma. This may be used to
discriminate between different cultural needs; for instance, dictionary
order versus a more systems-oriented collating order. This standard
recommends not using the <version> field, unless it is necessary.
Systems which use a unique language and code set for all manual pages
may omit the <locale> substring and store all manual pages in <mandir>.
For example, systems which only have English manual pages coded with
ASCII, may store manual pages (the man<section> directories) directly in
/usr/share/man. (That is the traditional circumstance and arrangement,
in fact.)
Countries for which there is a well-accepted standard character code set
may omit the <character-set> field, but it is strongly recommended that
it be included, especially for countries with several competing
standards.
となってますね。ということは "Appendix E of the POSIX 1003.1 standard
which describes the locale identification string -- the most well-accepted
method to describe a cultural environment" に従うと "The <character-set>
field should represent the standard describing the character set. If the
<character-set> field is just a numeric specification, the number represents
the number of the international standard describing the character set.
It is recommended that this be a numeric representation if possible (ISO
standards, especially), not include additional punctuation symbols, and that
any letters be in lowercase." であるから、eucJP よりも eucjp が正しい、と
いうことになるのか ?
Linux における日本語ロケールに関する指針
1999年12月15日
バージョン: 1.03
だと
関連規格
この文書におけるロケール(locale)とは、以下に挙げる規格の文化圏固有操
作(locale)を指す。
POSIX.1
(IEEE 1003.1:1990, ISO/IEC 9945-1:1990s)
(翻訳規格 JIS X 3030-1994)
Programing Language C
(ISO/IEC 9899:1990)
(翻訳規格 JIS X 3010-1993)
Programing Language C (Amendment 1)
(ISO/IEC 9899:1990/Amd.1:1995)
(翻訳規格 JIS X 3010:1996)
であって
2. ロケール名称
ここでのロケール名称とは環境変数 LANG や LC_ALL 等に設定すべき値であ
り、 C ライブラリ関数 setlocale() に与えるべき値である。
・Linux における日本語環境において使用する文字コードは日本語 EUC と
し、そのロケール名称は
ja_JP.eucJP
を推奨する。eucJP の部分の大文字/小文字の区別を期待しないことが望
ましい。
となってますね。そうするとたしかに eucjp でも eucJP でも動作するほうが
ベターではないか、ということは言えそうです。
cwryu> The symlinks will resolve that problem, but that's not a "right"
cwryu> solution and violates glibc's policy.
cwryu>
cwryu> And xlib6g in the new xfree86 4.0.1 doesn't have this problem (at
cwryu> least for me, with ko_KR.euckr). So the final woody users will not
cwryu> matter.
もしかすると xlib6g を新しい glibc で build し直せば OK になったりする ?
いや、そうじゃないな。
$ diff -u 3.3.6/xc/nls/locale.alias 4.0.1/xc/nls/locale.alias |grep eucjp
+ja_JP.eucjp ja_JP.eucJP
+ja_JP.eucjp: ja_JP.eucJP
このへんが問題なのか。
ということは /usr/X11R6/lib/X11/locale/locale.alias をいじれば
解決 ?
やっぱりそうみたいですね。chroot したほうの woody の locale.alias を
いじって、あと /usr/X11R6/lib/X11 の下で ln -s ja_JP.eucJP ja_JP.eucjp
しておけば、LANG=ja_JP.eucjp でも LANG=ja_JP.eucJP でもちゃんと日本語の
リソースを読んで動作しました。(xcalendar で確認)。
でも ja_JP.ujis はやっぱり symlink 必要なんじゃないのかな ?
cwryu> Let's find exactly what causes that X locale problem.
cwryu>
cwryu> --
cwryu> Changwoo Ryu
さて、どうしましょうね ?
--
＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
<kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野 武俊)