Eclipseプラグインの国際化対応

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Dan Kehn, Senior Software Engineer, IBM　
Scott Fairbrother (scottf@us.ibm.com), Software Engineer, IBM　
Cam-Thu Le (camle@us.ibm.com), Software Engineer, IBM　

2002年 6月 01日

この記事は、国際市場向けにEclipseプラグインを作成するためのロードマップです。まずは国際化対応を行う理由とその技術的な課題を簡単に説明し、その後でプラグインの国際化対応方法をステップに分けて説明します。そして最後に、それらのステップがEclipse Platformの国際化対応にどのように適用されたのかを見てみます。

国際化対応コミュニティーには、次のような古くからのジョークがあります。

「3カ国語を話す人をトライリンガルと呼びます。2カ国語を話す人はバイリンガルです。では、1つの言語しか話さない人は何と呼ばれているでしょうか。」

「アメリカ人です。」

今日、ソフトウェア製品を英語版だけで提供することは、ユーザビリティー、品質、マーケティング、時には法的な面からも、もはや許されません。自社製品を世界市場に対応できるようにすることは、経済的な面で非常に意味のあることです。そして、この記事で説明するように、世界市場への対応を進めるプロセスは比較的簡単なのです。

まず始めに、いくつか注意点があります。Eclipse Platformは、Java SDKで提供される国際化対応の実装を採用しているので、先へ進む前にJava Tutorial: Internationalization trailをお読みになるとよいでしょう。このチュートリアルは、このプロセスに関係する問題およびステップの概要をわかりやすく説明しています。読者の皆さんがすでにチュートリアルをお読みになっていることを前提としていますので、この記事では、Eclipse自体についてはキー・ポイント、その他の重要項目を強調するに止め、おもにEclipse固有の問題とステップについて取り上げます。この記事で、見慣れない用語や略語に遭遇した場合には、用語集をご覧ください。

国際化対応の概要

国際化対応とは、世界市場向けのソフトウェアを作成するプロセスです。経済的な利点の他に、国によっては、製品の国内市場への導入を許可する前に、政府の設定した一定のローカライズ要件を満たすことを求めるところもあり、この対応にもなります。

Eclipse Platformの国際化対応プロセスは、次の2つのステップに分けて行われました。

1. 製品を各国語サポート可能にする
   このステップは、コーディング技法とユーザー・インターフェース設計の問題を取り扱います。製品を各国語サポート (NLS) 可能にする作業を通して、製品が各国語機能を考慮して設計され、適切なAPIを使用して各国語データを処理することが保証されます。このステップにおいて、適切なコーディング・プラクティス(ストリングをハードコーディングすることの回避、翻訳されたテキストを保持するための入力バッファーの拡大、非ラテン文字を含むストリングの適切な解析、ファイル形式を表すものの一部として保存されているストリングをローカライズしないこと、およびプログラム・コードからの各国語エレメントの分離など)について十分に検討され、最小限の費用と労力で翻訳を完了できるようにすることが必要です。
2. 製品を翻訳する
   このステップには、ある国の言語要素を他の国の言語に翻訳する作業が含まれます。単語やフレーズと同様に、絵やシンボルも文化の違いによって、異なった解釈が施される可能性があります。翻訳検証のステップにおいて、すべての翻訳が前後関係からみて正確かどうかレビューし、ユーザーが誤って解釈しないようにアイコンやクリップ・アートを修正し、さらにテキストが誤って切り捨てられていないかページ・レイアウトをチェックします。このステップでは、翻訳後の製品の機能的な整合性を検証しながら、隠れた文化的な影響も調べます。

上に戻る

国際化対応の影響

1つの言語しか知らない人は注意してください。これから感性のトレーニングが始まります。この記事の終わりにクイズをお出しするつもりです。

まず、Java Internationalizationチュートリアル (この記事の後の方にある参考文献を参照) から、文化に依存するデータを抜き出し、リストを作成してみましょう。このリストは、典型的な開発者が遭遇するものを可能性の高い順に並べてあり、それぞれについて詳しい説明が後に続いています。

1. テキスト
   メッセージ、GUI部品のラベル
   オンライン・ヘルプ (*.html)、プラグイン・マニフェスト (plugin.xml)
2. データ・フォーマット
   数字、日付、時間、通貨
   電話番号、住所
3. 地域と個人に関した置き換え
   寸法 (測定単位が違います)
   敬称および個人の肩書き
4. マルチメディアに関する考慮事項

テキスト

メッセージ、GUI部品のラベル
リソース・バンドルは、言語に依存するテキストを適切に処理します。その方法は、すべてのストリングを一度にResourceBundle サブクラスにロードするか、またはそれらを個々に検索するかのいずれかです。Eclipse Java Development Tooling (JDT) バージョン2.0は、翻訳対象となるストリングの検出をサポートするウィザードを提供します。これについては、このすぐ後の国際化対応のステップで説明します。

翻訳済みのストリングをメモリーにロードするのは、最初のステップにすぎません。次のステップで、それらを(ラベル、テキスト・フィールド、メニュー選択などに) 表示するために適切な制御に渡します。ページ設計者とプログラマーは互いに協力して、選択されたレイアウトでダイアログの適切なサイズ変更とリフローが可能なことを確認しなければなりません。Standard Widget Toolkit (SWT) ライブラリーのレイアウト・サポートでは、フィールドのサイズ変更に合わせて適切にレイアウトの詳細を指定しなければならず、「適切なことを行う」上でプログラマーに大きく依存しています。eclipse.org Webサイトの「Understanding Layout in SWT」 (参考文献を参照) の記事は、実装の問題を詳しく説明しています。

これは特に重要です。というのは、テキストの長さが翻訳中に長くなるからです。英語のフレーズは、多くの場合、それに相当する翻訳よりも通常40%程度短いものです。フォント・サイズも、各国語に合うように修正が必要です。

オンライン・ヘルプ (*.html)、プラグイン・マニフェスト (plugin.xml)
こうした形式のテキスト・コンテンツは、単純なキー指向 / 数値指向のpropertiesファイルよりも複雑なため、外部化のステップが多少複雑になります。

マニフェスト・ファイルは、外部化テキストのみを含む、同じ名前の付いたプロパティー・ファイルであるplugin.propertiesと対になっています。plugin.xmlやfragment.xmlなどのマニフェスト・ファイルのタグの属性には、翻訳対象のテキストとそうでないテキストの両方が含まれる場合があるので、特に注意が必要です。以下に良い例があります。

                
   <plugin
     name="Java Development Tools UI"
     id="org.eclipse.jdt.ui"
     version="2.0.0"
     provider-name="Object Technology International, Inc."
     class="org.eclipse.jdt.internal.ui.JavaPlugin">

