我应该将桌面应用程序的本地化数据存储在数据库中吗？答案

【问题标题】：Should I store localization data for desktop application in database?我应该将桌面应用程序的本地化数据存储在数据库中吗？
【发布时间】：2016-02-12 09:50:01
【问题描述】：

在我的办公室，我们正在讨论处理桌面应用程序本地化的最佳方式。

虽然使用资源文件似乎是一个显而易见的选择，但我们想到了可以使用数据库进行集中本地化管理。应用程序将在开始时连接到数据库以下载所有需要的翻译，或者它可以在呈现控件时按需下载翻译。

应用程序（使用 C# 创建）部署在高度受控的环境中，以供内部使用，并借助处理发布本身以及实时更新的工具。我们有一个文件分发存储库和一个数据库服务器来处理几个卫星站点。

数据库会是在桌面应用程序中处理用户界面翻译的可行解决方案吗？

【问题讨论】：

听起来不错，但这并不是每个人的最佳方式。它可能是您的方案中最好的（首先考虑一切）。问题是为什么资源对你不利？为什么是数据库？为了能够快速分享本地化更新？预计这种情况多久发生一次？优点值得缺点吗？只有您可以回答这些问题和其他问题。目前的问题要么过于宽泛（如果我们试图考虑所有事情），要么基于意见（每个人都可能考虑他的情况）。
@Sinatr 好吧，使用数据库存储翻译的发起者的想法是允许我们“集中管理本地化”以重用应用程序之间的翻译。这当然会导致资源文件不存在的问题 - 它依赖于网络并且速度明显较慢。我想知道是否有一种方法可以减轻数据库的缺陷，并且仍然能够从明显的优势中受益。
您可以构建自己的本地化。我正在使用在应用程序启动时加载并用于通过反射更新静态类属性的 txt 文件。那么您所需要的只是一个简单的机制来获取版本和下载完整的翻译（如果版本比客户已有的新）。数据库应该可以。

【解决方案1】：

有几点你应该考虑

如果上面的一个或多个点与应用程序的业务计划相匹配，那么您应该考虑使用数据库和服务器缓存

假设您开始向应用程序添加一个新屏幕（表单）。在此表单中，您有 3 个 UI 元素（element1、element2 和 element3）。应该有一个集中的本地化服务（业务对象），它执行以下操作

阅读所有表格
阅读表单中的每个元素（在这里您可以过滤可能包含多语言文本的相关元素，如标签、按钮等，并排除面板）
应用程序是否处于客户模式？（假设您的应用在启动/登录时会为客户选择 - 不同的外观和感觉、不同的文本等）
尝试从服务器构建的缓存中获取翻译密钥（基于字典的数据结构，包含 applicationCode（或密钥）、customerKey、translationKey和价值）。翻译键可以是 formName.uiElementName
如果在缓存中找不到密钥，请尝试从数据库中获取它
如果在数据库中找不到（新添加的表单及其 UI 元素），则尝试在数据库中添加新条目（applicationKey、customerKey、translationKey、空值）
如果在数据库中找到，则将条目添加到缓存中
您可能需要一个管理菜单来清除该缓存

现在构建一个集中式应用程序来管理本地化数据库。在此处管理文本，您可以将其用于当前正在运行的应用程序以及未来的应用程序。

【讨论】：

你的想法让我思考。为客户端应用程序使用一些缓存确实可以消除数据库翻译存储的大多数问题。我们可以在数据库上创建一个触发器以将更改发布到文件存储库，然后使用我们已经必须将新翻译文件分发到工作站的更新工具。

【解决方案2】：

拥有一个集中的本地化服务非常重要，但是构建一个集中的应用程序来管理本地化数据库可能是一项艰巨的任务（时间和金钱）。如果您正在寻找一个快速、简单的解决方案并且不介意商业产品，您可以探索Passport。它提供了您需要的用户管理功能（如本地化）以及您可能需要但没有时间编写的其他功能。这些通常包括：

安装简单，可以成功处理桌面应用程序中的用户界面翻译。如果您确实预计会有显着增长并且客户特定的翻译Passport 可以与您一起扩展。

【讨论】：