项目国际化

已经有一段时间了,所以这并不全面。

字符集

Unicode很好,但您不能忽略其他字符集。Windows XP(英语)上的默认字符集是Cp1252。在web上,您不知道浏览器会向您发送什么(尽管希望您的容器能够处理大部分内容)。当您使用的任何实现中都存在bug时,不要感到惊讶。当字符集在机器之间移动时,它们可以与文件名进行有趣的交互。

翻译字符串

一般来说,翻译人员不是编码人员。如果您将源文件发送给翻译人员,他们会将其破坏。字符串应提取到资源文件(例如Java中的属性文件或Visual C++中的资源DLL)。应该给翻译人员提供难以破坏的文件和不让他们破坏的工具。

翻译人员不知道字符串在产品中的来源。如果没有上下文,很难翻译字符串。如果你不提供指导,翻译的质量就会受到影响。

在上下文主题上,您可能会多次看到相同的字符串“foo”,并认为让UI中的所有实例指向相同的资源会更有效。这是个坏主意。在某些语言中,单词可能对上下文非常敏感。

翻译字符串需要花钱。如果发布产品的新版本,恢复旧版本是有意义的。拥有从旧资源文件恢复字符串的工具。

应尽量减少字符串串联和手动操作。如果适用,请使用格式功能。

翻译人员需要能够修改热键。 Ctrl键 + P 以英文打印;德国人使用 Ctrl键 + D .

如果您有一个翻译过程,需要有人在任何时候手动剪切和粘贴字符串,那么您就是在自找麻烦。

日期、时间、日历、货币、数字格式、时区

这些都可能因国家而异。逗号可以用来表示小数位。时间可以是24小时记数法。并不是每个人都使用公历。你也需要毫不含糊。如果您在网站上小心地将日期显示为美国的MM/DD/YYYY和英国的DD/MM/YYYY,则除非用户知道您已经这样做了,否则日期是不明确的。

尤其是货币

类库中提供的语言环境函数将为您提供本地货币符号,但您不能仅在给出美元价格的值之前粘贴英镑或欧元符号。

用户界面

布局应该是动态的。不仅字符串可能在翻译时长度加倍,整个UI可能需要反转(希伯来语;阿拉伯语),以便控件从右向左运行。那是在我们到达亚洲之前。

翻译前测试

• 使用代码的静态分析来定位问题。至少要利用IDE中内置的工具。(Eclipse用户可以转到“窗口”>“首选项”>“Java”>“编译器”>“错误/警告”,并检查非外部化字符串。)
• 通过模拟平移进行烟雾测试。解析资源文件并用伪翻译版本替换字符串并不困难,伪翻译版本可以将长度加倍并插入时髦的字符。使用外国操作系统不必说某种语言。现代系统应该允许您使用翻译的字符串和外国语言环境作为外国用户登录。如果你熟悉你的操作系统,你可以在不知道语言的任何一个单词的情况下找出它的作用。
• 键盘映射和字符集引用非常有用。
• 虚拟化在这里非常有用。

非技术问题

有时你必须对文化差异保持敏感(可能导致冒犯或不理解)。您经常看到的一个错误是使用标志作为选择网站语言或地理位置的视觉提示。除非你想让你的软件在全球政治中表明立场,否则这是个坏主意。如果您是法国人,并且提供了带圣乔治旗的英语选项(英国国旗是白色区域上的红十字),这可能会导致许多讲英语的人感到困惑——假设外语和国家也会出现类似的问题。图标需要经过文化相关性审查。竖起大拇指或绿色勾号是什么意思?语言应该相对中立——在一个地区以特定方式称呼用户可能是可以接受的,但在另一个地区则被认为是粗鲁的。

资源

C++和Java程序员可能会发现ICU网站很有用: http://www.icu-project.org/

一些有趣的事情:

1. 有一个PHP和MySQL应用程序,可以很好地与德语和法语配合使用,但现在需要支持俄语和中文。我想我把这个移到了。net,因为在我看来,PHP的Unicode支持不是很好。当然,使用utf8\U de/encode或mbstring函数是很有趣的。就像弗雷迪·克鲁格晚上来看你一样有趣。。。

2. 意识到有些语言比其他语言冗长得多。德语通常比英语要冗长得多,看到德语版本因为分配的空间太少而破坏了用户界面也不好玩。一些产品因其创造性的解决方法而声名鹊起,Oblivion的“Schw.Tr.d.Le.En.W.”令人难忘:-)

