プロジェクトの国際化

08-06-2019
|

質問

実際に取り組んだプロジェクトでは国際化 (i18n) をどのように実装しましたか?

私は Joel の有名な投稿を読んでから、ソフトウェアを異文化間で作ることに興味を持ちました。すべてのソフトウェア開発者が絶対に、積極的に Unicode と文字セットについて知っておくべき絶対最低限の事項 (言い訳はできません!). 。ただし、可能な限り Unicode 文字列を使用するようにした以外は、実際のプロジェクトでこれを活用することはまだできていません。しかし、すべての文字列を Unicode にし、作業するすべての文字列がどのようなエンコーディングで使用されているかを確実に理解できるようにすることは、i18n の氷山の一角にすぎません。

私がこれまでに取り組んできたものはすべて、米国の英語を話す人々の管理されたセットによって使用されるためのものでした。あるいは、i18n は、プロジェクトを開始する前に取り組む時間がなかっただけです。そこで私は、現実世界のプロジェクトでソフトウェアをよりローカライズすることについて、人々が持つヒントや戦争の話を探しています。

正しい解決策はありません

他のヒント

しばらく時間が経ったので、これは包括的ではありません。

文字セット

Unicode は優れていますが、他の文字セットを無視することはできません。Windows XP (英語) のデフォルトの文字セットは Cp1252 です。Web では、ブラウザーが何を送信するかわかりません (ただし、コンテナーがそのほとんどを処理してくれるといいのですが)。また、使用している実装にバグがあっても驚かないでください。文字セットは、マシン間を移動するときにファイル名と興味深い相互作用を行うことがあります。

文字列の翻訳

一般的に言えば、翻訳者はプログラマーではありません。ソースファイルを翻訳者に送ると、翻訳者はそれを壊してしまいます。文字列はリソースファイルに抽出する必要があります (例:Java のプロパティファイル、または Visual C++ のリソース DLL)。翻訳者には、破損しにくいファイルと、ファイルを破損させないツールを提供する必要があります。

翻訳者は、文字列が製品内のどこから来たのかを知りません。文脈のない文字列を翻訳するのは困難です。ガイダンスを提供しないと、翻訳の品質が低下します。

コンテキストの話ですが、同じ文字列「foo」が複数回出現するのを見て、UI 内のすべてのインスタンスが同じリソースを指すようにした方が効率的だと考えるかもしれません。これは悪い考えです。言語によっては、単語が文脈に非常に依存する場合があります。

文字列の翻訳にはコストがかかります。製品の新しいバージョンをリリースする場合、古いバージョンをリカバリするのが合理的です。古いリソースファイルから文字列を復元するツールを用意します。

文字列の連結と文字列の手動操作は最小限に抑える必要があります。必要に応じてフォーマット関数を使用します。

翻訳者はホットキーを変更できる必要があります。 Ctrl+P 英語で印刷されます。ドイツ人が使う Ctrl+D.

いつでも誰かが手動で文字列をカットアンドペーストする必要がある翻訳プロセスがある場合、トラブルが発生します。

日付、時刻、カレンダー、通貨、数値形式、タイムゾーン

これらはすべて国によって異なる場合があります。小数点以下の桁を示すためにカンマを使用することもできます。時間は 24 時間表記である場合があります。誰もがグレゴリオ暦を使用しているわけではありません。明確である必要もあります。Web サイト上で日付を米国の場合は MM/DD/YYYY、英国の場合は DD/MM/YYYY として表示するように注意した場合、ユーザーがそれを行ったことを認識しない限り、日付は曖昧になります。

特に通貨

クラスライブラリで提供される Locale 関数を使用すると、現地通貨記号が得られますが、ドルでの価格を示す値の前にポンド (スターリング) またはユーロ記号を貼り付けるだけでは済みません。

ユーザーインターフェース

レイアウトは動的である必要があります。翻訳すると文字列の長さが 2 倍になる可能性が高いだけでなく、UI 全体を反転する必要がある場合もあります (ヘブライ語;アラビア語) なので、コントロールは右から左に実行されます。それはアジアに到達する前の話です。

翻訳前のテスト

