您是如何在您从事的实际项目中实施国际化 (i18n) 的？
在阅读了 Joel 的著名文章后，我对制作跨文化软件产生了兴趣，每个软件开发人员绝对、肯定必须了解 Unicode 和字符集的绝对最低要求（没有借口！）。但是，除了确保尽可能使用 Unicode 字符串之外，我还没有能够在实际项目中利用这一点。但是，将所有字符串设为 Unicode 并确保您了解所使用的所有内容的编码方式只是 i18n 的冰山一角。
迄今为止，我所做的一切都是为一组受控的美国英语人士使用，或者 i18n 只是在推动项目上线之前我们没有时间进行工作。所以我正在寻找人们关于使软件在现实世界项目中更加本地化的任何技巧或战争故事。
已经有一段时间了，所以这并不全面。
字符集
Unicode 很棒，但你不能忽略其他字符集。Windows XP（英文）上的默认字符集是 Cp1252。在网络上，您不知道浏览器会向您发送什么（尽管希望您的容器能够处理大部分内容）。当您使用的任何实现中存在错误时，请不要感到惊讶。当字符集在机器之间移动时，它们可以与文件名进行有趣的交互。
翻译字符串
一般来说，翻译人员不是编码人员。如果您将源文件发送给翻译人员，他们会破坏它。字符串应该被提取到资源文件（例如Java 中的属性文件或Visual C++ 中的资源DLL）。应该为翻译者提供难以破解的文件和不会让他们破解的工具。
翻译人员不知道产品中字符串的来源。没有上下文就很难翻译字符串。如果您不提供指导，翻译质量就会受到影响。
在上下文的主题上，您可能会看到多次出现相同的字符串“foo”，并认为让 UI 中的所有实例都指向相同的资源会更有效。这是一个坏主意。在某些语言中，单词可能对上下文非常敏感。
翻译字符串需要花钱。如果您发布产品的新版本，则恢复旧版本是有意义的。拥有从旧资源文件中恢复字符串的工具。
应尽量减少字符串连接和手动操作字符串。在适用的情况下使用格式函数。
翻译人员需要能够修改热键。Ctrl+P是英文打印；德国人使用Ctrl+ D。
如果您的翻译过程需要有人随时手动剪切和粘贴字符串，那您就是在自找麻烦。
日期、时间、日历、货币、数字格式、时区
这些都可能因国家而异。逗号可用于表示小数位。时间可能是 24 小时制。不是每个人都使用公历。你也需要明确。如果您注意在您的网站上将日期显示为美国的 MM/DD/YYYY 和英国的 DD/MM/YYYY，除非用户知道您已经完成，否则这些日期是不明确的。
尤其是货币
类库中提供的 Locale 函数将为您提供当地货币符号，但您不能只在以美元表示价格的值前面加上英镑（英镑）或欧元符号。
用户界面
布局应该是动态的。不仅字符串在翻译时可能会加倍长度，而且整个 UI 可能需要反转（希伯来语；阿拉伯语），以便控件从右到左运行。那是在我们到达亚洲之前。
翻译前测试
非技术问题
有时您必须对文化差异保持敏感（可能会导致冒犯或不理解）。您经常看到的一个错误是使用标志作为选择网站语言或地理位置的视觉提示。除非您希望您的软件在全球政治中表明立场，否则这是一个坏主意。如果您是法国人并且提供了带有圣乔治国旗的英语选项（英格兰国旗是白色区域上的红十字），这可能会导致许多说英语的人感到困惑 - 假设外语和国家也会出现类似的问题. 图标需要经过文化相关性的审查。竖起大拇指或绿色勾号是什么意思？语言应该是相对中性的——在一个地区以特定方式称呼用户可能是可以接受的，但在另一个地区被认为是粗鲁的。
资源
C++ 和 Java 程序员可能会发现 ICU 网站很有用：http: //www.icu-project.org/
一些有趣的事情：
有一个 PHP 和 MySQL 应用程序可以很好地支持德语和法语，但现在需要支持俄语和中文。我想我把它移到了.net，因为 PHP 的 Unicode 支持——在我看来——不是很好。当然，玩弄 utf8_de/encode 或 mbstring-functions 很有趣。几乎和弗雷迪·克鲁格晚上来看你一样有趣……
意识到某些语言比其他语言更详细。德语通常比英语更冗长，并且看到德语版本如何因为分配的空间太少而破坏用户界面并不有趣。一些产品因其创造性的解决方法而获得了一些声誉，例如 Oblivion 的“Schw.Tr.d.Le.En.W.”。令人难忘:-)
玩弄日期格式，哇哦！是的，世界上确实有人在中间使用日期格式。试图找出 07/02/2008 应该是什么意思真是太有趣了，只是因为有些用户可能认为这可能是 7 月 2 日……但话说回来，你们在池塘里的人可能也相信那些把中间的月份：-P，特别是因为在英语中，7 月 2 日听起来比 7 月 2 日好很多，这不一定适用于其他语言（即在德语中，你永远不会说 Juli 2，但总是说 Zweiter Juli）。我尽可能使用 2008-02-07。很明显，这意味着 2 月 7 日并且排序正确，但是 dd/mm 与 mm/dd 可能是一个非常棘手的问题。
另一个有趣的事情，数字格式！10.000,50 vs 10,000.50 vs. 10 000,50 vs. 10'000,50 ...这是我现在最大的噩梦，必须支持多元文化环境，但无法可靠地知道用户的数字格式将使用。
正式或非正式。在某些语言中，有两种称呼人的方式，一种正式的方式和一种更非正式的方式。在英语中，您只需说“You”，但在德语中，您必须在正式的“Sie”和非正式的“Du”之间做出选择，法语 Tu/Vous 也是如此。选择正式的方式通常是安全的选择，但这很容易被忽视。
日历。在欧洲，一周的第一天是星期一，而在美国是星期日。日历小部件很好。向欧洲用户显示左侧为星期日、右侧为星期六的日历并不是很好，这会使他们感到困惑。
我为我以前的雇主工作过一个使用 .NET 的项目，我们使用了一种内置的 .resx 格式。我们基本上有一个文件，其中包含 .resx 文件中的所有翻译，然后是具有不同翻译的多个文件。这样做的结果是，您必须非常努力地确保应用程序中可见的所有字符串都存储在 .resx 中，并且无论何时更改，您都必须更新您支持的所有语言。
如果您变得懒惰并且不通知负责翻译的人员，或者您在未通过本地化系统的情况下嵌入字符串，那么稍后尝试修复它将是一场噩梦。同样，如果本地化是事后才想到的，那将很难落实到位。最重要的是，如果您没有将所有可见字符串都存储在外部标准位置，那么很难找到所有需要本地化的字符串。
另一个注意事项，非常严格地避免直接连接可见字符串，例如
String message = "The " + item + " is on sale!";
相反，您必须使用类似的东西
String message = String.Format("The {0} is on sale!", item);
原因是不同的语言通常对单词进行不同的排序，直接连接字符串需要一个新的构建来修复，但是如果你使用了像上面这样的某种字符串替换机制，你可以修改你的 .resx 文件（或任何本地化您使用的文件）用于需要重新排序单词的特定语言。
今天早上我刚听了Scott Hanselman 的播客，他在其中谈到了国际化，尤其是非常棘手的事情，比如土耳其语（有四个 i）和泰语。此外，杰夫阿特伍德有一个帖子：
除了前面的所有提示，请记住 i18n 不仅仅是将单词更改为其他语言上的等价词，尤其是对于从右到左书写的非拉丁语言字母（韩语、阿拉伯语），因此整个 UI 必须符合，例如
必须是
阿拉伯语文本 1 -
阿拉伯语文本 2 -
阿拉伯语文本 3 -
（反向项目符号列表似乎不起作用：P）
如果您的系统必须在用户更改所使用的语言后动态地应用更改，这可能是 UI 的噩梦。
另一个非常困难的事情是测试不同的语言，不仅仅是为了单词的正确性，而且因为像韩语这样的语言通常有更大的字体类型，这可能会导致语言特定的错误（比如按钮上的“保存”文本大于某些语言的按钮本身）。
发现一件更有趣的事情：斜体和粗体文本 makrup 不适用于 CJK（中文/日文/韩文）字符。它们只是变得不可读。（好吧，我之前也无法真正阅读它们，但尤其是粗体只会产生墨迹）
我认为从事国际化工作的每个人都应该熟悉 Common Locale Data Repository，它现在是 Unicode 的一个子项目：
这些人正在努力为各种 i18n 问题建立标准资源：货币、地名、大量的东西。鉴于该项目存在，任何维护自己的核心本地数据的项目都是非常疯狂的，恕我直言。
另一个挑战是接受用户的输入。在许多情况下，操作系统提供的输入处理（例如 Windows 中的 IME，它与常见的文本小部件透明地工作）可以缓解这种情况，但这种功能并非适用于所有可能的需求。
我建议使用99translations.com 之类的东西来维护您的翻译。否则，您将无法分辨每种语言的哪些翻译是最新的。
我使用的一个网站有一种翻译方法，所有者称之为“wiki + 机器翻译”。这是一个基于社区的网站，因此显然与公司的需求不同。
http://blog.bookmooch.com/2007/09/23/how-bookmooch-does-its-translations/
还没有人提到的一件事是带有一些谨慎部分的字符串，例如“该单元将在 5 天内到货”或“星期一发生了一些事情”。其中 5 和星期一将根据状态而变化。将它们一分为二并将它们连接起来并不是一个好主意。只有一个不同的部分和好的文档，你可能会侥幸成功，有两个不同的部分会有一些语言更喜欢改变它们的顺序。