号码本地化是否不必要？

我刚刚阅读了此页面http://weblogs.asp.net/scottgu/archive/2010/06/10/jquery-globalization-plugin-from-microsoft.aspx

他们所做的一件事是将阿拉伯日期转换为阿拉伯日历。我想知道这样做是否是个好主意。对于用户而言，它实际上是否会令人讨厌/困惑（即使用户是阿拉伯人）。

另外，我的第二个问题是，对于某些文化（例如德语），我们真的需要将33,899.99更改为33.899,99吗？我的意思是这样做没有什么害处，因为该库已经为我们做到了，但这实际上不会给用户带来更多混乱（即使他是德国人，等等）。

我敢肯定，这些人来自什么文化，如果我给您一个数字33,899.99，您将不可能正确地猜对吗？（除非我的网站/应用程序是您一生中使用过的第一个网站/应用程序，可以说这是可能的，但可能性很小）

我的意思是“通用”，这是每个人都会看到并知道其含义的格式。它不一定是用黑白之类的东西编写的标准。只要每个人都可以阅读并直接知道文本所代表的含义，那就很普遍了。可以肯定的是，1.234,00绝对不是通用的。我的意思是，我非常确定您可以找到一生中一直在使用计算机但从未遇到过这种数字格式的人。由于大多数网站/应用程序一直在使用1,234.00而不进行任何更改以适应本地化，因此我相信这已成为事实（每个人都会看到并知道它的含义的通用格式）。

至于日期，如果我们写03/01/02，我敢肯定，没有人会知道（马上，马上，没有歧义）今天是几号。但是如果我们将它们写成这样，没有人能弄错2003年1月2日，2003年2月1日，2001年2月3日不是吗？

顺便说一句，这个问题是针对本地化的，不要告诉我“嘿，不是每个人都懂英语！”之类的东西。因为那是国际化的问题（这超出了本主题）。让我们坚持关于本地化的讨论。

为什么非盎格鲁人必须对日期，数字等进行解码，而盎格鲁人只能读取它们呢？如果您希望让非Anglos感受到用户和客户的欢迎，那么数字和日期本地化绝对必要。为什么德国用户必须算出您的电话号码，而不是以自己的语言格式获取电话号码？

此外，您对数字格式（和日期：下面的qv）的看法简直是无可救药的。例如，毫无疑问，您会发现数字1,234,567是“自然的”，“明显的”和“逻辑的”……但是，来自具有多种编码方式的文化的人呢？例如，我的学生（中文）总是对1000多个数字感到困惑，因为他们对数字的分组方式不同。他们的思维过程（包括无数的千分之一）更“自然”的分组是123,4567。此外，在许多情况下，通常根本不适合使用欧洲数字系统。在那种情况下，能够写出全中文一百二十三万四千五百六十七或什至是这里常用的各种混合系统，将是很好的。

您对日期的想法也有误。您已经正确指出了01/02/03的模棱两可（如果仅仅是因为美国人拒绝遵守日期标准），而是建议2001年2月3日是毫不含糊的。但是，我不确定您是否注意到了那里。这是毫不含糊的英语。回到我的学生那里，我非常确定他们更愿意看到2001年2月3日（甚至二〇〇一年二月三日），这既清晰又能得到他们所想要的东西无需解码即可读取。

i18n和l10n的底线是：您想要钱和/或用户吗？您可以满足用户的需求。您的用户希望使用自己的语言而不是您自己的语言。故事结局。

编辑添加

它甚至比基于无数系统的情况更糟。看看这个可爱的进步的印度编号：

1
10
100
1000
10,000
1,00,000
10,00,000
1,00,00,000

...依此类推，直至：

100,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,000

看到最后按三个分组？看到按三分组后又按二分组吗？再次看到三人一组突然加入？

进行进一步的编辑以添加（似乎无法阻止这个主题！）

甚至十进制数字系统都是通用的假设也是错误的。有一些本机编号系统是基于4，基于5，基于8（八进制），基于10（十进制），基于12，基于20甚至是60。这些都是真实人一直在积极使用的系统（如未弥补科幻小说中的故事）。并不是所有这些都还活着（尽管例如，我们可以看到英语术语中基于12、60的数字系统的痕迹）。

