How to store a translation in a different table using Doctrine 2 + Gedmo Translatable

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:

(example 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.

Is it possible with Doctrine+ Gedmo Translatable to store the translations like this:

(example B)

 Article             ArticleTranslation
+--------------+    +------------------开发者_运维技巧----+
| id           |    | id                   |
+--------------+    +----------------------+
| online       |    | foreign_key          |
+--------------+    +----------------------+
                    | locale               |
                    +----------------------+
                    | title                |
                    +----------------------+
                    | content              |
                    +----------------------+

So untranslated fields should be in the Article table, translated fields in the ArticleTranslation table with one record per translated article.

How can this be achieved?

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