m17n を使って世界中にコードを移植する

多言語化ライブラリーによってユーザー・インターフェースを複数言語に対応させる

Linux アプリケーションを世界中で使えるようにするためには、しかも西欧の言語と世界各国の多くの言語との間に不公平を生じさせないためには、どんなに複雑な言語であっても任意の言語を入力でき、また保存、取得、描画できる、ローカライズしたアプリケーションを提供できなければなりません。多言語化ライブラリー、つまり m17n は、UNIX ライクのプラットフォームのあらゆる言語に対して、単一の国際化ソリューションを提供します。

Frank Pohlmann (frank@linuxuser.co.uk), U.K. Technical Editor, Linuxuser and Developer

Frank Pohlmann は中東の宗教の歴史を少し学びましたが、その後様々な援助委員会が、宗教の歴史に関する研究は現代世界にほとんど関係がないと判断してしまいました。それ以来、彼は趣味であるフリー・ソフトウェアに集中しています。彼は自分がイギリスにある Linuxuser & Developer の技術編集者であることを認めており、彼が Linux や FreeBSD の世界に入ったのは、ライターやアーティストのための UNIX カーネル内部や Linux アプリケーションに強い興味を持っているためです。



Martin Streicher (martin.streicher@linux-mag.com), Editor-in-Chief, Linux Magazine

Martin Streicher は Linux Magazine の編集責任者です。彼は Purdue University にてコンピューター・サイエンスでマスターを取得し、1982 年以来、UNIX ライクのシステムで Pascal や C、Perl、Java、そしてごく最近では Ruby プログラミング言語によるプログラミングを行ってきました。



2006年 10月 17日

パーソナル・コンピューターは、20 年にも満たない驚くほどの短期間に、個人の生活の、そして職業生活の一部となりました。目まぐるしい速さで進歩する半導体やプロセッサー、そしてサプライヤーの拡大、急激な価格低下、どこでも使えるようになったインターネットなどのおかげで、パーソナル・コンピューターは今や贅沢ではなく、ごく普通の家庭用品の一部となっています。

多くの豊かな国々 (例えばアメリカや日本、イギリスなど) では、2 世帯のうちの 1 世帯がコンピューターを持ち、ブロードバンド・サービスを利用しています。世界というレベルでは、そうした世帯の割合は異なるかもしれませんが、いずれにしてもパーソナル・コンピューターはどこにでもあると言っても過言ではなく、例えばモルジブ (Maldives) でもラップトップを購入できます。それでだけではなく、Dhivehi (モルジブの言語) を話す人のために、Microsoft はそのバージョンの Microsoft ® Windows ® XP オペレーティング・システムを提供しています。

ほとんど世界中でパーソナル・コンピューターが使える状況のため、最近のほとんどのオペレーティング・システムでは、国際化、つまりソフトウェアの多言語対応を実現するためのプログラミング・ライブラリーを提供しています。(国際化、つまり Internationalization は、i-nternationalizatio-n という意味で i18n と省略されることがよくあります。) 通常、国際化ライブラリーは、アプリケーションのテキスト・リソース (ボタンのラベルや UI (user interface) の表示、選択メニューなど) を複数の言語で保存します。国際化されたアプリケーションが起動したときに表示される言語は、ユーザーのロケール (通常は設定可能なシステム・プリファレンスや個々のアカウント・プリファレンス) に依存します。

少なくとも独立のソフトウェア・ベンダーにとっては、同じ実行可能プログラムならば日本でもギリシャでも同じように動作することが理想です。しかし「自国語」版のアプリケーションの構築は、理想からかけ離れています。広く認識され、共存している標準である、ISO (International Standards Organization)/IEC (International Engineering Consortium) 10646 と Unicode を含め、どの文字エンコーディング標準も、任意の言語でテキストを入力し、描画するための方法については規定していません。ISO/IEC 10646 と Unicode では、文字の保存や取得、ソートの方法と、文字の特殊な組み合わせについて規定しているのみです。例えば、こうした標準のどこを見ても、タイの言語で書かれた文書をタイ言語の正統な規則に従って適切に描画するための統一フォーマットや組み込みデータ、ディレクティブなどに関しては書かれていません。確かに Unicode はタイ語で書かれた文書の内容を正確に保持し、またそのファイルが、Unicode に対応したすべてのプラットフォーム間で移植可能なことを保証しています。しかし、そのファイルを見られるかどうか、またその文書を表示した場合に作者の意図どおりに表示されるかどうかは保証されていません。

