Bien que cette question puisse être similaire a beaucoup de autres J'aimerais demander des opinions/suggestions sur la meilleure approche pour l'internationalisation, en particulier pour FuelPHP.
Voici donc ce que j'ai obtenu jusqu'à présent :
Schéma de base de données n° 1 :
models (id, name_pt, name_es, name_en, description_pt, description_es, description_en)Exemple de données #1 :
(1, 'Modelo', 'Modelo', 'Model', 'Descrição do modelo', 'Descripción del modelo', 'Model description')Pour :
- Droit et simple
- Une table par modèle
- Pas besoin d'utiliser JOIN
-
Utilisation d'une méthode magique pour simplifier l'accès aux données :
public function & __get($property) { if (array_keyexists($property, array('name', 'description'))) { $property = $property.''.Session::get('lang_code'); }
return parent::__get($property);}
De cette façon, je suis capable de faire l'appel :
$model->name;
$model->description;au lieu de :
$model->{'name_'.Session::get('lang_code')};
$model->{'description_'.Session::get('lang_code')};Cons :
- Le fait de disposer d'un grand nombre de langues/de champs traduits peut être source de confusion.
- L'ajout d'une nouvelle langue implique l'ajout de nouveaux champs à la table.
-
La méthode magique ne fonctionne que lorsque nous avons déjà une instance/un objet ORM. Pour récupérer une instance ORM par le biais de la fonction créateur de requêtes commandée par un champ traduit, le code requis est toujours le même :
Model_Model::query() ->orderby('name'.Session::get('lang_code')) ->get();
Schéma de base de données n°2 :
languages (id, code, name)
models (id)
i18n_models (id, model_id, language_id, name, description)Exemple de données 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')Pour :
- Une meilleure organisation des données
- L'ajout d'une nouvelle langue est un jeu d'enfant
-
Comme dans la première approche, nous pouvons également avoir un accès direct aux données en utilisant la fonction set() pour remplir le tableau $_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 ));
Cons :
- La complexité augmente
- Il faut utiliser un JOIN ou une deuxième requête.
- Un tableau supplémentaire pour chaque modèle est nécessaire
Schéma de base de données n°3 :
Sur d'autres questions, j'ai vu des personnes suggérer l'utilisation d'une table i18n centrale pour toutes les traductions, en utilisant une ligne pour chaque traduction d'un modèle.
Pour :
- Table unique pour l'i18n partagée entre les modèles
- L'ajout d'une nouvelle langue devrait être facile comme dans l'approche précédente.
Cons :
- La complexité augmente lors de la récupération des données, nécessitant un JOIN pour chaque texte traduit d'un modèle.
- Nous pourrions essayer d'utiliser Conteneurs EAV avec cette approche, bien qu'elle utilise une clé/valeur pour le mappage, mais dans ce cas en particulier, nous devons également utiliser le language_id pour récupérer la traduction appropriée.
Personnellement, je préfère la seconde approche. Quels autres avantages/inconvénients voyez-vous ? Quelqu'un a-t-il implémenté i18n d'une manière différente sur FuePHP ? Partagez vos idées :)
