国际化网络应用程序似乎总是很繁琐的。无论你提前为可插拔语言做了多少计划，都会出现编码问题、与模板不匹配的奇怪措辞以及其他问题。
我认为，为了国际化他们的网络应用程序时，程序员应该注意以下几点，并希望得到SO社区的意见：
4个回答
61
国际化很难，下面是我在处理超过20种不同语言的两个网站时学到的一些事情：
- 无论何时都要使用UTF-8编码。HTML、服务器端语言（特别是PHP）、数据库等等都不能例外。
- 除非你想做大量工作，否则不要将文本放在图片中。如果必要，可以使用CSS将文本覆盖在图片上。
- 将配置与本地化分离。这样本地化人员可以翻译文本，而你也可以处理每个区域设置不同的配置（功能、布局等）。你不希望本地化人员有能力干扰你的应用程序。
- 确保你的布局能够处理比英语长2-3倍的文本。同时也要考虑比英语少50%的文本（日语和汉语通常较短）。
- 某些语言需要更大号的字体（例如日语、汉语）。
- 颜色也是因地区而异的。红色和绿色并非在任何地方都意味着相同的含义！
- 将区域名称作为classname添加到文档的body标签中。这样你就可以轻松地在CSS文件中指定特定区域的布局。
- 注意变量替换。不要拆分字符串。将它们保持完整，如：“您有X条新消息”，然后用#替换'X'。
- 不同的语言有不同的复数形式。0,1,2-4，5-7，7及以上。难以处理。
- 上下文很难处理。有时候本地化人员需要知道一个字符串在哪里/如何使用，以确保其被正确翻译。
参考资源：
- Ryan Doherty
1
我知道这很老。这些是好的建议，我会记在心里。你能提供一个具体的使用示例吗？ - Joshua
12
在我的公司中，我们所有的字符串都存储在*.properties文件中。我们的构建工具会构建一个“测试语言”副本的属性文件，用于替换这样的字符串：
Click here
使用类似这样的方式：
[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]
当我们在配置文件中将语言设置为“test”时，就会使用这些属性文件。（当然，我们不会发布测试语言文件。）
这使我们能够：
- 确保Unicode字符正确显示，包括日语/中文/韩语。
- 确保布局适合具有较长单词的语言（德语平均比英语单词更长）。
- 发现任何硬编码的字符串（因为它们将是纯英语）。
至于实际翻译，由专业翻译人员而非开发人员完成。
- Kip
2
5这被称为“伪本地化”（pseudolocalization）。 - Gan
4
作为一个居住在国外的英国人，我对许多网络应用的国际化方法感到沮丧，我已经在博客中写过我的挫败感。
我的建议是：
我的建议是：
- 考虑如何展示页面的国际版本
- 使用地理位置可能适用于许多用户，但正如我的例子所示，对于许多用户来说并不适用
- 为什么不使用Accept-Language标头来确定要提供的语言
- 如果用户通过搜索引擎访问页面，则不要将其重定向到其他地方，例如转到不同语言的主页
- 更改语言后重新加载不同页面非常烦人 - 要么提供相同的页面，要么在重定向之前警告用户当前内容在不同语言中不可用
- 英语是一种非常普遍的语言，因此可以默认使用该语言
- 但要确保GUI上清楚地显示更改语言选项（我喜欢Google Maps正在做的事情，如文章所示）
- planetjones
0
我有几个“双语”的应用程序 我在ASP.NET1.1中使用资源文件
还有一种叫做字符串资源工具的东西 基本上，您将两种语言的所有字符串放入.RES文件中，然后根据区域设置或某人单击语言链接确定要从哪个文件中读取
最大的陷阱是确保翻译正确
- WACM161
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接