現実は次のように困難な状況なのです。Linux GNU の C ライブラリー (glibc) は ISO 10646 に準拠した 31 ビット文字を処理する機能を持っていますが、こうした文字をディスプレイ上に表示することは保証していません。また、一部の glibc ストリング関数 (例えばstrcat() や strlen() など) は複数バイト文字を適切に処理できますが、例えばアラビア語を描画するために必要な双方向 (bidi: bidirectional) 表示関数は、GUI (graphical user interface) ツールキットと専用のストリング表示ライブラリーの中にしかありません。

また、GNOME は完全な i18n サポートを実現するために GTK+ ツールキットと Pango (テキスト描画ライブラリー) を必要とします。(しかし Pango には制約があり、広範な使い方ができません。囲み記事、「 Pango の問題点 」を参照してください。) 他の GUI ツールキットで i18n をサポートしているものもありますが、それらは必ずしも標準には準拠していません。もちろん Linux のグラフィカル・アプリケーションであれば、Xlib が必要です。(Xlib は X ウィンドウ・システムの基本的な描画ライブラリーであり、2 次元 (形状や線) の描画を行い、また文字描画のプリミティブを提供します。) しかし Xlib は西欧の言語しか描画できません。

Pango の問題点

Pango は複雑な文字を配置 (レイアウト) でき、描画できますが、複数バイトのテキストに対してソートや検索を行うことができません。Pango は、基礎となるライブラリー (通常は C 言語で書かれ、Unicode 標準で規定される全言語を操作できます) が基本的なテキスト処理を行う、と想定しているのです。

すべてを描画できる 1 つのライブラリー

アプリケーションを世界中で使えるようにするためには、しかも西欧の言語と世界各国の多くの言語との間に不公平を生じさせないためには、どんなに複雑な言語であっても任意の言語を入力でき、また保存、取得、描画できる必要があります。上で説明したように、仕様化されている標準は、複数バイト文字の保存や移植についてを規定していますが、入力と描画のための標準はまだありません。さらに具合の悪いことに、すべての言語を同じ程度にうまく描画できる一般的なライブラリーがほとんどありません。例えば、最高の多言語テキスト・エディターでさえ、単純な国際化ライブラリーと、ある会社独自の GUI ツールキットを取り混ぜて使わざるを得ません。さらに別の言語を追加しようとすると、また別の、おそらく新規のカスタム・ライブラリーが必要になります。

そこに多言語化ライブラリー、つまり m17n が登場します (多言語化、multilingualization は m-ultilingualizatio-n、つまり m17n というわけです)。m17n は、UNIX ライクのプラットフォーム上で使われるすべての言語に対して、テキストを入力し、処理し、描画するための単一ソリューションを提供しようとしています。また m17n は、ソフトウェア開発者に新たなモデルを押し付けるのではなく、通常の UNIX アプリケーションの、よく知られた既存のフレームワークを活用しようとしています。

m17n は究極的な目標として、単純にアプリケーションを英語から他の言語に移植するだけの国際化ではなく、もっといろいろな点での国際化を実現しようとしています。例えば m17n を使うことによって、1 つのバイナリーが、あるシステムではフランス語を、別のシステムではモンゴル語を表示でき、さらには同じ画面上に多言語のテキストを同時に表示することができます。さらに良いことに、m17n によってテキスト・データベースのようなものを強化でき、国際的なコンテンツを大量に保存し、処理することも (おそらく) 可能になります。

m17n ライブラリーは、日本のつくば市にある、独立行政法人産業技術総合研究所 (National Institute for Advanced Science and Technology) に勤務する 4 人の日本人プログラマーによって書かれたものです。日本は長年に渡って国際化の最前線にありますが、これには日本の学者が人文科学に関して、特に世界の言語に関して、百科事典的な手法をとらざるを得なかったことが寄与しています。(歴史的な面から解説した囲み記事、「 アジア言語の起 源」を参照してください。)

アジア言語の起源

世界の書き言葉の多くは (そしてユーザー数の面で最大の言語は)、世界で、そして日本で最も重要な宗教の 1 つである、仏教の中から生まれ、進化してきました。

