国际化数据库

Question

你们认为国际化应该只在代码层面完成，还是也应该在数据库中完成？

是否有针对国际化数据库的设计模式或通用做法？

如果你认为这是代码问题，那么你只需要使用资源文件来查找从数据库返回的键吗？

谢谢。

- Richard

Answer 1

国际化在数据库中的应用是指您的列可以容纳数据。与 Text、Char 和 Varchar 相比，使用 NText、NChar 和 NVarchar 更为合适。

对于不变的标签，使用资源文件是一个好的方法来处理用户界面。

- hova

Answer 2

如果你想让你的应用程序在用户界面上支持多种语言，那么有更多的可能性。如果标签永远不会改变(除非你发布一个新版本)，那么把资源文件嵌入可执行文件或程序集中是最好的选择，因为它们运行速度更快。另一方面，如果你的标签需要由用户在运行时进行调整，那么将翻译存储在数据库中是一个不错的选择。至于代码本身，数据库中表和字段的名称，我们尽可能使用英文，因为英语是IT人员的"事实标准"。

- Sergiu Damian

Answer 3

这取决于您在数据库中存储的内容。以我最近参与的一个项目为例，客户端输入的电影标题并且仅对该客户可见，可以直接存储在数据库中。另一方面，投影机错误代码因为可能被客户和位于不同国家的网络运营中心查看，应该作为错误代码（以及支持数据，如灯泡使用时间和正在播放的电影标题）存储，这些数据可以根据观看者的语言设置在GUI级别进行翻译。

- Paul Tomblin

Answer 4

@hova覆盖了技术细节，但你可能需要考虑的是支持显示你不懂语言的系统。

一种应对这种情况的方法是将英语作为默认语言，并设置用户可以切换到另一种语言。这样，支持用户可以登录并自然地查看系统（假设英语是他们的第一语言），而实际用户可以用他们的母语来查看系统。我个人认为，数据应该始终是“自然的”-即用户的语言。

这引出了另一个有趣的问题-您的系统是否允许跨境安装多种语言？在我的经验中，对于用户界面是可以的，但对于数据来说，不行。以地址格式化为一个微不足道的例子，从瑞士系统给法国第三方发送信件时，地址仍应该是瑞士格式而不是法国格式，因为它必须先通过瑞士邮政系统。

- ColinYounger

---

实际上，你对地址格式化的事情是错误的。国际邮政联盟要求地址中最后一项是国家名称，并且要加下划线。瑞士邮政系统只需要解析国家名称即可。 - Paul Tomblin

Answer 5

如果你的客户是日本人，想要看到他们的名字用汉字和片假名（有时还包括最正式的外字），那么你必须将它们存储为Unicode编码。没有其他选择。

- duffymo

Answer 6

即使是地址这样的事情，在美国和日本之间也有很大的不同。一个模式不能同时适用于两者。

- duffymo