ここには、翻訳対象のテキスト、翻訳対象外のテキスト、翻訳対象か否かはっきりしない（いわばグレーの）テキストが、すべてタグ属性として混在しています。id 属性とclass 属性は、プログラミングIDを表しているので、明らかに翻訳対象外です。同様に、name 属性が翻訳対象であることは明らかです。

version 属性 (ロケールに依存した小数点使用表示であるため) またはprovider 属性 (ロケールに依存した法的属性をもつが会社名であるため) は、翻訳対象と見なしたくなるかもしれません。なぜなら、これらの属性はエンド・ユーザーに表示されるからです。しかし、バージョン番号は通常、次の2つの理由で翻訳されません。1つめの理由は、エンド・ユーザーは数値をほとんど重要視しないということです。2つめの理由は、プログラマーは、バージョン番号が「3.5.4」のような複合ストリングとなるようなコードを記述する場合があるということです。バージョン・ストリングを解析する必要性を回避するために、バージョン情報が、メジャー番号、マイナー番号、そしてサービス更新番号のように別々の番号で保存されることは間違いなく優れた設計上の判断ですが、この議論は、この記事の取扱う範囲を超えているので、ここでは説明しません。

プロバイダー名も翻訳されません。「Inc.」が、翻訳上の正確さだけでは済まない法的な意味を持っているからです。どのテキストを外部に配置するかを特定すると、先ほどの例は次のようになります。

                
  <plugin
    name="%plugin.name"
    id="org.eclipse.jdt.ui"
    version="2.0.0"
    provider-name="Object Technology International, Inc."
    class="org.eclipse.jdt.internal.ui.JavaPlugin">

plugin.properties には、キーとなるplugin.name に関連する「Java Development Tools UI」という外部化ストリングが含まれています。

この簡単な例からわかることは、翻訳とは単にテキストの単語やフレーズを同等の言葉に置き換えることではなく、その地域の文化への考慮や法的影響の可能性に対する理解が必要な作業でもあるということです。そういうわけで、翻訳検証テストだけでなく、翻訳のプロフェッショナルが必要となります。

データ・フォーマット

数値、日付、時間、通貨
Javaライブラリーには、数値 (小数点、3桁ごとの区切り、グループ化)、日付 (MDY、DMY、週間労働時間の初日)、時間 (12時間または24時間形式、区切り文字)、および通貨 (各国通貨のシンボル、接尾部と接頭部のどちらに表示するか、リーディング・セパレーターの有無) に必要なフォーマットを処理するクラスが含まれています。

電話番号、住所
これらは結構厄介で、一般的にはあまりテキスト翻訳の際に考慮されませんが、注意が必要です。電話番号は、国によってそれぞれ形式が異なるので、多くのアプリケーションでは、自由な形式で入力することに委ねています。住所については簡単です。「州」フィールドおよび複数の住所行を追加すれば、通常は十分です。

地域と個人に関した置き換え

敬称および個人の肩書き
米国ではそれほど一般的ではありませんが、敬称 (Mr.、Mrs.、Dr.) を適切に使用できるようにすることは、他の国では重大なエチケット違反を避けるために絶対に必要と考えられます。

寸法
これらはそれほど頻繁には発生しません。これには、測定単位とそれに対応する換算された測定単位との置換が伴います (たとえば、マイルとキロメートル)。多くの場合、ユーザーにとっては、異なる単位を同時に表示できるか、または容易に切り替えられることが必要です。

マルチメディアに関する考慮事項

製品は通常、地域的な偏りのない中立的な音声、色、画像、およびアイコンを選択すべきです。

つまり、エラー・メッセージを伝えるのにホーマー・シンプソンの「どっ！」という声を使ったりしてはいけないということです。まじめな開発組織がそんなことをするわけがないとお考えなら、提案されて受け入れられなかったアイコンの典型的な例を見てみましょう。

ある開発者は、米国のシカゴからロサンゼルスまでを横断するルート66という国道を思い起こさせるシンボルを使用して、「IPルーター」を暗に示そうと考えました。ほとんどのアメリカ人は、これを分かりにくいと思ったでしょう。アメリカ人以外のユーザーなら、なおさら困惑したでしょう。

同様に、次の画像は、多くの北米のユーザーにはすぐわかるかもしれません。

しかし認知に関する調査では、米国以外の人々はこれを鳥かごだと想像しました。下記のアイコンの方が、メールの画像としてより広く受け入れられています。

混乱や不快な印象を与える画像を回避するための最良の方法は、文化的な問題を把握しているプロのグラフィック・アーティストに任せることです。

上に戻る

国際化対応のステップ

それでは、実際にEclipseプラグインの国際化対応を行うステップについて説明しましょう。

1. 翻訳対象ストリングを *.propertiesファイルに移動する
2. 表示に関係するパラメーターを区別する
3. ロケールの影響を受けるデータ・フォーマット、置換APIについて適切なものを使用する
4. 各国語環境で作動確認を行う
5. 初期翻訳済みプラグイン・フラグメントを作成する
6. 翻訳用に各国語向けの資料を準備し、送る
7. 翻訳済み資料を再パッケージし、検証する
8. フラグメントを展開する

これらの各ステップについて詳しく説明していきましょう。

ステップ1. 翻訳対象ストリングを *.propertiesファイルに移動する

幸いにも、EclipseのJava Development Toolingは、翻訳対象ストリングを適切に分離する上で大きく貢献します。パッケージ・コンテキスト・メニューのFind Strings to Externalize を選択すると、Externalize Strings ウィザードが表示されます。このウィザードによって、ハードコーディングされたストリングを見つけ出すステップと、それらが翻訳対象か否かを区別するステップと、必要な場合にリソース・バンドルを使用するためにコードを修正するステップを順次行うことができます。

「Hello World」という文字列を出力する標準的なプログラムを例にとって、ウィザードを使用する前の状態で、Externalize Strings ウィザードについて説明します。

                
package com.jumpstart.nls.example.helloworld;
  public class HelloWorld {
     static public void main(String[] args) {
       System.out.println("Copyright (c) IBM Corp. 2002.");
       System.out.println("Hello.");
       System.out.println("How are you?");
       System.out.println("Goodbye.");
   }
}

パッケージ・コンテキスト・メニューからFind Strings to Externalize を選択すると、パッケージ中で翻訳対象テキストを含む可能性のある、すべてのコンパイル・ユニットの選択ダイアログが表示されます。今回、私たちは、1つのJavaファイルのみを使用しているので、HelloWorld.javaファイルからExternalize Strings を直接選択する方がより簡単です。それによって、Externalize Strings ウィザードが表示されます。

表から項目を選択し、右のプッシュボタンの1つを選択すると、ストリングを次の3つのケースのいずれかとしてマークすることができます。

