如何正确定位数字？

在前端应用程序中本地化数字时应注意哪些注意事项？

示例：在巴西葡萄牙语（pt-BR）中，我们用点分隔小数，用逗号分隔小数。在美国英语（en-US）中则相反。在pt-BR中，我们显示以千位分隔的数字，与en-US相同。但是，今天阅读有关印度英语（en-IN）的信息时，我偶然发现了这个宝石：

印度编号系统是数字分组的首选。用文字或口语表达时，小于100,000 / 100 000的数字与标准英语中的数字相同。在印度编号系统的子集中表示的数字包括100,000 / 100000以上。

https://zh.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读取或接收数字时，您会遇到问题。

以我的经验，这是正确进行数字本地化的最大障碍之一：为了集中化数字格式和转换，人们开始创建通用的可重用函数以进行格式化，然后开始在整个范围内使用它们。地点。但是，一旦在程序的其他位置也需要以机器可读的字符串格式显示数字，就需要两个变体：本地化格式和非本地化格式。这带来了混淆两种转换形式的高风险（尤其是当开发人员和测试机器的默认语言环境设置类似于用于非UI格式的“固定”设置，而部分用户基础却没有）。

附录：如果事先不清楚该数字是由机器处理还是由人（或两者）处理，则此问题可能会变得非常棘手。例如，作为日志文件输出的一部分。在这种情况下，最好坚持不使用分隔符（除该点作为小数点分隔符以外）的“中性”标准。

正确的本地化非常困难。大多数编程生态系统都在尝试本地化解决方案，但以我的经验，它们或多或少都被破坏了。因此，我建议：

• 不要尝试自动化本地化。它并不总是有效。您很难发现问题并使用户感到沮丧。

• 保持一致：请勿混用不同的语言和格式约定，例如，英文文本中的Brasilian样式小数点分隔符。

• 明确支持给定的语言环境集。与您的翻译一起工作，找出正确的日期和数字格式。尽管大多数（但不是全部）问题可以委托给现有库，但您最终可能会创建自己的本地化工具包。

• 使每个用户都可以配置简单的格式选择：日期和时间格式，小数点分隔符，首选货币等。这对于旅行者，外籍人士或需要独立于语言的多种地区或文化混合的其他人特别有用。

一个重要的考虑：您应该决定多少就足够了。因为如果您陷入试图完美定位的困境，它将变得越来越复杂。

请使用“您已选择n个项目”之类的典型标签。如果仅选择一项，则读取错误。丑陋但实用的解决方案是写“您选择了n个项目”。但是，如果要正确执行操作，则需要两个不同的文本，具体取决于n。如果您尝试在多个语言环境中执行此操作，则会很快变得非常复杂，因为不同的语言具有不同的语法。有些语言对一个，两个和多个项目具有不同的共轭形式，依此类推。因此，有识之士总是会抱怨现有的本地化框架不足。

但是，您必须选择自己的战斗，并决定什么水平的成熟度就足够了。对于许多目的，用于格式化数字和日期的标准本地化库就足够了。

您可能并不了解所有语言警告。您在谈论数字，但是有复数形式，性别和排序规则。您需要知道它们的存在，并依靠其他人（尤其是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

好吧，虽然我对这里的所有答案都感到满意，但我对每个答案都分别标记为正确答案并不真正满意。

到目前为止，这是在数字本地化时应注意的事项：

对于人类：

• 数千个分隔符并不总是分隔成千上万个。参见问题中的印度案例；
• 千位和十进制字符会因文化而异。例如，德语用空格将成千上万的空格分隔，英语用逗号分隔，而葡萄牙语用点分隔。
• 从左到右和从右到左的语言之间是否存在相关差异，我们没有信息。
• 提供一组特定的受支持的本地化并向您的用户清楚表明；
• 允许您的用户将默认的本地化更改为支持的本地化之一，他们会很高兴，并感谢您，因为您是个慷慨的上帝。:);

对于计算机：

• 请记住，机器不是宽大的，在对数字进行序列化和反序列化时应始终采用相同的格式；
• 坚持使用单一格式；
• 使用最小可能的格式。避免千位分隔，小数应足以进行序列化和反序列化。

对于开发人员：

• （如下面的@hyde所建议）：使用现有库进行本地化；
• 如果可以，请使用本机测试人员并指定本地化/国际化测试用例，否则请信任该库；
• 请记住，本地化是一个主要解决的问题。每种主要语言都有一个本地或外部库，可以本地化数字，日期和时间。