Doctrine 2 - best practice per i18n?

Question

Sto cercando alcuni consigli su come gestire le tabelle che devono avere campi che devono essere tradotti in n lingue. Ho letto che l'approccio migliore è avere una tabella base che contiene tutti i campi che non sono specifici della lingua e una tabella che contiene tutti i campi con le traduzioni.

Esempio:

 

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

così avremo il PRODOTTO tabella di base che contiene tutti i metadati e un tavolo PRODUCT_TRANSLATIONS dove tutti i dati vengono memorizzati che devono essere tradotti in più lingue. La tabella PRODUCT ha una relazione OneToMany alla tabella PRODUCT_TRANSLATIONS.

Quale sarebbe il modo Doctrine per gestire uno scenario del genere? Se interrogo la tabella Prodotti, otterrei tutte le traduzioni unite a questa tabella. Ma la maggior parte delle volte voglio solo avere una traduzione per un determinato ID prodotto. Potrei usare una classe repository per scrivere i miei metodi getter per limitare il set di risultati a una sola lingua, ma avrò un sacco di tabelle che hanno campi che devono essere tradotti. Scommetto che esiste una soluzione più generica a questo problema. Un altro problema è che se interrogherò per un oggetto che è collegato ad un altro oggetto, otterrò tutte le traduzioni per quel secondo oggetto.

Btw: Sono a conoscenza dell'estensione del comportamento Translatable di Gediminas, ma non mi piace il fatto che tutte le traduzioni siano archiviate in una tabella.

Quindi sto cercando le migliori pratiche in fatto di internazionalizzazione. Ogni pensiero su questo argomento è molto apprezzato.

Answer 1

L'estensione di comportamento traducibile che hai citato fa consente un'entità di traduzione per classe. Controlla il sottotitolo "Entità della traduzione" nella sezione Esempi avanzati dello translatable doc.

Il breve è: utilizzare l'annotazione @Gedmo\TranslationEntity per specificare un'entità particolare da utilizzare per l'archiviazione delle traduzioni. In questo modo, puoi dividere il carico in più tabelle.

Answer 2

Btw: Sono consapevole dell'estensione comportamento Translatable da Gediminas ma non mi piace il fatto che tutte le traduzioni sono memorizzate in una tabella.

Credo che il tuo approccio a questo problema sia principalmente legato alla dimensione e al tipo del tuo progetto. Se si desidera implementare un semplice CMS, è anche possibile utilizzare un array per salvare il contenuto dei campi multi lingua. Tuttavia questo approccio è limitato.

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

Se il contenuto del vostro sistema è completamente diverso da una lingua all'altra o il vostro sistema ha bisogno di alcune query pesanti e report basati su quei campi multi lingua allora l'approccio lei ha citato sarebbe buono.