• Translate
  処置: propertiesファイルに1つ項目が追加されます。コード中の元のストリングが、自動生成キーおよびアクセス・コードと置き換わります。キーの指定に使用されたストリングは、「// $NON-NLS-1$」などのようにコメント・マーカーで翻訳対象外としてマークされます。
• Never Translate
  処置: このストリングは、コメント・マーカーによって翻訳対象外としてマークされます。Externalize Strings ウィザードは、その後の実行では、このストリングには、未翻訳というフラグを立てません。
• Skip
  処置: 修正は行われません。Externalize Strings ウィザードのその後の実行では、翻訳はされていないが翻訳対象の可能性があるものとして、このストリングにフラグを立てます。

注: コメント・マーカー「// $NON-NLS-1$」の末尾番号は、単一の行に複数のストリングがある場合に、翻訳対象ではないストリングを示します。

例:x.foo("Date", "TOD", "Time"); // $NON-NLS-2$

ここでは、中央のパラメーターが、非NLSとしてフラグを立てられています。他の2つはスキップされます。

私たちの例に戻ると、各カテゴリーのストリングの総数が、リストの下に要約されているのに注意してください。外部化ストリングのキー名は、ストリングの値に基づいて自動生成されますが、それらの名前は表で直接変更することができます。さらに、オプションの接頭辞を指定することもできます (以下の例では、「S_」)。

ヒント: 任意の行の最初の列にあるアイコンをクリックすると、Translate、Never Translate、またはSkipの中で次の選択に進みます。

どのストリングが翻訳対象であるかを特定したので、次のステップに進み、外部化の方法を選択します。Next を選択すると、次のようなページが表示されます。Property file name とリソース・バンドル・アクセサーのClass name が、デフォルトではなく特定の値に修正されました。

リソース・バンドル・アクセサー・クラスには、propertiesファイルをロードするコードと、ファイルからストリングをフェッチする静的メソッドが含まれます。ウィザードによってこのクラスを生成するか、または既存の独自の実装の中から代替実装を指定することができます。後者の場合、Use default substitution choice のチェックマークを外して、外部化ストリングを検索するための代替のコード・パターンを指定することができます。アクセサー・クラスがパッケージ外にある場合 (たとえば、中央リソース・バンドル・アクセサー・クラス)、基本となるソースにAdd [an] import declaration をオプションで指定することができます。

Externalize Strings ウィザードはJDT Refactoringフレームワークを使用するので、次の2ページはおなじみのはずです。まず、警告の一覧です。

最終的には、変更案が右側に並べて表示されます。

Finish を選択すると、ウィザードはソース・コードの修正を実行し、リソース・バンドル・アクセサー・クラスを作成し、初期propertiesファイルを生成します。標準のリソース・バンドル・クラスのコードは、次のようなものです。

                
  package com.jumpstart.nls.example.helloworld;
  import java.util.MissingResourceException;
  import java.util.ResourceBundle;
  public class HelloWorldMessages {
  private static final String BUNDLE_NAME =
     "com.jumpstart.nls.example.helloworld.HelloWorld"; //$NON-NLS-1$
  private static final ResourceBundle RESOURCE_BUNDLE =
     ResourceBundle.getBundle(BUNDLE_NAME);
  private HelloWorldMessages() {}
  public static String getString(String key) {
     try {
         return RESOURCE_BUNDLE.getString(key);
     } catch (MissingResourceException e) {
         return '!' + key + '!';
     }
   }
  }

この生成コードで唯一変更されているのは、static finalに割り当てられた値BUNDLE_NAME だけです。次のステップに進む前に、JDTチームのErich GammaとThomas Mäderによる重要なガイドラインのいくつかについて以下に説明します。

リソース・バンドルとpropertiesファイルを管理するためのガイドライン

これらのガイドラインは、次のことを目的にしています。

• NLSエラー (ランタイムに検索されない外部化ストリングの値) の数を低減する。
• コードで参照されたキーとpropertiesファイルで定義されたキーの相互参照を可能にする。
• 外部化ストリングの管理を簡素化する。中央プロパティー・ファイルを使用すると、変更の競合が頻繁に発生する可能性があります。また、キーを固有のものにする上で接頭辞の使用が必要になり、キーの管理が複雑になります。

これらの目標を達成するために、以下のガイドラインを提案します。

1. パッケージごとに1つのpropertiesファイルを使用し、クラス名をキー名の修飾に使用する

   たとえば、JDT検索コンポーネントのすべてのストリングは、次のようなキー / 値のペアを伴ってSearchMessages.propertiesに格納されています。SearchPage.expression.pattern=(? = any character, * = any string)
ShowTypeHierarchyAction.selectionDialog.title=Show in Type Hierarchy

