国際化：何について考えるべきか？

私は、を聞いていたジョンスキートの話最後のStackOverflowのDev日で、彼は国際化に関する私の好奇心をそそりました。

ワッフル作成プログラムが完了しているか、またはまだ進行中で、他の国に配布したいとします。国際化に関してどのようなことを心配する必要がありますか？自明ではないが簡単な落とし穴は何ですか？

頭に浮かぶ最も明白なことは、あなたのラベルはおそらく英語版とは異なる長さになるということです。これはあなたのレイアウトに大混乱をもたらす可能性があります。

何エーカーものホワイトスペースになるか、ラベルが密集し、使用可能なスペースがあふれてしまう可能性があります。

コンテンツのサイズに関係なく、レイアウトを柔軟でフローにする必要があります。さまざまな画面解像度に対応できるレイアウトを用意すると、この問題を解決するのに役立ちます。

もう1つの大きな問題は、右から左への言語サポートです。この場合も、レイアウトを柔軟にする必要があります。

翻訳が必要なのは、メニューやダイアログだけではありません。サポートドキュメント、ヘルプファイル、ツールヒント、ウィンドウタイトルのキャプションもすべて含まれています。通常、アプリケーションで理解するよりもはるかに多くのテキストがあり、常にリソースとしてではなく直接追加されたいくつかの文字列があります。

タイムゾーンと日付のフォーマット！ タイムゾーン全体で日付と時刻をスケジュールするアプリケーションを扱うときは、正しいことを行ってください。

すべての日付と時刻の値は単一の時点を表すため、タイムスタンプとして保持します。ユーザーに正しい形式でタイムスタンプを正しく表示するにはタイムゾーン情報が必要になるため、タイムゾーンをさらに追跡します。

現在、日本のユーザーがアイダホでクライアントアプリケーションを実行しているユーザーの日時をスケジュールできるアプリケーションに取り組んでいます。ユーザーが誰もが話している3:00PMことを知っていることをユーザーが見たときに確認します3:00PM。

人が特定の国にいるからといって、その言語を知っているとは限らないことに注意してください。言語と場所は2つの異なる問題です。

数字。ヨーロッパ、南アメリカのほとんどは小数点としてカンマ（10,23）を使用し、残り（イギリス、米国など）はピリオド（10.23）を使用します。

必ずしも簡単なことではありません... 開発しているソフトウェアの複雑さと、どこに出荷するかによって、考慮すべきことがたくさんあります。実際、それはどこにでも行き着くかもしれないので、重要なことは、どのロケールを公式にサポートするかです。

• 明らかに、インターフェースの言語があります。使用するすべてのテキストは、他の言語の同等のテキストに変更するのが比較的簡単なはずです。誰かがすでに指摘したように、ラベルの長さはさまざまです。たとえば、中国語で書かれたものは、ドイツ語で書かれたものと同じ幅ではありません。基本的なインターフェースだけでなく、すべての情報バブル、ヘルプファイル、エラーメッセージ、ログファイルではないかもしれませんが、アプリケーションによって異なります。アプリケーションが言語をサポートしている場合、Webサイトも追いつく必要があるかもしれません。
• 文字コード。多くの言語を提供するのは良いことですが、それをどのように行うのですか？すべてが狭い/基本的な文字エンコーディングでプログラムされている場合、アクセントを使用したり、ほとんどの言語で文字を使用していないという問題が発生します。韓国語、またはアラビア語を考えてください。誰かができる限りUnicodeを使わなければならないと思います。
• ウィジェットの配置/ウィンドウの向き。たとえば、アラビア語をサポートすることを選択した場合、多かれ少なかれインターフェースをフリップする方法を考える必要があります。それらは右から左に読んでいるので、それらが説明する要素（たとえば、入力用のテキストボックス）の右側にラベルを付けるのは通常です。
• 数値のフォーマット。一部のロケールでは、数値の小数部と整数部を区切るために、ドットの代わりにコンマがあります。それはかなり明白ですが、アプリケーションドメインによっては、他にも考慮すべきことがたくさんあるかもしれません。括弧の間に負の数がありますか、または括弧の前に「-」がありますか？数千はスペースまたはコンマで区切られていますか？数字の区切りは常に3ですか、それとも最初のグループのみが3で、残りは2ですか？アラビア数字やインドなどを使用していますか？
• 日付のフォーマット。それはほとんど同じくらい複雑です。曜日、年の月の完全な名前を保存する必要があり、それらもすべて省略されます。どのような順序で使用していますか（日、月、年？月、日、年？年、月、日など）。
• 時間のフォーマット。24時間ですか、それとも12時間ですか？'：'または 'h'？「：」または「。」秒の間？時間の書式設定についてはあまり詳しくありませんが、時間を表示する方法は私には多くの不明な点があると思います。
• グラフィックス！アイコンがある場合...それらの文字や単語がすべてのロケールで引き続き意味があることだけでなく、使用するシンボルも意味があり、正しい方向であることを確認する必要があります。矢印が英語版で左を指している場合、アラビア語版でそれが正しい方向を向いている可能性があります（ただし、必ずしもそうではありません！）。アイコンに赤い八角形として一時停止の標識を付けた場合、一部の地域の人々はそれが何のためにあるのか手がかりがなく、さらに悪いことに、あなたが意図してプログラミングした以外のことをしているはずだと確信するでしょう。
• システムでアドレスを処理する必要がある場合、それらはいくつかの場所でも扱いにくくなります。あなたがそれらを検証しなければならないならば、大きな頭痛の種です。
• 等。

幸いにも、多くの言語のライブラリがあり、作業の大部分を行っています。それを行うのに適したライブラリがない場合は、おそらくすべてのロケールのパラメータを定義し、XMLファイルまたは他のタイプの構成ファイル（またはソフトウェアに同梱している場合はデータベース）を使用してそれらを詳細に定義する必要があります。 、または小さなフットプリントを追加してもかまいません）。

使用しているプラ​​ットフォームに大きく依存します。.NETは、お客様のビルドに応じて変更できるリソースファイルをサポートしています。

プラットフォームでサポートされているかどうかに関係なく、他の問題には、ラベルとテキストボックスの順序を逆にする機能が含まれます（一部のカルチャでは、ラベルが右側にあることを好みます）。これらの同じカルチャでは、すべてのテキストブロックを右から左に読みたい場合があります。

ルックアップテーブルの値を忘れないでください。注文ステータス名、タイプの説明など

ルックアップテーブルに説明と名前がある場合（例：{OrderStatusId、OrderStatusName、OrderStatusDescription}）、これらも翻訳する必要があります。

Smith-Ferrierによる「.NET国際化：グローバルなWindowsおよびWebアプリケーションの構築に関する開発者向けガイド」のコピーを入手してください。

私は最近、私たちのアプリスイートでi18nの問題全体を徹底的に検討するタスクを割り当てられました。

この本は、私が思いもしなかった問題を浮き彫りにしました。

上記に加えて、日付の形式、スペル、画面の向きの制御も考慮してください。言語が右から左に読まれるレポートでは、インデントの方向を気にする必要があります。週末は国によって異なります。カレンダーを表示している場合は、週末が正しく表示されることを確認する必要があります。MS-Windowsを使用していない場合は、並べ替えの照合シーケンスの処理とOSの処理について、クライアントOSの機能を確認してください。モードが英語でない場合は、エラーメッセージをユーザーに翻訳する必要があります。コード内。データベース側では、正しい文字コードを選択する必要があります。これはデータベースごとに異なり、日付の比較に影響する可能性があります。