国際化された XTerm を目指して 32
これは使えるかも 部門より
kubota 曰く，"XFree86 の i18n メーリングリストに流れていた記事だが、luit が XFree86 の CVS ツリーに統合されたらしい。 luit とは、tty にかぶせて Unicode とその他のエンコーディングの変換をするプログラムで、たとえば UTF-8 XTerm に luit を (EUC-JP モードで) かぶせるとあら不思議、EUC-JP XTerm に早変わり、というもの。
将来的には XFree86 XTerm をいじり、XTerm から直接 luit を起動するようにしようと考えているようだ (ただし、上記の記事にあるように、少なくとも XFree86 4.3.0 以降になる) (このメールの safe sex 云々の箇所参照)。ぼくも一時 XTerm の改良に凝った時期もあったが、関係者の意見の相違が大きすぎ、採用してもらうところまでこぎつけることができなかった。
luit は、それほどたくさんのエンコーディングをサポートしているわけではないことの注意。また、luit を使って実現した EUC-JP XTerm は、全角と半角が、日本人がふだん親しんできたものとは異なってしまい、curses ベースのソフトウェアがうまく動かない。このへんについては、文字幅を指定するエスケープシーケンスを導入するという提案 (英文かつ長文注意。ぼくもきちんと読んでいない) がなされているが、本当に使いものになるのかどうかは未知数だ。
などなど、問題はあるが、活発な XFree86 メンバー (つまり、自分で作ったものを将来にわたってメンテしていく意思がある人) からこういったものが出てきた意義は大きい。今後、これがどうブラッシュアップされていくか、それとも根本的欠陥が見付かってぽしゃってしまうのか、少なくともここに挙げたような問題がどう解決されるのか、見守っていきたい。"
こういうものを待っていた。まさに今、ソースコードを取得して評価中。使い物になるかというのもそうだが、改良の余地があれば積極的にコミットしていくというアクションも必要であろう。かくいうオレも、可能な限りコミットしていければ…
問題点について解説 (スコア:2, 参考になる)
ここで述べている文字幅問題は、何度か紹介してきた、こちらで述べている問題 (日本語版を用意しました:-) とは違います。それ以前の問題です。
XFree86 の XTerm の UTF-8 モードは、Unicode Standard Annex #11 East Asian Width で「EastAsiamAmbiguous」に分類されている文字を、1 カラム (半角) 扱いします。そして、JIS X 0208 に含まれる多くの文字が (文字の多くが、ではない!)、EastAsianAmbiguous に分類される Unicode 文字にマッピングされます。それには、ロシア文字、ギリシア文字、●や★などの記号、が含まれます。
つまり、luit を使った EUC-JP XTerm は、現状では、ロシア文字、ギリシア文字、東アジアローカルな記号以外のほとんどの記号類を、半角で表示してしまいます。
Re:問題点について解説 (スコア:2, 興味深い)
昔懐かし日本語 EUCでは (いや，日本語だけではなく中国語等でもそうですが) 「G0, G1, G2 及び G3 の，各 G バッファ毎に文字の幅が一意に決定される」という，暗黙の前提があって， それを前提に多くのプログラムが書かれていたわけです．しかし，それはそれで一種の文字コード依存 (Code Set Dependence) ではあるわけで， そういうのを前提にしてプログラムを書いていた人は， Unicode べったりにプログラムを書く人を責められませんね．
でも， 文字コードのもつ性質に依存しない (Code Set Independence, CSI) ようにプログラムを書くのは， 移植性を考慮してプログラムを書くのと同じで， なかなか一朝一夕にできるものではありません． 移植性は，各種の OS やライブラリやコンパイラの 違いを知った上でなければ 考慮しろと言われてもできるものではないのですが， CSI による国際化は，各種文字コード，言語，習慣等の違いに対する移植性を考慮しろと言われるようなもので，こんどはそれらがどれくらい変わり得るかを知らなければならないわけですから．
たとえば，日本語 EUC や シフト JIS や Big5 や UTF-8 では， 「複数バイトの文字は，文字の1バイト目を見れば， その文字が残り何バイトあるかがわかる」 という性質があったわけですが，これが中国の新しい文字コードである GB18030 では成立しません． (GB18030 では，2バイト目まで見ればわかる．) いままで，それを想定していたプログラムはみんな書き直しになります．
それ以前にも，たとえば， 「文字のバイト数と画面上の表示カラム数は一致する」 という想定が破られたりしたことがありますね． (この想定は，シフト JIS では成立するが，日本語 EUC では成立しない．) どうもこの世界では，都合のいい想定は必ずいつかは破られることになっているらしい．
これに気付いたのは (スコア:1)
車輪の再発明? (スコア:2, 興味深い)
R6では色々政治的な(?)理由でR5の国際化機能が削られてしまい、 代りに貧弱な地域化機能が入ったわけですが、 現在のこうした涙ぐましい努力を見るにつけ、 車輪の再発明を強いられる事への口惜しさを感じます。
X11R5については当時早稲田大学の片岡氏による更なるm17n拡張も行われました。 実際、当時の早稲田大学ではdefaultの端末をktermでなくextermにしているユーザは多かったですし、 多言語混在のテキストを編集するには、muleよりもxeditの方が便利だったりしたほどです。
現在片岡氏とその成果がどうなっているのかは寡聞にして知りません。 早稲田で配布されていた国際化拡張X11バイナリキットもすでにftpから消えているようです。その後のプロジェクトについても、
に、かつての残滓が見られる程度のようです。 (リンクに許可がいるらしいので<a>は入れません。)「ちゃんとした」国際化の後を継ぐプロジェクトは現れないものでしょうか。 (「おまえがやれ」って? 御説ごもっとも。 まずは世界の言語表記を勉強するとこから始めないといけないのかな。 道は遠く険しいなあ。)
Re:車輪の再発明? (スコア:1)
それは、フリー (自由) ソフトウェアでしょうか、あるいはオープンソースの定義に合致するのでしょうか? System1 は、ウェブページ上のスクリーンショットを見る限りではすごそうですが、ダウンロードの項目がないですし。見た感じけっこうよさげなので、もしそれが本当に世界中のどの ftp サイトにも残ってないとすれば、それはどういうことでしょうか? もしかしてフリーじゃなくて配布が制限されていたからどこにも残ってないとか? (バイナリキットが、なんて話をされているところからすると、フリーじゃないどころか、ソース公開さえされていなかったのでしょうか)
exterm というのは、名前を聞いたことはありますが、どんなものなんでしょうか。X11R5 の、ということは、標準的な X11R5 の機能だけしか使ってないってことですよね。それだとコンパイルも楽ちんっぽいのでいちど試してみたいですが、もしかして、これもフリーじゃないとか?
Re:車輪の再発明? (スコア:0)
exterm は X11R5 の contrib に入ってたと記憶。 現在の Kterm と同程度の機能だったかと。 当時の Kterm は日本語用エンコードしか扱えなかった かと思います。
Re: 文字の幅 (スコア:0)
素のX11R5/contribのextermはそんなもんだったかな。
System-1は知らないけど、その前のもそっとオープンだった版試した時点では、 XLOCALE, Xlib以下にも手が入ってて、 extermのチューンだけでなく、他の多くのclientも国際化されてた。 動かないのもいくつかあったけど。
ソースもあった気がするが、 手が入りすぎてて常人にはmake World不可能とか言われた。
fork (スコア:1)
System1 が X11 から fork した時点で、あるいは、exterm が xterm から fork した時点で、fork しっぱなしだといずれ消えてしまう、とは思わなかったのかな。あるいは、当初は自分がずーっと (X.org や XFree86 のアクティビティに負けないくらい活発に) メンテしつづけるつもりだった (から fork しっぱなしでも十分に勢力を保ってられると思っていた) としても、もしかしたらメンテしつづけることができないと思った時点で、本家 X11 や xterm に統合しようとする努力がなされなかったのだろうか。
あるいは、System1 や exterm のユーザ層のなかから、本家への統合作業を買って出る人が出なかったのはなぜでしょう。ユーザ層が小さかったから? 常人には理解不能なソースだったから? アナタ作る人、ワタシ使う人、というような文化が蔓延していたから? 一子相伝の伽藍方式が信じられていたから? ぼくはその当時の事を知らないので、わかりません。
どちらにせよ、今となってはもう exterm が再びメジャーになる望みはないのではないでしょうか。本家への統合作業をしなければ、本家よりも高いアクティビティと知名度を維持できなければ負けるのは必然です。
過去を悔やんだり、過去の人を責めても得るものはないです。が、過去に学ばない人は同じ過ちを繰り返すかもしれません。
というわけで、過去を知る人に聞きたいのですが、なぜ System1 や exterm はすたれてしまったのでしょうか。
Re:fork (スコア:0)
extermが何故消えたのかは分かりませんが、 System1に関して言えば、 むしろX Consortiumに統合されたくないという思いもあったのかも。
聞くところによると片岡氏は元々MITにいて、 Xを作ったプロジェクト（Athena Projectでしたっけ？）に所属しており、 多いに貢献していたとのことです。 誤解を恐れずに言えばacademismが髭を生やして歩いているような人だそうですが、 XがMITの手を離れ、X Consortiumがcommercialismに傾いていったことを嘆いておられたそうで、もしかすると反目もあったのかもしれません。
個人的には、何もX Window Systemが
Re:fork (スコア:1)
片岡氏がどういう考えで System 1 を作られ， それが今どういう状態にあるのかも知りませんが． (元記事の方も伝聞と想像だけで， その辺りはご存じないようですし．)
理想の多言語システムを作ろうというのは 結構なことではありますが， そういうことを考えられる方はたいてい 言語処理の専門家で，世の中にそれ以外の人がいるということを 往々にしてお忘れのように思います． その他大勢の人に使ってもらえなければ， どんなすごいシステムを作っても虚しいだけですよ． 「実用的」という言葉にはそういう意味も含まれる と思うのですがね．
Re:車輪の再発明? (スコア:0)
exterm を Linux(XFree86 4.0.x) でコンパイルしようとしたことありますが、
IM関係が wnn に依存していてコンパイル出来ませんでした。
XIM関係が整備されてなかった時代でしょうか？
内部は wchar_t で処理されていましたね。
X11R5とX11R6のXIMとwchar_t (スコア:0)
XIMはX11R6で登場しました。X11R5には有りません。 このあたり [kyoto-inet.or.jp]に簡単な解説がありますね。
また、X11R5を使った環境では一口にwchar_tと言っても、一意に定まりません。 X11R5ではXsiなどの国際化により、X自身がlocale機能も持っていました。 このため、XとOSとでwchar_tの定義が違う場合があり、 知らないと混乱させられることになったものでした。
Xのインストールにしても、 XLOCALEを有効にするかどうか、Xsiを使うかXimpを使うか、等々、 国際化に関しては環境構築時に選択しなくてはならない要素が多々ありました。 そして、一度選択したら以降統
IBMのプロジェクトとは，また別なのかな。 (スコア:1)
Linux World ExpoのIBMのブースで研究員らしき方から説明を受けた記憶があります。
Re:IBMのプロジェクトとは，また別なのかな。 (スコア:1)
リンクするなら，そこじゃなくて こちらです．
ちょっとどころか，全くアプローチが違います． XFree86 のは， 「処理は Unicode べったりハードコーディング (この場合 xterm 自身)． 必要ならば外に出すときにコード変換 (それをするのが luit)」 なのに対して，IBM 版は， 「ロケールに合わせて動く CSI (Code Set Independent) アプローチ」 ですから，正反対の思想で作られているわけです．
Re:IBMのプロジェクトとは，また別なのかな。 (スコア:1)
IBM といえば、こんなのがありますね。あまり試したことがないのですが。これについては、最近、Bruno Haible さんが、GNU textutils について、パッチを送ったのになかなか取り込んでもらえないと嘆いていました。bash と readline だけ試したことがありますが、すごく重かったです。キーのオートリピートの速度に追いつかない。
あと、Li18nux による こんなパッチもあります。試してみたけどなかなかうまく動かなかった記憶があります。
まあ、乱立状態ではありますが、競い合って互いにいいものを目指してもらえれば、と思ってます。
Re:IBMのプロジェクトとは，また別なのかな。 (スコア:0)
これどのぐらいの早さの計算機のどのOSの話でしょうか？
普段、使ってますが重すぎて使えないなんてことはないですが…
とりあえず、Pentium 200 の Solaris に
readline library & bash (スコア:1)
Celeron 300 です。そのころはたしか Linux 2.0.なんとか、だったと思います。ずいぶん前のことなので、bash のバージョンとかも分かりません。もしかしたら、デバッグオプションつきでコンパイルしてたとかかもしれません。
キーリピートの速さの設定によっても違うのでしょうが、ぼくは設定のしかたを知らないので、デフォルトというのがもしあるなら、デフォルトのままです。その状態で、ずーっとキーを押しつづけると、そのうち、入力される文字が追いつかなくなり、キーを離してもしばらく入力されつづけるようになります。
通常の bash ではそんなことはありませんでした。
Re:readline library & bash (スコア:0)
私がPenII の300(Linux 2.4.x)で試した限りでは、問題なかったです。
bash(とパッチ)のバージョンにもよるのかな？
確かに、キーリピートの設定やコンパイルオプション等もあるかもしれませんね。
> 通常の bash ではそんなことはありませんでした。
確かに、通常の bash では出ませんでした。
まぁ、通常の bash(readline) は multibyte
文字の幅 (スコア:0)
ではないんですかね。従来の US-ASCII:JIS X 0208 =
1:2 が欲しいなら、そういうフォントを使えばいいの
では…
従来の文字幅が欲しいなら kterm を使えばいいわけだし、
どうでもいいじゃないですか。
Re:文字の幅 (スコア:1)
フォントだけでは決まりません。XFree86 XTerm の実装では、半角用フォントと全角用フォントのふたつを用意して、文字ごとにどちらかを使うというふうになっています。
文字幅が重要なのは、たとえば tcsh の漢字サポート版では、漢字を入力した後に BS キーや ← キーを押すと、2 文字分のカーソル移動コントロールコードが出力され、kterm や rxvt などの動作とマッチするようになっています。つまり、すべてのプログラムで統一した解釈になっている必要があります。
もし現在のその統一された動作が変だから変更しようというのなら、世界中のプログラムをそのように書き換える必要があります。しかも「移行期」を設けることはできません。一晩で完全に移行してしまう必要があります。ぼくにはそれを実現するだけの政治力はないですし、仮にあったとしても、人々を混乱に陥れるだけの大義名分がありません。
ただ、文字幅に関するデファクトスタンダードを持っているのも、それを変更する（とすれば）コストを払う羽目になるのも、東アジア人です。そのことについて無知な欧米人が、「文字幅に関するスタンダードを（従来はなかったので）新しく作るのだ」と称して勝手なことをされては困る（彼らは困らない。われわれだけが困る。しかも彼らはわれわれが困っていることに無知でいられる）ので、この点はきちっと押さえておく必要があると思うのです。コントロールコード 0x08 と倍幅文字の関係については、Markus Kuhn の説得に成功したので、まあ一安心です。
そして、これがほんとうにきちんと動作するためには、個々の文字について、どれが半角でどれが全角、ということが決まってないといけません。日本においても規格は存在しないですが、PC-8801 の時代から、JIS X 0208 文字を (NEC 独自規格の 2 バイト半角文字を除き) 半角で表示する実装は、ぼくは知りません。
kterm を使えばいいというのはその通りかもしれませんが、国や言語ごとに別のソフトウェアを使うのはもうやめよう、というのが国際化の流れなわけですし。実際、国や言語ごとに別々のソフトウェアをメンテできるほど、オープンソースの世界は人材豊富ではありません。
Re:文字の幅 (スコア:1)
たしかに，readline や curses 等その他多数のプログラムを直すより，xterm ひとつ直す方が楽なのは事実ですが…． でも，その多くのプログラムは，結局「EUC-JP の G1 の 文字はみんな2カラムだ」みたいな前提を置いて動いているわけで，そういうプログラムは UTF-8 対応するときに そういう前提を捨てざるを得ないわけだから，今のうちにそれをやってしまって，「現在の xterm + luit でも 動くようにする」のはいかがなものでしょうか．それとも，なにがなんでもポンド記号「￡」は全角でないといや? UTF-8 になっても?
移行期間はどうするか? もちろん kterm を使えばいいんですよ．UTF-8 なんか使いたくない? それこそ，kterm を使い続ければいいんですよ．
Re:文字の幅 (スコア:1)
なんか意図が伝わらなさそうな書き方をしてしまったので補足します．
日本の既存のプログラムを修正しないで動作させようとすれば，既存のプログラムが想定していた前提条件を満足してやる必要があります．そのためには，たとえば，ポンド記号「￡」は「全角」でなければなりません．しかし，それは日本の既存プログラムの都合であって，たとえば英国に行けば，日本でポンド記号が使われていたのとは比較にならない規模でポンド記号が使われているわけで，しかも，もちろんそれは「全角」ではありません．そこで，英国の既存のプログラムを修正しないで動作させようとすれば，逆にポンド記号「£」は「全角」であってはならないことになります．
でも，お互いそれは，既存のプログラムがそうなっているという勝手な都合に過ぎないわけで，どちらかを相手に押し付けて済ませるのが正しい解決ではないでしょう．(いや，どちらかと言えば，外国人である日本人が，英国人の文字であるポンド記号に対して強く主張しても受け入れられないでしょうけれど．もちろん，ポンド記号以外にも問題になる文字はあって，それぞれの文字によって関係者の顔ぶれが変わります．)
一方で，既存のプログラムを手を入れることなく使い続けたいという要求は確実にあるわけで，そのために，xterm に互換モードを設けて，既存プログラムを救済するということは可能でしょう．
既存プログラムの救済手段としてある文字が「全角」であるべきかどうかということと， UTF-8 対応の多言語端末プログラムとして xterm がある文字を「全角」で表示すべきかどうかということとは，別の問題として考えた方がいいと思うのですが， 前者の面ばかり強調されるようだったので， 上のように書いたのです． (もちろん，後者の環境で動作するプログラムは，必要に応じてそれなりに修正するわけです．日本のプログラムだけじゃなくて，世界中のプログラムをね．)
Re:文字の幅 (スコア:1)
XTerm に互換モードを設けて、というのは、UTF-8 で使うのであれば、そういう方法がいいと思います。デフォルトはポンド記号は半角にすべきです。UTF-8 は世界のどこでも使われる予定であり、世界の大部分 (CJK を除く) ではポンド記号は半角だったのですから (CJK な人々は修正を迫られるか互換モードを使うことになります)。現状の XTerm では、デフォルトの動作はそうなっていますが、互換モードは存在しません。というか、デフォルトしかありません。
で、将来、XTerm で EUC-JP などが使えるようになったときにどうするかですが、ポンド記号を半角にして EUC-JP を使ってきた人はいません。EUC-JP でポンド記号を使うときは必ず (世界のどこでも) 全角だったので、ポンド記号が全角になるほうがデフォルトになるべきです。こちらの場合は UTF-8 の場合とは異なり、修正を迫られる人は世界のどこにも存在しません。
Re:文字の幅 (スコア:0)
素朴な疑問。
UNIX統一仕様の一部である端末制御仕様の X/Open Curses では多カラム文字のための処理が定義されていて、 そこでは明らかに、locale DB によるカラム数情報を参照 することが意識されてるんだけど、そういった情報と 連動させるとかそういった話はないのかしらん?
特定の文字が端末において何カラムになるかというのは、 ロケール情報の一部であり、UNIX標準では wcwidth(3) で取得可能です。
まっとうな実装なら、端末も Locale 対応にして、 幅設定するには Locale DB を改変して
Re:文字の幅 (スコア:1)
はい。wcwidth(3) は知ってます。実際、 Robert Brady さんパッチを改良したぼくのパッチでは、wcwidth(3) を使っています。
これの最初の「不具合」は、 「en_US.UTF-8 ロケールでは wcwidth(3) の定義がいいかげんなので 自前でデータベースを持ったほうがいい」というもので、 そんなの、ロケール定義を実装すればしまいだろ、とか 思ったものです。が、それは無視するとしても、 wcwidth(3) そのものが移植性に乏しいとか (BSD なみなさん、がんばってください)、 リモート環境ではうまくいかないとかの問題が指摘されています。 ですので、 wcwidth(3) が正しく動くことは必要なことではありますが、 だからといってロケール定義を好き勝手にしてもきちんと動くという わけではないです。 ぼくはそれでも、リモートでない場合とか、自分で分かっててやるぶんには かまわないだろうと思うのですが...
あと、この XTerm に固有の問題ですが、 wcwidth(3) は wchar_t を引数にとる一方、 XTerm は内部コードとして Unicode を採用しているために 変換が必要になる、という問題があります。 Unicode とワイド文字の間の変換を、 移植性よく、効率よく書くにはどうすればいいのでしょうか? いちおう、上記のぼくのパッチには、それらしきコードが書いてありますが。 XTerm + luit のアプローチだと、XTerm そのものは エンコーディング変換を一切やらない建前だし (そうすることで XTerm 本体の保守性を保つのだとか。ぼくがメンテするのではないので、 そう言われると反論しにくい)、かといって luit はロケールを使わずに ISO-2022 をそのまま解釈する構造になっていて、 やはりワイド文字とかマルチバイト文字とかとはなじみが悪いです。 というわけで、wcwidth(3) に基づいた文字幅を実現するのは このままではなかなか難しそうです。
ところで、合成文字や bidi の場合は、wcwidth(3) はどのように動作すべきと 定められているのでしょうか?
Re:文字の幅 (スコア:1)
Single UNIX Specification では，wcwidth() は，ヌル文字 L'\0' の場合 0，非表示文字の場合 -1, その他の場合は文字幅を示す整数値を返すことになっています．BIDI や合成文字についての言及はありません．
もともと wcwidth() や，その導入の元になった column position (桁位置) という概念自体が，POSIX.2 の一部のユーティリティ (fold とか pr -w とか ls -C とか vi とか) にある「文字の桁幅」を意識した処理のためで，その定義も「ある行の中のある文字の桁位置は，その行の中で，その文字の前にある文字の桁幅の合計に 1 を加えたものと定義する」というくらいしか書いてなくて， 行の途中で文字の進行方向が変わったり， 他の文字と合成されて表示されるような文字があったりする場合は全く考慮されていません．
Re:文字の幅 (スコア:1)
ワイド文字のエンコーディングには××を使わなければならない，といった標準はないので (__STDC_ISO_10646__ が定義されていれば別ですが)， 完全な移植性を求めるなら， 「いったん mbtowc() でマルチバイト文字に変換してから Unicode に直す」 しかありません．で，それは決して「効率よく」はない．
昔々，EUC が AT&T UNIX Pacific で規定された (厳密に言えば日本語 UNIX 諮問委員会の案を一般化しただけですが) ときには，マルチバイト文字とワイド文字との間の関係は完全に明文化されていたけれど，それは ISO/IEC 2022 の枠組みを強烈に意識していたので，その枠に収まらない Shift_JIS や Big5 での実現を排除してしまうことになり，それが標準になることもなかった．(実際 UNIX Pacific も， wchar_t を16ビットから32ビットにしたときに，ワイド文字の内部形式の互換はとらなかった．)
たとえば，HP-UX では EUC-JP も Shift_JIS も 両方サポートしていたけれど，ワイド文字の形式は UNIX Pacific 方式とは違っていて，しかも， たとえ同じ文字でも エンコーディングが違えばワイド文字の表現まで 変わってしまうのでびっくりしたことがあります． Solaris では一応 EUC-JP と Shift_JIS とでは 同じ文字のワイド文字表現は同じにしていましたが， UTF-8 になるとワイド文字が UCS-4 になってしまった ので，そういう意味での互換性はなくなりました．
ワイド文字が Unicode であることを明文化している システム (Windows NT の UCS-2 と glibc 2.2 の UCS-4) もありますし，たとえばマルチバイト文字の エンコーディングが UTF-8 の場合，wchar_t が32ビットなら，その内部表現が UCS-4 になるのが一番自然でしょうが，その想定が必ず正しいという保証はありません．たとえば，UTF-16 の範囲の文字しか使わないと思えば，上のビットが何ビットか余っていることになるので，それを別の用途に使いたいと思う人がいるかもしれません． (もっとも， Markus は wchar_t が Unicode でない実装を否定したいようですがね．)
Re: 文字の幅 (スコア:0)
これってDevanagariやThaiの扱いはどうなるんでしょ？
どんな仕様を提案するにしても、今日本人が欧米人に対して言うように、 後で「無知な日本人めっ」とか言われることになったら悲しいよね。
Re: 文字の幅 (スコア:1)
端末エミュレーターに限って言えば， 一文字が一定幅か，その整数倍の幅をもつという前提が (近似的にでも) 成り立たない文字に 適用するのはかなり困難でしょう． Devanagari や Thai がどうかは知らないので， なんとも言いかねます．
インド人やタイ人だってコンピューターを 使っているわけですから，勝手な思い込みで決めつけず，謙虚に意見を聞けばいいのです． 何にも知らないくせに， 「これなら世界中の文字に対応できる」とか， 「どうせ××文字なんて使うやつは少ないから， 後回しでいいんだ」とか， 偉そうに主張するのが一番嫌われる．
日本人なんておとなしいものですよ． なんせ，「これでは日本語が通らない」としか言わないのだから．
Re: 文字の幅 (スコア:1)
タイは、TIS620 というエンコーディングが使われており、結合文字が必須です。おそらくタイ人自身による実装である xiterm+thai というのが Debian では利用可能です。XTerm も UTF-8 モードではかなり前から結合文字の使用が可能です。これはタイ人じゃなくて Robert Brady さんという人の仕事です。ちなみに XTerm で全角文字が使えるようになったのも、この人のおかげです。
すみませんが、インドのことについては知りません。
「これでは日本語が通らない」としか言わないかというと、そうでもなくて、ASCII と CJK に対応したものを作って「国際化ができた」とか言うことがよくあります。
Re: 文字の幅 (スコア:1)
これは一本取られましたね． 「良くも悪くも，日本語のことしか考えていない」 という方が近いかな．
遠い外国の事情はわからないことが多いので， 「とりあえず日本語は通ります」といって出すのが いいのかもしれません．他の国の人が試して， 問題があれば直してくれるかもしれませんから．
日本語「も」使えます (スコア:1)
それでしたら、問題があるかどうか試してほしいという意思表示が必要だと思います。「とりあえず日本語は通ります」という言い方だと、「ああ、あれは日本語専用だからわれわれには関係ない」と思ってほっとかれるおそれがあります。
ぼくは、誇大広告になるのを覚悟で、「マルチバイト文字に対応するように改良した。CJK はマルチバイトが必要だし、将来 Unicode を使いたくなったら Unicode もマルチバイトだからこのパッチが役立つ。従来の 8 ビットエンコーディングには悪影響を与えないはずだからこのパッチを採用してくれ」とかいうふうに言うことにしています。