インド語、シナ語、チベット・ビルマ語などの言語や記述は、すべて仏教の経典に関係しています。また日本の仏教学者は、仏教を深く研究する前に、サンスクリット語やパーリ語、中国古語、チベット古語、日本語化した中国語、いくつかの種類の日本古語、そしてもちろん 3 種類の日本語文字 ( script (文字) と呼ぶべきかはわかりませんが) を学ぶ必要がありました。仏教学者であるためには、最低限サンスクリット語と中国古語、いくつかの種類の日本古語が必須でした。その後、生きた仏教の言語である (スリランカの) シンハラ語やタイ語、現代朝鮮語などが追加されました。

世界に関する研究に単一言語の手法を持ち込むことなど、仏教文化にルーツを持つ輸出志向の経済国にとっては考えられないことなのです。

m17n ライブラリーは、3 つのライブラリーと、(個々の文字と、各文字の描画に十分なメタデータを保存するための) データベースから構成されます。

  • m17n C ライブラリーは、glibc (そして libc の様々なバリエーション) の基本的なテキスト処理関数に対応するものです。
  • m17n X ライブラリーは Xlib に密接に対応しています。このライブラリーは基本的な文字描画関数を提供しており、描画に関する前提をほとんど何も必要としません。
  • m17n ツールキットは、画面上にグリフ (glyph) を描画するための準備となる、複雑な文字の処理を行う関数を提供します。例えばタイ文字の描画を行う前には、ソートや合成、並べ替えなどの処理が必要です。
  • 最後に、m17n データベースは、各言語に特有のデータを保存します。例えば、ある特定の言語は、独自のフォントや特殊なエンコーディング、ネイティブ・データを入力するための特別な仕組みを必要とするかもしれません。m17n ライブラリーは言語に独立であり、また m17n データベースは言語に依存する全情報を保持します。

図 1 は、m17n の 4 つの部分と、m17n のライブラリーと既存のシステム・コンポーネントとの対応を示しています。m17n のコンポーネントと従来の (レガシー) UNIX ライブラリーが異様に似ているのは、偶然ではありません。m17n を作った人達は、できるだけ単純に多言語アプリケーションを書けるようにしました。1 つのセマンティック関数を、それと等価な多言語の関数と置き換えればよいのです。

図 1. m17n のライブラリーの階層構造
図 1. m17n のライブラリーの階層構造

(余談ですが、m17n の C ライブラリーと X ライブラリーは X サーバーが利用できることを前提としています。しかし m17n は、基礎となるオペレーティング・システムと描画機構に関しては最低限の想定しかしていません。そのため、m17n を他のウィンドウ・システムに移植することもできます。実際、m17n をクロス・プラットフォームの GUI ツールキット (例えば UNIX ライクのシステム用の Qt など) の中に統合する作業が現在行われており、m17n のチームは GTK のリビジョンの中にコードを織り込んでいます。)


文字の成型

m17n では、新しい綴りの追加も単純にできるようになっています。新しい文字を描画するために 17n のライブラリーを再プログラムする必要はありません。新しい、m17n のM-text を作成し、その M-text を m17n のデータベースに追加すればよいのです。

M-text は、C ストリングの一般化と考えることができます。つまり通常 C ストリングに関連付けられる任意のプロパティーを、M-text を使って文字コードに追加できるのです。あるプロパティーは文字が表現しようとする言語を指定するかもしれず、また別のプロパティーは特定のフォントを指定するかもしれません。Bidi 情報も M-text 表現の中にエンコードされ、また基本的な形態情報を表すこともできます。

例えば、図 2 (m17n の開発者の許可を得て複製したものです) は、プロパティーを使ってテキスト・ストリングの外観を変更する様子を示しています。このストリングは、「This is sample text to show the property」と単純です。しかし各文字は、 (1 つ、あるいは図のように複数の) face プロパティーを持つことができ、それによって文字の描画に使用されるタイプフェースが決まります。図の中の face プロパティーは意図的に単純にしてありますが、これを見ると、この機能の柔軟さがよく理解できると思います。世界中には無数の書き言葉があることを考えれば、こうした柔軟さは必須です。

図 2. プロパティーを個別に、あるいは組み合わせて使うことでテキストの外観を変更する
図 2. プロパティーを個別に、あるいは組み合わせて使うことでテキストの外観を変更する

