题

您是如何在您从事的实际项目中实施国际化（i18n）的？

在阅读 Joel 的著名文章后，我对制作跨文化软件产生了兴趣， 每个软件开发人员绝对必须了解 Unicode 和字符集的绝对最低限度（没有任何借口！）. 。然而，除了确保尽可能使用 Unicode 字符串之外，我还无法在实际项目中利用这一点。但是，将所有字符串设为 Unicode 并确保您了解所使用的所有内容的编码方式只是 i18n 的冰山一角。

迄今为止，我所做的一切工作都是供一组受控制的美国英语使用者使用的，或者说国际化并不是我们在推动项目上线之前有时间做的事情。因此，我正在寻找人们关于使软件在现实世界项目中更加本地化的任何技巧或战争故事。

没有正确的解决方案

其他提示

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

字符集

Unicode 很棒，但是您不能忽视其他字符集。Windows XP（英文）上的默认字符集是 Cp1252。在网络上，您不知道浏览器会向您发送什么（尽管希望您的容器能够处理大部分内容）。当您使用的任何实现中存在错误时，请不要感到惊讶。当字符集在机器之间移动时，它们可以与文件名发生有趣的交互。

翻译字符串

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

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

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

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

应尽量减少字符串连接和手动操作字符串。在适用的情况下使用格式函数。

翻译人员需要能够修改热键。 控制键+磷 以英文印刷；德国人使用 控制键+D.

如果您的翻译过程需要有人随时手动剪切和粘贴字符串，那么您就是在自找麻烦。

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

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

尤其是货币

类库中提供的 Locale 函数将为您提供本地货币符号，但您不能只在给出美元价格的值前面粘贴英镑（英镑）或欧元符号。

用户界面

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

翻译前测试

  • 使用代码的静态分析来定位问题。至少要利用 IDE 中内置的工具。（Eclipse 用户可以转到 Window > Preferences > Java > Compiler > Errors/Warnings 并检查非外部化字符串。）
  • 通过模拟翻译进行冒烟测试。解析资源文件并将字符串替换为伪翻译版本（将长度加倍并插入时髦字符）并不困难。您不必会说某种语言即可使用外国操作系统。现代系统应该允许您以外国用户身份登录，并使用翻译后的字符串和外国语言环境。如果您熟悉操作系统，则无需了解该语言的任何单词即可弄清楚其功能。
  • 键盘映射和字符集参考非常有用。
  • 虚拟化在这里会非常有用。

非技术问题

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

资源

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

一些有趣的事情：

  1. 拥有一个可以很好地处理德语和法语的 PHP 和 MySQL 应用程序，但现在需要支持俄语和中文。我想我将其转移到 .net，因为在我看来，PHP 的 Unicode 支持并不是很好。当然，使用 utf8_de/encode 或 mbstring-functions 很有趣。几乎和弗雷迪·克鲁格晚上来拜访你一样有趣......

  2. 意识到某些语言比其他语言更加冗长。德语通常比英语冗长得多，并且看到德语版本如何因为分配的空间太少而破坏用户界面并不有趣。有些产品以其创造性的方式围绕着这些产品而闻名，而Ollivion的“ Schw.tr.D.L.L.En.W.”获得了一些成果。令人难忘:-)

  3. 尝试一下日期格式，哇哦！是的，世界上确实有人使用日期格式，其中一天在中间。试图找出 07/02/2008 的含义真是太有趣了，只是因为有些用户可能认为这可能是 7 月 2 日......但话又说回来，你们可能对将月份放在中间的用户也有同样的看法:-P，特别是因为在英语中，7 月 2 日听起来比 7 月 2 日好得多，但这不一定适用于其他日期语言（即在德语中，你永远不会说 Juli 2，而总是说 Zweiter Juli）。我尽可能使用 2008-02-07。很明显，这意味着 2 月 7 日，并且排序正确，但是 dd/mm 与 dd/mm 对比。mm/dd 可能是一个非常棘手的问题。

  4. 另一个有趣的事情， 数字格式！10.000.50 对比 10,000.50 对比10 000,50 对比10'000,50...这是我现在最大的噩梦，必须支持多元文化环境，但没有任何方法可靠地知道用户将使用什么数字格式。

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

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

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

如果您偷懒并且没有通知负责翻译的人员，或者您在没有经过本地化系统的情况下嵌入字符串，那么稍后尝试修复它将是一场噩梦。同样，如果本地化是事后才想到的，那么实施起来也会非常困难。最重要的是，如果您没有将所有可见字符串存储在外部标准位置，则很难找到所有需要本地化的字符串。

另请注意，非常严格地避免直接连接可见字符串，例如

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

相反，你必须使用类似的东西

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

原因是不同的语言通常对单词的排序不同，并且直接连接字符串将需要新的构建来修复，但是如果您使用了像上面这样的某种字符串替换机制，您可以修改您的 .resx 文件（或任何本地化文件）您使用的文件）用于需要重新排序单词的特定语言。

我刚刚在听一个 斯科特·汉塞尔曼的播客 今天早上，他谈到了国际化，尤其是真正棘手的事情，比如土耳其语（有四个 i）和泰语。此外，杰夫·阿特伍德还有一个 邮政:

除了前面的所有提示之外，请记住 i18n 不仅仅是将单词更改为其他语言上的等效单词，特别是对于从右到左书写的非拉丁语言字母表（韩语、阿拉伯语），因此整个 UI 必须符合，例如

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

必须是

阿拉伯文文本 1 -

阿拉伯文文本 2 -

阿拉伯文文本 3 -

（反向项目符号列表似乎不起作用：P）

如果您的系统必须在用户更改所使用的语言后动态应用更改，这可能是 UI 噩梦。

另一件非常困难的事情是测试不同的语言，不仅仅是为了单词的正确性，而且由于韩语等语言的字符通常具有更大的字体类型，这可能会导致特定于语言的错误（例如按钮上的“保存”文本大于某些语言的按钮本身）。

有待发现的更有趣的事情之一：斜体和粗体文本标记不适用于 CJK（中文/日文/韩文）字符。它们简直变得不可读。（好吧，我以前也无法真正阅读它们，但特别是粗体只会产生墨迹）

我想每个从事国际化工作的人都应该熟悉 Common Locale Data Repository，它现在是 Unicode 的一个子项目：

公共区域设置数据存储库

这些人正在努力为各种国际化问题建立标准资源：货币、地名、大量的东西。恕我直言，鉴于该项目的存在，任何维护自己的核心本地数据的项目都是相当疯狂的。

我建议使用类似的东西 99translations.com 维护您的翻译。否则，您将无法判断每种语言的哪些翻译是最新的。

另一个挑战是接受用户的输入。在许多情况下，这可以通过操作系统提供的输入处理来缓解，例如 Windows 中的 IME，它可以与常见的文本小部件透明地工作，但该功能无法满足所有可能的需求。

我使用的一个网站有一种翻译方法，店主称之为“维基+机器翻译”。这是一个基于社区的网站，因此显然与公司的需求不同。

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

还没有人提到的一件事是带有一些警惕的部分，就像“单位将在5天内”或“星期一发生的事情发生”。其中5和星期一将根据州而改变。将它们分成两部分并将它们连接起来并不是一个好主意。如果只有一个不同的部分和良好的文档，您可能会侥幸逃脱，如果有两个不同的部分，就会有一些语言更喜欢改变它们的顺序。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top