至于日期，让我们不要忘记世界许多地方仍在积极使用农历。穆斯林世界倾向于使用阴历，其中的日期可能会在整个一年中漂移，而中国人使用的阴历是一个复杂的系统，该日期不会超过真实日期一个月。（那只是在我头顶上命名两个。）

另外，我的第二个问题是，对于某些文化（例如德语），我们真的需要将39.99更改为3.899.99吗？我的意思是这样做没有什么害处，因为该库已经为我们做到了，但这实际上不会给用户带来更多的混乱（即使他是德国人）。

即使用户是德国人，他也会与德国符号混淆吗？我敢肯定我不同意这一点。不，会给用户带来更多混乱的是本地化站点与非本地化数据的冲突。在这方面，数字和日期是关键问题。

如果要本地化服务，则需要正确地对其进行本地化。跳过数字格式是懒惰且无知的。

3,899.99不是通用格式，并且“每个人都会理解”的假设在理论上是懒惰的。这也比较不礼貌。由于我们正在讨论您发布的特定链接，因此您可以轻松地进行操作-那么，为什么不这样做并至少表现出一定的文化意识呢？

美国<> Universal。

读取“ 2003年1月2日”之类的日期需要花费一些时间才能解码。我们总是把月份放在前一天。因此它必须是“ 2003年1月2日”。当然可以，但是我们必须花5秒钟来解码它。

显示一个类似于1,234的数字，大多数欧洲人会想到一个十进制数字。1,345.00只是“感到错误”。

如果您不本地化应用程序也可以。只是不要指望它会在您的国家/地区受到欢迎。

您的问题似乎是一个错误的假设。没有数字或日期的“通用格式”。3,899.99在某些地方有效，而在其他地方则令人困惑。反之亦然。人们可以经常弄清楚他们需要什么，但这不是重点。您谈论的日期格式也是如此。格式本身在语言环境之间是不同的。这里没有“通用”。

除了在某些科学和技术领域中通用软件通常无法解决的问题之外，对于这些事物，没有通用的格式。如果您希望您自己的地方以外的其他地方以本机术语接受软件，则需要为此工作。

您能在人们的喉咙里推一些事实上的标准吗？当然。但是，在任何专业的国际化软件中，都不应将数字本地化（按您的问题）视为不必要。

您似乎以为您所阅读的内容是通用的，而事实并非如此。

在我住的地方，逗号表示小数点分隔符，而点（稀疏地）用作千位分隔符。我剖析$ 3,004.25是不自然的。但是，如果您给我$ 5,535，我可能会读为大约5美元半。读3.899,99完全不会让我感到困惑，而且我不明白您为什么这么认为。

对于日期，我当然可以阅读2001年2月3日，也可以阅读2001年2月3日。

因此，用户通常可以解析大多数本地化的数字和日期。有时可能会有歧义，例如$ 5,535。无论如何，我只是不明白为什么您认为它会比他们自己的语言环境更清晰。

我对数字和货币的本地化了解不多，但是ISO 8601（http://en.wikipedia.org/wiki/ISO_8601）涵盖的日期格式为YYYY-MM-DD，例如2011-05-10 5月10日。

另外，我的第二个问题是，对于某些文化（例如德语），我们真的需要将39.99更改为3.899.99吗？我的意思是这样做没有什么害处，因为该库已经为我们做到了，但这实际上不会给用户带来更多的混乱（即使他是德国人）。

我是德国人，亲自为我发言，的确令人困惑，因为我读了很多英语课本，而不是德语课本，而且都混在一起。这就是为什么我必须对遇到的每个数字稍作休息，以弄清该数字遵循的符号规则以及其实际含义。

因此，在我的本地化设置中，我将数字分组字符配置为单引号（'），如1'234.00（瑞士使用的系统）一样。

我确定这些人来自什么文化，如果我给您3,899.99的电话号码，您将无法正确地认错？（因为他可能还是已经学会了通用格式）

您可能可以弄清楚，但是需要一些时间。

我的意思是“通用”，这是每个人都会看到并知道其含义的格式。可以肯定的是1.234,00绝对不是通用的。我的意思是，我非常确定您会找到一个一生都从未见过这种数字格式的人。由于大多数应用程序一直在使用1,234.00而不进行本地化，所以我认为这是事实（一种通用格式，每个人都会看到并且知道它的含义）。