世界には、個々のグリフを並べ替え、再配置して複雑な合成グリフを描画するために複雑な手順を必要とする文字が数多くあります。タミル語やビルマ語、タイ語などはどれも、描画の前にそうした並べ替え処理が必要です。もっと具体的な例として、図 3 (これも許可を得て複製したものです) は、ディヴァナガリー (Devanagri) 文字でHindi という単語を適切に描画するための処理を示しています。この処理には 2 つのフェーズが必要です。最初のフェーズは、文字の順番を (メモリー中での) バイト順から、(紙に書くような) 適切な順番となるように、変換します。2 番目のフェーズは、グリフや読分け記号の特別なシーケンスがないかをスキャンし、(もしあった場合には) そうした特別シーケンスを「複合」グリフで置き換えます。 (英語にも、テキストを読みやすくするためにそうした変換を行う場合が 2 ~ 3 あります。例えば使われるフォントとタイプフェースによって、f と i のシーケンスが 1 つの fi グリフに置き換えられるような場合です。)

図 3. 「Hindi」という単語を描画する
図 3. 「Hindi」という単語を描画する

こうした並べ替え処理の手順の一般的な名称は、CFL (Complex Font Layout) です。通常、CFL 情報はフォントの中に含まれますが、描画ライブラリーの中にハードコーディングされることもあります。m17n では、CFL 情報は FLT (Font Layout Table) の中に捉えられます。ほとんど FLT データを必要としない綴り方もありますが、複雑な規則を捉えるために膨大な情報を必要とするものもあります。

例えば中国語や日本語の綴り方は、個々のグリフを組み合わせて合成する場合に影響を与えるような、文脈による規則はありません。しかしタイ語には、話し言葉のタイ語にはまったく影響せず、綴り方には影響するような、非常に興味深い規則があります。タイ語の綴り方は、周囲にどんなテキストがあるかによって影響を受けますが、話し言葉はそうした影響を受けません。インド語の文字のある種の合成規則も、やや複雑であり、FLT で表現する必要があります。

このように、タイプフェースや bidi、Unicode などのデータと、そして言語によって、最終的に画面上にテキストが描画されます。次のやっかいな問題は、(おそらく皆さんも疑問に思っていると思いますが) ASCII ではないフォントをどのように入力するかです。


500 キーのキーボードからタイプ入力する

英語やヨーロッパ系の言語の大部分では、1 つ (あるいは 2 つ) のキーを 1 つの文字にマッピングするだけで十分です。キー表面の印刷は異なるかもしれず、またキーボード・ドライバーは少し余計に特別なケースをエンコードするかもしれませんが、モデルは同じです。つまり 1 つのキーを押すことによって特定の文字を入力します。

では、何百もの文字があり、しかも文脈によって特別な組み合わせがある綴り方を処理するにはどうすればよいのでしょう。このためには、単純なキー入力ではなく、キー・シーケンス (いくつかのキーを素早く連続して押すこと) を使います。IM (input method) と呼ばれる特別なソフトウェアが、各キー・シーケンスを、1 つの文字、あるいは一連の文字列に変換するのです。

もちろん、1 度キーを押すだけで済むキー・シーケンスもあります。さらに、標準のラテン・アルファベットのキーボードを他言語の綴りに変換する IM を作ることもできます。例えば、昔の日本語キーボードはラテン文字をひらがなやカタカナに変換していました。しかし、約 46 あるひらがなグリフを、26 文字で A から Z までのラテン・アルファベットで表現することは少しばかり面倒です。

キー・マッピングやキー・シーケンス、他言語変換 IM などは、どれも m17n データベースの中で表現することができます。この手法の大きな利点として、アプリケーションのコードと、綴り方に関する規則 (および変則) とを明確に分離できることです。アプリケーション・コードはプログラマーが開発するのがベストであり、どうすれば適切なテキスト表示となるかを考えるのは言語学者の仕事です。


ライブラリーを入手する

先ほど触れたように、m17n は 3 つのライブラリーとm17n データベースから構成されています。現在のところ m17n libc が入手可能であり、m17n 版の Xlib を使ってコーディングすることができます。開発チームは、GTK+ の一部として実現される第 3 階層ライブラリー、m17n X ツールキットを開発中です。また m17n の開発者達は、Perl や Ruby などのプログラミング言語で m17n を使えるよう、言語バインディングの開発も行っています。(このツールキットとバインディングのリリース・スケジュールは未定です。) また m17n ライブラリーは LSB (Linux Standard Base) の一部として認められており、今後 Linux 国際化の標準実装が実現された場合には主要構成ブロックとなるはずです。

