FuelPHP ORM schema di database per i18n, opinioni/suggerimenti

Question

Mentre questa domanda potrebbe essere similartomanyothers, mi piacerebbe chiedere opinioni/suggerimenti sul migliore approccio per i18n specificatamente su FuelPHP.

Così, qui è quello che ho finora:

Schema del database # 1:

models (id, name_pt, name_es, name_en, description_pt, description_es, description_en) 

campione di dati # 1:

(1, 'Modelo', 'Modelo', 'Model', 'Descrição do modelo', 'Descripción del modelo', 'Model description') 

Pro :

• dritta e semplice
• Una tabella per modello
• Non c'è bisogno di utilizzare JOIN
• L'utilizzo di un metodo magico per semplificare l'accesso ai dati:

 

public function & __get($property) 
{ 
    if (array_key_exists($property, array('name', 'description'))) 
    { 
     $property = $property.'_'.Session::get('lang_code'); 
    } 

    return parent::__get($property); 
} 

Questo modo, sono in grado di chiamare:

$model->name; 
$model->description; 

invece di:

$model->{'name_'.Session::get('lang_code')}; 
$model->{'description_'.Session::get('lang_code')}; 

Contro:

• avere un sacco di lingue/campi tradotte potrebbe ottenere disordinato.
• Aggiunta di una nuova lingua, implica l'aggiunta di nuovi campi alla tabella
• Il metodo magico funziona solo quando abbiamo già un'istanza/oggetto ORM.Per recuperare un'istanza ORM attraverso il query builder ordinato da un campo tradotto è ancora richiesto il codice come:

 

Model_Model::query() 
    ->order_by('name_'.Session::get('lang_code')) 
    ->get(); 

Schema del database # 2:

languages (id, code, name) 
models (id) 
i18n_models (id, model_id, language_id, name, description) 

campione di dati N. 2:

-- languages 
(1, 'pt', 'Português') 
(2, 'es', 'Español') 
(3, 'en', 'English') 

-- models 
(1) 

-- i18n_models 
(1, 1, 1, 'Modelo', 'Descrição do modelo') 
(2, 1, 2, 'Modelo', 'Descripción del modelo') 
(3, 1, 3, 'Model', 'Model description') 

Pro:

• migliore organizzazione dei dati
• L'aggiunta di una nuova lingua è un gioco da ragazzi
• Come nel primo approccio, si può anche avere un accesso diretto ai dati utilizzando il metodo set() a compilare la matrice $ _custom_data:

 

$i18n = Model_I18n_Model::query() 
    ->where('model_id', $model->id) 
    ->where('language_id', Session::get('lang_code')) 
    ->get_one(); 

$model->set(array(
    'name' => $i18n->name, 
    'description' => $i18n->description 
)); 

Contro:

• complessità aumenta
• un join o una seconda query devono essere utilizzate
• è richiesto un tavolo extra per ogni modello schema

Database 3:

Su altre domande, ho visto persone suggerire l'uso di una tabella centrale i18n per tutte le traduzioni, usando una riga per ogni traduzione che ha un modello.

Pro:

• Tavolo unico per i18n condivisa fra modelli
• L'aggiunta di una nuova lingua dovrebbe essere facile come nel precedente approccio

Contro:

• Compl exity aumenta durante il recupero dei dati, richiede un JOIN per ogni testo tradotto un modello ha
• Possiamo provare a utilizzare EAV containers con questo approccio, sebbene utilizzi una chiave/valore per la mappatura, ma in questo caso in particolare dobbiamo anche utilizzare language_id per recuperare la traduzione corretta.

Personalmente, preferisco il secondo approccio. Quali altri vantaggi/svantaggi vedi? Qualcuno ha implementato i18n in modo diverso su FuePHP?Condividi le tue idee :)

Answer 1

Quello che faccio semplicemente è aggiungere un campo lang nella tabella.

Poi ho filtro su quel campo:

SELECT * FROM articles WHERE lang = 'en' 

ho anche usarlo in CRUD per le sezioni di amministrazione dove l'utente può passare da una lingua, e vedono tutte le voci per quella lingua specifica.

E un editor lavorerà automaticamente per i contenuti in lingua cui si trova.

INSERT INTO articles VALUES('My Title', 'My Article', 'en') 

E semplicemente ottenere 'it' da parte degli utenti attuali locali. (Faccio in modo che cambino nei moduli per sovrascriverli).