Next: Temp Notes, Previous: Temp catgets, Up: Temp Programmers [Contents][Index]
メッセージカタログにアクセスするために二つの異なるシステムをインストールすることは不経済なことのように思えます。我々がcatgetsの不足しているものを改善したいと思ったのなら、なぜ新しいシステムを実装するのではなく、catgetsを(互換性を保ちながら)拡張しようとしないのでしょうか?
いずれにせよ我々は、メッセージカタログにアクセスするためのシステムをオペレーティ
ングシステムに対して二つインストールすることになるでしょう。一つはGNUソフ
トウェアのためルーチン群であり、もう一つはその他全てのソフトウェアのためのルーチン群(catgets)です。傲慢でしょうか?
カタログにアクセスする別のシステムが実装されたと仮定してみましょう。我々がお奨めするのはどちらでしょうか?
少なくともLinuxシステムに対しては、我々は可能な限り多くのソフトウェア開発者を呼び込む必要があります。そのため、我々はソフトウェア開発者が彼らのソフトウェアを移植しやすいようにする必要があります。そしてそれはcatgetsをサポートすることを意味します。我々は
libintlコードをlibc中に実装するでしょうが、libcには別のメッセージカタログに対するアクセス方法を同じように取り込まなければいけないということなのでしょうか?
そして、libintlと非catgetsルーチンを組み合わせて使おうとする人達に関してはどうでしょうか?ソフトウェア開発者が彼らのソフトウェアを他のプラットフォームに移植する際、彼らはそのソフトウェアに単にlibintlを含めるだけでなく、フロントエンド(libintl)コードと、バックエンド(非catgetsアクセスルーチン)コードを付け加えようとするでしょう。
しかしメッセージカタログのサポートは氷山の一角に過ぎません。他のロカールカテゴリのデータはどうでしょうか。それらもまた、多くの相違点を持っています。我々はそれに対処することを諦めて、重複したルーチン群を別々に開発せねばならないのでしょうか(libintlをメッセージカタログサポート以上のものにすべきなのでしょうか)?
UNIX上の改良可能な多くの部分と同じように、我々は将来に向けて改良を加えつつも、過去のものに対する互換性を落とさないようにしていました。