我应该如何在数据库中存储用户输入数据的本地化版本?

发布于 2024-11-08 16:02:09 字数 271 浏览 0 评论 0原文

我正在为一个客户开发一个网络应用程序,该应用程序需要 3 种语言(英语和其他 2 种语言)本地化。我了解如何使用 ASP.NET 应用程序中的资源来显示静态数据的本地化版本。但是,我不确定如何处理本地化用户输入数据的问题。例如,管理员可能想要向应用程序添加一些新的元数据(例如新的产品类别)。这最终需要翻译成所有 3 种语言,但最初会以管理员知道的任何语言输入。由于此类数据不是静态的,因此我们将其存储在数据库中。我们是否应该在主键中添加文化代码来区分相同数据的不同本地化版本?对于此类问题是否存在我不知道的“最佳实践”或模式?

I am working for a client on a web app that requires localization in 3 languages (English and 2 others). I understand how to use resources in an ASP.NET application to display localized versions of static data. However, I am not sure how to approach the issue of localized user-entered data. For example, an administrator may want to add some new metadata the application (e.g. a new product category). This will eventually need to be translated into all 3 languages, but it will initially be entered in whatever language the administrator knows. Since this kind of data is not static, we store it in the database. Should we add a culture code to the primary key to differentiate different localized versions of the same data? Is there a "best practice" or pattern I'm not aware of for this kind of problem?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

雨巷深深 2024-11-15 16:02:09

您的实体有一个子表,其中包含 MainItemID 和 LanguageCode(EN、DE、FR 等)的复合 PK。该子表存储您的语言特定文本。

如果您总是使用英语,或者它是后备,那么您可以使用德语、法语等的子表和英语的主表。 LEFT JOIN 和 ISNULL 将解决这个问题。

无论哪种方式都可以,具体取决于您的具体需求,我怀疑这是第一个。当然,您需要确保至少有一个子行用于输入新产品类别的数据

Have a child table your your entity, with a composite PK of MainItemID and LanguageCode (EN, DE, FR etc). This child table stores your language specific text.

If you always have English, or it is a fallback then you could have the child table for DE, FR etc and the main table for English. A LEFT JOIN and ISNULL will take care of this.

Either way is OK depending on your exact needs which I suspect is the first one. Of course, you'd need to ensure you have at least one child row on data entry of, say, a new product category

清风挽心 2024-11-15 16:02:09

我建议您创建一个表来跟踪语言,然后使用 languageID 作为另一个表中的外键而不是语言代码。

Language(LanguageID, Name)

然后在其他表中使用该 LanguageID 作为外键。

例如,您正在表中存储本地化文本

  LocalizedTextTable(ID,text,LanguageID)

I would suggest you make a table to track the Language and then use the languageID as a foreign key in the other table instead of language code.

Language(LanguageID, Name)

And then in the other tables use that LanguageID as a foreign key.

e.g. you are storing localized text in the table

  LocalizedTextTable(ID,text,LanguageID)
椵侞 2024-11-15 16:02:09

我的解决方案是创建一个字符串列,其中保存所有支持语言的编码数据。插入和提取数据需要特殊的应用程序逻辑。
支持多语言数据的专业文本编辑器也有很大帮助。

My solution was to create a string column which holds encoded data for all supported languages. Special application logic is required to insert and extract the data.
Specialized text editor supporting multi-lingual data helped a lot too.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文