国際化XTerm、実現へ向けて始動 25
是非実現を 部門より
kubota 曰く、 "以前にも話題になった、 XFree86 の XTerm の続報です。いよいよ、実際に実装されるコードについての議論が 始まります。
6 月に入って、XTerm 国際化パッチに必要な luit 改良パッチが CVS に commit されたことを受け、 i18n@xfree86 メーリングリストおよび linux-utf8 メーリングリストにパッチを流しました。 それに対する返事は今のところ好意的で、 パッチの存在意義そのものを否定するような意見は今のところありません。 したがって、このままいくと、大した修正もなく、 patch@xfree86 に登録→採用、となる可能性が大きいと思っています。 ですので、なにか意見があればよろしくお願いします。 (特に、デフォルトの動作をどうするかについて、迷っています)。 "
"機能ですが、現在のロケールを調べることで、 ISO-8859-{1,2,3,4,5,6,7,8,9,10,11,13,14,15,16}, KOI8-R, CP-1251, TIS-620 (ISO-8859-11), EUC-{JP,KR,CN}, GB2312 (EUC-CN), Big5 から自動選択する、というものです。 もし luit が改良されれば、サポートされるエンコーディングは 追加されます。 ただし、XTerm そのものの動作を改良するパッチではないので、 全角文字および (タイ文字などの) 結合文字はサポートされますが、 BiDi はサポートされません。 また、「●」などの記号の多くやギリシャ・ロシア文字など、 EUC では全角扱いのほうがいい文字が半角になってしまう問題についても、 手をつけていません。
試すには、XFree86 の CVS から xc/programs/xterm と xc/programs/luit をとってきて コンパイルしてください。xterm コンパイル時には、 ./configure --enable-wide-chars としてください。 XFree86 4.2 じゃない人は、luit コンパイル時に、 fontenc パッチが必要になります。 できあがった luit は、XFree86 のバイナリを置いてあるディレクトリ (/usr/X11R6/bin など) に置くか、または、"XTerm*localeFilter: hogehoge" というリソースで luit のパスを指定する必要があります。 詳しくは、パッチに含まれるマニュアルページのパッチを参照してください。"
使う人は自分のためにも是非ご意見を。
なにを迷ってるかというと (スコア:3, 参考になる)
- 8ビットモード。ロケールもエンコーディングも完全に無視する。エンコーディングは、フォント指定で行う。XTerm に最も古くからあるモード。
- UTF-8 モード。UTF-8 がハードコードされている。XFree86 4.0 のころに新設された。
- UTF-8 + luit モード。UTF-8 モードの上に luit をかぶせることで、様々なエンコーディングをサポートする。今回のパッチで新設する。
で、これらのモードを効率よく利用するため、「locale」リソースに以下のような指定をできるようにします。- true かならずロケールに従った動作をする。そのために、UTF-8 ロケールでは UTF-8 モードにして、それ以外のロケールでは UTF-8 + luit モード。
- false 従来と同じ動作。つまり、UTF-8 ロケールでは UTF-8 モード、それ以外のロケールでは 8 ビットモード。
- medium その中間。UTF-8 ロケールでは UTF-8 モード、東アジアとタイのロケールのときは UTF-8 + luit モード、それ以外では 8 ビットモード。
- それ以外の文字列 その文字列をエンコーディング名とみなし、UTF-8 + luit モード。
で、迷っているのは、true/false/medium のどれをデフォルト動作にしようか、というものです。ロケールに従わないソフトウェアはバグである、という認識に立てば true がデフォルトでないといけませんが、過去との互換性を保つのなら false が最良となります。パッチは「locale: true」の動作をデフォルトとするように実装しましたが、いまのところ、i18n@xfree86 では、medium 動作がデフォルトであるべきだ、との意見が出ています。また、medium 動作の実装について、MB_CUR_MAX を判定に使うのがよいとの意見もあります。
いかがでしょうか?
Re:なにを迷ってるかというと (スコア:0)
> MB_CUR_MAX を判定に使うのがよいとの意見もあります。
これだとlibcにlocaleがないようなOS(ex. Darwin)で
X Localeを使う時に問題が出ませんか？
UNICODE化 = 国際化? (スコア:0)
どうも、8bit文字圏の連中は
"UNICODE対応すれば国際化終了ぉ～おっけー"
なんて考えているようにしか見えない。
# 違いますよね?
その辺り、Xの開発に関わっているマルチバイト圏内の方の意見も
聞いてみたいです。
Re:UNICODE化 = 国際化? (スコア:1)
それから、大事なのが、どんなエンコーディングをサポートするか、 というのみならず、様々な言語に最低限必要な固有の処理をサポートすること。 たとえば日本語なら XIM などの入力手段は必須ですし、 ターミナルエミュレータなら全角文字もサポートしないといけない。 あと、タイ語だと結合文字が必要だし、中東は右から左への方向が必須。 注意しないといけないのは、これは、その言語を扱おうとすると ぜったいに必要になるということ。その言語をしゃべる一般人全員が 必要とするものです。この絶対的な必要性と比較すると、 「Unicode だけじゃいや、EUC-JP もサポートしてくれ」 なんて要求は、ずっと優先度が低いと思っています。
世界を「8bit文字圏」と「マルチバイト」に二分するような考えかたに立つと、 このへんが見えなくなってしまうおそれがあります。
まあ、ヨーロッパ言語圏においては、 一般人レベルでは、「Unicode にさえすればすべての問題が解決する」と思っている人が多数でしょうね。 それはもちろん、地道に訂正していくしかありません。 「やつらは、ぼくらの言語のことなど何も考えていない」 という非難は、そう簡単に口にできるものではないはずです。 だって、それはそのまま自分に返ってきますから。 たとえば、アラビア人からその非難の言葉を受けずにすむ人って、 そんなにいないと思います。
Re:なにを迷ってるかというと (スコア:0)
近頃はPC-UNIXが手軽に使えるので、学生にはPCマシン渡してPC-UNIXを自分でインストールさせて使わせているのですが、この手の新機能の設定って行
試すには (スコア:2, 参考になる)
すみません、誤解を招く表現をしてしまいました。もちろん、このトピックの主題となっているパッチ [xfree86.org]を xterm にあてることが必要です。こっち [debian.or.jp]からだと、きちんとしたファイルの形でダウンロードできます。
それから、フォントは XFree86 に含まれている、*-iso10646-1 なフォントを指定してください。-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 とか -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 とかだと、対応する全角文字用フォントがあって、それ自動で使用してくれるので、おすすめです。
Li18nux のとの違いって.... (スコア:1)
いまいちよぉわかっていないんですが、 Li18nux の IIIMF Project [li18nux.net] のほうの Xlib_i18n の中の XTerm と、今回の久保田さんの XTerm とは別物なのでしょうか？
オフトピだが、僕がこんなこというのもアレだが、XFree86-4.2.0 って X11R6.4 準拠だと言いながらも xlibi18n がいい加減に porting されていたりしていて、なんかブチ切れそう。実は Vine で ATOKX が使えないくて Turbolinux 8 で使えるというのも、このへんが原因だったりするんですが。 だれか XFree86 のやつに鉄拳パンチくらわせて説教してくれないかなぁ。
Re:Li18nux のとの違いって.... (スコア:4, 興味深い)
ところで、xlibi18n って、Li18nux が作っているもののことでしょうか? X11R6.4 との関係は? ATOKX が使えたり使えなかったりする理由は? そのへんはぼくは全然わかってないので、詳しい説明つきの鉄拳パンチをくだされば歓迎します。
ただし、XFree86 の国際化関係コードがバグだらけかもしれない、ということなら、そのとおりだと思います。というか、ぼくでさえいくつか見つけることができたくらいなのだから。ただし、そのバグは、X.org の配布物にもまったく同じバグがあったように覚えています。たとえばこんなのとか [srad.jp]。
というか、XFree86 にしろ X.org にしろ、ぼくみたいな新参者にしょうもないバグを発見させるなよ、って思うのです。オープンソースは多くの目玉によるピアレビューによってバグが少なくなるだって? 冗談言うな、いままで XFree86 にしろ X.org にしろどれだけの人の目に触れてきたんだよ、って言いたい。
そうなんですか… (スコア:2, 参考になる)
なんかちょっとがっかりしました。
ボランティアなプロジェクトではそうなりがち。
XFree86って、バージョンアップの度に際立った機能があるんだけど、そっちに人的リソースが行ってしまっているのかな？
きちんと国際化したフリーなＸが欲しいです。
（「欲しい」と言うからには… いつか私も手伝えるか？）
Re:Li18nux のとの違いって.... (スコア:1)
（そーいや知り合いでXをhackするって話、聞いたことありません…）
Re:Li18nux のとの違いって.... (スコア:1)
まず訂正一か所させてください。 XX11R6.4 でなく R6.6 がきっちり porting されていないというところが問題点でした。 というのも、Sunから提供された IM まわりのコードがきちっとポーティングされていなかったために、htt_xbe からの入力ができなかったのです。
いちおう、バニラなXFree86-4.2.0では iiimf での入力ができませんが、こいつに Li18nux の Xlib-i18n から xc/lib/X11/xlibi18n/ 以下のコードをコピペしたら iiiimf が使えるようになります。 この原因が UTF8 が Utf8 になっていたためなのか ximcp40 が収録されていなかったためなのが、そこまで追い掛けていなかったため、現在でも不明なのです。 時間があったら追い掛けたいところなのです。
今考えると、iiimfでテストできる環境が少ないために、この問題に気付かなかっただけなのかもしれないと思っていたりもします。
Re:Li18nux のとの違いって.... (スコア:1)
と言いつつも、ぼく自身は X の仕様を読んだことがないのですが、 そこまで原因を追いつめることができてらっしゃるのでしたら (って、ぼくは不勉強のため意味がよく分かっていないのですが)、 しかるべきところにバグ報告するか、 あるいは、そのような時間がとれないのでしたら、 だれかがその作業を代わって続けられるように、 どのようなバグなのかを具体的に説明してもらえたら、と思うのです。 (説明してもらえても、 すみませんが、ぼくがその作業を引き継ぐとは約束はできませんが)。
ちなみに、i18n@xfree86 メーリングリストでは、 IIIMF どころか、XIM のテストができる人もほとんどいません。 (というか、ぼく自身も IIIMF のテストはできません。 だいぶ前に IIIMF のソースをダウンロードして試したことがあるのですが、 コンパイルすら通らなくて。たぶん改善されているだろうから、 時間があればまた試してみたいとは思っています。ちなみに、 Yudit [yudit.org] 作者の Gaspar Shinai さんも IIIMF には興味を持っているようです。 Li18nux の人々はたぶん XFree86 を見捨ててしまっているっぽいので、 それ以外の人々が IIIMF とかに興味を持ってくれるのは貴重なことです)。
コード・レビューについて。 (スコア:0)
ですが、定常的にレビューする側の役割のひとは、基本的に
人間lint以上のことはしてくれません。これによって改善する
のは、メモリーリークを未然に防ぐことやインデントをきれいに
つけることくらいではないかと‥。
コードを書いている立場から
Re:コード・レビューについて。 (スコア:0)
コードレビューできる部分が一部に偏ってしまうのはしょうがないかと
ちゃんとレビューできているのなら Xutf8 が入る時醜い事には
ならなかっただろうし
Xutf8 (スコア:1)
ただし、ぼくがみつけた XFree86 のバグは、 X.org 配布物由来のものです (ので、こちらは 見てないですが、Li18nux のコードにも同じバグがあるかも)。 ということは、X.org のコードチェック体制も似たようなもの、 ということなのでしょうか?
いずれにせよ、libX11 ってでかすぎてとても読めたものじゃないです。 チェックがいいかげんになるのも、うなずけてしまいます。
X11R6 の locale (スコア:0)
X11R6 になってからつい最近まで X コンソーシアムの方は
活発ではなかったからちゃんとレビューされなかったのは
しょうがなかったのかも
Xlib_i18n っていまどうなっているの? (スコア:0)
そちらの現状がわからないので
XFree86-4.2 と Xlib_i18n の現状を比較している文書とかないですかね
li18nux はいまでも cvs で checkout するしか方法がない?
これは (スコア:1)
Re:これは (スコア:0)
こんなんでまともな国際化ができるのか?
ダメでなくてもいい (スコア:3, すばらしい洞察)
日本語が使えるターミナルエミュレータは、 Rxvt [rxvt.org]、 Eterm [eterm.org]、 aterm [sourceforge.net]、 などなど、いっぱいあります。国際化されたターミナルエミュレータは、 kterm、 mlterm [sourceforge.net] くらいが思いつきます。exterm も含めて、好きなものを使えばいいと思います。
ただし、「exterm があるんだから、ほかのはいらないじゃん」という考え方には、反対です。Eterm は派手な GUI を特徴とするし、aterm は半透明機能があります。mlterm だって独自機能満載ですし、それぞれに存在意義があります。
国際化は「あたりまえ」の時代になってほしいと思っています。自分の好みのソフトウェア選ぶ、という、かつてはヨーロッパ言語圏に住む人だけの特権だった行為を、われわれもできるようになりたい。そういうふうに思っているのです。
Re:ダメでなくてもいい (スコア:0)
個人的にはextermとwr_WR.ctで十分かと思ってました。
XIMが使えないのか。それはヤヴァイな。(藁
exterm がダメな理由 (スコア:2, 参考になる)
xterm? (スコア:1)
おそらく X.Org の方にあれが import されることはないので(されるとすれば Li18nux の方)、
xfterm とかいう名前にしてくれたほうが、混乱が少なくてうれしいんだが…
国際化？ (スコア:0)
＃luit は入力は国際化されてはいるのだろうけど、出力をエンコードを固定してる
mlterm/kterm も独自に locale かかえるのと同じで現代的な posix locale
モデルに沿ってないので、国際化というよりは、地域化のお化け。
＃もちろん、これが悪いわけではない。
exterm はこの観点から行くと国際化されてるけど、
おそらくXIM も ximp もない時代で wnn のコードが混じってる。
現時点でまともに動く、国際化されたと言える
ターミナルエミュレータは Li18nux の xterm しかないのでは？
＃まぁ、これも BiDi は出来てないですけど。
国際化という言葉の定義? (スコア:1)
ですので、上記コメントは (少なくともその部分については) 事実としては正しいですが、その事実に言及することがどういう意味を 持つのか (持たせたいのか)、ということが、上記コメントでは明らかにされていません。 つまり、「国際化」という言葉をどう定義し、それにどんな価値を見出すのか、 ということです。
コメントの意図が分からないので、それに対する返答もできません。