3. 玩弄日期格式,呜呜!是的,事实上,世界上有人使用日期格式,其中一天在中间。所以想知道2008年2月7日到底意味着什么很有趣,只是因为一些用户可能认为可能是7月2日。。。但话说回来,对于那些把月份放在中间的用户,你们可能也会这么认为:-P,特别是因为在英语中,7月2日听起来比7月2日好多了,这并不一定适用于其他语言(例如,在德语中,你永远不会说Juli 2,但总是说Zweiter Juli)。我尽可能使用2008-02-07。很明显,这意味着2月7日,它的排序也很正确,但dd/mm和mm/dd可能是一个非常棘手的问题。

4. 另一件有趣的事, Number formats ! 10000,50 vs 10000.50 vs.10000,50 vs.10000,50 vs.10000,50。。。这是我目前最大的噩梦,必须支持多文化环境,但无法可靠地知道用户将使用什么数字格式。

5. 正式或非正式。在某些语言中,有两种称呼人的方式,一种是正式的方式,另一种是非正式的方式。在英语中,你只说“you”,但在德语中,你必须在正式的“Sie”和非正式的“Du”之间做出决定,法语Tu/vou也是如此。选择正式的方式通常是安全的,但这很容易被忽视。

6. 日历。在欧洲,一周的第一天是星期一,而在美国是星期天。日历小部件很好。向欧洲用户显示左侧为星期日、右侧为星期六的日历并不太好,这会让他们感到困惑。

我为我以前的雇主做过一个项目,这个项目使用了。NET,并且有一个内置的。我们使用的resx格式。我们基本上有一个文件,里面有所有的翻译。resx文件,然后是具有不同翻译的多个文件。这样做的结果是,您必须非常努力地确保应用程序中可见的所有字符串都存储在中。resx,任何时候更改一种语言,都必须更新支持的所有语言。

如果你变得懒惰,不通知负责翻译的人,或者你在没有经过本地化系统的情况下嵌入字符串,那么以后尝试修复它将是一场噩梦。同样,如果本地化是事后才想到的,那么很难落实到位。总之,如果您没有将所有可见字符串存储在标准位置的外部,那么很难找到所有需要本地化的字符串。

另一个注意事项是,非常严格地避免直接连接可见字符串,例如

String message = "The " + item + " is on sale!";

相反,您必须使用以下内容

String message = String.Format("The {0} is on sale!", item);

这是因为不同的语言通常会对单词进行不同的排序,直接连接字符串将需要一个新的构建来修复,但是如果您使用了上述某种字符串替换机制,则可以修改。需要重新排序单词的特定语言的resx文件(或您使用的任何本地化文件)。

我刚才在听 Podcast from Scott Hanselman 今天早上,他谈到了国际化,尤其是真正棘手的事情,比如土耳其语(四个i’s)和泰语。还有,杰夫·阿特伍德 post :

除了前面的所有提示之外,请记住i18n不仅仅是为了在其他语言上更改对应的单词,特别是对于从右到左书写的非拉丁语言字母表(朝鲜语、阿拉伯语),因此整个UI必须一致,如

• 项目1
• 项目2
• 项目3

必须是

阿拉伯文文本1-

阿拉伯文文本2-

阿拉伯文文本3-

(颠倒的项目符号列表似乎不起作用:P)

如果您的系统必须在用户更改所使用的语言后以友好的方式应用更改,那么这可能是一场UI噩梦。

另一件非常困难的事情是测试不同的语言,不仅是为了单词的正确性,而且因为像韩国语这样的语言的字符通常有更大的字体,这可能会导致特定于语言的错误(例如,对于某些语言,按钮上的“保存”文本比按钮本身大)。

要发现的一件有趣的事情是:斜体和粗体文字makrup不适用于CJK(中文/日文/韩文)字符。它们只是变得不可读。(好吧,我以前也看不懂,但特别是加粗只会造成墨迹)

我认为从事国际化工作的每个人都应该熟悉通用语言环境数据存储库,它现在是Unicode的一个子项目:

Common Locale Data Repository

这些人正在努力为各种i18n问题建立一个标准资源:货币、地名、成吨的东西。IMHO,任何维护自己核心本地数据的项目都是相当疯狂的。

我建议使用 99translations.com 维护您的翻译。否则,你将无法说出你的翻译在每种语言中都是最新的。

另一个挑战是接受用户的输入。在许多情况下,操作系统提供的输入处理(如Windows中的IME)可以缓解这一问题,IME可以透明地与常见的文本小部件配合使用,但这种功能并不能满足所有可能的需要。

我使用的一个网站有一种被所有者称为“维基+机器翻译”的翻译方法。这是一个基于社区的网站,因此与公司的需求明显不同。

http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/

有一件事还没有人提到,那就是在“部队将在5天内出发”或“星期一发生了什么事”中有一些令人警惕的部分其中5和周一将根据州的不同而变化。将它们一分为二并连接起来不是一个好主意。如果只有一个不同的部分和良好的文档,您可能会侥幸逃脱,如果有两个不同的部分,则会有一些语言倾向于更改它们的顺序。