データ入力に小数点コンマが使用されていますか？
歴史的に、私は 世界のほとんどの部分で、小数はカンマで表されています を知っています。
- 3.14（主に米国とカナダ）
- 3,14（他のほとんどの場所）
ソフトウェア開発では、通常ピリオド（3.14）が使用されます。これは世界中で真実です。プログラミング言語は、ユーザーのロケール設定に従って、正しい形式でUIに数値を表示する機能を提供します。
ただし、入力でコンマ10進数を認識するコードを見たことはありません。ユーザーが3,14と入力すると、拒否されるか、「300」と解釈されます。
ソフトウェアは3,14などの入力を正しく解釈する必要がありますか？あるいは、それが必要ではないのかもしれません-おそらく、ユーザーが「コンピュータ」の慣習を採用することに慣れているからでしょうか？
良い質問ですが、Wolframの参照はひどく間違っています。
ピリオドの使用.ユーザーインターフェースでの使用は今日ではほとんど普遍的であり、コンマをオーバーロードしないようにすることをお勧めします。
小数点の広がりは、グローバリゼーションとテクノロジーの影響に関するかなり興味深いケースです。この場合、小数点でのグローバルな財務諸表の広範な標準化（カンマが財務諸表では数千、数百万などを表すために使用されるため）と、小数点を使用するハイテクユーザーインターフェイス（携帯電話の計算機など）の普及が相まって、ユーザーインターフェイスでの小数点記号としてのカンマの使用を根絶しました。
私は何十年もヨーロッパ、アジア、オーストラリアでビジネスを行ってきましたが、ユーザーインターフェイスで小数点記号としてカンマが使用されるのを見たことがありません。
小数点区切り記号としてのカンマのサポートを復元しようとすると、賢明なUIの傾向に反するだけでなく（これはIMOでもあります）、グローバルコミュニティに有益な非公式の標準化プロセスが取り消されます。
関連するメモとして、金融および科学アプリケーションでは、カンマと指数を認識することがUIの良い習慣です（例：299,792,456または3e8）を有効な数値入力として（たとえば、電卓またはスプレッドシートに貼り付けた場合）。
わかりました、私がナンセンスだと言った場合に備えて、専門家が飛び込むのを奨励することを期待して、答えを提供しようとします。
まず第一にあなたの一般的な質問への答えを考えます
ソフトウェアは3,14などの入力を正しく解釈する必要がありますか？
しっかりと「依存する」会社でのみ明確に答えることができます。
上記のコメントのキーワード「適切にローカライズされたアプリケーションはそれを行う」は「適切にローカライズされた」と思います。ロケール設定に従って10進数を解釈しようとするが、言語または日付の形式を正しく取得する必要がないアプリケーションがある場合、それは非常に混乱します。一方、言語、通貨、日付設定などを順守している場合は、対応する小数点記号も順守されていることを期待できます。
ただし、アプリケーションを複数のロケールにローカライズすることは簡単な作業ではありません。一般に、次の2つのプロジェクトに分かれています。
- アプリケーションの国際化（i18n）。つまり、すべてのロケール固有の部分（文字列コンテンツ、テキスト方向、照合、日付形式、数値および通貨形式など）が抽象化され、構成可能になります
- アプリケーションのローカリゼーション。サポートされているロケールごとに実行する必要があります。
最初に適切に国際化しないと、アプリケーションのローカライズを試みるべきではありません。あなたはあなた自身を保守の地獄にするかもしれません。
アプリケーションが変更された場合、これらの両方の側面も継続的に維持する必要があります。これらの影響を考慮すると、適切なローカリゼーションを提供するかどうかの決定は、多くの場合、全か無かの考慮事項です。その価値があるかどうかを判断する必要があります。これは、アプリケーションのタイプ、顧客ベース、リソースなど、多くの要因に依存する可能性があります。しかし、そうすることを決定した場合、適切に実行する必要があり、それはほとんど問題ではありません。小数点区切りを正しくする方法。
ただし、まだ例外はあると言われています。例えば。電卓アプリケーションの場合、完全なローカリゼーションはそれほど問題になりませんが、小数点としてカンマまたはドットを使用できるので便利です。例えば。 Apple "Calculator"では、コンマの代わりにドットを使用できますが、常にコンマとして表示されます。スポットライトを使用して計算を行うと、コンマとドットは文字どおり表示されますが、互換性が解釈されます（たとえば、1,234.56は1.23456として解釈されますが、1.234,56は1234.56として正しく解釈されます）。
ただし、例外は単純なアプリケーションにのみ適用されます。 ドイツ語のキーボードレイアウト を見ると、数字キーパッドにコンマがあり、英語のレイアウトにドットがあることがわかります。したがって、多くの数値入力を必要とするアプリケーションがある場合、ユーザーexpectは、コンマを小数点として使用できます。それは単に人間工学的な問題です。
私の意見では、ローカリゼーションの取り組みはしばしば過度に行われ、それは驚くべき結果につながる可能性があります。例えば。 ExcelまたはLibreOffice CalcからCSVファイルをエクスポートまたはインポートする場合、フィールドのドットとコンマの解釈方法のロケール設定に依存します。確かに、それは表示と入力に準拠する必要がありますが、それはファイル形式に影響するはずです！？特定のCSVファイルをインポートできるようにするには、ロケールシステムの設定を変更する必要さえありました。もちろん、CSVは実際の標準ではなく、アドホックな形式ではないと主張することもできますが、それでも紛らわしく、直観に反しています。
また、POSIXは、環境変数に格納されるロケール設定を定義します。しかし、特定のShellビルトインの結果は驚くべきものになる可能性があります。
$ export LC_NUMERIC="en_US.UTF-8"
$ printf "%'f\n" 1234.5678
1,234.567800
$ export LC_NUMERIC="de_DE.UTF-8"
$ printf "%'f\n" 1234.5678
bash: printf: 1234.5678: invalid number
0,000000
$ printf "%'f\n" 1234,5678
1234,567800
どういう意味ですか？ロケールを変更するときは、正しい入力形式を指定する必要があります。しかし、自分で適切なフォーマットを提供する必要がある場合、フォーマット関数の使用法は何ですか？また、「シェル」もスクリプト言語ではありませんか？つまり、ロケールを変更すると、言語自体の意味が変更されます！？インタラクティブな入力と非インタラクティブな入力とは、必ずしもそれほど明確ではないようです...
あなたの質問は具体的に入力を扱っていますが、少なくとも1つの実用的なヒントを提供したいと思います（プログラムのローカライズを決定するかどうかに関係なく適用されます）：1から999までの数値を表示する必要がある場合は、3を使用しない必要に応じて10進数。 1,234のような数値は、1234または1.234として解釈される可能性があります。これは、数値自体を調べると、「、」が1000の区切り文字または小数点の区切り文字であるかどうかが明確でないためです。一方、1,23のような数は明確です。しかし、それは私自身の「プライベート」ルールです。そのための「公式」のユーザビリティガイドラインがあるかどうか、私は実際に興味があります。たぶん、専門家の一人がそれにコメントすることができますか？
もちろん、1000から999999までの整数があり、1,000の区切り文字を使用する必要がある場合、そのようなヒントはありません。しかし、通常は、数値を整数にする必要がある場合はコンテキストから明らかなので、問題は少なくなります。