数据库中的国际化

Question

你们认为国际化应该只在代码级完成，还是应该在数据库中完成。

是否有任何设计模式或接受的国际化数据库实践？

如果您认为这是一个代码问题，那么您是否只使用资源文件来查找从数据库返回的密钥？

感谢

Answer 1

国际化延伸到数据库，只要你的列将能够保存数据。 NText，NChar，NVarchar而不是Text，Char，Varchar。

就您的用户界面而言，对于不变标签，资源文件是一个很好的使用方法。

Answer 2

这取决于你存储在数据库中的许多东西。以我最近的一个项目为例，一个在客户端输入的电影标题仅对该客户可见，这是一个公平的游戏，可以存储在数据库中。另一方面，由于客户端以及可能位于不同国家的网络操作中心可以查看投影仪错误代码，因此应将其存储为错误代码（以及支持的数据，如灯泡小时数和所显示的电影标题），可以根据观看者的语言设置以gui级别进行翻译。

Answer 3

如果您提到在UI级别上让您的应用支持多种语言，那么还有更多的可能性。如果标签永不改变，除非你发布一个新版本，那么嵌入到可执行文件或程序集本身的资源文件是你最好的选择，因为它们工作得更快。另一方面，如果您的标签需要在运行时由用户进行调整，那么将翻译存储在数据库中是一个不错的选择。就代码本身而言，数据库中的表&字段的名称尽可能使用英语，因为英语是IT人员的“事实上”标准。

Answer 4

@hova涵盖了技术性，但您可能要考虑的是支持显示您不理解的语言的系统。

解决此问题的一种方法是将英语作为默认语言，并将用户设置切换为其他语言。这样，您的支持用户就可以以自然的方式登录并查看系统（假设英语为第一语言），并且您的实际用户可以使用他们的第一语言查看系统。海事组织，数据应该始终是“自然的” - 用户的语言。

这引发了另一个有趣的问题 - 您的系统是否允许多种语言跨境安装？根据我的经验，对于用户界面来说是的，但对于数据而言，没有。举一个简单的地址格式示例，瑞士系统给法国第三方的信件应该仍然有一个瑞士格式的地址，而不是法语地址，因为它必须先通过瑞士邮政系统。

Answer 5

如果你的客户是日本人，想看到他们的名字在汉字和片假名（有时是最正式的外文），你必须将它们存储为Unicode。没办法。

Answer 6

即使像地址这样的东西在美国和日本之间也有很大的不同。一种模式不会削减它们。