Doctrine 2: las mejores prácticas para i18n?

Question

Estoy buscando algunos consejos sobre cómo manejar tablas que necesitan tener campos que deben traducirse a n idiomas. He leído que el mejor enfoque es tener una tabla base que contenga todos los campos que no son específicos del idioma y una tabla que contenga todos los campos con las traducciones.

Ejemplo:

 

PRODUCT    PRODUCT_TRANSLATIONS 
+--------------+ +----------------------+ 
| id   | | id     | 
+--------------+ +----------------------+ 
| category_id | | product_id   | 
+--------------+ +----------------------+ 
| price  | | language_id   | 
+--------------+ +----------------------+ 
        | name     | 
        +----------------------+ 
        | description   | 
        +----------------------+ 

Así que vamos a tener el producto de la tabla base que contiene todos los metadatos y una mesa PRODUCT_TRANSLATIONS donde todos los datos se almacena esa necesidad de ser traducido a varios idiomas. La tabla PRODUCT tiene una relación OneToMany con la tabla PRODUCT_TRANSLATIONS.

¿Cuál sería la forma de Doctrine para manejar ese escenario? Si consulto la tabla Productos, obtendré todas las traducciones unidas a esta tabla. Pero la mayoría de las veces solo quiero tener una traducción para una identificación de producto determinada. Podría usar una clase de repositorio para escribir mis propios métodos getter para limitar el conjunto de resultados a un solo idioma, pero tendré muchas tablas que tienen campos que deben traducirse. Apuesto a que hay una solución más genérica para ese problema. Otro problema es que si consulto un objeto que está relacionado con otro objeto, obtendré todas las traducciones para ese segundo objeto.

Por cierto, soy consciente de la extensión de comportamiento traducible de Gediminas, pero no me gusta el hecho de que todas las traducciones estén almacenadas en una sola tabla.

Así que estoy buscando las mejores prácticas en lo que respecta a la internacionalización. Cualquier pensamiento sobre este tema es muy apreciado.

Answer 1

La extensión de comportamiento traducible que mencionó hace permite una entidad de traducción por clase. Consulte el subencabezado "Entidad de traducción" en la sección de Ejemplos avanzados del translatable doc.

El cortocircuito es esto: utilice la anotación @Gedmo\TranslationEntity para especificar una entidad particular que se utilizará en el almacenamiento de traducciones. De esta forma, puede dividir la carga en varias tablas.

Answer 2

BTW: Estoy al tanto de la extensión comportamiento traducible por Gediminas pero no me gusta el hecho de que todas las traducciones se almacenan en una tabla.

Creo que su enfoque a este problema se relaciona principalmente con el tamaño y el tipo de su proyecto. Si desea implementar un CMS simple, también puede usar una matriz para guardar el contenido de los campos de varios idiomas. Sin embargo, este enfoque es limitado.

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

Si el contenido de su sistema es completamente diferente de un idioma a otro, o el sistema necesita algunas consultas pesadas e informes basados ​​en los campos multilingües entonces el enfoque que usted ha mencionado sería bueno.