经过深思熟虑如何支持 i18n，我想出了一种公认的解决方案，即拥有一个单独的表。
可翻译问题
我按照建议安装了可翻译的学说扩展，但没有按照我想要的方式工作，有经验的用户建议我不要使用它。即使有一个单独的表，它在主表和翻译表中都有可翻译列，并以 eav 方式存储值。另外，如果默认区域设置发生变化(这发生在我身上，并且可能会再次发生)，它会使事情变得复杂，因为主表中的默认值似乎没有指定的区域设置。而且我有几个可翻译字段(5~)。这将导致 5甚至更多的左连接以防回退。
其他解决方案
我认为的另一个解决方案是拥有一个单独的表，仅针对每个表进行翻译，并可能通过 postLoad 事件监听器设置默认区域设置和回退。这样我可以在没有 obj.translations['en'] 的情况下调用 obj.getTitle() 。 getTitle() ，无需提供语言环境。
问题
这种方法的问题是回退。一个解决方法是在连接过程中添加“WITH locale in ('en','de')”，例如。这将返回更多数据，但回退可以工作。另一种方法是使用合并但是条令不可能映射到实体上，有什么办法可以有效的实现fallback吗？
最佳答案
您可以查看https://github.com/KnpLabs/DoctrineBehaviors#translatable ，这是我们经过深入研究后发现的最佳解决方案。
我们目前正在将它用于许多实体，并且效果非常好。 您可以像任何其他实体、连接一样查询翻译，例如使用 DQL。
是的，您可以轻松想象使用现有 api 的后备机制。
关于symfony - 数据库翻译与学说，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10423786/