Доктрина 2 - лучшие практики для i18n?

Question

Я ищу несколько советов о том, как обрабатывать таблицы, в которых должны быть поля, которые должны быть переведены на n языков. Я читал, что лучше всего иметь одну базовую таблицу, содержащую все поля, не зависящие от языка, и одну таблицу, содержащую все поля с переводами.

Пример:

 <b>PRODUCT</b>             <b>PRODUCT_TRANSLATIONS</b>
+--------------+    +----------------------+
| id           |    | id                   |
+--------------+    +----------------------+
| category_id  |    | product_id           |
+--------------+    +----------------------+
| price        |    | language_id          |
+--------------+    +----------------------+
                    | name                 |
                    +----------------------+
                    | description          |
                    +----------------------+

Таким образом, у нас будет базовая таблица PRODUCT, в которой хранятся все метаданные, и таблица PRODUCT_TRANSLATIONS, в которой хранятся все данные, которые необходимо перевести на несколько языков. Таблица PRODUCT имеет отношение OneToMany к таблице PRODUCT_TRANSLATIONS.

Каким был бы Доктринский способ справиться с таким сценарием? Если бы я запросил таблицу «Продукты», я бы подключил все переводы к этой таблице. Но в большинстве случаев мне нужен только один перевод для данного идентификатора продукта. Я мог бы использовать класс репозитория для написания своих собственных методов получения, чтобы ограничить набор результатов только одним языком, но у меня будет много таблиц, в которых есть поля, которые необходимо перевести. Бьюсь об заклад, есть более общее решение этой проблемы. Другая проблема состоит в том, что если я запрашиваю один объект, который связан с другим объектом, я получу все переводы для этого второго объекта.

Кстати: мне известно о расширении поведения для перевода с помощью Гедиминаса, но мне не нравится тот факт, что все переводы хранятся в одной таблице.

Так что я ищу любые лучшие практики, когда дело доходит до интернационализации. Любая мысль на эту тему высоко ценится.

Answer 1

Кстати: мне известно о переводимом расширении поведения Гедиминаса, но мне не нравится тот факт, что все переводы хранятся в одной таблице.

Я считаю, что ваш подход кЭта проблема в основном связана с размером и типом вашего проекта.Если вы хотите реализовать простую CMS, вы также можете использовать массив для сохранения содержимого многоязычных полей.Однако этот подход ограничен.

/**
 * @var array
 *
 * @ORM\Column(name="title", type="array", nullable=true)
 */
private $title;

Если содержимое вашей системы полностью отличается от одного языка к другому или вашей системе требуются сложные запросы и отчеты, основанные на этих многоязычных полях, то упомянутый вами подход будетбудь хорошим.

Answer 2

Упомянутое вами расширение для переводимого поведения позволяет разрешать трансляцию для каждого класса.Посмотрите подзаголовок «Сущность перевода» в разделе «Расширенные примеры» переводимого документа .

Суть в следующем: используйте аннотацию @Gedmo\TranslationEntity, чтобы указать конкретную сущность, которая будетиспользуется для хранения переводов.Таким образом, вы можете разделить нагрузку на несколько таблиц.