从我阅读的内容来看，对字符串排序，显示日期，浮点数字格式都取决于语言环境。我还认为还有其他事情。
我应该期待并测试哪些错误？
#1 楼
我遇到的一些问题：货币格式取决于语言环境。
使用不同的基于语言环境的键盘也会遇到问题。我见过这样的问题：仅在将语言和键盘配置为特定区域设置时才出现问题（这是土耳其语和土耳其语键盘）。
对于德语，您需要注意换行-德语往往会串联单词，因此您会得到很长的单词，可以完全破坏整体布局。
如果您的应用程序使用数据库，则要确保数据库排序规则不会对非ASCII字符造成任何可怕的影响语言用途。
如果涉及任何进出口，还需要确保指定要使用的Unicode格式。
法语，德语，西班牙语或意大利语的可能性不大，但是请检查应用程序中没有将字符串呈现为图像的地方（我遇到了日语问题）。 ASCII字符的图像渲染通常小于ASCII字符集之外的渲染，这会导致异常错误。
评论
货币格式取决于语言环境这会让我感到震惊。 $ XX，XXX.00与$ XX.XXX，00。更不用说£，€等ux.stackexchange.com/questions/9105/…
–WernerCD
2014年3月21日15:40
@WernerCD，也是小数位数。日元没有小数点。有些货币有3。
–凯特·保罗（Kate Paulk）
2014年3月24日10:59
#2 楼
我们被收入的有限输入字段所烧毁。因为我住在德国，所以价值高达100000€，对于我们的测试人员而言，还算不错。但是该网站已针对俄罗斯这样的国家/地区进行了翻译，其中100000卢布的确不算太多....#3 楼
您可以通过了解有关您的应用程序的更多信息来节省大量时间。首先，与货币格式，数字格式，度量系统，长短日期格式，长短时间有关的许多问题如果开发人员正在使用OS API（可能的话）而不是编写函数来处理此功能，则操作系统将处理格式，日历，一周中的第一天以及排序顺序。如果是这种情况，则可以减少（而不是消除）测试范围。 （顺便说一句...我们将此功能类型称为MS的全球化测试。）假设应用程序编写为支持Unicode且您的开发人员在过去20年来一直未曾陷入困境，则数据处理也是如此。或出于某种奇怪的原因而将其转换为古老的ANSI字符代码页模型。 :-)
至于专门针对本地化测试（针对特定国际市场修改程序），因此需要寻找的问题包括
字符串扩展-esp德语。通常允许多@ 35％的字符
代码中的硬编码字符串（未翻译）
代码中的串联字符串（导致翻译后的字符串的排序不合理）
键助记符映射到键盘上不起作用的本机字符（加速键和快捷键）
UI布局（通常由于调整文本标签的大小而发生更改。
某些应用可能需要特定的驱动程序或适用于目标市场的库（语言环境）
如果有帮助文件，请不要忘记查看
如果有Web链接，请确保它们也指向适当的位置（尤其是那些页面）已本地化）
当然，翻译的“质量”可能会有问题。如果这是一个问题，我建议您与国内的母语人士合作，以一种类似于编辑者审阅书籍或文章的方式来查看译文。有时会发生翻译问题，因为翻译人员无法理解使用字符串的上下文。提供各种窗口/对话框的位图可以帮助翻译人员理解字符串的上下文。
评论
感谢您和交流的其他成员的详细和有用的答案。也感谢您提供有关在Microsoft中进行测试的书。我读了两次。
–user3251930
2014年3月21日在20:14
#4 楼
许多质量检查论坛中描述的典型错误是：文本扩展，导致字符串被截断
GUI更改，导致GUI元素和
控件或其重叠。对齐错误
自动热键分配，导致重复的热键
硬编码字符串，导致未翻译的字符串
不支持的代码页，导致垃圾
丢失或多余的控件，导致丢失或丢失损坏的
功能
我建议您阅读这篇文章，并对其进行详细说明：
http://www.moravia.com/files/download/Best_Practices_in_Localization_Testing.pdf
#5 楼
您可能认为这很“明显”，但是鉴于这是我们遇到的最常见的翻译问题，我认为有必要提一下。它不是一个bug，而是更多的东西，它被完全忽略了：单词的使用顺序通常与基本语言的使用顺序不同。例如，说您要翻译Welcome, [name]。天真的方法是简单地翻译“ Welcome”，然后将它们放在代码trans("Welcome,") + username中-这是不正确的，因为某些语言不会使用该模式。它应该类似于为此，借用Python语法：
trans("Welcome, %(name)s") % {'name': username}
这要求翻译人员理解
%(name)s是占位符，必须保留。但是，这使它们在使用不同语法的语言中更加灵活。例如，上述日语翻译为（根据Google翻译）：ようこそ、%(name)sに
惊喜！最后还有一个额外的字符，欧洲语言不使用，不能使用朴素的代码添加。
我不知道问题中列出的欧洲语言是否具有相似性问题（尽管在一个更复杂的示例中，我可以看到基于拉丁语的语言与日耳曼语的语言有所不同），所以这可能不适用于OP，但对其他语言仍然有帮助。
评论
顺便说一句，您从Google翻译获得的日语翻译更像是“欢迎使用％（placename）”，其中“ to”已移至该地点的名称之后，但这肯定是一个问题。
– MarkS。
2014年3月22日17:56
#6 楼
货币格式：确保货币格式确实与您所谈论的货币匹配！如果我告诉您我在纽约有500美元的酒店账单，而您将其翻译成德语，将500美元的账单更改为500欧元将是一个非常糟糕的主意。换算成500日元可能是无害的，因为日本读者会知道这个数字可能不正确。请确保不要翻译不应该翻译的内容。实际上是代码一部分的字符串。如果您翻译数据库密钥，将会遇到麻烦。
上下文相关的翻译：键盘上的键与用于解锁门的键或C-flat之类的音乐键不同。如果您一次翻译了“密钥”一词，您的用户可能会非常困惑或为您的费用而大笑。
复数很有趣。英文：0项，1项，2项，依此类推。规则在不同的语言中是不同的。最好避免这种情况：-)
#7 楼
这些天，我每天都修复Android应用程序的本地化错误。我遇到的最常见错误是关键字/变量损坏。
示例：
<![CDATA[变成<![CDATA [ %2$d%%\n变成%2$d％%\n 预翻译软件使用Google Translate或相当于为翻译人员提供了改进的第一步。这样的软件经常破坏变量。
注意：需要变量来翻译诸如“ You have 3 talismans”之类的东西：（英语）
You have %NUMBER %OBJECT（日语）君は%OBJECTを%NUMBER個持ってる ...，考虑到如何每种语言的复数形式和语法不同。这就是为什么需要变量的原因。可以通过改进翻译平台或培训翻译人员来解决问题，这都不容易，因为我们是使用第三方众包的开源项目翻译平台。
评论
这些是哪些变量？为什么要在文本中使用变量？
–user3251930
2014年3月21日14:57
有关变量为何必不可少的信息，请参见Izkata的答案。
–最大
2014年3月21日在19:03
@ user3251930：添加了注释来解释这一点。
–尼古拉斯·拉乌尔（Nicolas Raoul）
2014年3月23日在7:33
#8 楼
为避免出现很多问题，请确保从Web层到数据库的整个应用程序层都独家使用UTF-8字符集。在相关说明中，请确保服务器时间及其所有引用（存储）等）使用GMT（UTC + 0）完成。否则，夏令时会重叠，本地化的引用等可能会破坏时间戳，逻辑等。只有在客户端，日期/时间才可以转换为本地时区/语言环境。
检查输入/输出的一致性（实际上是用户输入的任何语言输入的内容）。
确保翻译由本地人完成。 Chevrolet Nova（英语中的意思是“爆炸之星”）在西班牙语中表示“ No Go”（营销灾难的真实故事）。
检查搜索引擎结果。特别地，词干总是特定于语言的，当假设使用英语时，词干会导致非常奇怪的结果。
评论
你在申请中是什么意思？目标是什么？您是指移动平台还是台式机？我发现了同样的问题，可能会有所帮助：developers.stackexchange.com/questions/233048/…