m17n ライブラリーの最新バージョンは、2006 年 2 月 22 日にリリースされたバージョン 1.3.3 です。このライブラリーを入手する方法としては、下記のようにいくつかあります。

  • m17n のソースコードをダウンロードする。ダウンロードのページには、英語と日本語の両方で書かれた、プログラマー用のドキュメンテーションの tarballs も提供されています。
  • CVS (Concurrent Versions System) を使いたい人は、次の CVS コマンドを使ってコードをダウンロードします。
    $ cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n login
    $ cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-lib
    $ cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/m17n co m17n-db

    ソースからビルドすることも容易にできます。m17n ライブラリーは典型的な構成スクリプトを使ってシステムのプロファイリングを行い、コンパイルやインストールに適した Makefile を作成します。(詳細は、m17n ソフトウェア・キットの中にある README ファイルを参照してください。)

  • もし Debian ディストリビューションを使っているのであれば、便利な APT インストール・ユーティリティーを使って、m17n のライブラリーと依存関係をインストールすることができます。例えば Debian システムで利用可能なすべての m17n パッケージを見つけるためには、apt-cache を使って apt-cache search m17n のようにします。

    APT がどの Debian リポジトリーを指すかによって、リスト 1 に示すような出力が得られます。

    リスト 1. apt-cache search m17n コマンドの出力
    libm17n-0 - a multilingual text processing library - runtime
    libm17n-dev - a multilingual text processing library - development
    m17n-db - a multilingual text processing library - database
    m17n-docs - a multilingual text processing library - documents
    m17n-env - set up multilingual X environment
    m17n-lib-bin - a multilingual text processing library - utilities
    mlterm-im-m17nlib - MultiLingual TERMinal, m17nlib input method plugin

    パッケージ名を見つけたら、apt-get install を実行すれば m17n パッケージが自動的にダウンロードされ、インストールされます。m17n の開発者によると、Fedora Core や Mandrake、SUSE Linux、Gentoo Linux などのためのパッケージも入手可能だということです。

m17n ライブラリーは、いくかの他のライブラリーに依存しており、そうしたライブラリーは皆さんのシステムの中にないかもしれません。ドキュメンテーションの中に書かれた、前提条件に関する最新リストをよく調べてください。


m17n の基本

m17n のライブラリーは、内部的にいくつかの API (application program interface) に分かれています。

  • Core : この API は M-text を処理するための関数を提供します。Core API は m17n データベースを必要としません。
  • Shell : Shell API は、m17n データベースを参照、検索する機能を追加します。Shell には、この API のすべての機能が含まれています。
  • GUI : GUI API は、テキストを入力する機能と、グラフィック・ディスプレイ上にテキストを描画するための機能を提供します。GUI には Shell API と Core API の両方の全機能が暗黙的に含まれています。
  • Miscellaneous : この API は、m17n ライブラリーをデバッグし、トレースする際の補助となる、いくつかの関数を定義しています。

m17n ライブラリーの使い方は、Linux や UNIX のライブラリーの使い方と同じです。このライブラリーの全機能を使うつもりであれば、ヘッダー・ファイル m17n.h をプログラムに含め、次に -lm17n を、(例えば Makefile の) リンク・オプションに追加します。m17n の一部のみが必要であれば、Core、Shell、GUI、そして Miscellaneous といった API は、それぞれ個別のインクルード・ファイルを持っています。残念なことに、m17n を使った簡潔なサンプル・コードが不足しており、より重要な参考となる m17n 対応アプリケーションなどの多くは約 2 年前のものです。しかし m17n のSDK (software development kit) には、様々なエンコーディングのファイルを表示する単純なプログラムが含まれています。ダウンロードした m17n キットの中にある、example という名前のディレクトリーを探してください。そのディレクトリーの中で mview.c というファイルを開きます。このファイルの一部をリスト 2 に示します。

リスト 2. m17n のサンプル・ファイル
...
325  M17N_INIT ();
326  if (merror_code != MERROR_NONE)
327    FATAL_ERROR ("%s\n", "Fail to initialize the m17n library.");
328  
329  /* Decide how to decode the input stream.  */
330  if (coding_name)
331    {
332      coding = mconv_resolve_coding (msymbol (coding_name));
333      if (coding == Mnil)
334        FATAL_ERROR ("Invalid coding: %s\n", coding_name);
335    }
336  else
337    coding = Mcoding_utf_8;
338  
339  mt = mconv_decode_stream (coding, fp);
340  fclose (fp);
341  if (! mt)
342    FATAL_ERROR ("%s\n", "Fail to decode the input file or stream!");
343  
344  {
345    MPlist *param = mplist ();
346    MFace *face = mface ();
347  
348    if (fontsize)
349      mface_put_prop (face, Msize, (void *) fontsize);
350    mplist_put (param, Mwidget, shell);
351    mplist_put (param, Mface, face);
352    frame = mframe (param);
353    m17n_object_unref (param);
354    m17n_object_unref (face);
355  }
356  
357  /* Create this widget hierarchy.
358     Shell - form -+- quit
359                   |
360                   +- viewport - text  */
361  
362  form = XtCreateManagedWidget ("form", formWidgetClass, shell, NULL, 0);
363  XtSetArg (arg[0], XtNleft, XawChainLeft);
364  XtSetArg (arg[1], XtNright, XawChainLeft);
365  XtSetArg (arg[2], XtNtop, XawChainTop);
366  XtSetArg (arg[3], XtNbottom, XawChainTop);
367  XtSetArg (arg[4], XtNaccelerators, XtParseAcceleratorTable (quit_action));
368  quit = XtCreateManagedWidget ("quit", commandWidgetClass, form, arg, 5);
369  XtAddCallback (quit, XtNcallback, QuitProc, NULL);
370  
371  viewport_width = (int) mframe_get_prop (frame, Mfont_width) * 80;
372  viewport_height
373    = ((int) mframe_get_prop (frame, Mfont_ascent)
374       + (int) mframe_get_prop (frame, Mfont_descent)) * 24;
375  XtSetArg (arg[0], XtNallowVert, True);
376  XtSetArg (arg[1], XtNforceBars, False);
377  XtSetArg (arg[2], XtNfromVert, quit);
378  XtSetArg (arg[3], XtNtop, XawChainTop);
379  XtSetArg (arg[4], XtNbottom, XawChainBottom);
380  XtSetArg (arg[5], XtNright, XawChainRight);
381  XtSetArg (arg[6], XtNwidth, viewport_width);
382  XtSetArg (arg[7], XtNheight, viewport_height);
383  viewport = XtCreateManagedWidget ("viewport", viewportWidgetClass, form,
384                                    arg, 8);
385  
386  /* Before creating the text widget, we must calculate the height of
387     the M-text to draw.  */
388  control.two_dimensional = 1;
389  control.enable_bidi = 1;
390  control.disable_caching = 1;
391  control.max_line_width = viewport_width;
392  mdraw_text_extents (frame, mt, 0, mtext_len (mt), &control,
393                      NULL, NULL, &metric);
...

