数据库模型国际化玩法框架

发布于 2025-01-08 05:54:23 字数 626 浏览 2 评论 0原文

我想用 play! 编写一个多语言应用程序。我以前从未这样做过,所以我首先寻求一些如何正确执行此操作的建议。

任务: 假设我有一个带有问题和答案的简单应用程序。把它想象成一项调查。用户根据语言选择问题并以正确的语言显示答案。 为了更好地理解,模型看起来像:

Question: id, QuestionString

Answer: id, fk_questionId,answerString, isRightBool

正如你看到的通常的 1:n 关系。但现在如何实现多语言支持呢?

  1. 一个想法是复制整个数据库......这个想法看起来很简单但丑陋,因为以后的更改会产生额外的开销......我想这将是一场噩梦。
  2. 其他字段,如 QuestionStringGerman、questionStringEnglish。也不喜欢这个想法...
  3. 每个模型类具有 1:n 关系的附加表。就像question_lang和answer_lang一样。列是语言。看起来比较容易处理。
  4. 一张表可容纳所有翻译。列是语言。看起来最简单但很难进行纠正。

哪种方法最适合动态翻译。也许我错过了什么。如果有人能告诉我解决这个问题的正确方法是什么,我会很高兴。

提前谢谢!

Id like to program a multi-language application with play!. I never did that before so im looking for some advice how to do it right the first place.

the task:
lets assume i have a simple application with questions and answers. imagine it like a survey. Depending one the language the user chooses the questions and the answers are displayed in the correct language.
For better unstanding the model would look like:

question: id, questionString

answer: id, fk_questionId, answerString, isRightBool

As u see a usual 1:n relation. But how to approach now the multi language support?

  1. An idea would be duplicating the whole database...that idea seems simple but ugly because of the additional overhead for later changes...would be a nightmare i guess.
  2. additional fields like questionStringGerman, questionStringEnglish. Dont like that idea either...
  3. Additional table for each modelclass with an 1:n relation. Like question_lang, and answer_lang. Colums are the languages. Seems easier to handle.
  4. One table for all translations. Colums are the languages. Seems the easiest but hard to handle for correction.

Which approach is the best for dynamic translation. Maybe i miss something. Would be glad if some could tell me what the riht approach is to approach that problem.

Thx in advance!

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

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

发布评论

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

评论(2

策马西风 2025-01-15 05:54:23

我实际上已经做过一次了。

我的解决方案是使用三个表:

table1: QuestionId(qid, other fields)
表2:问题(qqid、fk_qid、问题、语言集、其他字段)
table3:answers(id, fk_qqid, answer, other fields)

这样,您可以拥有任意多种语言。每个语言问题将被视为一个独立的记录。要获取同一问题的所有翻译,questionId 的 qid 将帮助您获取该集合。

I have actually done it once.

My solution was to use three tables:

table1: questionId(qid, other fields)
table2: questions(qqid, fk_qid, question, languageSet, other fields)
table3: answers(id, fk_qqid, answer, other fields)

this way, you can have as many languages as you would like. each language question will be treated as an independent record. to get all translation for the same question, questionId's qid will help you to get the set.

我不是你的备胎 2025-01-15 05:54:23

我个人的想法如下:

Table: Language
Id, Name

Table: Translation
Id, UniqueName(IdxUnique), LanguageId(FK), TranslationText

Table: Question
Id, TranslationUniqueName(FK)

Table: Answer
Id, QuestionId(FK), IsRight, TranslationUniqueName(FK)

我在使用 Id 进行翻译和使用 UniqueName(密钥)之间左右为难 - Id 在性能方面可能边际有益,但使用有意义的唯一密钥可以促进开发更容易(例如,将某些内容设置为 WelcomeText 并让系统查找翻译比将其设置为 16

更清晰)此外,如果您添加/删除/复制翻译,尤其是跨多个数据库实例(不同环境)的翻译。

在回应您对其他答案的评论时,如果未选择语言,您可以在 Language 表本身中添加权重或将 LanguageId 与用户帐户相关联。您还可以(如果您想聪明的话)尝试根据用户的位置进行猜测(但 ofc 您应该始终为他们提供更改选项 - 没有什么比被重定向到 google.es 更烦人的了> 当您在西班牙时)。

在任何情况下,您执行翻译的方法都应该为您执行此操作 - 例如,您的应用程序只需创建一个 GetTranslation('WelcomeText') - 然后您的 GetTranslation() 方法就可以查找要使用的适当语言并获取正确的字符串

I'd personally have as follows:

Table: Language
Id, Name

Table: Translation
Id, UniqueName(IdxUnique), LanguageId(FK), TranslationText

Table: Question
Id, TranslationUniqueName(FK)

Table: Answer
Id, QuestionId(FK), IsRight, TranslationUniqueName(FK)

I'm torn between using an Id for the Translation and a UniqueName (Key) - Id is probably marginally beneficial in terms of performance but using a Meaningful Unique key makes development easier (eg Set something to WelcomeText and let the system look up the translation is far cleaner than setting it to 16)

Also, Keys are more portable if you're adding/deleting/duplicating translations, especially across multiple database instances (different environments).

In Response to your comments on the other answer, for when no language is selected, you could add weightings in the Language table itself or associate a LanguageId with the user account. You could also (if you want to be clever) attempt to guess based on the location of the user (but ofc you should always give them the option to change - nothing more annoying than being redirected to google.es when you're in Spain).

In any case, your method to do the translation should do this for you - eg your app just makes a GetTranslation('WelcomeText') - Your GetTranslation() method can then look up the appropriate language to use and get the correct string.

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