LSB 1.1とLi18nux 1.0 12
ストーリー by Oliver
l10nは死んだ、次はm17nだ 部門より
l10nは死んだ、次はm17nだ 部門より
Ryuzi Kambe曰く、"1/31日に、Linux Standard Base(LSB)1.1とInternationalization Initiative（Li18nux）1.0が、Free Standards Groupによってリリースされたそうです。これにより、ディストリビューション間でのソフトウェアの動作保証の確認や、ソフトウェア開発が(これらを前提とした場合には)容易になるハズ。
しかしCNETの記事によると、これで一番助かるのは実はRedHatであると述べている。長い目で見た場合、今自分が使っているディストリビューションにとって、このリリースは果たして朗報だろうか？"
他の標準でも同じですが (スコア:2, すばらしい洞察)
LSBに準拠したプログラムはLSBに準拠したシステム上で動くことは保証されますが, LSBに準拠したシステムの上で動いたプログラムが他のLSBに準拠したシステムの上で動く保証は全く無いんですよね.
ですからシステム規模の話になると, 最終的に物を言うのはxxというディストリビューションで動かしたとかの実績になってしまって, 今までとあまり代わり映えが無いような気がします.
Re:他の標準でも同じですが (スコア:3, 参考になる)
こういう，複数の実装間でのバイナリ互換性を保証しようという 話は昔からありまして，UNIX System V での System V ABI (Application Binary Interface) とか，OSF でやっていた ANDF (Architecture Neutral Distribution Format) とか， 死屍累々という感じです。 Java もある意味，似たような目標を掲げているわけですが。
LSB は，仕様書を読んでいただければわかりますが， System V ABI の焼き直しです。 使用できる API の範囲を限定し， それぞれの API の動作を規定し， その範囲での互換性を保証しようというわけです。
問題は，
ですね。 API の標準化は， 特定の分野について標準的なインタフェースを規定し， その範囲での互換性を図るもので，それ自体はシステム全体としての機能を制限するものではないのですが， ABI の標準化は，システムの提供する機能範囲を限定して，その範囲での共通化を図るという，機能を制限する方向の標準化なので， うまく行かないのかな，という気はします。
もう一つ，Li18nux について，この関連で言えば， I18N/L10N の機能は API 仕様だけでは閉じていなくて， 「詳細の動作はロケールの定義に依存する」 という部分が多いのが難しいところ。 ロケールの詳細定義まで標準化しないと互換性が保証できない のですが，こちらもまた標準化がうまくいっていない部分です。
Re:他の標準でも同じですが (スコア:2, 興味深い)
たとえば、国際化されたテキストのレンダリングを行おうとした場合、 XOM、Qt、Pango(gtk+-1.3.x)などの選択肢がありますが、li18nuxの 規格はXOMが一定の機能を持つことを要求しています。
実用的な観点からするとディストリビュータはQtもしくはPangoを 良いものにして採用すると良いのですが、規格に適合するためには XOMの質を気にする必要が生じます。
また、規格に準拠してるならどこでも動くという主張をするためには XOMを使うことが必要になります。
#いまさらXOMをまともにしても手遅れだっちゅーねん
Re:他の標準でも同じですが (スコア:1)
どの程度LSBに対応する気があるのでしょうか。
少なくともRedHatが対応しないと誰も使わない
気がしますが
-----------------
#そんなワタシはOS/2ユーザー:-)
過給器リナックス (スコア:2, 参考になる)
「LI18NUX 2000国際化規約BASIC Level に準拠 [turbolinux.co.jp]」なターボ。 。「Linuxディストリビューションとしてはじめて、 同パイロットプログラム Basic levelへの適合検査に合格しました」とあって、ついでに「 FHS2.1に98%準拠 」だそうです。
Re:過給器リナックス (スコア:1)
RedHat以外にも、LSBに準拠する意志のあるディストリビューションが実際にあるというのは、このストーリーでは重要な情報ではないのでしょうか？
レッドハットはどうなんだろう (スコア:1)
「過給器」という 2ch 的呼称が気にさわったのかも知れません。それで不快感を覚えたのであれば謝ります（悪意は無いです。最近インプレッサのカタログの見すぎで、つい出てしまった）。
レッドハットのトップページ [redhat.com]から検索しても、"LSB" も "Li18nux" も関連文書が出てきません。Distro 開発の上で、考慮していないはずもないので、たぶん PR 不足だと思いますよ > Red Hat。
まさか、シェアでトップをとっている以上、標準に準拠しないほうに利がある、なんて考えている人がいるとは思いたくありませんが。それじゃ某社といっしょです。
Re:レッドハットはどうなんだろう (スコア:1)
> Distro 開発の上で、考慮していないはずもないので、たぶん PR 不足だと思いますよ > Red Hat。
Li18nuxのMLみてると開発側ががんばっているのはわかるのですが、製品になっては出てきてない気が……
たしかにいろいろ難しい面があるので、正式に採用するのはまだ難しいのかな？とは思います。
第一、Xlib-I18N とかIIIMFとかはTruboもデフォルトではいれてくれなかった気が……
Re:レッドハットはどうなんだろう (スコア:1)
Xlib-I18NはXFree86よりも良い部分もあるとは思いますが、 RedHat的には国際化はgtk+のレイヤーでやるつもりで、 わざわざ非標準なXlibを採用するつもりはないのではないでしょうか？
私の理解 || RedHatの方針の是非は別として、ダメな規格に束縛されて 進歩を止めることだけはやめて欲しいです。
また、IIIMFの方に関してですが*現在のIIIMF*はいろいろな面で クサレなのでデフォルトでいれてるようなディストリビューションには かなり問題があると思います。
(個人的にはli18nuxはSunの悪趣味を押し付けるための団体で、 RedHatやdebianがその影響をそれほど受けていないことを心強く 思っています。)
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