在德国，您肯定能找到很多从未见过1,234.00标记的人。

同样，在此问题上还有法律含义。想象一下，用错误的小数点写的银行帐户余额。由此可能引起各种各样的麻烦。

至于日期，如果我们写03/01/02，我敢肯定，没有人会知道它是什么日期。

是的，我讨厌那个！如此之多的人仍然这样做，每次让我感到困惑的是什么时候意味着什么，甚至更是如此，因为英美制记法之间显然存在冲突，其中一个人在下个月的前一天写东西，另一个人在前一天的一个月写东西。 。

如果无法进行本地化（例如以书面形式），则我建议使用标准格式2003-02-01，以解决可能跨越国界的任何问题。虽然您无法立即看到，但是是表示2月1日还是1月2日，该表示法已标准化为首先具有更大权重的数字（前一天）。

有多种方法可以实现您想要的，但是它们都涉及使用一种自然而然的格式。例如，我们将时间戳记以人类可读的格式存储在产品中：YYYYMMDDHHMMSS。那里没有混乱，但是没有人在日常生活中使用这种格式。

我认为您需要的是一种通用的基础格式，例如，自1970年1月1日以来的秒数。一旦有了该格式，就可以以您喜欢的任何格式显示时间，并且库和OS可以重新显示正确的时间。您喜欢的任何方式。

我想，评论多于答案，但...

它不是自然而然的

“因为他可能还是已经学会了通用格式”

请原谅我，但是直到学到很晚才真正学习“通用”格式，因为那是事实：没人在乎。或至少在他们需要之前（例如，用于正式文件，商业等）。因此，当您看到不使用您的区域性惯例的格式时，就会感到困惑。通常MM/DD/YYYY还是DD/MM/YYYY一个大问题。

学习是特权

同样，不幸的是，很多人没有机会“学习”那些东西。即使在发达国家，并不是每个人都能上学（甚至是小学）或完成学业。我不能对此施加足够的压力，但是：我们也为他们设计软件。

看看Google的做法。他们显然很努力地在内部开发与语言相关的产品，因此，他们也正竭尽全力提供本地化服务。

尽管我们这里的许多程序员通常都喜欢我们的“通用”语言（英语，并且用ASCII编码，非常好用），但是当许多人以自己的语言打招呼时，他们会感到更加受欢迎。就像在国外机场走出大门一样，那里没有人说您的语言，而且文字对您来说很遥远。如果您不习惯的话，这可能会有点吓人。坦白地说，将其带回IT领域，即使打开包含Unicode字符或另一种语言的单词的语音近似版本的源文件也非常令人痛苦。

但是，我确实使您感到困惑：您最终想知道每次系统设计者的意图是什么，以及他们打算使用哪种格式。但是，发生这种情况时，这对您而言并不会像无法理解其他事物的人那样使您感到困惑。

文化问题

最后，我认为问题的核心是另外一件事：如果我们遵循您的建议，那么我们将蚕食许多其他应有的存在，被记住和庆祝的伟大文化。他们通过自己的作品和这些微小的（看似无关紧要的）细节来生活：它们是文化的一部分，并且出于某种原因存在于每种文化中。

我不想把这变成对邪恶的大西方帝国扩张的热潮，但这是引发人们严厉的反应和评论的那种事情。仅仅是因为您似乎想抛弃别人的意见，口味和文化（我敢肯定您不会），甚至建议您比他们更了解他们应该使用和喜欢的东西。或者，无论如何，您几乎不尊重它们的方式，不认为它们是您的用户群的一部分，不想努力欢迎它们，并且实际上并不太在乎它们。

编辑-个人轶事：每当我用美国而不是英国/澳大利亚的拼写写“道歉”或“授权”时，我的伴侣都会对我大吼大叫，所以，如果我开始使用日期和日期，请猜测她会对我做什么。数字以一种有趣的方式... :)

世界上大多数国家都将其,用作小数点分隔符（下图为绿色）。我不明白为什么多数应该适应少数。

我想我看到了一种建议的千位分隔符替代格式：1'000'000
尽管我不知道是否有建议的十进制分隔符。
我认为本地化现在没有必要。