コードの静的分析を使用して問題を特定します。少なくとも、IDE に組み込まれているツールを活用してください。(Eclipse ユーザーは、「ウィンドウ」>「設定」>「Java」>「コンパイラー」>「エラー/警告」に移動して、外部化されていない文字列を確認できます。)
翻訳をシミュレートしてスモークテスト。リソースファイルを解析し、文字列を長さを 2 倍にし、おかしな文字を挿入する疑似翻訳バージョンに置き換えることは、難しくありません。外国のオペレーティングシステムを使用するために言語を話す必要はありません。最新のシステムでは、翻訳された文字列と外国のロケールを使用して外国ユーザーとしてログインできるはずです。OS に精通していれば、言語をまったく知らなくても、何が何をするのかを理解できます。
キーボードマップと文字セットのリファレンスは非常に便利です。
ここでは仮想化が非常に役立ちます。

技術的以外の問題

場合によっては、文化の違いに敏感になる必要があります（不快感や無理解が生じる可能性があります）。よく見られる間違いは、Web サイトの言語または地域を選択する視覚的な合図として国旗を使用することです。ソフトウェアで世界政治のどちら側を宣言するかを希望しない限り、これは悪い考えです。あなたがフランス人で、St. に英語のオプションを提供した場合。ジョージの国旗 (イギリスの国旗は白地に赤十字です) ですが、これは多くの英語話者にとって混乱を招く可能性があります。外国語や外国でも同様の問題が生じると想定してください。アイコンは文化的な関連性を精査する必要があります。親指や緑色のチェックマークは何を意味しますか?言語は比較的中立的である必要があります。特定の方法でユーザーに話しかけることは、ある地域では許容されますが、別の地域では失礼とみなされる場合があります。

リソース

C++ および Java プログラマーは、ICU の Web サイトが役に立つかもしれません。 http://www.icu-project.org/

楽しいこと:

PHP および MySQL アプリケーションはドイツ語とフランス語で適切に動作しますが、ロシア語と中国語をサポートする必要があります。私の意見では、PHP の Unicode サポートはあまり良くないので、これを .net に移行すると思います。確かに、utf8_de/encode や mbstring 関数をいじるのは楽しいです。フレディ・クルーガーが夜に訪ねてくるのと同じくらい楽しい...
一部の言語は他の言語よりもはるかに冗長であることに気づきました。通常、ドイツ語は英語よりもはるかに冗長であり、割り当てられたスペースが少なすぎるためにドイツ語版がどのようにユーザーインターフェイスを破壊するかを見るのは楽しくありませんでした。一部の製品は、それを回避するための創造的な方法でいくつかの名声を得ました。思い出に残る:-)
日付形式をいじってみると、うわー!はい、実際に世界には、日が真ん中になる日付形式を使用している人がいます。2008 年 7 月 2 日が何を意味するのかを調べるのはとても楽しいです。ユーザーの中には、それが 7 月 2 日である可能性があると信じている人もいるかもしれないからです...しかし、繰り返しになりますが、池の向こうの皆さんも、月を真ん中に置くユーザーについては同じことを信じているかもしれません :-P、特に英語では、7 月 2 日よりも 7 月 2 日のほうがはるかに良く聞こえますが、これは他の言語には必ずしも当てはまりません。言語（すなわち、ドイツ語では、決して Juli 2 とは言わず、常に Zweiter Juli と言います)。可能な限り 2008-02-07 を使用します。これが 2 月 7 日を意味していることは明らかで、適切に分類されていますが、dd/mm とmm/dd は非常に難しい問題になる可能性があります。
もう一つ楽しいこと、数値形式！10.000.50 対 10,000.50 対10,000,50 vs.10,000、50...これは現時点で私にとって最大の悪夢です。多文化環境をサポートしなければならないのに、ユーザーが使用する数値形式を確実に知る方法がないのです。
公式か非公式か。言語によっては、人に話しかける際に、フォーマルな方法とよりカジュアルな方法の 2 つの方法があります。英語では「You」と言うだけですが、ドイツ語では、フランス語の Tu/Vous と同様に、正式な「Sie」と非公式の「Du」のどちらかを決める必要があります。通常は正式な方法を選択するのが安全ですが、これは見落とされがちです。
カレンダー。ヨーロッパでは週の最初の日は月曜日ですが、米国では日曜日です。カレンダーウィジェットは便利ですね。ヨーロッパのユーザーに、左側に日曜日、右側に土曜日が表示されたカレンダーを表示するのは、あまり良いものではなく、混乱させます。

