推出自己的本地化框架是否可以？我可以使用默认的.NET本地化行为（即将文本放在程序集中以某种方式命名的资源文件中），除了我们有本地化的图像和文本，除了WinForms和WPF之外还需要在DirectX中呈现。
我可以将特定于表单的字符串放在一个地方，将其他字符串放在其他地方，但我认为将所有内容保存在一个地方更有意义，更不用说它有助于避免重复（对于域名值，如是/不，等等）。我们也有可能在将来将此工具移动到另一个平台，因此将所有本地化信息放在一个与平台无关的区域中会很不错。
我意识到这有点主观，但我在这里寻找最佳实践......我已经开始研究采用两种方法的项目。有什么想法吗？
答案 0 :(得分：2)
我开发了通过数据库存储的数据和元数据实现本地化的系统。如果您的应用程序已经大量使用快速数据库后端，您可以创建一个支持数据库的本地化层，并使用它来存储本地化信息，包括文本和非文本数据。它在几个小时内对我们有用。
修改即可。细节不适合这里，但基本上我们镜像了Windows API或.NET使用的键/值资源管理器的逻辑。我们通过允许将资源分组成组来扩展它，这些组可以任意嵌套。资源名称可以例如“ClientManagement.MainForm.StatusBar.ReadyMsg”给出，这意味着准备好的消息文本显示在客户端管理用户界面中主窗体的状态栏上。在应用程序启动时，从配置文件和使用它初始化的资源管理器中读取区域设置;在显式更改之前，对资源管理器的所有后续调用都将使用此类语言环境设置。我们还构建了一个管理用户界面，允许我们编辑存储在数据库中的资源，甚至添加新语言。最终评论：要本地化的数据不仅仅是屏幕上的标签和图标。例如，组合框中的选项值也需要进行本地化。
答案 1 :(得分：0)
我们使用数据库后端实现了本地化。我们能够创建一个很棒的资源编辑器，允许“翻译”最终用户动态更新翻译（不能用resx做到这一点！）。我们还能够通过模块支持审批流程和组翻译，以便整个模块可以被批准用于某种语言。
我们还决定为Asp.Net实施本地化提供程序，它基本上是开发人员无需代码的“自动”本地化。这实际上是项目中唯一困难的部分，因为界面没有很好的记录。它很难调试，因为它实际上是在Visual Studio主机进程中运行的。我们使用Web服务来解耦实现，这大大简化了事情。另一个好处是翻译会自动缓存，因此数据库不能很好地工作。不好的是，当您的翻译服务/后端关闭时，如果您没有预编译您的asp.net网站，当用户启动“新”页面时，编译器可能决定不翻译页面。此行为仍然存在（即使在翻译服务再次启动之后），直到您强制重新编译该站点。