使用 https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/translatable.md#advanced-examples 上的说明可以拆分表,以便将翻译存储在另一个表中。 结果表结构为:
(示例A)
Article ArticleTranslation
+--------------+ +----------------------+
| id | | id |
+--------------+ +----------------------+
| title | | locale |
+--------------+ +----------------------+
| content | | objectclass |
+--------------+ +----------------------+
| online | | foreign_key |
+--------------+ +----------------------+
| field |
+----------------------+
在我看来,使用这种标准方法存在两个问题: 1. 翻译后的实体存储在翻译表中的多条记录中(每个字段一条) 2. 原始记录也应该在翻译表中。
Doctrine+ Gedmo Translatable 是否可以存储这样的翻译:
(示例 B)
Article ArticleTranslation
+--------------+ +----------------------+
| id | | id |
+--------------+ +----------------------+
| online | | foreign_key |
+--------------+ +----------------------+
| locale |
+----------------------+
| title |
+----------------------+
| content |
+----------------------+
因此,未翻译字段应位于 Article 表中,已翻译字段应位于 ArticleTranslation 表中,每篇已翻译文章一条记录。
如何实现这一目标?
使用当前架构,它在翻译表中存储每个字段的记录。一般来说,这样做是为了避免在从实体中添加或删除可翻译字段时出现同步问题。 方法的实现将导致专门用于扩展的额外模式迁移命令或在后台进行一些神奇的映射。为了避免混淆,计划更新的唯一内容是原始记录翻译存储作为默认语言环境后备,而翻译表中没有记录。 我知道在高级情况下,这种行为不是您会做的,但对于大多数希望其配置尽可能简单的用户来说,这是一种行为。 关于集合翻译,您可以使用查询提示这种行为永远不会像 SF2 那样覆盖 99% 的用例,以保持简单性
如果您可以使用其他解决方案,您可以重用 Sylius 翻译想法 https://docs.sylius.com/en/1.12/book/architecture/translations.html ,同时您还需要复制 OrmTranslatableListener 来映射特征领域