アカウント名:
パスワード:
確かに、ロケールの問題は多いと思う。
ロケールに限ったことではないのですが、一般の人に Linux などの UN*X 互換 OS を進められない原因の１つだと思う。つまりアプリケーションによって操作方法とか仕様の統一が行われておらず混乱を招いているということなんですが...。
そういう意味で、ロケール指定方法の統一とか、フレーム
まだ言いたいことがあった。というより忘れてた(^^;。
ロケール問題で、kubota さんが取り上げてた問題で、いわゆる複数のロケール(含む、国, 時間帯, 通貨, 言語など)をどう表現し扱うのか。
一番の問題点は、Unicode 系で統一しようとする動きですよね。日本にいる限り日本人である限り、Unicode (UTF-7/8 など) の便利さは否定しないものの、Unicode だけに統一しちゃうというのは NG です。という
ロケールに合わせて動作すべき，というのはもっともですが， kterm や less や lv などのように， 文字エンコーディングを意識して動作する場合はなかなか難しいものがあります。 というのも，現在のロケールでサポートされている文字エンコーディングが何か，というのを知ることができないから。 文字エンコーディングの名前を返す標準的な関数としては nl_langinfo(CODESET) がありますが， 古い OS (ちょっと前までの Linux を含む) では関数自体がないし，もっと致命的なのは， これの返す値が標準化されていないこと。 特定 OS だけで動けばいいのなら楽でしょうが， 移植性を考えると，頭痛がしてきます。
ロケール問題で、kubota さ
エンコーディングを自前で操作するソフトウェアですが、nl_langinfo() がなければ、Bruno Haible さんの libiconv や libcharset を使うことができます。ただ、LGPL なのでどこにでも使うというわけにはいかないですが。 [gnu.org]
完璧を目指すのでなければ、ある程度は nl_langinfo(CODESET) のエミュレートはできます。もしバグレポートが来なければいまのところその程度で困る人はいないということだし、バグレポートが来ればテーブルにそれを追加すればいいし、どちらにせよ、実用上問題にはなりません。
最近、Li18nux が、ロケール名称の統一化ガイ
最近、Li18nux が、ロケール名称の統一化ガイドラインを作ろうとしていますが、なぜこれが10年前ではなく今の仕事となっているのかが、不思議でたまりません
うう，耳が痛い． なぜ10年前にできなかったのか， ということですが，
…から，他社と共通化するという方向性が乏しかったのが原因と思います．その後，Windows 3.1 以降で Windows 上での国際化機能は実質的に統一され，UNIX 陣営も CDE (Common Desktop Environment) で統一する方向があったのですが， Linux や *BSD では，それがまた独自でばらばらの状態に戻ってしまった．そういう意味では，最大の問題は:
かもしれません．たとえば MIME では charset パラメーターの値は登録制になっていますが， setlocale() や iconv_open() で使う名前はそうなっていないから，ばらばらに実装することを許してしまった．
(もちろん10年前には Li18nux はありませんでしたので、これは Li18nux の責任ではありません)。
主要メンバーは10年前からの残党ですが :-)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
ロケール問題 (スコア:1)
確かに、ロケールの問題は多いと思う。
ロケールに限ったことではないのですが、一般の人に Linux などの UN*X 互換 OS を進められない原因の１つだと思う。つまりアプリケーションによって操作方法とか仕様の統一が行われておらず混乱を招いているということなんですが...。
そういう意味で、ロケール指定方法の統一とか、フレーム
Re:ロケール問題 (スコア:1)
まだ言いたいことがあった。というより忘れてた(^^;。
ロケール問題で、kubota さんが取り上げてた問題で、いわゆる複数のロケール(含む、国, 時間帯, 通貨, 言語など)をどう表現し扱うのか。
一番の問題点は、Unicode 系で統一しようとする動きですよね。日本にいる限り日本人である限り、Unicode (UTF-7/8 など) の便利さは否定しないものの、Unicode だけに統一しちゃうというのは NG です。という
Re:ロケール問題 (スコア:1)
ロケールに合わせて動作すべき，というのはもっともですが， kterm や less や lv などのように， 文字エンコーディングを意識して動作する場合はなかなか難しいものがあります。 というのも，現在のロケールでサポートされている文字エンコーディングが何か，というのを知ることができないから。 文字エンコーディングの名前を返す標準的な関数としては nl_langinfo(CODESET) がありますが， 古い OS (ちょっと前までの Linux を含む) では関数自体がないし，もっと致命的なのは， これの返す値が標準化されていないこと。 特定 OS だけで動けばいいのなら楽でしょうが， 移植性を考えると，頭痛がしてきます。
nl_langinfo (スコア:1)
エンコーディングを自前で操作するソフトウェアですが、nl_langinfo() がなければ、Bruno Haible さんの libiconv や libcharset を使うことができます。ただ、LGPL なのでどこにでも使うというわけにはいかないですが。 [gnu.org]
完璧を目指すのでなければ、ある程度は nl_langinfo(CODESET) のエミュレートはできます。もしバグレポートが来なければいまのところその程度で困る人はいないということだし、バグレポートが来ればテーブルにそれを追加すればいいし、どちらにせよ、実用上問題にはなりません。
最近、Li18nux が、ロケール名称の統一化ガイ
Re:nl_langinfo (スコア:1)
うう，耳が痛い． なぜ10年前にできなかったのか， ということですが，
…から，他社と共通化するという方向性が乏しかったのが原因と思います．その後，Windows 3.1 以降で Windows 上での国際化機能は実質的に統一され，UNIX 陣営も CDE (Common Desktop Environment) で統一する方向があったのですが， Linux や *BSD では，それがまた独自でばらばらの状態に戻ってしまった．そういう意味では，最大の問題は:
かもしれません．たとえば MIME では charset パラメーターの値は登録制になっていますが， setlocale() や iconv_open() で使う名前はそうなっていないから，ばらばらに実装することを許してしまった．
主要メンバーは10年前からの残党ですが :-)