レベル: 初級 Dan Kehn, Senior Software Engineer, IBM
2001年 7月 02日 この記事では、国際化対応製品を検証する方法を示し、翻訳テストの際に生じることが予想される一般的な問題のための対応を示します。この記事には、プロパティー・ファイル比較 ビューを定義するEclipseプラグインが含まれています。このプラグインを使用することにより、翻訳テスターはエラーを迅速に検出することができます。
翻訳検証テスト
このEclipseプラグインの国際化対応シリーズの最初の記事で示した国際化対応ステップに従った読者は、各国語 (NL) のリソース (*.propertiesファイル、HTMLファイル、アイコンなど) を翻訳センターに送信したはずです。それらの項目が戻され、それを再び製品に組み込みました。さて、次は何をすればよいのでしょうか?かけた時間と費用にふさわしい見返りを得るためには、翻訳された言語で製品が正しく機能すること、および製品が実際に使用されるコンテキストで正しい意味を持つことを検証しなければなりません。このプロセスは、翻訳検証テスト (Translation Verification Testing (TVT)) と呼ばれます。
TVTは、プロセスと技法の2つの側面から見ることができます。ここで採用するプロセス は、製品機能の妥当性検査ですでに使用したプロセスと似ていると思われるかもしれません。しかし、ここで利用する特定の技法 は、まったく特別なもので、何を選択するかによってテスト・プロセスの品質および効率が左右されます。この記事では、翻訳検査技法と、典型的なエラーの概要を示し、翻訳テスターの効率および効果を向上させるために役立つツールを提供します。このツールは、ここからダウンロードすることができます。
理想を言えば、製品の各国語版 (NLV) と国内版は、同時に開発され、国内版の出荷前に翻訳のテストを済ませて、同時に出荷されるべきです。各国語対応の製品の2回目以降のリリースでは、それが特に望まれます。しかし、初回リリースの場合には、コードがNL対応となった状態で、翻訳を待たずに、国内版がリリースされることがあります。NL対応させる必要のある素材の量によって異なりますが、言語翻訳には数週間または数か月かかることがあり、その間国内版のリリースを控えておくわけにはいきませんので、多くの場合、これはやむをえないことです。
Eclipse Workbenchバージョン1.0の場合もそうでした。今後のEclipseリリースでは、翻訳およびテストの作業の大半は前のリリースで行われていますので、国内版と国際化対応版のリリース時期はほぼ同時に近くなるはずです。妥当性テスト・サイクルを計画するときには、翻訳によって影響を受けた素材の量に比例させて、テストに割く時間と人員の量を考慮してください。一般的に、翻訳対象素材に対して小規模な変更を行う場合には、1行のコードの誤りでシステム全体の安定性を損ないかねない機能的な変更とは異なり、リスクは限定的です。そのため、バージョン2以降の翻訳作業は、バージョン1.0のときに要した時間と人員に比べて2/3から1/2程度までに規模を縮小することができます。
基本的な翻訳検証テストで行うこと
最高の成果を収めるには、NL版のオペレーティング・システムと対象地域の代表的なハードウェアを使用して、翻訳されたすべての言語について製品をテストする必要があります。しかし、サブセットを選択する必要がある場合には、次に示すガイドラインに従って製品のNL対応をテストしてください。
- 1バイト文字セット (SBCS) のテストを行う場合: ドイツ語を使用してください (ドイツ語のほうが英語に比べて長くなるためです)。オリジナル言語が適切に置き換えられているかどうかを検証するほかに、バッファー・オーバーフロー、表示されるメッセージの切り捨て、Latin-1以外の文字のデータ入力 (例えば、é、á、ä など)、およびページ・レイアウトの問題も検査してください。
- 2バイト文字セット (DBCS) のテストを行う場合: 日本語を使用してください。日本語には、DBCSに関連した全般的な要素が網羅されています。
- 両方向文字セット (BIDI) をテストする場合: ヘブライ語またはアラビア語を使用してください。これらは、BIDI言語の代表的なものです。
TVTでは、以下の検出に重点を置いてください。
- ロケールに対応した機能の不使用
- 翻訳によって生じたコードの新たな問題
- ハード・コーディングされたストリング
- テキスト長増大の問題
- 不注意で翻訳されてしまったストリング
- フォント変更、エンコード/コード・ページの問題
- コンテキストに合わない翻訳エラー
この記事では、これらの事項のすべてについて詳しく扱う余裕はありませんが、注意が及びにくい点については詳しく説明することにします。
TVT最前線からのヒント
製品のNL対応版を最小限の遅れで出荷できるように、すべてのテスト作業をNL対応版に振り向けたくなることがあります。しかしNL版で行われた修正が、国内版に悪影響を与える可能性もあります。コード修正を適用するかどうかを決めるときには、その修正が完成後の製品にとってどの程度重要であるのかを判断してください。翻訳テスターは、自分たちの文化のコンテキストに合わない翻訳の欠陥による、悪い影響には敏感です。報告された問題の優先順位を決めるときには、彼らの意見を参考にしてください。国内版の安定性を損ねかねないような修正を無理に行わないでください。ただし、翻訳後の製品の一部が使用できなくなるような問題は、後回しにしないでください。自分の判断を信じて、問題に関する「絶対に必要な修正」のリストを作成してください。
共通問題のテスト
プロの機能テスターは、誰でも、境界テスト、ストレス・テスト、共通パス・テストなど、自分が専門とする得意な問題分野を持っています。翻訳テストのプロについても、同じことが言えます。彼らは、テスト対象の言語に精通し、頭の中で一般的な問題分野のリストを作り上げています。これらの分野のほとんどは、すべてのターゲット言語への翻訳に適用されますが、特定の言語、文化、または国だけに当てはまるものもあります。ここでは、前者のほうに注目しましょう。これらの問題には、ターゲット言語を習得しなくても対処することができるからです。そしてまた、検証テストの初期段階で (つまり、翻訳テストの専門家が到着して時間とお金が使われる前に) 修正を適用することができます。
 |
