実際に取り組んだプロジェクトで国際化 (i18n) をどのように実装しましたか?
私は Joel の有名な投稿、 The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)を読んだ後、ソフトウェアを異文化に対応させることに興味を持ちました。ただし、可能であれば 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 全体を反転 (ヘブライ語、アラビア語) する必要がある場合があります。それはアジアに行く前の話です。
翻訳前のテスト
非技術的な問題
場合によっては、文化の違いに敏感になる必要があります (不快感や理解不能が生じる可能性があります)。よく見かける間違いは、ウェブサイトの言語や地域を選択する視覚的な合図としてフラグを使用することです。あなたのソフトウェアがグローバルな政治への支持を宣言したいのでない限り、これは悪い考えです。あなたがフランス人で、セント ジョージズ フラグ (イングランドの国旗は白地に赤十字) で英語のオプションを提供した場合、これは多くの英語話者にとって混乱を招く可能性があります - 同様の問題が外国語や外国で発生すると想定してください。 . アイコンは、文化的な関連性について吟味する必要があります。サムズアップまたは緑色のチェックマークは何を意味しますか? 言葉遣いは比較的中立的なものにする必要があります。特定の方法でユーザーに話しかけることは、ある地域では許容されますが、別の地域では失礼と見なされる場合があります。
資力
C++ および Java プログラマーは、ICU の Web サイト ( http://www.icu-project.org/ ) が役立つ場合があります。
いくつかの楽しいこと:
ドイツ語とフランス語でうまく動作する PHP と MySQL アプリケーションを用意していますが、ロシア語と中国語をサポートする必要があります。PHP の Unicode サポートは (私の意見では) あまり良くないので、これを .net に移行すると思います。確かに、utf8_de/encode や mbstring-functions をいじくり回すのは楽しいものです。フレディ・クリューガーが夜にあなたを訪ねてくるのと同じくらい楽しい...
一部の言語は他の言語よりもはるかに冗長であることを認識しています。ドイツ語は通常、英語よりもはるかに冗長であり、割り当てられたスペースが少なすぎるためにドイツ語版がどのようにユーザー インターフェイスを破壊するかを見るのは面白くありませんでした。一部の製品は、Oblivion の「Schw.Tr.d.Le.En.W.」で、それを回避する独創的な方法で名声を得ました。思い出に残る:-)
日付形式をいじって、うわー！はい、実際には、一日が真ん中にある日付形式を使用する人が世界中にいます. 2008 年 7 月 2 日が何を意味するのかを調べるのはとても楽しいです。一部のユーザーは、それが 7 月 2 日である可能性があると信じているからです。真ん中の月:-P、特に英語では、7 月 2 日は 7 月 2 日よりもはるかによく聞こえるため、他の言語には必ずしも当てはまりません (つまり、ドイツ語では、Juli 2 とは決して言いませんが、常に Zweiter Juli とは言いません)。私は可能な限り 2008-02-07 を使用します。これは 2 月 7 日を意味し、適切にソートされることは明らかですが、dd/mm と mm/dd は非常に難しい問題になる可能性があります。
もう1つの楽しいこと、数値フォーマット！10.000,50 対 10,000.50 対 10 000,50 対 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 ファイル (または任意のローカリゼーション) を変更できます。単語を並べ替える必要がある特定の言語のファイル)。
私は今朝スコット・ハンゼルマンからのポッドキャストを聞いていました。そこで彼は国際化、特にトルコ語（4つのi）やタイ語のような本当にトリッキーなことについて話します。また、ジェフ・アトウッドには投稿がありました：
これまでのすべてのヒントに加えて、i18n は、他の言語、特に右から左に書かれた非ラテン語のアルファベット (韓国語、アラビア語) の同等の単語を変更するだけではないことを覚えておいてください。そのため、UI 全体が適合する必要があります。
でなければならないだろう
アラビア語のテキスト 1 -
アラビア語のテキスト 2 -
アラビア語のテキスト 3 -
(逆の箇条書きリストは機能しないようです:P)
ユーザーが使用する言語を変更すると、システムが動的に変更を適用する必要がある場合、これは UI の悪夢になる可能性があります。
もう1つの非常に難しいことは、単語の正確さだけでなく、さまざまな言語をテストすることです.韓国語などの言語は通常、文字のフォントタイプが大きいため、言語固有のバグにつながる可能性があります(ボタンの「SAVE」テキストが一部の言語のボタン自体）。
おもしろいことに、イタリック体と太字のテキスト マークラップは、CJK (中国語/日本語/韓国語) 文字では機能しません。それらは単に読めなくなります。（わかりました、どちらも以前は本当に読めませんでしたが、特に太字はインクのしみを作成するだけです）
もう 1 つの課題は、ユーザーからの入力を受け入れることです。多くの場合、これは、一般的なテキスト ウィジェットと透過的に動作する Windows の IME など、オペレーティング システムによって提供される入力処理によって緩和されますが、この機能はあらゆるニーズに対応できるわけではありません。
国際化に携わるすべての人は、Unicode のサブプロジェクトである Common Locale Data Repository に精通している必要があると思います。
それらの人々は、あらゆる種類の i18n の問題 (通貨、地名、大量のもの) の標準的なリソースを確立するために懸命に取り組んでいます。このプロジェクトが存在することを考えると、独自のコアローカルデータを維持しているプロジェクトは、かなりばかげています、私見です。
翻訳を維持するために99translations.comのようなものを使用することをお勧めします。そうしないと、すべての言語でどの翻訳が最新であるかを知ることができなくなります。
私が使用している Web サイトには、所有者が「wiki + 機械翻訳」と呼ぶ翻訳方法があります。これはコミュニティベースのサイトなので、企業のニーズとは明らかに異なります.
http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/
まだ誰も言及していないことの 1 つは、「ユニットは 5 日後に到着します」または「月曜日に何かが起こる」のように、いくつかの用心深い部分を持つ文字列です。5 と月曜日は州によって異なります。それらを 2 つに分割して連結するのは得策ではありません。1 つの異なる部分と優れたドキュメントがあれば、問題は解決するかもしれません。