こんにちは、プラグイン＆国際化担当のＰです。今回は一太郎Arkの「マルチリンガルな部分」について、その基礎になる「こだわり」や「設計思想」について書かせていただきます。
| 第四回 一太郎Arkの国際化 | ||||||||||||||||||
|
|
このページでは、一太郎Arkの様々な面に焦点を当てて、Ark開発スタッフ自らがメッセージを発信します。今回は一太郎Arkといえば「マルチリンガル」。国際化の面から一太郎Arkを語ります。 |
こんにちは、プラグイン＆国際化担当のＰです。今回は一太郎Arkの「マルチリンガルな部分」について、その基礎になる「こだわり」や「設計思想」について書かせていただきます。
|
 |
|
筆者はかねがね、韓国語・中国語・ベトナム語・タイ語といったアジア圏の言語を、日本語と同じように扱うことができるアプリケーションを作りたいと考えていました。 以前から、ハンドルネームや絵文字の一部としてギリシャ文字やキリル文字を使う人たちがいました。ShiftJISコードやJISコードにギリシャ文字やキリル文字が含まれているため、このような芸当ができるわけです。もし日本で使われる文字セットのなかにハングルやタイ語の文字などが含まれていたなら、同じようにそれらの文字を使う人が出てきたかもしれません。しかしこれらの文字は含まれていなかったので、そのような文化（流行）は生まれませんでした。というより、生まれようがありませんでした。 一方、韓国や中国で一般的に使われているパソコンでは、日本語の文字である「ひらがな」を使うことができます。中国で使われている辞書で「カラオケ」をひくと、説明に「からorchestra」という感じでひらがなが入っていたりしますが、これはパソコンが「ひらがな」を簡単に扱えることと無関係ではないように思えます。 このようなことから、アプリケーションの扱える言語や文字の範囲が、その国の文化（流行）の可能性や、近隣諸国との文化交流に大きな影響を与える時代になってきているのではないかな？と感じていました。同時に、自分たちが作るアプリケーションの制限が、未来の日本で、新しい文化（流行）が生まれる可能性を潰してしまったり、方向性を歪めるようなことがあったら大変だと考えました。 近未来の日本のアプリケーションには、少なくとも近隣諸国の文字・文章・人名くらいは何の問題もなく扱えるくらいのポテンシャルがほしいと思いませんか？そうすれば、たとえば「キムチ」はハングルで書くのがかっこいいぞとか、タイ料理はタイ語で書こうかなとか、中国の人名を簡体字で併記してみるぞとか、意外なところから流行が生まれたり、文化交流が進んだりするかもしれません。 |
 |
|
近年、日本には以前にもまして外国出身の人たちが増えてきました。学校や会社にも、日本式の漢字名を持たない人たちが増えてきています。このような人たちの名前をグループウェアのようなアプリケーションに登録するとき、旧来の「漢字名」と「ふりがな」を使うことが前提のシステムでは、かなり苦労することになります。 アルファベット系の文字を使った名前のときはそのまま漢字名として入れたいところですが、一見アルファベットのようでいて１文字でもJISコードにない文字があると不都合が生じます。中国・韓国など漢字系の名前もそのまま入れたいところですが、JISコードにない漢字を入れてしまうと後々になって問題が発生したりします。ロシア語やギリシャ語はそのまま入力できますが、タイ語やベトナム語はそのまま入力することができません。それ以外にも、長さ制限にかかることがあったり、姓と名しか入れられなかったり、印刷時に文字化けしたり文字の幅がそろわなくなったりします。 これを解決するには、たとえば本名としてその人の母国語での正式名称（世界中の文字を使って記述可能）を登録し、そのほかに英語名（アルファベットのみ）や日本語表記（よみがな）、必要なら中国語表記・韓国語表記などを設定できるようなシステムにしたいところです。 また、少し話題は変わりますが、海外出張にノートパソコンを持っていき、現地で電子メールを受信することがあります。このとき、内蔵時計を現地時間に修正してあると、たとえば日付変更線をまたぐ前後に受信したメールの受信時刻が入れ替わり不都合が生じることがあります。送信時刻に関しては、世界標準時順でソートしたいこともあれば、それぞれの現地時間順でソートしたいこともあります。 また、長期にわたって滞在するときには、現地の言語のOS環境に日本語アプリケーションをインストールしたいこともあるでしょう。そして、日本の本社に、現地の言語で書かれた文章を引用したマルチリンガルな電子メールを送りたいこともあるでしょう。しかし現在までに、これらをすべて実現してくれるアプリケーションはなかなか見つけられない状況でした。 これらの問題を解決するには、来るべき国際化時代を念頭に置いた新しいアプリケーション設計と発想が必要であると痛感していました。こう書くとなんか大げさですが、まあ簡単に言うと、そろそろ新しい発想でアプリケーションを作らないと、自分たちも日本も時代に遅れてしまうな、ということですね。 そこに今回、100% pure Javaワープロである一太郎Arkの仕事が入ってきました。Java2の国際化に関する可能性を探ってみたいと思っていたところでもありましたので、Java2の機能はすべて使い、できればさらに一歩を踏み出してみようということで、気合いを入れて国際化仕様を決めることにしました。 |
 |
そんなわけで、一太郎Arkの国際化を担当するにあたり、以下のような目標を決めました。（全部実現できたわけではありませんが…）
|
 |
|
Java2はご存じの通り、文字はすべてUnicodeで扱います。そのため、必然的に一太郎Arkで扱える文字もUnicodeに含まれるもの、ということになりました。 ここで１つ問題が発生しました。表示に使うフォントの問題です。Unicodeのすべての領域をカバーしたフォントというものが存在すれば話は簡単なのですが、そのようなフォントファイルは作ることができません。それは、Unicodeの「CJK統合漢字」という領域は、同じコードポイントであっても中国語・日本語・韓国語によって違う字面で表示しなければならないからです。 たとえばUnicodeで0x5203というと、日本語で「刃」という漢字ですが、韓国語と中国語では明らかに日本語とはちがう字面で表示しなければなりません。  つまり、ある文字を表示するために使うフォントファイルを特定するためには、コードポイントから機械的に決定することは不可能で、その文字がどの「言語」に属しているかという情報をもとにフォントファイルを選ばなくてはならないということです。 そのため、一太郎Arkでは、ユーザーが文書全体・文字範囲に対して「ロケール」を指定し、また「ロケール」に対して使用する「フォント」を指定するような仕様としました。「ロケール」というのは、「言語」に「地域」の情報を加えたものだと考えてください。ユーザーは「英語/アメリカ」「日本語/日本」「中国語/台湾」のようなロケール情報を本文領域に対していわば間接的に設定し、一太郎Arkはそのロケール情報をもとに表示用フォントファイルを特定するということになります。 このロケール情報は、XML(HTML)のLANGアトリビュートを使って保持されます。文書のロケールはHTMLタグにつけられ、本文領域のロケールはSPANタグを使って設定されます。 |
 |
|
本文領域に言語情報をつける方法と、それによるフォントファイルの特定というしくみはできました。しかし一太郎Arkは公称「ワープロ」なので、「ここはゴシック体、ここは明朝体に変えたい」という要望が出てきます。これもフォントファイルの特定に関係する問題です。 これについては、CSSのGeneric Fontという機能を使って、上の仕組みに組み込むことにしました。つまり、ユーザーは書体を変えたい場所に「serif」とか「fantasy」というようなCSSのGeneric Font名を指定します。一太郎Arkは、ある文字を表示するとき、まずロケール情報を調べ、次にCSSのGeneric Font名が指定されているかどうか見て、その２つから実際のフォントファイル名を特定し、表示に使います。 後に述べるUI表示用のフォント（メニューやメッセージ）の特定も、この仕組みに組み入れました。これを図にすると以下のようになります。
もし、ある文字にロケール情報が設定されていないときは、XML(HTML)のルールに従って上の要素の指定を捜します。最終的には文書のロケールにあたりますが、もし文書のロケールがなかったときのために、一太郎Arkが優先的に使うロケールというものを決めておきます。 以上の基本設定は、メニューバーの「ツール−言語・フォントの設定」から行うようにしました。このダイアログはつまり、「ロケール・CSSのフォント名」と「実際のフォント」を対応づけるためのものであるといえます。 文字にロケールやCSSのフォント名をつけるのは、メニューバーの「書式−フォント・言語−設定」です。このダイアログでロケールやフォントを指定します。また、CSSのフォント名だけだと不自由するかもしれないので、文字にフォント名を直接つけることもできるようにしました。ただしこれをやると、HTMLファイルとして出力したとき、「ＭＳゴシック」などといった文字が埋め込まれてしまうことになりますので、推奨しません。 この仕組みに関して、今回の一太郎Arkでやり残したことがあります。それはマルチフォントのしくみです。CSSでは、フォント名を並べて書くことによって１つめのフォントファイルがなかったら２つめ、２つめもなかったら３つめ、という風に自動的にスイッチする仕組みがあるのですが、今回ダイアログ側がこれに対応できなかったため、一太郎Ark上からそのような設定を行うことができません。ほかのエディタなどで設定したHTMLファイルは、正しく表示されます。 |
|||||||||||||||||||||||||||||||||||||
 |
|
一太郎Arkではメニューの言語を、起動中に、ウインドウごとに変更することが可能です。これは、Javaのしくみを使って、ありとあらゆるメッセージデータをプログラム本体から分離することにより実現しました。 デフォルトでは日本語と英語のメッセージデータが内蔵されています。メニューバーの「表示−画面表示設定」からダイアログを開いて、「ユーザーインターフェース」タブの「UIの言語」で変更できます。もちろん、ここで選択する前に、その言語のフォント設定をしておく必要があります。 さらに、一太郎Arkにプラグインのしくみが実装されたため、あとから別の言語のメッセージデータを追加していくことが可能になりました。メッセージデータは全部で約1500ありますが、これを翻訳し、プラグインとしてパッケージングすれば、一太郎Arkのメニューを違う言語に変更することができます。 1500ものメッセージを翻訳するのはちょっと大変ですが、メニューなど目立つ部分の約250個くらいだけ翻訳して残りは英語のままにするという手もあります。この方法なら手軽にできるので、近く手順を紹介したいと考えています。 ところでよく考えると、メニューやダイアログは１つのロケールとは限りません。たとえばUIを日本語にしていても、韓国語のウェブサイトを読み込んできたら、「文書のプロパティ」ダイアログの「タイトル」は韓国語になっているでしょうから、韓国語のフォント設定を使うべきです。またファイル履歴は、UIを英語に変えていても、日本語OS上で日本語ファイルを扱っていれば日本語が混じっているので、日本語のフォント設定を使うべきです。ほかにも、本文に複数の言語が混じっていたら検索ダイアログはどうしたらいいか？とか、フォント名はどのフォントで表示したら確実に表示できるか？とか、コメントのロケールは？など、いろいろな問題があります。 現在の一太郎Arkでは、すべてを解決することができませんでした。このあたりは次への課題ということで、実際に使ってみながら分析を進めているところです。 |
 |
|
Java2は、国際化に対応したアプリケーションを作成するため、さまざまなライブラリを用意してくれています。しかし、これらのライブラリが想定する「国際化」とは、「英語Windowsで動作させればメニューが英語になり、日本語Windowsで動作させればメニューが日本語になる」というようなアプリケーションでした。 一太郎Arkは１歩先を見て、どのような言語環境で動作させたときでも自由にメニュー言語を変えられることを目標にし、Java2の仕組みで足りない部分を新たに作成することによってそれを実現しました。 おかげで一太郎Arkは、日本語Windowsでも英語Windowsでもまったく同じように動作します。残念なことにSunのJava2はGlobal IMEには対応していないため入力はできませんが、OSにインストールできない日本語フォントファイルもJava2のフォントディレクトリに入れれば使えるため、表示は問題ありません。（ただし、パッケージに書かれた環境以外での動作はサポート対象外とさせていただいております。ごめんなさい。） |
 |
以上述べてきたように、一太郎Arkは１．どのような言語のOS環境でも…というアプリケーションに仕上がりました。 今後解決しなければならない課題はまだまだ残されています。右から左に記述するアラビア語などの言語への対応、合成文字を使うタイ語などへの対応、ダイアログ内での複数言語対策、入出力時の自動ロケール認識、ハイパーリンク時の文字セット判別などがあります。 なんとなく読み物風になってしまいましたが、一太郎Arkの国際化を担当したやつはこんなことを考えていたんだな、ということがちょっとでも伝われば幸いです。 この回はプラグイン＆国際化担当のＰが担当しました。 次回（2月中旬更新予定）の「開発の現場から」は、予定を1ヶ月早めて「一太郎Arkで始めるXML/XHTML」の後編をお届けします。 |