アクセント付き文字に関するヒント
国際化キーボード・レイアウトに関するWindowsのサポートは、QWERTYキーボードでアクセント付き文字を入力するのに役立ちます。このサポートにより、アクセント付き文字のいわゆる「デッド・キー」入力を行うことが可能になります。例えば、「単一引用符 + アクセントを付けたい文字」と入力すると、その文字に揚音アクセントが付きます('+e =é、'+a = á、その他)。同様に、脱字記号 (^) を使用すると曲折アクセント記号(â) が付き、抑音符号修飾子 (`) を使用すると抑音アクセント (à) が付き、二重引用符 (") を使用すると分音符号 (ä) が付きます。ただし、これによってQWERTYキーボードのユーザーがアクセント付き文字を入力できるようにはなりますが、「ネイティブ」キーボード上のそれに相当するアクセント・キーが使用できるとはかぎりません。これは、2つのケースでのキー・スキャン・コード・シーケンスが異なり、入力エラーが非ネイティブ・キーボードで検出されない可能性があるためです。2バイト文字の入力エラーも、やはり問題となります。Windowsは非DBCSマシンでの2バイト文字入力をサポートしますが、そのセットアップは単にキーボード・レイアウトの切り替えを行うだけでなく、DBCSフォントのインストールと複数ストローク・キーの使用が必要になります。
|
|
ロケールに対応した機能の不使用
このタイプの問題は、Eclipseプラグインの国際化対応およびJava Tutorial: Internationalization trailで述べられている、ロケールに特有のデータ表示に集中して起こります。開発者は、まず、数値、通貨、時刻、および日付に関する地域設定を変更して、現在のロケールを使用してこれらのフィールドが実際に表示されること、および入力が予想どおりに受け入れられることを確認することによって、前もってこれをテストすることができます。リストにアクセント付き文字が含まれている場合であっても、リストが正しくソートされることを確認してください。正確な照合順序は非ネイティブには確認できないため、ネイティブの翻訳テスターにまかせる必要がありますが、一般にアクセントの付かない文字とそれに対応するアクセント付き文字は、相互に近い位置にソートされるものと予想できます。つまり、Collator クラスまたはそれに相当するクラスをソートに使用していない場合には、すぐに分かります。一般にバイナリー比較では、アクセント付き文字はアクセントのない対応文字とは非常に離れた位置に現れるためです (例えば、a = \u0061、á = \u00e8)。
幸いなことに、ロケール対応のJavaのクラスを使用していないという失敗は、この記事の後の部分でリストする問題ほど一般的ではありません。おそらくこれは、ロケールに依存するフィールドが少数派に属しているためと考えられます。プログラマーも、翻訳プロセス自体によって生じる問題に比べ、これらのクラスによって解決するような性質のNL問題は直感的に識別できる傾向があります。これから述べる、より微妙なテストの問題に移る前に、入力フィールドへの入力について考慮する必要があります。アクセント付き文字を入力できること、およびそれらの文字を永続記憶域から再読み取りしたときに、コード・ページ変換によって (またはコード・ページ変換が行われないことによって) 文字が損なわれないことを確認してください。Unicodeを意識しない操作によって2バイト文字が破壊 (分割) されないことを確認してください。
翻訳によって生じたコードの新たな問題
このタイプの問題の特性について一般的なことを述べるのは難しいのですが、NLデータの形式がプログラマーのネイティブ言語に準拠していると思い込んだり、あるいはデータがNLの影響をまったく受けないと考えたりという、誤った想定を原因とする点では共通しています。例えば、区切り文字がピリオドまたはスペースであるという想定のもとにテキストを構文解析したり、適切なユーザー入力フィールドの妥当性検査をコーディングしないで、データベース列名などのような、文字セットの影響を受けるデータを定義または変更するためのNLデータを不用意に使用したりするなどの例があります。
ハード・コーディングされたストリングのテスト
ハード・コーディングされたストリングは、他のすべての原因を数量ではるかに圧倒する、あらゆるTVTエラーの温床です。これを探し出す基本的な方法として、ブラック・ボックス・アプローチとホワイト・ボックス・アプローチの2つがあります。ホワイト・ボックス・アプローチ は、Javaソース・コード、XML、およびHTMLをスキャンすることによって、ハード・コーディングされたストリングを探します。Eclipse Workbench Java Development Tooling (JDT) のExternal Strings ウィザードを使用すると、Javaソース・コードのスキャン・プロセスが自動化されます。
ブラック・ボックス・アプローチ では、その多くの作業が人手によって行われます。すべての製品のユーザー・インターフェース・エレメント (ビュー、メニュー、ダイアログなど) をUS英語以外のワークステーションで表示し、テスターがそれを見てすべてのテキストが翻訳されていることを確認するという、テスト・ケース・シナリオの実行に依存するためです。
ただし、その中間に位置するグレー・ボックス・アプローチ という方法もあります。この方法では、すべてのテキストが、同じ文字数およびワード数の認識しやすいストリングに翻訳されます。例えば、次の情報メッセージは、
Import resources from the local file system
以下のようになります。
***** ********* **** *** ***** **** ******
製品テスト・チームが賢くも自動化されたテスト・ツールを使用するなら、スクリプトを変更して、ストリングがハード・コーディングされていてブラック・ボックス・アプローチでは検出されないような事例を検出するようにすることができるでしょう。こうした見落としが生じる原因としては、翻訳されていないサード・パーティー製品が製品の中で使用されていることや、合成されたストリングが存在していることなどが考えられます。テストを自動化するメリットがない場合でも、このアプローチを使用することにより、ハード・コーディングされたストリングを手作業で簡単に検出できるようになります。さらに、特定の言語スキルを必要としないという利点もあります。テスターの中には、「ピッグ・ラテン」アプローチを愛用する人もいます。この場合、上記の例は次のようになります。
Importway esourcesray omfray ethay ocallay ilefay ystemsay
この方法には、ある程度の読みやすさを維持しながら、どのテキストが翻訳されていないかを明らかにできるという利点があります。
誤って翻訳されたストリングのテスト
グレー・ボックス・アプローチは、おそらく、すべてのストリングが翻訳されていることを確認する方法として、最も厳密です。しかしこの方法は、不注意で翻訳されてしまったストリングがないことを確認する場合にも役立ちます。例えば、下記のプロパティー・ファイルorg.eclipse.jdt.internal.formatter\options.properties からの抜粋について考えてください。
style.reuseExistingLayout.number=8
style.reuseExistingLayout.category=Style
style.reuseExistingLayout.name=&Reuse existing layout
style.reuseExistingLayout.possibleValues=2|Reuse|Do not reuse
style.reuseExistingLayout.description=If the user formatted code a certain way, ...
|
明らかにユーザー・テキストと分かるものすべてをアスタリスクに変換したものには次のキーと値が含まれているでしょう。
style.reuseExistingLayout.possibleValues=2|*****|** *** ***** |
これ自身が実行時のバグを引き起こすとは限らない一方で、これらの値が実際に、ユーザーの設定を保存するがどうかのキーであるかは明白ではありません (つまり、”Reuse”か、”Do not reuse”であるかがエンド・ユーザーに示されることがありません)。翻訳者が、英語では区別されている2つの用語をターゲット言語で同じ語に翻訳してしまうと、一方の設定を変更したときに、無関係な設定まで上書きされる可能性があります。
翻訳可能テキストとランタイム・パラメーター化の両方にプロパティー・ファイルを使用することには、上記のような危険性があります。確かにこれはプログラミング手法として有効ですが、翻訳者がその危険性を認識していなければなりません。少なくとも、プロパティー・ファイル自体にコメントを追加して知らせる必要があります。より好ましい方法としては、明確な方針に基づいた値を使用するやり方があります。前の例に戻ってみましょう。
style.reuseExistingLayout.possibleValues=2|REUSE_LAYOUT_YES|REUSE_LAYOUT_NO |
この場合、翻訳者にとっても彼らの翻訳ツールにとっても、等号の後の値を変更すべきでないことは明らかです。
テキスト長増大の問題のテスト
英語テキストを他のヨーロッパ言語に翻訳すると、平均して40%前後テキストが長くなります。以下の例について考えてみてください。最初に、英語で1つの単語が、ドイツ語では2語になることがあります。
Restart -> Neu starten
7文字が11文字に増える程度のことは問題となりません。しかし、次の例はどうでしょうか?英語で2つの単語をドイツ語に翻訳すると、1つの (長い) 単語になります。
Counter Logs -> Leistungsindikatorenprotokolle
12文字が30文字にまで増えてしまいました!ドイツ語のテキストが英語に比べて長くなることはよく知られていますが、これは、ドイツ語に限ったことではありません。"air bag" (エア・バッグ) に相当するAcademie Française (アカデミー・フランセーズ) 公認のフランス語は、coussin gonflable de sécurité です。翻訳前の開発段階でこれに対処するためには、プロパティー・ファイルのテキストを変更して、長さを2倍にすることができます。これがテスト・ケースであることを明らかにするために、単純なスクリプトを使用してそれぞれの語を2回繰り返すことができます。再び上記の例を使用します。
Import import resources resources from from the the local local file file system system
このようにしてからアプリケーションを再実行しても、ページ・レイアウトが適切であること、およびテキストが切り捨てられないことなどを確認してください。ページのサイズ変更が可能な場合には、4つのそれぞれの隅からサイズ変更を行ってみてください。このテストにも弱点があります。このテストでは、フレーズにスペースが含まれていて、単語の自動次行送りが可能であることが想定されていますが、ローマ字以外の文字を使用する言語のうちのいくつかは、そのようになっていないためです。
レイアウトの都合で翻訳テキストを最小にする必要がある場合には、オリジナル言語のファイル内で制限を明記してください。例えば、コメントを追加します。
# translation note: Text below is limited to approximately 60
# characters, see testcase 1.13 to validate
|
これにより、翻訳者は、冗長な訳文が許されないことを自覚するようになります。テスト・ケース参照を使用すると、翻訳テスターは、テキストが切り捨てられないことを確認できるようになります。プロポーショナル・フォントでは、文字の選択によって最終的なテキスト幅が変化するためです。翻訳者には、表の列幅、特にサイズ変換できない列幅などの、レイアウト制約を指定する能力も必要です。
# translation note: Width in pixels of the "Completed"
# column. The text is a 'C' in US English, it should
# be as short as possible in the translation.
taskList.completedHeading=C
taskList.completedHeadingwidth="10"
|
こうすることにより、翻訳者または翻訳テスターは、不自然に短い翻訳に頼ることなく、言語およびオペレーティング・システムに関連付けられたデフォルト・フォントを考慮して、最適サイズの翻訳を行うことができます。
注: テキスト切り捨てが起こると、スクロール、他のダイアログの表示、または「続く >>」ボタンの提供などの、代替ユーザー・インターフェース・メカニズムを利用しても、完全なテキストを見ることができなくなります。テキストが切り捨てられて見えなくなってしまうことは、ユーザーが表示エリアをスクロールしなければらない事態に比べ、明らかに深刻です。これらの理由およびアクセシビリティを考慮して、スクロールや折り返しができないようなテキスト域は作成しないようにしてください。
フォント・サイズ変更のテスト
フォント・ピクセル・サイズは、オペレーティング・システムや言語が異なると、高さと幅が変更される可能性があります。こうしたケースの多くは、基本ウィジェットによって処理されます。例えば、テキスト・フィールドが、大きなフォントに合わせて自動的にサイズ変更されたり、必要に応じて自動スクロールしたりします。しかし、ユーザー独自のグラフィックスおよびテキストを作成した場合、テキストが勝手に切り捨てられないように、適切なシステム・メトリックを照会する必要があります。
特に、2バイト言語フォントの場合には、一般に最小の高さが単一バイト言語フォントよりも大きくなるため、こうしたことを考慮する必要があります。余談ですが、Section 508 アクセシビリティに準拠するためには、フォント・サイズ変更の処理は必要ありません が、視覚障害者など大きなフォントに変更したい人からは尊重されています。Windowsでは、デフォルト・フォントのサイズを大きくしてマシンを再始動することにより、クイック・テストを行うことができます (「画面 > 設定> 詳細 > 全般 > フォント サイズ > 大きいフォント」)。ユーザーが日常的に使用しているアプリケーションでこのテストを行うと、失敗するアプリケーションの多さに驚かれることと思います。こうした例を見習わないようにしてください。
コンテキストに合わない翻訳のエラーのテスト
こうした翻訳の品質に直接影響する要素として、コンテキストの明瞭さがあります。これは、プロパティー・ファイルの翻訳時に明らかになります。
これは架空の例ですが、問題を的確に表しています。このメッセージはどのようなコンテキストで表示されているのでしょうか?最初のパラメーターが日付で、2番目のパラメーターが時刻を表している可能性があります。しかし、最初のパラメーターはリソースで、2番目のパラメーターはそれが保管されているサーバーのURLであるとも考えられます。コメントによる指示がなければ、翻訳者は最も可能性の高い選択肢に合わせて逐語訳するしかありません。
Eclipse Workbenchからの実例を次に示します。
WorkbenchPreference.autobuild = Perform build automatically on resource modification
|
このコンテキストでは、「on」は、「リソースが変更されたとき」を意味します。これは、Workbenchユーザーには分かりきったことかもしれませんが、最初の翻訳は特定の製品に関する知識のない中央組織によって行われます。「リソース変更」ということが彼らにはよく分からないため、「on」が文字通りに「の上に」と解釈されたり、「スーパー・タスクとして」のようなきわめて狭いプログラム用語として解釈されたりする可能性があります。
プロパティー・ファイルに注記を追加して、翻訳者に特定のメッセージのコンテキストを知らせるような配慮が必要です。特に、主語が明示されていない場合にはこうしたことが大切です。多くの言語では、主語がはっきり分からないと形容詞や動詞の正確な形式が選択できないためです。Javaソース・コード・エディターでマーカーとして表示された、JDTから出されるメッセージの例を示します。ここで使われているコメントは、翻訳者にとって分かりやすいコメントの例となっています。
# Note: The error messages below are displayed in the Java source
# editor with an "X" next to the offending line. They are also
# displayed in the Task List with a reference back to the file.
# Double-clicking the error in the Task List will open the editor
# and scroll to the corresponding line number.
# The subject is a method, i.e., "Method must return a result of type 'x'"
108 = Must return a result of type {0}
# "Variable (or field) must provide either dimension expressions...
159 = Must provide either dimension expressions or an array initializer
# "Class must implement the inherited abstract method 'x'"
400 = Must implement the inherited abstract method {0}
# "This class overrides deprecated method from 'its superclass'"
412 = Overrides deprecated method from {0}
|
このようなメッセージを書く開発者に対して、語句の微妙な解釈に対する意識を誰も期待していません。上の例は、開発者が最大限の努力をしても、翻訳テストに代わるものがないことを示しています。
翻訳漏れのテスト
翻訳された製品の稼働バージョンでTVTを行うほかに、「プロパティー・ファイル比較」ビューを使用することにより、テスト・サイクルを短縮し、一般的なエラーを検出することができます。これにより、製品のNL版の品質を向上させることができます。
このツールの目的は、次の2点に要約されます。
- 翻訳されたファイルの内容を、オリジナル言語のファイルと隣り合わせて表示することにより、翻訳検証の速度を上げる。これは、「コンテキストに合わない」翻訳を検証することを目的としていますが、テスターは、短時間で翻訳をレビューでき、ファイルのすべての内容が翻訳され、正しいコード・ページに変換されていることも確認できます。
- リリースされたNL製品で、翻訳されたファイルにキーワード漏れがあるために例外がthrowされることがないようにする。
オリジナルのソース言語ファイルが翻訳のために送られる時期と、TVTが開始される時期には、時間的なずれがあります。この間に、コード (さらには、オリジナル・ソース言語ファイルのいくつか) が変更されている可能性もあります。翻訳には存在しない新規キーワードが追加され、それが原因でランタイム・エラーが発生することが考えられます。
このような状態を解決するために、このビューを使用して、ソース言語ファイルと対応する翻訳ファイルとを対比してください。抜けているキーワードがあると、このツールによってフラグが立てられ、ファイルの修正が行いやすくなります。
要約
製品を国際的な市場に対応させるには、費用と時間がかかります。しかし、世界各地でのソフトウェアの売上がなんらかの指標として使用されるような場合、この必要性を無視すること自体がコストをはらむことになります。このシリーズの最初の記事で示した技法や、この記事で示したテストに関するヒントおよびツールを活用することにより、présenter votre produit en n'importe quelle langue comme si c'était sa langue maternelle(製品を、どのような言語の場合にもネイティブ言語の製品のように提供する) ことが可能になります。
プロパティー・ファイルを対比するためのツール
翻訳検証テストでは、すでに述べた翻訳エラーを訂正するために、その言語に精通した人が製品を実際に実行する必要があります。このプロセスは、時間を要するため、退屈で、エラーのもとになることもあります。こうしたコストを軽減し、生産性を高め、最終的な製品の品質を向上させるために、私は、ランタイム・フォーマット設定およびパラメーター置換を使用して、2つのプロパティー・ファイルを隣り合わせて表示させる単純なビューを作成しました。これを使用することにより、言語のエキスパートは、初期の翻訳を迅速に検証し、稼働製品と同じようにフォーマット設定されたメッセージを見ることができます。このツールの
コードをダウンロード
してください。
より正確に言うと、プロパティー・ファイル比較 ツールによって対処できる問題は、次のようなものです。
- 言語のエキスパートが初期の翻訳を迅速に検証できるようにする。最初の翻訳は、製品に関する知識のない翻訳者によって、「大量に」行われます。彼らが使用する翻訳ツールは、翻訳の整合性を確保するためには役立ちますが、「現場検証」の代わりになりうるものではありません。翻訳検証テスターは、製品の裏まで知り尽くし、翻訳ファイルをオリジナルと対比して迅速に検討し、明白な不備を発見することができます。
- パラメーター置換を含め、稼働製品と同じようにフォーマット設定されたメッセージを見ることができるようにする。これにより、引用符が抜けていたり余分であったり、あるいは右括弧が抜けていたりという、よくある誤りを検出することができます。こうした誤りの大部分はソース言語で起こることですが、翻訳中に生じることもあります。単一引用符が余分であったり抜けてたりする誤りは、英語の場合にもよくあることです(例えば、"The process didnt complete" ではアポストロフィが抜けていますが、"The process didn''t complete" ではアポストロフィが余分です)。詳しくは、下記の引用符は1つなのか、2つなのか? を参照してください。
- メッセージが表示できることを確認する。あまりにも分かりきったことのようですが、エンコード/変換のエラーは珍しいことではありません (詳細については、Eclipseプラグインの国際化対応を参照してください)。実際のランタイム環境でプロパティー・ファイルをすぐに表示できるかどうかを調べることは、「健全さ」の検査としてお勧めできます。
- ソース言語で定義されたすべてのキーがターゲット言語のプロパティー・ファイルに存在し、ターゲット言語のプロパティー・ファイルに存在するすべてのキーがソース言語で定義されていることを確認する。ソース言語でキーが追加または削除され、適切な修正がターゲット言語ファイルにまで及ばなかったとき、およびターゲット言語ファイルから誤ってキーが削除されたときには、不一致が生じます。
- 未翻訳テキストにフラグを立てる。
プラグインをインストールした後で、「Perspectives >Show View > Java > Property Files Compare」と選択してください。そして、ソース言語とターゲット言語が入っているディレクトリーの名前を入力し、「Source Language Directory」フィールドまたは「Target Language Directory」フィールドがフォーカスされている状態でEnterキーを押すと、すべての *.propertiesファイルの検索が開始されます。左側に表示されたプロパティー・ファイルのうちの1つを選択すると、ディレクトリー・パス内の最後に "eclipse" が現れている個所から同じ部分ファイル指定の突き合わせが開始され、右側にあるその対応ターゲットの自動選択が試みられます。
図1. プロパティー・ファイル比較 (Properties file comparison) ビュー
例えば、Eclipse Workbenchがx:＼eclipse2.0 にインストールされている場合、Eclipseインストール・ルートはそのすぐ下のeclipse というサブディレクトリーになります。このビューは、(a) ネイティブ言語のプロパティー・ファイルが、言語ごとに別のサブディレクトリー・ツリーに分けて保持されていること、または、(b) オリジナル言語 (ソース) ファイルには国別接尾部がなく、ターゲット・ファイルには、オペレーティング・システムから戻された国別コードに基づく接尾部があることを前提としています。例えば、次の例を見てください。
(a) ディレクトリーごとに言語が分けられている場合
x:＼english＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin.properties
x:＼french＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin.properties
x:＼german＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin.properties
(b) 国特有のファイル接尾部ごとに言語が分けられている場合
x:＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin.properties
x:＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin_fr.properties
x:＼eclipse＼plugins＼org.eclipse.core.jdt＼plugin_de.properties
|
したがって、最初のディレクトリー・フィールドにx:＼english と入力してEnterキーを押すと、Englishサブディレクトリーから検索が開始されます。2番目のディレクトリー・フィールドにx:＼french と入力すると、Frenchサブディレクトリーから検索が開始されます。「Source Language」リストの中から検索されたプロパティー・ファイルを選択すると、「Target Language」リスト内の対応するファイルが自動的に選択され、その内容がキーでソートされて表示されます。
「プロパティー・ファイル比較」ビューは便利ですが、機能がかなり限られています。また、実はディレクトリー構造に関する想定が行われているため、窮屈さを感じる人もいるのではないかと思います。ここで弁解をさせていただくと、問題解決のために急いで開発したものであって、しかもその後改良を加える暇がなかったのです。ここでダウンロードできるようにしてあるのは、そのソース・コードがEclipseプラグイン開発の立派なお手本ではないことを承知したうえで使っていただくのであれば、読者の役に立つのでなないかと考えたからです。
注: このほかにもう1つ、RBManager と呼ばれるツールがalphaWorksから入手可能になっています。そこに記載された説明によると、「RBManager (リソース・バンドル・マネージャー) は、リソースにバンドルされるファイルの作成、更新、および管理に関連する退屈な作業の多くを自動化するツールであり、また、きわめて一般的な誤りがバンドル間で広がるのを防いでくれます。このツールは、アプリケーションおよびWebベースのサービスの国際化に取り組む開発チームにとって役に立ちます。」
RBManagerにはプロパティー・ファイル・ビューを対比する機能はありませんが (これから追加されるのでしょうか?)、一般に翻訳に関連する多くのリソース・ファイルを管理するために役立つことは確かです。RBManagerには、立派な文書とチュートリアルが備わっています。
引用符は1つなのか、2つなのか?
プロパティー・ファイル・メッセージをどのようなフォーマットにするのかによって、単一引用符の入力方法 (つまり、2回続ける必要があるのか1回だけでよいのか) が影響を受けます。この問題を理解するために、次のコードを見てください。
package com.ibm.jumpstart.messageformattest;
import java.text.MessageFormat;
public class MessageFormatTest {
public static void main(String[] args) {
String msg1 = "This is a ''{0}'' program and it''s not ready for production.";
String msg2 = "This is a beta program and it's not ready for production.";
String msg3 = "This is a beta program and it's not ready for {0}.";
System.out.println(MessageFormat.format(msg1, new String[] {"beta"}));
System.out.println(MessageFormat.format(msg2, new String[0]));
System.out.println(msg2);
System.out.println(MessageFormat.format(msg3, new String[] {"production"}));
System.out.println(msg3);
}
}
出力は次のようになります。This is a 'beta' program and it's not ready for production.
This is a beta program and its not ready for production.
This is a beta program and it's not ready for production.
This is a beta program and its not ready for {0}.
This is a beta program and it's not ready for {0}.
|
4行目は特に問題となります。アポストロフィが抜けているだけでなく、パラメーター置換も行われていません。これらの違いが生じるのは、MessageFormat が、出力に引用符を含める必要がある場合には引用符が2回入力されるものと想定しているためです。このこと自体は問題ではないのですが、あるプログラマーはMessageFormatを使用し、別のプログラマーは独自の方法でパラメーター置換を行い、さらに別のプログラマーは置換パラメーターがない場合にMessageFormatをまったく使用しないとしたら、どうなるでしょう?翻訳者は、翻訳対象テキストがどのコードで処理されるのかを知るはずがありませんので、必要な単一引用符/アポストロフィをどのように入力するのかを知っていなければなりません。
Eclipse Workbenchバージョン1.0のTVTでは、必要な引用符について次のような規則を採用しています。
- 置換パラメーターがない場合には、引用符を1つだけ入力する。
- 置換パラメーター ({0} など) がある場合には、引用符を2つ入力する。
この規則は、事実上すべてのプログラムが、置換パラメーターがある場合にだけMessageFormatを使用していることを踏まえて決められたものです。こうしたプログラミングの不整合を避ける目的で、Eclipse JDTのバージョン2.0には、メッセージの検索とパラメーター置換を中央に集約させやすくするための、Externalize Strings (ストリング外部化) ウィザードが組み込まれています。必要な引用符の規則を1つに統一するために、このストラテジーを採用するか、あるいは一貫性のある方法でMessageFormatを使用するかしてください。
参考文献
著者について | | | Dan Kehnは、ノース・カロライナ州Research Triangle Parkで勤務するIBMのシニア・ソフトウェア・エンジニアです。彼は今日では幅広く受け入れられているオブジェクト指向のプログラミングに1985年より関心を持っています。彼は豊富なソフトウェア経験を持っており、VisualAge for Smalltalkのようなツールの開発やオペレーティング・システムやメモリー分析、ユーザー・インターフェースの設計などに従事してきました。Danはヨーロッパで4年間さらにU.S.の至る所でオブジェクト指向開発プロジェクトのコンサルタントとして働いてきました。彼は最近、オブジェクト指向の分析/設計、アプリケーション開発ツール、WebSphere Application ServerでのWebプログラミングに興味を持っています。2001年5月には、Eclipse Jumpstartチームに加わりました。チームの主な目的は、Eclipse Platformベースの製品を開発するISVの支援です。彼とJumpstartチームのメンバーで、この記事でソリューションを抜粋している「The Java Developer's Guide to Eclipse 」を執筆しました。 |
記事の評価
| 
