Question

Using the instructions on https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/translatable.md#advanced-examples a table can be split in order to store the translations in another table. The resulting table structure is:

(例A)

 Article             ArticleTranslation
+--------------+    +----------------------+
| id           |    | id                   |
+--------------+    +----------------------+
| title        |    | locale               |
+--------------+    +----------------------+
| content      |    | objectclass          |
+--------------+    +----------------------+
| online       |    | foreign_key          |
+--------------+    +----------------------+
                    | field                |
                    +----------------------+

In my view there are two problems using this standard approach: 1. the translated entity is stored into multiple records (one per field) in the translation table 2. The original record should be in the translated table as well.

有可能由Doctrine+ Gedmo Translat 储存这样的翻译:

(例B)

 Article             ArticleTranslation
+--------------+    +----------------------+
| id           |    | id                   |
+--------------+    +----------------------+
| online       |    | foreign_key          |
+--------------+    +----------------------+
                    | locale               |
                    +----------------------+
                    | title                |
                    +----------------------+
                    | content              |
                    +----------------------+

因此,未经翻译的田地应列入《公约》的表格,在《公约》的翻译表中填满一个记录,每翻译一个记录。

How can this be achieved?

Answer 1

using current architecture it stores a record per field in translation table. In general it was done this way in order to avoid synchronization issues if you add or remove translatable fields from your entities. Implementation of your method would result in having additional schema migration command specifically for extension or having some magic mapping in background. To avoid confusion the only thing which is scheduled for update is original record translation storage as default locale fallback, without having record in translation table. I understand that in advanced cases this bahavior is not what you would have done, but it is a behavior for most users which want it configurable as simple as possible. And regarding collection translations you can use query hint This behavior will never cover 99% of use cases like SF2 does in order to maintain simplicity

友情链接