2. 専用の静的なリソース・バンドル・アクセサー・クラスを使用する

   Externalize Strings ウィザードでこのクラスを生成します。これにはpropertiesファイルと同様に名前を付けます。そこで、私たちの例ではSearchMessagesと呼ぶことにします。フォーマットされたストリングを作成する必要がある場合は、簡便性メソッド (convenience method) をバンドル・アクセサー・クラスに追加します。例:

   
   リスト5. 静的なリソース・バンドル・アクセサー・クラス
   

   public static String getFormattedString(String key, Object arg) { String format= null; try { format= RESOURCE_BUNDLE.getString(key); } catch (MissingResourceException e) { return "!" + key + "!";//$NON-NLS-2$ //$NON-NLS-1$ } if (arg == null) arg= ""; //$NON-NLS-1$ return MessageFormat.format(format, new Object[] { arg }); } public static String getFormattedString (String key, String[] args) { return MessageFormat.format(RESOURCE_BUNDLE.getString(key), args); }

   
   
   
3. 計算されたキーを使用しない

   コード内の計算されたキーとpropertiesファイル内の計算されたキーを関連付ける簡単な方法はありません。特に、キーがもはや使用されていないかどうかを判断するのはほとんど不可能です。

4. キー名の規則は、<クラス名>.<修飾子> です。

   例: PackageExplorerPart.title

ステップ2. 表示に関係するパラメーターを区別する

外部化テキストのすべてが、ターゲット言語に翻訳される単語やフレーズという訳ではありません。プラグインの実装に、より具体的に関係しているものもあります。プロパティー、設定、およびデフォルトのダイアログ設定などがその例です。

propertiesファイルに含まれる可能性のある具体的な例を、いくつか以下に示します。

• サイズまたはレイアウトの制約に関する情報。例: 表のサイズ変更できない列の適切な幅
• 言語またはオペレーティング・システムに依存するデフォルトのフォントに関する情報。ラテン－1言語にとって有効なデフォルトのフォントは、DBCS言語にとって無効な選択です (詳細については、フォント関連の .propertiesファイルを参照)。

AbstractUIPlugin からサブクラス化するプラグインに関して、NL関連パラメーターは、デフォルトの設定のストア (pref_store.ini) とダイアログ設定 (dialog_settings.xml) に格納されています。Eclipse Workbench自体はデフォルト設定のストアを使用せず、代わりにpropertiesファイルにデフォルトを格納し、AbstractUIPluginのinitializeDefaultPreferences(IPreferenceStore) メソッドを介してそれらを初期化します。

ステップ3. ロケールの影響を受けるデータ・フォーマット、置換APIについては適切なものを使用する

詳細については、Java Tutorial: Internationalization trailを参照してください。

ステップ4. 各国語環境で作動確認を行う

製品が翻訳しやすいように作られているかを検証することは重要ですが、この記事の取扱範囲を超えていますので説明はしません。しかし次回の記事 (「Testing your internationalized Eclipse plug-in」) では、製品の各国語対応に関係する点を検証する方策について説明する予定です。

ステップ5. 初期翻訳済みプラグイン・フラグメントを作成する

この時点で、各国語のプロパティー・ファイルを、ロケール固有の接尾辞 (たとえば、MyMessages_xx.properties、xxは言語を示す) を持つ同様の名前の付いたファイルにコピーし、ステップ6の「翻訳用に各国語向けの資料を準備し、送る」に進むことができます。この場合、製品はコードと製品がサポートするすべての言語が一緒に単一のインストールとして提供されます。

しかし、このアプローチにはいくつかの欠点があります。第1に、コードとその各国語リソースが、同じディレクトリー / JARファイルに混在しています。翻訳がコードの提供より遅れる場合、基本となるコードが変更されていないにもかかわらず、プラグインJARファイルを更新しなければなりません。第2に、プロパティー・ファイル以外のファイルは本質的にロケールを区別しないので、各言語のディレクトリーを分離するには、それらのファイルを分離しなければなりません (たとえば、HTML、XML、画像)。

これらの問題に対処するために、Eclipse Platformは、プラグイン・フラグメントと呼ばれる、プラグインを補完する、別のタイプの再利用可能なコンポーネントの概念を導入しています。プラグイン・フラグメントは、ターゲットのプラグインに追加の機能を提供します。ランタイムに、これらのプラグイン・コントリビューションは、従属しているすべてのフラグメントとマージされます。これらのコントリビューションは、コード・コントリビューションと、プロパティー・ファイルやHTMLファイルなど、プラグインに関連するリソースのコントリビューションとを含む場合があります。つまり、プラグインはプラグインのクラスローダーを介して、フラグメントのコンテンツにアクセスすることができます。

翻訳対象の情報を提供するためにフラグメントを使用する方法および理由

プラグイン・フラグメントは、HTMLファイル、XMLファイル、INIファイル、ビットマップ・ファイルなどのEclipse翻訳情報を配布するための理想的な方法です。妨げにならない方法で翻訳を配布するために、Eclipse Platformの翻訳はフラグメントJARファイルにパッケージされ、元のランタイム・エレメントを変更または修正することなく既存のEclipseインストールに追加されます。これが、言語パックという概念につながります。

Eclipse Platformは、フラグメントのランタイム・エレメントが元のターゲットのプラグインを補強する形で、プラグイン・フラグメントをマージします。ターゲットのプラグインは、決して移動、削除、修正されることはありません。フラグメントのリソースはクラスローダーによって探し出されるので、プラグインを使用する開発者は、リソースがプラグインのJARファイルからロードされるのか、あるいはそのフラグメントのJARファイルの1つからロードされるのかを知る必要はありません。

Eclipse言語パックJAR

Java言語は、リソース・バンドル機能によって言語パックの概念をサポートします。Javaリソース・バンドルでは、別の言語をサポートするためにアプリケーション・コードを修正する必要はありません。*.propertiesファイルのネームスペースは、basename_lang_region_variant という命名規則によってファイル名の衝突を回避します。ランタイムに、ResourceBundle 機能は、現在のロケールに該当するpropertiesファイルを検索します。

HTMLファイルやXMLファイルなどのファイルをフラグメントで展開するアプローチは、Eclipseフラグメントがディレクトリー構造を使用して異なる言語のバージョンを分類する点で、Javaリソース・バンドルとわずかに異なります。

フラグメント・コンテンツの例
プラグインおよびフラグメントのプラグインは、eclipseサブディレクトリーのすぐ下にある個々のサブディレクトリーに存在します。例のフラグメントを見ると (ドイツのシステムに展開されています)、nlフォルダー、fragment.xml、およびnl1.jarファイルが表示されています。

一般的に、翻訳済みの *.propertiesファイルはリソース・バンドルのルールに従って接尾辞が付けられ、JARファイルに展開されます。反対に、ビューがリソース・バンドルなどのようなロケールを区別しない名前 (*.xmlなど) の入力ファイル・タイプを必要とする場合は、ファイルの各言語バージョンに対してサブディレクトリー構造を定義します。上記のdeサブディレクトリーは、そのような例の1つです (deはドイツ語を表します)。

フラグメント・マニフェスト
各plug-inフォルダーは、フラグメント・マニフェスト・ファイルであるfragment.xmlをオプションで含むことができます。マニフェスト・ファイルはプラグイン・フラグメントを記述し、次の2つの例外を除いてプラグイン・マニフェスト (plugin.xml) とほぼ同一です。

• フラグメントがプラグイン・クラスを持たないので、class 属性はありません。フラグメントは単にターゲットの仕様に従います。
• フラグメントがそのターゲットのプラグインと同じ依存関係を持つので、依存関係はありません。

各国語フラグメントの記述に使用されているマニフェストは、一般的にきわめてシンプルで、<fragment> および<runtime>/<library> のタグのみを指定します。以下は、完全なフラグメント・マニフェスト・ファイルの例です。

                
<?xml version="1.0" encoding="UTF-8"?>
<fragment
   id="com.jumpstart.nls.example.helloworld.nl1"
   name="NLS Example Plugin NL Support"
   version="1.0.0"
   provider-name="IBM"
   plugin-id="com.jumpstart.nls.example"
   plugin-version="1.0.0">
<runtime>
   <library name="nl1.jar"/>
   <library name="$nl$/"/>
</runtime>
</fragment>

<fragment> タグ属性は次のようなものです。

• name -- 拡張用にユーザーが表示可能な名前。
• id -- このフラグメント設定のID。このフラグメント・インスタンスを一意に識別するために使用されます。
• plugin-id -- ターゲットの拡張ポイントへの参照。このプラグイン・フラグメントは、このターゲットの拡張とマージされます。
• plugin-version -- フラグメント・プラグインのバージョン。
• version -- major.minor.service形式のバージョン指定。

<runtime> セクションには、プラグイン・フラグメント・ランタイムを構成する1つまたは複数のライブラリーの定義が含まれています。参照されたライブラリーは、プラグインによって必要とされる正確なコードをロード、マージ、および実行するプラットフォーム実行メカニズムによって使用されます。各<library> サブタグは、name 属性を持っており、ライブラリー・ファイルまたはディレクトリー・エクスポート・マスクを指定します。フォルダーのコンテンツとそのサブフォルダーをライブラリーに含めるために、$foldername$/ というマスクを使用します。このfoldername とは、ライブラリー検索パスに追加されるディレクトリーです。\nlフォルダーのコンテンツとそのサブフォルダーのコンテンツを含めるために、どのようにこのマスクを使用するかを後で見ることにします。

フラグメントの構築
Eclipse Workbenchには、プラグイン開発に使用されるツール、Plug-in Development Environment (PDE) が付属しています。PDEには、プラグイン・フラグメントを開発するためのサポートが含まれています。

では、PDEを使用して各国語の翻訳のためのフラグメントを構築する方法について考えてみましょう。1つのフラグメントにおける言語数には、事実上制限はありません。フラグメントは、1つまたは複数の言語の翻訳を含む「言語パック」の基礎となるものです。ただし今回の例では、ドイツ語の翻訳の言語パックに限定します。

プラグイン・フラグメントを構築するには、New Projectウィザード (File >New >Project...) を開始し、Plug-in Development カテゴリー、Fragment Project タイプを選択します。New Fragmentウィザードの最初のページで、プロジェクト名を入力します。プロジェクト名がフラグメントIDにもなるという点を念頭に置いてください。たとえば、各国語サポートをHelloWorldの例に追加するプロジェクトを開始する場合、プロジェクト名を「com.jumpstart.nls.example.helloworld.nl1」にしたとします。末尾の「.nl1」は必須ではありませんが、「言語パック」を表すフラグメントと、さらなるコードおよび機能を追加するフラグメントとを区別するのに役立ちます。

Next を押します。2ページ目に、プロジェクトのソース・フォルダーおよびランタイム・ライブラリーのデフォルト値が表示されます。

これらの値は適切と思われるので、再度Next を押し、「Fragment Code Generators」ページに進みます。フラグメント・マニフェスト・ファイルを作成することを示す2つめのラジオ・ボタンをテンプレートから選択し、Default Fragment Generator ウィザードをリストから選択します。

Next を押すと、「Simple Fragment Content」ページが表示されます。このページには2つの項目があり、既存のプラグインのフラグメントをターゲットとするのに使用されます。プラグインのターゲットのIDとバージョンを入力する必要があります。Browse ボタンを使用して、拡張したいプラグインを選択することができます。

次に、フラグメント・マニフェスト・エディターに進みましょう。これは、Overview、Runtime、Extensions、Extension Points、およびSourceのページを持つマルチページ・エディターである点で、プラグイン・マニフェスト・エディターに似ています。

タブのついたページが、フラグメントxmlファイルのセクションに対応しています。Runtime ページを使用して、翻訳が含まれるライブラリーのフラグメント・クラスパスを指定することができます。

ライブラリーが既にこのフラグメントのクラスパスに含まれているように、新しいフラグメント・ウィザードでnl1.jarを指定しました。この時点で欠落しているのは、\nlフォルダーのコンテンツとそのサブフォルダーのコンテンツを含めることです。OverviewページのRuntime LibrariesセクションからMore を選択するか、Runtimeページに移動して、New... を選択し、フォルダー・マスクに $foldername$/ を入力すると、新しいランタイム・ライブラリーを追加することができます。

フラグメント・マニフェスト・エディターのSourceページを見てみると、PDEがプラグイン・フラグメントの記述に必要なすべてのXMLを生成することがわかります。

ステップ6. 翻訳用に各国語の資料を準備し、送る

正確な翻訳を行うには特別の技術が必要となり、それには対価を支払う必要があります。(残念ながら、高校4年間のドイツ語の授業程度では不十分です。) プロフェッショナルな品質の翻訳を喜んで行ってくれる会社がたくさんあります。

Eclipse Platformの場合、このステップは2つのフェーズで行われました。第1のフェーズでは、すべての外部化テキストを翻訳センターに送りました。最初の翻訳は、「コンテキストとは無関係に」行われました。翻訳担当者は、稼働している製品の確認もせず、製品固有の知識も持ち合わせていません。彼らは、翻訳速度の向上と一貫性の確保に役立つツールを自在に使いこなしますが、結局ところ、ターゲット言語で稼働している製品を検証するのは、翻訳テスターに依頼してしています (第2のフェーズ)。

コンテキストとは無関係に翻訳を行うリスクと、思わず吹き出してしまうようなその結果については、次回の記事 (「Testing your internationalized Eclipse plug-in」) で説明するつもりです。

ステップ7. 翻訳済み資料を再パッケージし、検証する

ファイルが翻訳されると、ステップ5の「初期翻訳済みプラグイン・フラグメントを作成する」に示されたように、適切なディレクトリー / JARファイルでそれらを再び組み立て直します。NL1 Fragmentフォルダーには、plugin.propertiesファイルの言語バージョンが含まれています。HelloWorld.propertiesファイルをドイツ語に翻訳した後、その名前をHelloWorld_de.propertiesに変更し、NL1 Fragmentソース・フォルダーに格納します。nl \de (ドイツ語) フォルダーは新しく、PDEではなく手動で作成することに注意してください。やがて翻訳が追加されるにつれて、これらの言語固有のフォルダーは、propertiesファイル以外のバージョン (以下のhello.xmlなど) として分離します。

翻訳済みのpropertiesファイルには、多くの場合、コード・ページに依存するアクセント付き文字が含まれるので、propertiesファイルは、PropertyResourceBundle クラスによって想定されているISO 8859-1コード・ページに変換しなければなりません。native2asciiユーティリティー (参考文献を参照) はコード・ページの変換を処理し、必要なUnicodeエスケープを挿入します。

Unicodeエスケープという用語に関しては、もう少し説明が必要でしょう。Java SDKに付属しているnative2ascii変換ユーティリティーは、ソース・エンコードを受け入れ、ISO 8859-1でエンコードされた出力を作成し、このコード・ページ外の文字をUnicodeエスケープとして知られる表記に変換します。その表記は\uddddで、ddddはUnicodeコード・ページでの変換先文字のコード・ポイントです。

以下に例を示します。「Son père est allé à l'hôtel」 (彼の父はホテルへ行った) というフランス語のフレーズについて考えてみましょう。これには、ラテン－1コード・ページには載っていない4つのアクセント付き文字が含まれています。このフレーズをnative2asciiユーティリティーによって変換すると、次のようになります。Son p\u00e8re est all\u00e9\u00e0 h\u00f4tel

アクセント付き文字はもうありません。そして、ストリングは完全に、ISO 8858-1にあるコード・ポイントを持つ文字で構成されます。しかし、置き換えられた\u00e8、\u00e9、\u00e0、\u00f4 は何でしょうか。これらは、\udddd表記のアクセント付き文字のUnicodeコード・ポイントです。

native2asciiユーティリティーを使用する場合には、少し注意しなければなりません。ソース・エンコードは、それを実行するマシンのアクティブなコード・ページと同じであると想定されています。しかし翻訳担当者は一般的にデフォルトの国別コード・ページで翻訳を保存し、さらにこのコード・ページは、国ごとに、またオペレーティング・システムごとに異なります。そのため、翻訳の統合担当者は、(a) どのコード・ページで翻訳担当者がファイルを保存するかを知っておくこと、あるいは (b) 共通のコード・ページでファイルを保存するよう翻訳担当者に要求することが必要です。-encoding パラメーターによってnative2asciiを起動した場合は、ソース・エンコードを指定することができます。

ヒント:ソース・コード・ページが不確かな場合、この記事の後の方にある表3. 一般的なアクセント付きラテン文字のUnicodeコード・ポイントでnative2asciiの出力を、抜き打ち検査することができます。この表中にない \udddd 表記 (\u0205など) が変換後のファイルにある場合は、誤ったソース・エンコードを指定した可能性があります。DBCS言語には、これに相当する抜き打ち検査はありません。DBCS言語では、実質的に変換後のファイルのすべての文字がUnicodeエスケープになります。稼働中の製品を注意深く検証するしかありません。

翻訳のテストというテーマについては、この記事とは別に単独の記事として扱うだけの価値があります。次回の記事 (「Testing your internationalized Eclipse plug-in」) では、Eclipse Platformの最新の翻訳検証の間に学んだ教訓とプロセスについて説明し、プロパティー・ファイルの翻訳に対してクイック・チェックを実行するビュー (もちろん、Eclipseプラグイン) についても紹介します。

ステップ8. フラグメントを展開する

フラグメント・ソースは、プラグイン・ソースと同様に、JARファイルの形でパッケージすることができます。PDEを使用してJARパッケージを生成し、「fragment.xml」ファイルを選択し、ポップアップ・メニューから「Create Fragment JARs...」を選択します。ウィザードによって、フラグメントに必要なすべてのJARを生成するビルド・スクリプトを作成することができます。

このフラグメントの例を展開するには、fragment.xml、\nlディレクトリー、およびJARをpluginsディレクトリーのcom.jumpstart.example.helloworld.nl1サブディレクトリーにコピーします。以上で、例と国際化対応のステップについての説明を終わります。次のセクションでは、特に、EclipsePlatformの翻訳対象エレメント、その構成、および別の言語の導入に必要なものについて説明します。

上に戻る

Eclipse Platform (V 1.0) の国際化対応

このセクションのポイントは、Eclipseの国際化対応を行う「方法」ではなく、バージョン1.0の実装とその翻訳に関連するビルド・プロセスを概観することです。これらのトピックのいくつかは、プラットフォーム自体に固有のものであり、単にプラットフォームに対するプラグインの各国語対応を望むだけの開発者には関係ないプロセスを取り扱っています。このセクションは、プラットフォームがどのように各国語対応になるかを理解し、翻訳済みの製品を含む多数のファイル、サブディレクトリー、およびJARを上手く舵取りしたいと望む読者を対象にしています。

Eclipse Platformは、2バイト文字の入力、双方向データのサポートといった機能をはじめとして、国際化に対応しています。Eclipse Platformは、以下の言語で利用することができます。

• ブラジル系ポルトガル語
• フランス語
• ドイツ語
• イタリア語
• 日本語
• 韓国語
• 中国語 (簡体字)
• スペイン語
• 中国語 (繁体字)

IBMでは、これらの言語をまとめてグループ－1言語と呼びます。

翻訳されたエレメントとその格納場所

Eclipse Platformは、Java SDKで提供される国際化対応フレームワークに依存しています。したがって、翻訳対象テキストの大半は、*.propertiesファイルに置かれます。しかし、HTMLやXML、ビットマップなどの翻訳すべき情報を含む他のファイル形式があります (表2. Eclipse固有の翻訳対象リソース (Java以外) に要約があります)。

翻訳はある種の技術であり、時間、労力、費用とのバランスです。そこでは、製品の進化の速度と、市場投入のタイミングが勘案されます。翻訳対象に関して、どの部分が必須であり、また、どの部分が後回し可能かについて、常に詳細な検討と、妥協を視野に入れた判断がなされています。

簡潔に言うと、Eclipseは、翻訳については、次の3つの主要エリアに絞り込んでいます。

• プラグイン
• オンライン・ヘルプ
• ウェルカム・ビュー

関係するファイルを以下に示します。

• *.propertiesファイル
• *.htmlファイルおよびそれに関連する「ワイヤリング」ファイル
• welcome.xmlファイル

Eclipseプラグイン: .propertiesファイル

Eclipseでは、各製品のプラグインにpropertiesファイルが含まれています。プラグインを翻訳するということは、そのpropertiesファイルを翻訳するということです。propertiesファイルの処理には、主に2つのステップがあります。

上に戻る

フォント関連の .propertiesファイル

オペレーティング・システムによって、使用されているフォント・セットは異なっています。また、言語によっては、独自のフォント・セットを持っているものもあります。(特にDBCS言語)。オペレーティング・システムはデフォルトのフォントを推奨しますが、ページ設計者の最適なレイアウトは特定のフォントと結び付いているので、デフォルトのフォントを使用すると、ページの形式に悪影響を与える可能性があります。翻訳済みのテキストが正確に表示されるように、Eclipse Workbenchは、各言語 / オペレーティング・システムの組み合わせに合った特定のフォント・セットを使用します。

注:オペレーティング・システムまたは言語のサポートを新たに追加するEclipse Platform開発者の場合のみ、新しいjfacefonts* プロパティー・ファイルを作成する必要があります。Eclipse Platformに付属しているJFace propertiesファイルで指定されたフォントなど、別のプラグインのサブディレクトリーのコンテンツは絶対に修正しないでください。

各種のEclipseのフォントがJFaceプラグインで定義されています。デフォルトのEclipse fonts.propertiesファイルは以下にあります。

                eclipse\plugins\org.eclipse.ui\workbench.jar
    org\eclipse\jface\text\JFaceTextMessages.properties
    org\eclipse\jface\resources\jfacefonts.properties (OS default)
    org\eclipse\jface\resources\jfacefonts_linux.properties
    org\eclipse\jface\resources\jfacefonts_windows2000.properties
    org\eclipse\jface\resources\jfacefonts_windowsnt.properties

各言語には4種類のorg.eclipse.ui jfacefonts propertiesファイルがあり、すべて同じNLフラグメントJARの<eclipse_root>\fragments\org.eclipse.ui.nl1\nl1.jarに格納されています。

たとえば、イタリア語には、jfactfonts_it.properties、jfactfonts_linux_it.properties、jfactfonts_windowsnt_it.properties、およびjfactfonts_windows2000_it.propertiesがあります。スペイン語には、jfactfonts_es.properties、jfactfonts_linux_es.properties、jfactfonts_windowsnt_es.properties、jfactfonts_windows2000_es.propertiesがあります。

新しい言語のサポートを追加するには、上記のベースのjfacefontsファイルをコピーし、国別の接尾辞 (国別コード"xx" のjfactfont_linux_xx.properties など) を追加し、新しいjfacefontsファイルをNLフラグメントJARに挿入します。

エンド・ユーザー・メッセージの .propertiesファイル
プラグインのエンド・ユーザー・メッセージを翻訳するには、次のステップを実行します。

1. .propertiesファイルを翻訳する。
2. ローカルにエンコードされたコード・ページからPropertyResourceBundle にて想定されているエンコードにpropertiesファイルを変換する。
3. Javaリソース命名規則に従い、正確なロケールのファイル名に変更する (たとえば、enは英語、deはドイツ語、frはフランス語、itはイタリア語)。
4. PDEによって作成したNLフラグメントJARのソース・ディレクトリーにpropertiesファイルを挿入する。

Javaリソース・ファイル命名規則によって、言語、地域、方言 (basename_language_region_variant) を指定できますが、Eclipseは、3つの言語 (ポルトガル語、中国語 / 中国、中国語 / 台湾)以外のすべての場合に言語を指定するだけです。<name>_<locale>_<region>.properties

PropertyResourceBundle は、ランタイムに現在のロケールに対応するリソース・ファイルを自動的に検索します。たとえば、ドイツ語の場合、翻訳に先立って英語のplugin.propertiesが、plugin_de.propertiesとしてコピーされます。

Eclipseオンライン・ヘルプ: HTMLファイルおよび .propertiesファイル

Eclipseには、5つのオンライン・ヘルプがあります。ベース言語のドキュメンテーションは各々のサブディレクトリーの中に、プラグインとして提供され、翻訳済みのバージョンは、プラグイン・フラグメントとして提供されます。「ドキュメンテーション」プラグインは、以下に置かれます。

上記の各ディレクトリーのプラグイン・マニフェスト・ファイルであるplugin.xmlは、ヘルプ・コントリビューションを定義します。必要なヘルプ・インフォセットおよびワイヤリング・ファイルは、同じディレクトリーの中に定義されています。オンライン・ヘルプを翻訳するには、次のステップを実行します。

1. 各オンライン・ヘルプのdoc.propertiesファイルを翻訳する。
2. 翻訳済みのdoc.propertiesを、ローカルにエンコードされたコード・ページから変換し、ロケール固有のリソース・ファイル命名規則に従って名前を変更する。
3. PDEによって作成したNLフラグメントJARのソース・ディレクトリーにpropertiesファイルを挿入する。
4. オンライン・ヘルプの *.htmlファイルを翻訳する。
5. 翻訳済みの .htmlをそれに対応するプラグイン・フラグメント・ディレクトリーに入れる。

オンライン・ヘルプを複数の言語に翻訳する場合は、言語ディレクトリー構造を作成して、国別に翻訳済みのHTMLを保持しなければなりません。これらのファイルはプロパティー・ファイルのようにロケールを区別しないので、元のファイル名と拡張子を保持する必要があります。たとえば日本語の .htmlファイルのセットとドイツ語のセットを区別するには、1つのディレクトリー名が1つの国を表すように、別々のディレクトリー名の下で各セットを保存しなければなりません。

たとえば、Workbench User Guide *.htmlファイルのドイツ語のセットは、eclipse\fragments \ org.eclipse.platform.doc.user.nl1\nl\ de に格納されます。日本語のwelcome.xmlは、eclipse\fragments\org.eclipse.platform.doc.user.nl1\nl\ ja にあります。

Eclipseの「Help > Welcome」メニュー選択: welcome.xmlファイル

welcome.xmlは、Workbenchが最初に開いたとき、またはユーザーがHelp > Welcome を選択したときに表示される最初の画面です。このファイルは、eclipse\plugins\org.eclipse.sdk_1.0.0にあります。

以下は、welcome.xmlファイルを翻訳するためのステップです。

1. welcome.xmlファイルを翻訳する。
2. UTF-8形式で翻訳を保存する (たとえば、Notepadを使用)。UTF-8で保存するのを忘れると、アクセント付き文字 (つまり、UTF-8コード・ページの一部ではないコード・ポイント) があった場合に、XML解析プログラムがエラーを表示します。
3. .htmlファイルと同様に、welcome.xmlを多くの言語に翻訳した場合、ロケール固有のディレクトリー名の下で各welcome.xmlを保存する必要があります。たとえば、ドイツ語のwelcome.xmlはeclipse\fragments\org.eclipse.sdk_1.0.0\nl\ de にあり、日本語のwelcome.xmlはeclipse\fragments\org.eclipse.sdk_1.0.0\nl\ ja. にあります。

上に戻る

まとめとその他の参照

自社製品を世界市場に対応できるようにすることは、経済的な面で非常に意味のあることです。そして上述のステップは、そのプロセスが比較的簡単であることを示しています。ではここで、最初にお話したように、クイズを出させていただきます。

「IBMによる世界中のソフトウェア売上高の過半数は、米国内での売上である。真か偽か。」

「偽」です。実際にIBMのソフトウェア売上高の50%以上が、米国外で発生しています。

幸いにも、Eclipse Platformを基に製品を開発した方は、ベース製品を翻訳する準備が万全ということになります。あとは、この記事で説明した明確なステップに従って、Eclipseベースの製品を世界の市場に解き放つだけです。

Eclipse固有の翻訳対象リソース (Java以外)

次の表は、前述の翻訳対象リソースのリストをまとめたものであり、翻訳の進め方について簡単な説明を付けてあります。

翻訳対象リソースの詳細については、Greg Adamsのeclipse.org Webサイトの記事「Creating Product Branding」 (参考文献を参照) を参照してください。

一般的なアクセント付きラテン文字のUnicodeコード・ポイント

用語集

コード・ポイント
文字は1バイト以上の情報で表すことができます。コード・ポイントとは、各グラフィック文字に割り当てられた16進値です。

コード・ページ
コード・ページとは、単一のグラフィック文字セット内、あるいはグラフィック文字セットの集合内における各グラフィック文字に対するコード・ポイントの仕様です。特定のコード・ページ内では、コード・ポイントは1つしか固有の意味を持つことができません。CHCPコマンドによって、Windows® オペレーティング・システムでアクティブなコード・ページを表示することができます (どの時点においてもアクティブにできるコード・ページは1つだけです)。

エンコード
特定のデータ片に関連するコード・ページのことです。ファイルを特定のコード・ページで「エンコードする」という言い方をします。たとえば、Notepadはデフォルトでは米国英語マシンのコード・ページ437でそのデータをエンコードします。ユーザーはSave As ダイアログによって、有名なUnicodeやUTF-8など、他の複数のエンコードを選択することができます。

国際化対応 (略称「I18N」)
国際化対応とは、言語、文化的データ、または取扱う文字のエンコード・スキームなどに関する事前知識を持たずに、各国語に対応するプログラムを開発できるようにするプロセスのことです。システム的な観点からいうと、実行時に特定の言語での動作に切換えられるようなインターフェイスを、プログラムに用意しておくことです。

1バイト文字セット (SBCS)
1バイト文字セットでは、1バイトのコード・ポイントがセットの各文字を表します。通常SBCSは、英語、ヨーロッパ言語、キリル文字言語、アラビア語、およびヘブライ語などの文字を表すのに使用されます。

2バイト文字セット (DBCS)
2バイト文字セット (DBCS) では、2バイトのコード・ポイントがセットの各文字を表します。日本語、中国語、韓国語など、本質的に表意文字の言語は、256のコード・ポイントによって内部で表すことができる文字よりも文字数が多いので、2バイト文字セットが必要です。

ローカライズ (略称「L10N」)
ローカライズとは、サポート対象の言語、文化的データ、およびコード化文字セットの組み合わせに対する固有の情報を、1つのコンピューター・システム内に作り上げるプロセスのことを指します。

混合バイト文字セット (MBCS)
混合バイト文字セットは、1バイト文字と2バイト文字の両方を含む文字セットです。MBCSでは、データの各バイトが2バイト文字の最初のバイトなのか、それとも1バイト文字なのかをチェックする必要があります。あるバイトが特定の範囲にある (たとえばX'80' よりも大きい) 場合、それは2バイト文字の最初のバイトです。

NLS
各国語サポートのことです。

Unicode
「Unicodeは、プラットフォーム、プログラム、言語に関係なく、各文字に一意の番号を提供します」 (http://www.unicode.org から引用。)
注意: 確かにJavaテキスト操作クラスはUnicode中心ではありますが、プログラムで保護されない場所に格納されたデータには、多くの場合、当てはまりません。Javaプログラマーは、必要な場合にローカルのコード・ページからUnicodeへの変換を実行することによって、データ・エンコードを考慮する必要があります。

参考文献

• Eclipse Platformは、Java SDKで提供される国際化対応の実装を採用しているので、Java Tutorial: Internationalization trail (Sun Microsystems, Inc.、2002年) をお読みになるとよいでしょう。
  
  
• 「Understanding Layouts in SWT」 (eclipse.org Webサイト、2001年3月) の記事は、実装の問題を詳しく説明しています。
  
  
• 翻訳対象リソースの詳細については、「Creating Product Branding」 (eclipse.org Webサイト、2001年11月) の記事もご覧ください。
  
  
• (Java SDKに付属している)native2ascii ユーティリティーを試してみてください。このユーティリティーはコード・ページ変換を処理し、必要なUnicodeエスケープをすべて挿入します。
  
  
• IBMalphaWorks サイトからResource Bundle Manager ツールをダウンロードしてください。RBManagerは、リソース・バンドル・ファイルの作成、更新、管理に関連する退屈な作業を自動化してくれます。また、よくある間違いの大半がバンドル間で広がるのを防いでくれます。このツールは、アプリケーションおよびWebベースのサービスの国際化に取り組む開発チームにとって役に立ちます。
  
  
• Nadine Kano氏によるDeveloping International Software for Windows 95 and Windows NT (Microsoft Press、1995年、ISBN 1-55615-840-8) は、コード・ページ、Unicode、およびWin32のその他の面についてさらに詳しく説明しています。Windows 98、Windows NT 4.0、およびWindows 2000用には更新されていませんが、資料の大半は依然として有効です。
  
  
• Eclipse Platformの紹介とその動作については、Greg AdamsとMarc Ericksonの記事「Eclipse Platformの利用」(developerWorks、2001年11月) をお読みください。
  
  
• Eclipseの詳細については、eclipse.org Webサイトをご覧ください。
  

著者について

		Dan Kehn は、ノースカロライナ州Research Triangle ParkにあるIBMのシニア・ソフトウェア・エンジニアです。彼がオブジェクト指向プログラミングに関心を持ったのは1985年であり、オブジェクト指向プログラミングが今日のように広く受け入れられるようになるずっと前のことでした。彼は、VisualAge for Smalltalkなどの開発ツールや、オペレーティング・システム・パフォーマンスおよびメモリーの分析、インターフェース設計に取り組み、ソフトウェアに関して幅広い経験があります。Danは、ヨーロッパ滞在中は4年間、米国滞在中はその全期間にわたって、オブジェクト指向開発プロジェクトのコンサルタントとして勤務しました。最近は、オブジェクト指向分析 / 設計、プログラミング・ツール、およびWebSphere Application ServerによるWebプログラミングなどに関心を寄せています。彼は昨年、Eclipse Jumpstartチームに加わりました。このチームの主な目的は、ISVがEclipse Platformに基づいて市販用の製品を開発するのを支援することです。その他にも、Danは、メタ・プログラミング、チーム開発、メモリー分析など、 Smalltalkに関する様々なトピックに関する記事をいくつも書いています。これらの記事は、Eye on SmallTalk でご覧になれます。Danの連絡先は、kehn at us.ibm.com です。

		Scott Fairbrother は、ノースカロライナ州Research Triangle ParkにあるIBMのEclipse Jumpstartチームに勤務しています。彼は、ソフトウェア開発者として20年以上の経験があります。彼は、ビジネス・プロセス管理のためのオブジェクト指向アプリケーション・フレームワークを開発しました。また、Windows 2000のIBMミドルウェアの仕様を作成し、Microsoft Visual Studio .NETに関しても執筆しました。Scottの連絡先は、scottf at us.ibm.com です。

		Cam-Thu Le 氏は、1983年にIBMに入社しました。彼女の経験は、開発、テスト、ならびに各国語サポート (NLS) の計画および調整など、ソフトウェア開発の多くの面にわたります。Camは、4690 POS製品やVisualAge for SmalltalkといったIBM製品の各国語バージョンを世界中で同時に出荷する上で主導的な役割を果たしました。彼女は去年、NLSの中心であるEclipse Projectに加わり、Eclipse WorkbenchおよびWebSphere Studio Workbenchの各国語バージョンを構築およびテストする際のとりまとめを行いました。Camの連絡先は、camle at us.ibm.com です。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る