如何测试您的应用程序是否符合Iñtërnâtiônàlizætiøn标准？我告诉人们将Unicode字符串Iñtërnâtiônàlizætiøn存储到每个字段中，然后查看它是否在输出中正确显示。
---包括作为Excel报告中单元格内容的输出，以rtf格式表示docs，xml文件等。
还应该做哪些其他测试？
从@Paddy添加了想法：
还尝试从右到左的语言。例如，שלוםירושלים（[耶路撒冷的和平]）。应该是这样的：
שלום ירושלים http://sandbox.kluger.com/shalom.jpg
注意：Stackoverflow正确实现。如果文本与图像不匹配，则表示您的浏览器，操作系统或代理可能存在问题。
另请注意：您不必更改或“设置”已在运行的应用程序以接受W欧洲字符或希伯来语示例。您应该只需在应用程序中键入这些字符，并让它们在输出中正确返回。如果您没有放置希伯来语键盘，请将此问题中的示例复制并粘贴到您的应用中。
答案 0 :(得分：6)
选择一个文本，其中文本从右向左读取并为此设置系统 - 确保它正确读取（说起来容易做起来难......）。
答案 1 :(得分：4)
使用Windows Vista以来提供的the three "pseudo-locales"之一：
三种不同的伪语言环境用于测试3种语言环境：
基础
qps-ploc区域设置用于类似英语的伪 本地化。它的字符串是英文字符串的较长版本， 使用非拉丁文和重音字符代替普通脚本。 另外简单的拉丁字符串应该按相反的顺序排序 这个地区。镜像
qpa-mirr用于从右到左的伪数据，这是 另一个感兴趣的领域。东亚
qps-asia旨在利用大型CJK角色 保留曲目，对测试也很有用。
Windows将开始格式化日期，时间，数字，货币在一个虚构的 psuedo-locale 中，看起来像英语，你可以使用它，但是当你不尊重它时显而易见语言环境：
[Шěđлеśđαỳ!!!]，8ōf[Μäŕςћ!!]ōf2006
答案 2 :(得分：3)
确保您的应用可以处理Turkish。它有几个怪癖，打破了承担英国规则的应用程序。因为有四种字母“i”（点状和无点，大写和小写），假定uppercase(i) => I的应用程序在使用土耳其语规则时将会中断uppercase(i) => İ。
常见的事情是检查用户是否使用"exit"或lowercase(userInput) == "exit"键入了命令uppercase(userInput) == "EXIT"。这符合英国规则的预期，但在"exıt" != "exit"和"EXİT" != "EXIT"的土耳其规则下将失败。要正确地执行此操作，必须使用内置于所有现代语言中的不区分大小写的比较例程。
答案 3 :(得分：3)
国际化比unicode处理更多。如果您知道日期，还需要确保日期显示在用户的时区内（并确保人们有办法告诉您他们的时区是什么）。
测试时区处理的一个简单事实是，有两个时区（Pacific/Tongatapu和Pacific/Midway）实际上相隔24小时。因此，如果正确处理时区，那么对于任何时间戳，这两个时区中的用户的日期应该永远不相同。如果您在测试中使用任何其他时区，结果可能会根据您运行测试套件的时间而有所不同。
您还需要确保日期和时间的格式化方式对用户的语言环境有意义，或者对此失败，解释日期呈现中的任何潜在歧义（例如“05/11/2009（dd） /月/年）“）。
答案 4 :(得分：2)
“Iñtërnâtiônàlizætiøn”是一个真正错误的字符串，因为它中的所有字符也出现在ISO-8859-1中，所以字符串可以完全没有任何Unicode支持！我不知道为什么它在它的主要功能完全失败时如此常用！
即使是中文或希伯来语文本也不是一个好选择（尽管从右到左是一整套蠕虫本身），因为它不一定包含3字节UTF-8以外的任何东西，这奇怪的是MySQL的默认UTF-8实现（仅限于3字节字符）中的一个非常大的漏洞，直到通过在MySQL 5.5中添加utf8mb4字符集来修复它。目前，> 3字节UTF-8的一个常见用法是Emojis，如下所示：[⛔]。如果你没有在这些括号中看到一些非常小的彩色图片，恭喜你，你刚刚在你的Unicode堆栈中找到了一个漏洞！
答案 5 :(得分：1)
我从一个完全不同的角度思考这个问题。我不记得我们做了什么，但在之前的项目中，我认为我们最后更改了区域设置（在区域和语言选项控制面板中？），以帮助我们确保本地化字符串正常工作。
