国际化 Web 应用程序的最佳实践？

Posted 2023-02-24

【中文标题】国际化 Web 应用程序的最佳实践？

【英文标题】：Best practices for internationalizing web applications?

【发布时间】：2010-09-14 10:02:55

【问题描述】：

国际化网络应用程序似乎总是一件苦差事。无论您为可插入语言提前计划了多少，总是会遇到编码问题、不适合您的模板的时髦措辞以及其他问题。

我认为，对于程序员在决定将其 Web 应用程序国际化时应注意的一系列事项，征求 SO 社区的意见会很有用。

【参考方案1】：

国际化很难，以下是我从使用 20 多种不同语言的 2 个网站中学到的一些东西：

在任何地方都使用 UTF-8。没有例外。 html、服务器端语言（尤其要注意 php）、数据库等。 除非您需要大量工作，否则图像中没有文字。如有必要，使用 CSS 将文本放在图像上。 将配置与本地化分开。这样，本地化人员可以翻译文本，您可以处理每个区域设置的不同配置（功能、布局等）。您不希望本地化人员有能力干扰您的应用。 确保您的布局可以处理比英文长 2-3 倍的文本。而且还比英语少 50%（日语和中文通常更短）。 某些语言需要更大的字体（日文、中文） 颜色也特定于区域设置。红色和绿色在任何地方都不是同一个意思！ 将作为语言环境名称的类名添加到文档的正文标记中。这样，您可以轻松地在 CSS 文件中指定特定区域设置的布局。 注意变量替换。不要分裂你的字符串。像这样让它们保持完整：“您有 X 条新消息”并将“X”替换为 #。 不同的语言有不同的复数形式。 0、1、2-4、5-7、7-无穷大。很难对付。 上下文很难。有时本地化人员需要知道字符串的使用位置/方式，以确保正确翻译。

资源：

http://interglacial.com/~sburke/tpj/as_html/tpj13.html http://www.ryandoherty.net/2008/05/26/quick-tips-for-localizing-web-apps/ http://ed.agadak.net/2007/12/one-potato-two-potato-three-potato-four

【讨论】：

我意识到这是旧的。这些都是很好的建议，我会牢记在心。你能提供一个具体的例子吗？

【参考方案2】：

在我公司，我们所有的字符串都存储在 *.properties 文件中。我们的构建工具构建了属性文件的“测试语言”副本，它替换了这样的字符串：

Click here

类似这样的：

[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]

现在，当我们在配置文件中将语言设置为“测试”时，将使用这些属性文件。 （当然我们不提供测试语言文件）。

这使我们能够：

确保正确显示 Unicode 字符，包括日文/中文/韩文。 确保布局针对具有较长单词的语言（尤其是德语的平均单词比英语更长）进行适当缩放。 找出所有硬编码的字符串（因为它们是纯英语的）。

至于实际翻译，这是由专业翻译人员完成的，而不是开发人员。

【讨论】：

这叫pseudolocalization。

Java 在 l18n 方面很疯狂；翻译的默认存储是 .properties 文件，这是does not support Unicode 开箱即用的少数 Java 文件格式之一！

【参考方案3】：

作为一个生活在国外的英国人，我对许多 Web 应用程序的国际化方法感到沮丧，并拥有blogged about my frustrations。

我的建议是：

考虑如何展示国际版网页 使用地理定位可能适用于许多用户，但正如我的示例对许多用户显示的那样，它不会 为什么不使用 Accept-Language 标头来确定要提供的语言 如果用户通过搜索引擎访问页面，则不要将其重定向到其他地方，例如转到其他语言的主页 更改语言并重新加载不同的页面非常烦人 - 要么提供相同的页面，要么在重定向之前警告用户当前内容无法以其他语言提供 英语是一种非常常见的语言，所以可能默认为英语 但请确保 GUI 上的更改语言选项清晰（我喜欢 Google 地图所做的，如帖子所示）

我在网上看到的都是公司内部化错误。从用户的角度正确理解确实很棘手。

【参考方案4】：

我有几个“双语”应用 我在 ASP.NET1.1 中使用了资源文件

还有一个叫做字符串资源工具的东西 基本上，您将所有字符串都放在两种语言的 .RES 文件中，然后根据文化或是否有人单击该语言的链接来确定要读取的文件

最大的问题是确保翻译正确