このコードを分解すると、次のようになります。

  • 325 ライン目は m17n ライブラリーを初期化します。
  • 330 ライン目の coding_name 変数には、入力ファイルのエンコーディングを指定するコマンド・ライン引数が使われます。そうしたコマンド・ラインが提供されない場合には、代わりに UTF-8 が使われます。
  • 339 ライン目は入力データを読み取り、それを (この時 coding の中に反映されている) エンコーディング・タイプに従ってデコードします。
  • 345 ライン目から 354 ライン目は描画すべきテキスト・フレームのプロパティーを設定します。345 ライン目は手元にある M-text からプロパティーのリストを抽出し、一方 346 ライン目は、与えられたテキストに使用する適切なタイプフェースを抽出します。348 ライン目は描画されるフォント・サイズを設定し (fontsize もコマンド・ライン引数です)、350 ライン目と 351 ライン目は描画すべきフレームの追加プロパティー (例えば、どのウィジェットに対して描画するか (この前は shell = XtOpenApplication (&context, "M17NView", NULL, 0, &argc, argv, NULL, sessionShellWidgetClass, NULL, 0) など)、そして最終的なタイプ仕様を設定します。
  • 362 ライン目から 383 ライン目は典型的な X ツールキット・コールであり、アプリケーションのメイン・ウィンドウを設定します。371 ライン目と 372 ライン目は、ネイティブの綴り方では 80 列 x 24 のウィンドウであったビューポートをどのくらいの大きさにするかを計算します。
  • 最後に、M-text 描画のためのパラメーターをいくつか設定した後、392 ライン目で m17n のテキストが画面上に描画されます。

全体としてみれば、上記の短いコード・スニペットで概説した手順は、標準的な X アプリケーションで通常行われることを正確に説明しています。多くの場合、他言語アプリケーションの作成は、ほんの少しコードを追加し、また従来の X コールの代わりに m17n 関数を使うだけで実現することができます。


m17n の今後

m17n のコードをビルドできるシステムがなくても心配することはありません。オンラインの m17n 描画デモを利用すれば、このライブラリーを試すことができます (「 参考文献 」のリンクを参照してください)。

m17n の開発者達によると、GTK+ と m17n を統合するための作業が進行中とのことです。これは m17n に関する努力の重要性や影響力を高めるために必要な次のステップと言えます。現在の m17n プロジェクトにはコード・サンプルが不足しており、そこから引用したり派生させたり、それを元にした構築をしにくい状態です。また、さらに優れたドキュメンテーションや、主要なプラットフォームのためのバイナリーもあった方が良いと思います。しかし m17n は、非常に限定された地域の言語に対しても WYSIWYG 編集を実現すると約束しています。これはどんな言語にとっても良い知らせです。

パーソナル・コンピューターは、もはや目新しいものではありません。実際のところ、20 年にも満たないうちにコンピューターは一般的な家庭用品になってしまいました (ただし服を洗濯するのではなく、情報を操作するためののものですが)。しかし一部の国々では、まだコンピューターはどこにでもあるとは言えず、手軽にコンピューターを利用することも難しい状態にあります。この不公平を解消するためには、こうした国々がハードウェアやソフトウェアを安価に利用できる必要があります。そしてさらに、そうした国々の人達が母国語でコンピューターを使えなければなりません。

m17n ライブラリーは Unicode や他の標準の上に構築されており、書き言葉の規則に従って、任意の複雑な綴り方を描画することができます。また m17n ライブラリーはコードと文字の形式とを分離しているため、同じコードを繰り返し使うことができ、さらには同じアプリケーションの中で様々な綴り方を描画することもできます。作業はまだ継続中ですが、m17n はコンピューターの言語を世界的規模の方言としてしまうための最先端に立っています。

参考文献

学ぶために

  • 多言語化ライブラリー、m17n のサイト を訪れ、詳しい情報を入手してください。
  • ISO 10646 標準は、文字ベースかグラフィックス・ベースかによらず、(過去、現在、将来を含め) すべての文字のエンコーディングを、コンピューター・ベースのメディア上での処理、表示、保存に適した 31 ビット形式で標準化しようとしています。
  • Unicode 標準 は ISO 10646 よりも知られており、ISO 10646 エンコーディングをすべて網羅していますが、テキスト順序やフォーマットに関する意味情報を、より多く含んでいます。例えば、Unicode の新しいバージョンには、 bidi 文字 の並べ方に関する情報が追加されています。
  • Linux 国際化 (i18n) のための中心作業では、すべての Linux ベンダーが i18n 標準に準拠するように要求していますが、この中には UNIX ベンダーも含まれています。アジアやアフリカ、アメリカ原住民、太平洋地域などの言語機能を実現するソフトウェア・ライブラリーは、オペレーティング・システムを国際化するための抽象化を含む必要があります。
  • このレポートは、 l10n (relevance of localization: ローカライゼーションの重要性) を示し、なぜそれを自然言語技術の一部と見なすべきなのかを論じています。
  • International Component for Unicode は m17n ライブラリーと似ていますが、同じではありません。
  • IIISMF プロジェクトは、変化しながらも UNIX と Linux のための IM を提供しています
  • developerWorks の Linux ゾーン には、Linux 開発者のための資料が他にも豊富に用意されています。
  • developerWorks technical events and Webcasts で最新情報を入手してください。

製品や技術を入手するために

  • 皆さんの次期 Linux 開発プロジェクトを、 IBM trial software を使って構築してください。developerWorks から直接ダウンロードすることができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=226801
ArticleTitle=m17n を使って世界中にコードを移植する
publish-date=10172006