我正在编写一个 asp.net 应用程序,该应用程序需要本地化到北美以外的几个地区。我需要做些什么来为这种全球化做准备?学习如何编写面向世界的应用程序的前 1 到 2 个资源是什么?
7 回答
我学到的几件事:
绝对且残酷地减少您拥有的包含文本的图像数量。这样做将使您的生活轻松 10 亿%,因为您不必为每种该死的语言获取一组新图像。
要非常警惕依赖于始终保持相同大小的事物的 css 定位。如果这些东西包含文本,它们将不会保持相同的大小,然后您将需要返回并修复您的设计。
如果您在 sql 表中使用字符类型,请确保任何可能接收国际输入的字符类型都是 unicode(nchar、nvarchar、ntext)。就此而言,我只是标准化使用 unicode 版本。
如果您正在动态构建 SQL 查询,请确保在任何引用的文本之前包含 N 前缀,如果文本有可能是 unicode 的话。如果您最终将垃圾放入 SQL 表中,请检查是否存在。
确保您的所有网页都明确声明它们是 unicode 格式。请参阅上面提到的 Joel 的文章。
您将在这个项目中大量使用资源文件。这很好——ASP.NET 2.0 对此有很好的支持。您需要查看 App_LocalResources 和 App_GlobalResources 文件夹以及 GetLocalResourceObject、GetGlobalResourceObject 和 meta:resourceKey 的概念。Professional ASP.NET 2.0的第 30 章对此有一些很好的内容。这本书的 3.5 版本可能也有很好的内容,但我不拥有它。
想想字体。您可能想要使用的许多标准字体不支持 unicode。我一直很幸运使用 Arial Unicode MS、MS Gothic、MS Mincho。不过,我不确定这些是如何跨平台的。另请注意,并非所有字体都支持所有 Unicode 字符定义。再次,测试,测试,测试。
现在开始考虑如何将翻译输入到这个系统中。与您的翻译供应商讨论他们希望如何来回传递数据以进行翻译。想想这样一个事实,通过您的本地资源文件,您可能会在系统中重复一些常用的字符串。您是否将它们规范化为全局资源文件,或者您是否有某种数据库层,其中每个使用的文本只生成一个副本。在我们最近的项目中,我们使用了从包含所有翻译和资源文件的原始英文版本的数据库表中生成的资源文件。
测试。一般来说,我会用德语、波兰语和亚洲语言(日语、汉语、韩语)进行考试。德语和波兰语很冗长,几乎可以保证会拉伸文本区域,亚洲语言使用完全不同的字符集来测试您的 unicode 支持。
了解 System.Globalization 命名空间:
另外,一本好书是NET Internationalization: The Developer's Guide to Building Global Windows and Web Applications
如果您针对的是其他文化、语言,那么在 Unicode 上稍微刷新一下会很好。
这是一个难题。我住在加拿大,所以多语种是一个大问题。在我从事软件开发的所有这些年中,我从未见过我喜欢的解决方案。我见过很多有效的解决方案,并且完成了工作,但它们总是感觉像是一个大杂烩。我会选择@harriyott,并确保您的所有字符串实际上都不是代码。资源文件适用于桌面应用程序。但是在 ASP.Net 中,我建议使用数据库。@John Christensen 也有一些很好的建议。
确保您在打开代码分析的情况下进行编译,并注意它给您的全球化警告。以不变的格式 ( CultureInfo.InvariantCulture ) 保存数据,直到将其显示给用户(然后使用CultureInfo.CurrentCulture)。
我会认真考虑阅读以下代码项目文章:
它涵盖了文化和区域设置的所有内容,设置线程当前的文化、资源文件、编码,你可以命名它!
当然,它加载了漂亮的图片和示例:-)。祝你好运!
我会建议:
- 将所有字符串放在数据库或资源文件中。
- 为翻译的文本留出额外的空间,因为有些(例如德语)比较冗长。