翻译数据库字符串
我有一个为英国市场编写的应用程序，目前仅支持英语（英国），并且客户希望将应用程序的一部分部署到非英国站点并将数据同步回英国总部。
我可以使用资源文件和本地文化信息转换应用程序标签和消息，但想知道如何转换数据库绑定数据。
例如 这是基于总部的表格
tblFault
ID ; Description
1 ; Not Functional
2 ; Build Fault
3 ; Leak
4 ; Aesthetics
5 ; Testing
如果我要将数据翻译为非英国语言，我可以只替换描述，但如果数据不同步，这会导致一些问题？
我是否应该用另一列扩展表格以获取其他语言，然后使用当地文化更改选择？
tblFault
ID ; Description-EN ; Descrption-US ; Description-DE etc
1 ; Not Functional ; ;
2 ; Build Fault ; ;
3 ; Leak ; ;
4 ; Aesthetics ; ;
5 ; Testing ; ;
您会推荐什么方法？
谢谢菲尔
I have an application written for the UK market that currently only supports English (UK) and a client wants to deploy part of the application out to a non UK site and syncronise the data back to the UK HQ.
I can convert the application labels and messages using resource files and the local culture information but was wondering how you would convert the database bound data.
E.G.
Here is the HQ based table
tblFault
ID ; Description
1 ; Not Functional
2 ; Build Fault
3 ; Leak
4 ; Aesthetics
5 ; Testing
If I was to translate the data to the non UK language I could just replace the descriptions but this would cause some problems if the data is unsyncronised?
Should I extend the table with another column for additional language and then alter the selection using the local culture?
tblFault
ID ; Description-EN ; Descrption-US ; Description-DE etc
1 ; Not Functional ; ;
2 ; Build Fault ; ;
3 ; Leak ; ;
4 ; Aesthetics ; ;
5 ; Testing ; ;
What method would you recommend?
Thanks
Phil
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于故障与其描述之间存在 1:n 关系，因此最干净的解决方案是创建一个子表：
Since you have a 1:n relationship between faults and their descriptions, the cleanest solution would be to create a subtable:
这绝对是一种方法。
我之前在类似情况下使用的另一种方法是创建一个“LanguageId”列。
通常我会有这样的内容：
这允许我编写一个查询，如果字符串 35（例如）没有我正在寻找的语言，我仍然可以提供英语。想法是有总比没有好。
这种方法的缺点是复合主键和一些连接逻辑。
That's definitely one approach.
Another approach that I've used in situations like this before was to create a "LanguageId" column.
Typically I would have something like this:
This allow me to write a query that if string 35 (for example) doesn't have the language I'm looking for, I could still provide English. With the thought being that something is better than nothing.
The downside to this approach is composite primary keys, and some join logic.
很可能更像这样：
Something more like so, in all likelihood: