使用扩展方法替代本地化

时间:2011-11-23 12:32:53

标签: c# resources localization extension-methods

我即将为我的雇主开始一个本地化项目。它涉及一个预先存在的项目,其中包含许多Windows窗体和已建立的代码库,使用C#和ASP.NET编程。我已经研究过如何在visual studio中本地化应用程序并找到资源。

虽然这些问题足以解决问题,但我对使用资源的不利方面并不满意。这就是说,它具有相当大的占用空间,需要对每个表单文件进行更改。此外,资源文件只能在Visual Studio中编辑。我更愿意在没有编程知识的情况下启用外部翻译来进行翻译。

所以我想出了另一种解决方案:

使用String上的扩展方法构建静态本地化实用程序类:

public static String Localize(this String s)

实用程序类在启动时从文件加载本地化字符串。当程序在某处需要字符串时,它被称为

"foo".Localize();

程序将使用字符串本身作为表中的键来查找翻译。 它似乎是一个安全有效的解决方案,我对它留在现有代码库上的小占用空间感到满意。

基本上我想问:

  • 我错过了我的解决方案的缺点吗?
  • 我应该查看本地化数据的哪些文件格式(我已经遇到过.po文件格式)?
  • 是否有足够的理由偏离资源文件解决方案?

您将获得任何建议和/或考虑因素。

3 个答案:

答案 0 :(得分:3)

你正在尝试重新发明MS很久以前发明的轮子。您可以使用大量可用于资源的工具,甚至可以编写自己的资源提供程序。

可用的一些工具:What tools are available for adding Localization to an ASP.NET project?

如果您想为翻译人员使用数据库:Data Driven Resource provider from Rick Strahl

答案 1 :(得分:0)

  

我错过了我的解决方案的缺点吗?

我可以指出一些,aspx文件中的文本怎么样。您是否也要为他们提供扩展方法?我想这很难。

e.g。 <asp:Label Text="Title"> - 你打算怎么翻译?

此外,你的一些说法并非完全正确。

  

资源文件只能在Visual Studio中编辑

它们是xml文件,因此您可以使用任何编辑器编辑它们或编写自定义实用程序来执行此操作。

答案 2 :(得分:0)

  

我错过了我的解决方案的缺点吗?

标准资源文件不仅仅是更改文本。

您可能需要调整某些元素的大小以适应新文本(如果您不使用现有的布局管理机制)。对于某些语言,您需要更改字体/字体大小(想想中文,日文,韩文)或对齐(想想从右到左的语言,如阿拉伯语和希伯来语)。

此外,翻译标准文件意味着使用知道格式的编辑器可以“按原样”看到对话框,因此它提供了比独立字符串更多的上下文,从而提高了翻译质量。