这个实现的扩展性是否良好：
要求是：
系统必须支持x种语言；其中 x will = 企业可以翻译的尽可能多的语言
所有系统维护的值（页面内容、电子邮件内容、存储在面向用户的数百个查找表中的值）都需要支持多语言。
我的实现：
表：（使用的示例名称）
local_text_table
language_lookup_table
Content_table_1
Content_table_2
Content_table_3
Content_table_4
....
Plan:
language_lookup_table 包含所有可能语言的列表
lang_id lang_name
local_text_table 包含系统上使用的所有可能文本（电子邮件、页面内容、菜单标签、页脚文本等）的列表，以及系统将支持的每种语言的 1 列 - FK 到 language_lookup_table。
text_id
英文文本
西班牙语文本
阿拉伯文文本
...
这样，整个系统的所有翻译都存储在一张表中。我可以一步启用/禁用/更新/编辑/添加/删除翻译。在代码中，所有文本都存储为引用 (text_id) 的关键字。系统检测用户会话正在运行的语言，并相应地从该关键字的列中提取文本。如果特定行为 NULL（未翻译），它将默认为英文文本列。
这个好吗？
当然，这对于存储在数百个表中的查找值不起作用，因为除了为每个表提供每种语言自己的列之外，我还没有计划。然后，我还拥有用户内容，以允许用户翻译他们的用户帖子，例如博客、评论等，而我对此没有计划。但我想首先关注系统文本并最终确定它。
您的设计存在缺陷，因为如果不向 local_text_table 添加列，您将无法添加新语言。
该表的更好设计是：
text_id
lang_id (foreign key to language_lookup_table)
translated_text
现在，您可以将语言添加到 language_lookup_table，然后开始将翻译添加到 local_text_table，而无需对关系模型进行任何更改。如果您有办法通过 UI（甚至直接在数据库中）输入这些数据，您应该能够直接在生产中添加新语言。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
