パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

LSB 1.1とLi18nux 1.0」記事へのコメント

  • l10nは死んだ、次はm17nだ 部門より

    九割九分はそうなんですが、一部には、i18n 的抽象化にそぐわないものもあります。すっかり Emacs + Wnn に慣れたこの体ではありますが、ときたま、「カスタムされた秀丸は作業効率が高かったなあ」とか、「カスタムされた WXII は体の一

    • by kubota (64) on 2002年02月01日 23時43分 (#59380) ホームページ 日記

      とはいっても、昔ながらの 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, 参考になる)

        by asataku (2091) <takumi@asaki.jp> on 2002年02月04日 10時45分 (#59685) ホームページ 日記
        QtはcppによるC++の独自拡張さえ気にならなければ非常にプログラムしやすい環境ですし、
        Qt3からはm17nも可能になるようにTrollTechもがんばっていますが、
        実際にこれで十分かというとまだまだですね。
        まずはフォントの問題(特にAntiAlias時)、それから内部Unicodeのため変換テーブルの問題、
        そして、TrollTech自信が国際化についてそれほどわかっていないが為の問題。
        などが現状でもあげられる問題でしょうか。
        あとは、非GUIなプログラムのことはあまり考慮されてないというのもあるかな。
        ライブラリ自身もでかいし、現状のほとんどのlinuxの環境ではQtアプリの起動の遅さの問題もある。

        locale-codecとASCIIしか扱わないならば割とましですが、
        さらに踏み込んで考えた場合にはまだまだでしょう。
        --
        -- Che Che - Bye Bye
        親コメント

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...