通常我们所有的程序员，以及经常在互联网上徘徊的人们都非常可能知道英语的数字格式和度量，但是很多人对此并不了解，但仍在使用计算机，如果他们看到的格式看起来像他们自己的格式，但含义相反。

我确实认为编号和度量标准的统一在全球范围内是一件好事，其中可以使用1,000.00格式作为标准，为什么不这样做，但是我们绝对应该放宽英寸和磅，并称1,000,000,000十亿。

PS：我在“发现与历史”频道中观看了许多美国纪录片，并且它们总是football fields以一个整体为单位进行评估。他们是否意识到美国以外没有人知道一个（美国）足球场有多长时间？

我个人的信念是

软件本地化是有害的

它不仅在大多数情况下执行不佳，而且还会削减英语社区的用户，而英语社区拥有更多的资源来寻求帮助。对于德语来说，这可能没什么大不了的，但是如果您以斯洛伐克语为例，那就更像是用脚射击用户，即使假设您获得了不错的翻译。您必须了解本地术语，如果它不适合表达您想要的内容，则需要对其进行扩展（这可能会造成破坏，因为其他人可能会在大约同一时间为同一事物选择另一个术语，或者可能给同一个术语带来不同的含义）。
我曾经不得不在法国Mac上修复某些内容。这很痛苦，因为我的法语IT术语比说Mac的所有者差。我不得不在猜测相应术语之间来回翻译。

我可以肯定的是，掌握英语术语并不比母语难得多，而且要学习一定程度的英语以使您能够操作计算机并不是很大的挑战。它还为您打开了一个世界。相反，截至目前，如果您来自德国，许多软件供应商会越来越难获得其软件的英文版本，更糟糕的是，许多站点会自动选择您的语言。微软到目前为止，如果您用英语搜索某些内容并在其网站上打开结果，该资源就会自动显示在您的语言环境中。太好了！

恕我直言，如果一个接口需要本地化才能理解，那么您就弄错了接口，如果您翻译它，缺陷也不会消失，它们会成倍增加。

软件本地化必须正确完成

如果您对软件进行了本地化，那么如果没有尝试正确地进行安装，绝对没有意义。德语几乎无法理解的德语界面中几乎没有任何价值。

您同意，即使在德国，每个人都可以理解前者的含义，但在翻译过程中，您会将“房子”翻译为“豪斯”。
同样，您应该翻译9/11/2001为11.9.2001。一个德国人很可能会发现，以前的符号代表一个日期，但可能会将其解释为2001年11月的第9天。

我之所以选择这个历史性的日期，是为了用我的亲身经历来说明一些事情。德国媒体有时将这场悲剧称为“九十一”。当时我的英语不太好，尤其是我对日期符号的了解不是很好，所以我在脑海中将其可视化为“ 911”，并认为这是某种隐喻，使用电话号码将事件与紧急状态相关联。回顾我的思路，我同意这是非常遥不可及的，但是对于一个习惯于其他日期表示法的人来说，这似乎是合理的，因为它没有像“十一点九”那样敲响钟声。这应该向您展示我们的思维中刻有某些约定的方式，以及这如何导致对明显数据的误解。

至于数字，这对人类来说不是一个大问题，但对于程序来说却是一个更大的问题。德语本地化软件将输出1234.56为“ 1.234,56”（如果很幸运，则输出为“ 1234,56”，如果完全不幸运，则输出为“ 1'234,56”）。如果直接以英语格式将其提供给宽容的解析器，它将被解释为1.234，而无宽容的解析器则会使逗号阻塞。相反，这是关于同一问题的。
还需要注意的重要一点是，在numpad德语键盘布局上，有一个逗号，其中有一个点。因此，您很可能会从德国人那里获得德语格式的输入。能够处理这个方式比翻译“取消”“Abbrechen”更重要。

因此，如果您真的走了“我不在乎格式”之路，那么您和您的用户将不翻译任何内容，从而对您和您的用户有所帮助，因为这至少会提醒他们英语环境。通过强迫人们对他们不懂的单词使用词典，而不是打印出他们误解的信息，因为与他们对您的含义的理解不同，您遭受的损害较小。