可以使用自己的本地化框架吗?我可以使用默认的.NET本地化行为(即,将文本放在程序集中以特定方式命名的资源文件中),但除了WinForms和WPF之外,我们还有需要在DirectX中呈现的本地化图像和文本。
我可以将特定于表单的字符串放在一个地方,而将其他字符串放在其他地方,但我认为将所有内容都放在一个地方更有意义,更不用说这将有助于避免重复(对于Yes/No等域值)。我们也有可能在未来将这个工具转移到另一个平台上,所以在一个平台无关的领域拥有所有的本地化信息将是很好的。
我知道这有点主观,但我在这里寻找一种最佳实践……我曾经从事过采用这两种方法的项目。有什么想法吗?
发布于 2010-01-02 21:40:03
我已经开发了一些系统,其中本地化是通过数据库存储的数据和元数据来实现的。如果你的应用已经在大量使用快速数据库后端,你可以创建一个数据库支持的本地化层,并使用它来存储本地化信息,包括文本和非文本数据。在一些情况下,它对我们来说很有效。
编辑。细节不适合在这里介绍,但基本上我们反映了Windows API或.NET使用的键/值资源管理器的逻辑。我们通过允许将资源分组到组中来扩展这一点,这些组可以任意嵌套。例如,资源名称可以指定为"ClientManagement.MainForm.StatusBar.ReadyMsg",,表示要在客户端管理用户界面中的主窗体的状态栏上显示的就绪消息文本。在应用程序启动时,将从配置文件中读取区域设置,并使用该区域设置初始化资源管理器;所有后续对资源管理器的调用都将使用此类区域设置,直到显式更改。我们还构建了一个管理用户界面,允许我们编辑存储在数据库中的资源,甚至添加新的语言。最后一点:要本地化的数据不仅仅是屏幕上的标签和图标。例如,组合框中的选项值也需要本地化。
发布于 2010-02-24 16:27:19
我们使用DB后端实现了本地化。我们能够创建一个强大的资源编辑器,允许“翻译器”终端用户动态更新翻译(使用resx无法做到这一点)。我们还能够支持审批流程,并按模块对翻译进行分组,这样整个模块都可以被批准在某种语言中使用,或者不可以。
我们还决定实现Asp.Net的本地化提供程序,它基本上进行“自动”本地化,不需要开发人员编写代码。这实际上是项目中唯一困难的部分,因为接口没有很好地记录下来。它很难调试,因为它实际上运行在Visual Studio主机进程中。我们使用web服务来解耦实现,这极大地简化了事情。另一件好事是翻译被自动缓存,因此数据库的工作不是很困难。一件坏事是,当你的翻译服务/后端关闭时,如果你没有预编译你的asp.net网站,当用户启动一个“新”页面时,编译器可能决定不翻译该页面。这种行为会一直存在(即使在翻译服务再次启动之后),直到您强制重新编译站点。
https://stackoverflow.com/questions/1992941
复制