アカウント名:
パスワード:
l10nは死んだ、次はm17nだ 部門より
九割九分はそうなんですが、一部には、i18n 的抽象化にそぐわないものもあります。すっかり Emacs + Wnn に慣れたこの体ではありますが、ときたま、「カスタムされた秀丸は作業効率が高かったなあ」とか、「カスタムされた WXII は体の一部のように動いてくれたもんだったなあ」とか回想モードに入ります(遠い目)。日本語禁則処理とかも、きめ細かかったしね。
<オフトピ>XZ エディタってどうしちゃったんですか?</オフトピ>
とはいっても、昔ながらの l10n 的手法に基くソフトウェアの多くが現に死んでいます。kterm、canna など、もう誰もメンテしていませんし。残念ながら、それらのソフトウェアをメンテナンスする人材を輩出するユーザベースとして、日本は小さすぎるのではないでしょうか。
ではそれらをメンテすればいいかというと、別の問題が出てきます。ローカルパッチは本家に認知されていないので、本家の側で、ローカルパッチのやりかたに反するような改良が加えられる可能性があります。それを防ぐためには、ローカルパッチの側が十分な存在感を本家に示す必要がありますが、各国・各言語ごとに存在しうるローカルパッチがそれぞれ同じように十分な存在感を示そうと活動するさまは、単なる勢力抗争であり、世界中の人が幸せになれる道ではありません。
もとからローカルなソフトウェアとして開発されるものも多くあります。たとえば漢字変換などです。そういう分野では、まだまだ当分、l10n 的なアプローチが続くことでしょう。ですので、WXII をなつかしまないといけないのは、単に WXII だけの問題で、l10n 対 i18n のせいではありません。漢字変換ソフトウェアに対して要望があれば、Project HEKE [kmc.gr.jp] や SKK オープンラボ [ring.gr.jp]など、現在活動中のプロジェクトがありますので、 そちらに言ってみるのはいかがでしょうか。
また、i18n の別の利点として、日本語サポートなどという、ある意味、できてあたりまえの基礎の基礎の部分に日本人開発者のマンパワーをとられなくてもよくなるので、その分、もっと生産的で面白いところにマンパワーをまわすことができるようになります。 w3m-m17n の坂本さんのがんばれ和製オープンソースソフト [biglobe.ne.jp] に、そういったことが書かれています。
一方、m17n にも問題がないわけではありません。 mlterm、yudit、mule といった m17n なソフトウェアは、 世界中の開発者のごく一部を占める有能かつ m17n を 自らの中心的興味としている開発者たちによって、 力技によって世界中の言語や文字をサポートする というアプローチで作られています。いまはこの方法でいいにしても、 いずれはこの方法は破綻するのは目に見えています。なぜなら、 このアプローチに基く限り、 世界中のゴマンとあるソフトウェアのうち、ほんの数個だけしか 使えるソフトウェアがない、という状況はいつまでたっても 改善されえないですし、その一部の開発者が興味や時間を失ったり すると、もう途絶えてしまいます。一方、単に扱える文字数を増やしたり、 ワイド文字やマルチバイト文字やユニコードに対応したりしただけの ソフトウェアは、世界中の人々にとって必ずしも使いやすいとは 限りません。ですのでいずれは、 誰もが簡単に m17n ソフトウェアを作れるような環境 (ライブラリ?) が必要になってくるのだろうと思います。 (Qt とか Pango とかって、こういうのにあたるのでしょうか?)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
i18n 至上主義に「?」 (スコア:2, 参考になる)
九割九分はそうなんですが、一部には、i18n 的抽象化にそぐわないものもあります。すっかり Emacs + Wnn に慣れたこの体ではありますが、ときたま、「カスタムされた秀丸は作業効率が高かったなあ」とか、「カスタムされた WXII は体の一部のように動いてくれたもんだったなあ」とか回想モードに入ります(遠い目)。日本語禁則処理とかも、きめ細かかったしね。
<オフトピ>XZ エディタってどうしちゃったんですか?</オフトピ>
Re:i18n 至上主義に「?」 (スコア:4, すばらしい洞察)
とはいっても、昔ながらの l10n 的手法に基くソフトウェアの多くが現に死んでいます。kterm、canna など、もう誰もメンテしていませんし。残念ながら、それらのソフトウェアをメンテナンスする人材を輩出するユーザベースとして、日本は小さすぎるのではないでしょうか。
ではそれらをメンテすればいいかというと、別の問題が出てきます。ローカルパッチは本家に認知されていないので、本家の側で、ローカルパッチのやりかたに反するような改良が加えられる可能性があります。それを防ぐためには、ローカルパッチの側が十分な存在感を本家に示す必要がありますが、各国・各言語ごとに存在しうるローカルパッチがそれぞれ同じように十分な存在感を示そうと活動するさまは、単なる勢力抗争であり、世界中の人が幸せになれる道ではありません。
もとからローカルなソフトウェアとして開発されるものも多くあります。たとえば漢字変換などです。そういう分野では、まだまだ当分、l10n 的なアプローチが続くことでしょう。ですので、WXII をなつかしまないといけないのは、単に WXII だけの問題で、l10n 対 i18n のせいではありません。漢字変換ソフトウェアに対して要望があれば、Project HEKE [kmc.gr.jp] や SKK オープンラボ [ring.gr.jp]など、現在活動中のプロジェクトがありますので、 そちらに言ってみるのはいかがでしょうか。
また、i18n の別の利点として、日本語サポートなどという、ある意味、できてあたりまえの基礎の基礎の部分に日本人開発者のマンパワーをとられなくてもよくなるので、その分、もっと生産的で面白いところにマンパワーをまわすことができるようになります。 w3m-m17n の坂本さんのがんばれ和製オープンソースソフト [biglobe.ne.jp] に、そういったことが書かれています。
一方、m17n にも問題がないわけではありません。 mlterm、yudit、mule といった m17n なソフトウェアは、 世界中の開発者のごく一部を占める有能かつ m17n を 自らの中心的興味としている開発者たちによって、 力技によって世界中の言語や文字をサポートする というアプローチで作られています。いまはこの方法でいいにしても、 いずれはこの方法は破綻するのは目に見えています。なぜなら、 このアプローチに基く限り、 世界中のゴマンとあるソフトウェアのうち、ほんの数個だけしか 使えるソフトウェアがない、という状況はいつまでたっても 改善されえないですし、その一部の開発者が興味や時間を失ったり すると、もう途絶えてしまいます。一方、単に扱える文字数を増やしたり、 ワイド文字やマルチバイト文字やユニコードに対応したりしただけの ソフトウェアは、世界中の人々にとって必ずしも使いやすいとは 限りません。ですのでいずれは、 誰もが簡単に m17n ソフトウェアを作れるような環境 (ライブラリ?) が必要になってくるのだろうと思います。 (Qt とか Pango とかって、こういうのにあたるのでしょうか?)
Qtとm17n (スコア:2, 参考になる)
Qt3からはm17nも可能になるようにTrollTechもがんばっていますが、
実際にこれで十分かというとまだまだですね。
まずはフォントの問題(特にAntiAlias時)、それから内部Unicodeのため変換テーブルの問題、
そして、TrollTech自信が国際化についてそれほどわかっていないが為の問題。
などが現状でもあげられる問題でしょうか。
あとは、非GUIなプログラムのことはあまり考慮されてないというのもあるかな。
ライブラリ自身もでかいし、現状のほとんどのlinuxの環境ではQtアプリの起動の遅さの問題もある。
locale-codecとASCIIしか扱わないならば割とましですが、
さらに踏み込んで考えた場合にはまだまだでしょう。
-- Che Che - Bye Bye