数値を適切にローカライズする方法は？
フロントエンドアプリケーションで数値をローカライズする際に注意する必要のある警告は何ですか？
例：ブラジルポルトガル語（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"));
これはあなたが再発明したいものではありません。お気に入りの言語またはフレームワークが提供する国際化機能を使用します。
いくつかの優れた答えはすでにここにありますが、私が忘れてはいけない重要なことについては触れていませんでした。数値のフォーマットが行われる場所がどこであっても、出力の用途が明確（または制御可能）であることを確認してください。
ユーザーインターフェイスの場合は、ローカライズされた書式を適用する必要があります
番号がファイルに書き込まれるか、ネットワーク経由で送信されるか、機械可読形式で必要な場所の別の形式、 notが現在のカルチャに従ってフォーマットされていることを確認してください。ただし、固定設定に従ってください（たとえば、.NET環境では
InvariantCultureを使用してください）。
そうしないと、カルチャAを使用して数値を書き込んだり送信したり、カルチャBを使用して数値を読み取ったり受信したりするときに問題が発生します。
私の経験では、これは数値の適切なローカライズを行う上での最大のハードルの1つです。数値のフォーマットと変換を一元化しようとすると、人々はフォーマットのための一般的な再利用可能な関数の作成を開始し、それからすべての関数を使い始めます。場所。ただし、プログラムの他の場所で機械可読文字列形式の数値も必要になるとすぐに、ローカライズされた形式とローカライズされていない形式の2つのバリアントが必要になります。これにより、2つの形式の変換が混同されるリスクが高くなります（特に、開発者とテストマシンのデフォルトロケール設定が非UIフォーマットに使用される「固定」設定に似ているが、ユーザーベースの一部にはない場合）。
補遺：この問題は、数値が後で機械によって処理されるのか、人間によって（またはその両方によって）処理されるのかが事前に明確でない状況では、非常に厄介になる可能性があります。たとえば、ログファイルの出力の一部として。そのような場合、小数点を小数点として使用することを除いて、セパレータを使用しないという「中立的な」標準に固執するのがおそらく最善です。
適切なローカリゼーションは非常に困難です。ほとんどのプログラミングエコシステムはローカリゼーションの解決策を試みていますが、私の経験では、それらは多かれ少なかれ壊れています。したがって、私はお勧めします：
ローカリゼーションを自動化しようとしないでください。常に機能するとは限りません。問題を特定することは困難であり、ユーザーを苛立たせます。
一貫性を保つ：異なる言語やフォーマット規則を混在させないでください。英語のテキストでのブラジルスタイルの小数点記号。
特定のロケールセットを明示的にサポートします。翻訳者と協力して、日付と数値の適切なフォーマットを理解してください。最終的には独自のローカリゼーションツールキットを作成することになりますが、ほとんど（すべてではありません）の問題は既存のライブラリに委任できます。
各ユーザーが構成できる簡単なフォーマットの選択を行います：日付と時刻のフォーマット、小数点記号、優先通貨、…。これは、言語に関係なく複数のロケールや文化を混在させる必要がある旅行者、外国人居住者、またはその他の人々に特に役立ちます。
言語のすべての注意点を知ることはできません。あなたは数字について話していますが、複数形、性別、照合があります。あなたはそれらが存在することを知り、他の人、特にICUおよびCLDRプロジェクト）によって行われた広範な作業に依存する必要があります。
最新の言語のほとんどは、これらのプロジェクトの一部またはすべての機能を実装していますが、実装していない場合でも、これらのプロジェクトについて読むと、何を探すべきかがわかります。
更新
CLDR調査ツールは、すべてのパターンへのアクセスを提供します。これは、特定の言語と地域で数値をフォーマットする方法を示します。たとえば、ポルトガル語（ポルトガル）：
http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/
そして、本当にすべてのデータをチェックしたい場合（そしておそらくそれを使用したい場合）は、CLDRをJSON形式でGitHubからダウンロードできます。
https://github.com/unicode-cldr/cldr-json#cldr-json
ダウンロードに関する詳細はこちら：
重要な考慮事項：どのくらいで十分かを決定する必要があります。完全にローカライズしようとするうさぎの穴を下っていくと、それはますます複雑になります。
「n個のアイテムを選択しました」などの一般的なラベルを考えてみましょう。アイテムが1つしか選択されていない場合、これは間違って読み取られます。醜いが実用的な解決策は、「n個のアイテムを選択しました」と書くことです。しかし、それを正しく行うには、nに応じて2つの異なるテキストが必要です。これを複数のロケールで実行しようとすると、言語によって文法が異なるため、すぐに非常に複雑になります。一部の言語では、1つ、2つ、および複数の項目に対して異なる活用形があります。このため、既存のローカリゼーションフレームワークでは不十分であるという知識を持つ人々は常に不満を言うでしょう。
しかし、あなたはあなたの戦いを選択し、どのレベルの洗練が十分であるかを決定しなければなりません。多くの目的で、数値と日付をフォーマットするための標準ローカリゼーションライブラリで十分です。
ええと、私はここですべての答えに満足していますが、それぞれを個別に正解としてマークすることに満足していません。
これまでのところ、これは数値をローカライズするときに注意する必要があることです。
人間向け：
- 数千のセパレータが常に数千で分離しているわけではありません。質問のインドのケースを参照してください。
- 数千および小数の文字は文化によって異なります。たとえば、ドイツ語ではスペースを使用して数千が分割されますが、英語ではカンマ、ポルトガル語ではドットです。
- 左から右への言語と右から左への言語に関連する違いがある場合、情報はありません。
- サポートされるローカリゼーションの特定のセットを提供し、それをユーザーに明確にします。
- ユーザーがデフォルトのローカリゼーションをサポートされているローカリゼーションの1つに変更できるようにしてください。あなたは寛大な神なので、喜んでケーキを送ってくれます。 :);
コンピュータの場合：
- マシンは寛大ではなく、数値をシリアライズおよびデシリアライズするときに常に同じフォーマットを受け取る必要があることに注意してください。
- 単一のフォーマットを使用してください。
- 可能な限り最小限の形式を使用してください。数千の区切りを避け、シリアル化および非シリアル化には小数で十分です。
開発者向け：
- （以下の@hydeで提案）：ローカライズに既存のライブラリを使用します。
- 可能であれば、ネイティブテスターを使用してローカリゼーション/国際化テストケースを指定します。それ以外の場合は、ライブラリを信頼してください。
- ローカリゼーションはほとんど解決された問題であることを覚えておいてください。すべての主要な言語には、数値、日付、時刻をローカライズできるネイティブまたは外部のライブラリがあります。