私は以前の雇用主で .NET を使用するプロジェクトに取り組んでいましたが、そこで使用されていた組み込みの .resx 形式がありました。基本的に、.resx ファイルにすべての翻訳を含むファイルがあり、その後、異なる翻訳を持つ複数のファイルがありました。この結果、アプリケーションに表示されるすべての文字列が .resx に保存されるように細心の注意を払う必要があり、文字列が変更されるたびに、サポートするすべての言語を更新する必要があります。

怠けて翻訳担当者に通知しなかったり、ローカリゼーションシステムを経由せずに文字列を埋め込んだりすると、後で修正しようとするのは悪夢のようなことになります。同様に、ローカリゼーションが後付けの場合、導入するのは非常に困難になります。要するに、表示されるすべての文字列が外部の標準的な場所に保存されていない場合、ローカライズする必要がある文字列をすべて見つけるのは非常に困難になります。

もう 1 つの注意点として、表示される文字列を直接連結することは厳密に避けてください。

String message = "The " + item + " is on sale!";

代わりに、次のようなものを使用する必要があります

String message = String.Format("The {0} is on sale!", item);

その理由は、多くの場合、言語が異なると単語の順序が異なるためであり、文字列を直接連結すると修正するには新しいビルドが必要になりますが、上記のような何らかの文字列置換メカニズムを使用した場合は、.resx ファイル (またはその他のローカライゼーション) を変更できます。使用するファイル) の単語を並べ替える必要がある特定の言語に対応します。

私はちょうど聞いていましたスコット・ハンセルマンのポッドキャスト今朝、彼は国際化について、特にトルコ語 (i が 4 つある) やタイ語など、非常に難しいことについて話しています。また、ジェフ・アトウッドには役職:

これまでのすべてのヒントに加えて、i18n では、他の言語、特に右から左に書かれる非ラテン言語のアルファベット (韓国語、アラビア語) の場合は、単に単語を変更するだけではないことを覚えておいてください。そのため、UI 全体が次のように準拠する必要があります。

項目1
項目2
項目3

そうでなければならないだろう

アラビア語テキスト 1 -

アラビア語テキスト 2 -

アラビア語テキスト 3 -

(反転箇条書きリストは機能しないようです:P)

ユーザーが使用言語を変更すると、システムが動的に変更を適用する必要がある場合、これは UI の悪夢になる可能性があります。

もう 1 つの非常に難しいことは、単語の正しさだけでなく、さまざまな言語をテストすることです。ただし、韓国語のような言語は通常、文字のフォントタイプが大きいため、言語固有のバグが発生する可能性があります (ボタン上の「保存」のテキストが大きいなど)一部の言語ではボタン自体）。

発見すべき面白いことの 1 つは次のとおりです。イタリック体と太字のテキストマークアップは、CJK (中国語/日本語/韓国語) 文字では機能しません。単に判読できなくなるだけです。(OK、私も以前はまったく読めませんでしたが、特に太字だとインクのにじみができるだけです)

国際化に携わっている人なら誰でも、現在 Unicode のサブプロジェクトとなっている Common Locale Data Repository についてよく知っているはずだと思います。

共通ロケールデータリポジトリ

これらの人々は、あらゆる種類の i18n 問題に対する標準リソースを確立するために熱心に取り組んでいます。通貨、地名、たくさんのもの。このプロジェクトが存在することを考えると、独自のコアローカルデータを維持しているプロジェクトは、かなりおかしなことだと思います。

次のようなものを使用することをお勧めします 99translations.com 翻訳を維持するため。そうしないと、各言語でどの翻訳が最新であるかを判断できなくなります。

もう 1 つの課題は、ユーザーからの意見を受け入れることです。多くの場合、この問題は、一般的なテキストウィジェットと透過的に動作する Windows の IME など、オペレーティングシステムによって提供される入力処理によって緩和されますが、この機能はあらゆるニーズに対応できるわけではありません。

私が使用しているウェブサイトの 1 つは、所有者が「Wiki + 機械翻訳」と呼ぶ翻訳方法を採用しています。これはコミュニティベースのサイトなので、企業のニーズとは明らかに異なります。

http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/

誰も言及していないことの1つは、「ユニットは5日間で積み重なる」または「月曜日に何かが起こる」のように、いくつかの慎重な部分を持つ文字列です。州に応じて5と月曜日が変わる場所。これらを 2 つに分割して連結するのは得策ではありません。変化する部分が 1 つだけで、適切なドキュメントがあれば問題なく済むかもしれませんが、変化する部分が 2 つある場合は、それらの順序を変更することを好む言語が存在するでしょう。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow