数字を適切にローカライズする方法は？

フロントエンドアプリケーションで番号をローカライズする際に注意する必要があるのはどの警告ですか？

例：ブラジルポルトガル語（pt-BR）では、ドットで千を分割し、コンマで小数を分割します。米国英語（en-US）ではそれは逆です。pt-BRでは、en-USと同様に、桁で区切られた桁が表示されます。しかし、今日、インド英語（en-IN）について読んで、この宝石に出会いました。

インドの番号付けシステムは、数字のグループ化に適しています。言葉で書かれたとき、または話されたとき、100,000 / 100 000未満の数字は、標準英語と同じように表現されます。100,000 / 100,000以上の数字は、インドのナンバリングシステムのサブセットで表されます。

https://en.wikipedia.org/wiki/Indian_English#Numbering_system

つまり：

1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000

コンマとドット、およびその他の特定の区切り記号に加えて、マスキングも有効な懸念事項のようです。

フロントエンドアプリケーションで番号をローカライズする際に注意すべき他の注意事項はありますか？特に非ラテン文字セットに数字を表示している場合はどうなりますか？

ほとんどのプログラミング言語とフレームワークには、このために使用できる実用的で実用的なメカニズムが既にあります。

たとえば、C＃エコシステムにはSystem.Globalization名前空間があり、必要なものを指定できますCulture。

Console.WriteLine(myMoneyValue.ToString("C", "en-US"));

これは、あなたが再発明したいものではありません。お気に入りの言語またはフレームワークが提供する国際化機能を使用します。

ここでいくつかの優れた回答がすでにありますが、忘れてはならない重要なことについては言及していません：数字の書式設定がどこで行われても、出力の用途が明確である（または制御できる）ことを確認してください：

• ユーザーインターフェイスの場合は、ローカライズされた書式を適用する必要があります

• 番号がファイルに書き込まれようとして、あるいはネットワークを介して送信される、または番号がで必要とされる場所の別のフォームされたときに機械読み取り可能な形式、必ずそれがされていることを確認していない現在の文化に従ってフォーマットが、固定設定に応じて、 （たとえば、.NET環境では、を使用しますInvariantCulture）。

そうしないと、カルチャAを使用して数値が書き込まれたり送信されたり、カルチャBを使用して読み取りまたは受信されたときに問題が発生します。

私の経験では、これは数値の適切なローカリゼーションを行う上で最大のハードルの1つです。数値の書式設定と変換を集中化するために、人々は書式設定用の一般的な再利用可能な関数を作成し始め、それをすべての場所で使用し始めます場所。ただし、プログラムのどこかで機械可読文字列形式の数値も必要になるとすぐに、ローカライズ形式と非ローカライズ形式の2つのバリアントが必要です。これにより、2つの形式の変換を混同するリスクが高くなります（特に、開発者とテストマシンのデフォルトのロケール設定が非UIフォーマットに使用される「固定」設定に似ていますが、ユーザーベースの一部にはありません）。

補遺：この問題は、数値が機械で処理されるのか、後で人間（またはその両方）で処理されるのかが事前に明確でない状況では、非常に厄介になる可能性があります。たとえば、ログファイルの出力の一部として。そのような場合は、小数点以外の区切り文字を使用しない「中立」標準を使用するのがおそらく最善です。

適切なローカライズは非常に困難です。ほとんどのプログラミングエコシステムは、ローカライズのソリューションを試みていますが、私の経験では、それらは多かれ少なかれ壊れています。したがって、私は提案します：

• ローカライズを自動化しようとしないでください。常に機能するとは限りません。問題を見つけることは困難であり、ユーザーを苛立たせます。

• 一貫性を保つ：異なる言語と形式の規則を混ぜないでください。たとえば、英語のテキストでのブラジルスタイルの小数点記号。

• 指定されたロケールのセットを明示的にサポートします。翻訳者と協力して、日付と数字の適切なフォーマットを決定します。ほとんどの（すべてではない）問題を既存のライブラリに委任できますが、おそらく独自のローカライズツールキットを作成することになります。

• 各ユーザーが構成可能な単純なフォーマットの選択を行います：日付と時刻のフォーマット、小数点、優先通貨など。これは、旅行者、外国人、または言語に関係なく複数のロケールまたは文化を混在させる必要がある他の人々に特に役立ちます。

重要な考慮事項：どれだけで十分かを判断する必要があります。完璧にローカライズしようとするウサギの穴を下ると、ますます複雑になるからです。

「n個のアイテムを選択しました」などの典型的なラベルを使用します。選択されているアイテムが1つだけの場合、これは間違って表示されます。いが実用的な解決策は、「n個のアイテムを選択しました」と書くことです。ただし、正しく実行する場合は、nに応じて2つの異なるテキストが必要です。複数のロケールでこれを行おうとすると、言語によって文法が異なるため、すぐに非常に複雑になります。一部の言語では、1つ、2つ、および複数のアイテムに対してさまざまな活用があります。このため、知識のある人は、既存のローカリゼーションフレームワークでは不十分であると常に不満を言うでしょう。

しかし、あなたはあなたの戦いを選択し、どのレベルの洗練が十分であるかを決定しなければなりません。多くの目的のために、数値と日付をフォーマットするための標準的なローカライズライブラリで十分です。

言語のすべての警告に気付くことができません。あなたは数字について話していますが、複数形、性別、照合があります。それらが存在することを知り、他の人々、特にICUおよびCLDRプロジェクトによって実行される広範な作業に依存する必要があります。

最新の言語のほとんどは、これらのプロジェクトの一部またはすべての機能を実装していますが、実装していない場合でも、これらのプロジェクトについて読むと、何を探すべきかがわかります。

http://site.icu-project.org

http://cldr.unicode.org

更新

CLDR調査ツールは、すべてのパターンへのアクセスを提供します。特定の言語と地域で数値をフォーマットする方法を示します。たとえば、ポルトガル語（ポルトガル）：

http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/

そして、本当にすべてのデータをチェックしたい（そしておそらくそれを使用したい）場合は、GitHubからJSON形式でCLDRをダウンロードできます。

https://github.com/unicode-cldr/cldr-json#cldr-json

ダウンロードに関する詳細はこちら：

http://cldr.unicode.org/index/downloads

さて、ここではすべての答えに満足していますが、正解としてマークするためにそれぞれに個別に満足しているわけではありません。

これまでのところ、これは数字をローカライズするときに注意すべきことです：

人間向け：

• 数千の区切り文字が常に数千で区切られているわけではありません。質問のインドの事例をご覧ください。
• 数千文字と小数文字は、文化によって文化が異なります。たとえば、ドイツ語ではスペースを使用して数千が分割されますが、英語ではカンマで、ポルトガル語ではドットです。
• 左から右への言語と右から左への言語に関連する違いがある場合、情報はありません。
• サポートされるローカライズの特定のセットを提供し、ユーザーに明確にします。
• ユーザーがデフォルトのローカライズをサポートされているローカライズの1つに変更できるようにしてください。寛大な神であるため、喜んで喜んでケーキをお送りします。:);

コンピューターの場合：

• マシンは寛容ではなく、数値のシリアル化と非シリアル化中に常に同じフォーマットを受け取る必要があることに注意してください。
• そのための単一の形式に固執します。
• 必要最小限の形式を使用してください。数千の分離は避けてください。シリアル化と逆シリアル化には小数で十分です。

開発者向け：

• （以下の@hydeで提案されているように）：既存のライブラリをローカライズに使用します。
• 可能であれば、ネイティブテスターを使用してローカライズ/国際化テストケースを指定します。それ以外の場合はライブラリを信頼します。
• ローカライズはほとんど解決される問題であることを忘れないでください。すべての主要言語には、数字、日付、および時間をローカライズできるネイティブまたは外部のライブラリがあります。