Internationalisation et behavior Doctrine I18n

Bonjour,

Je suis en train d'essayer de mettre en place l'internationalisation avec le behavior I18n de Doctrine. Je précise que je suis sur symfony 1.4.5 ce qui est censé permettre de pouvoir utiliser un champ "culture" à la place de champ "lang".

Cependant, il doit y avoir quelque chose qui m'échappe car mes pages me retournent toujours des erreurs :

Code:

---

Unknown record property / related component "myfield" on "MyObject"

---

J'ai bien modifié mon schema pour spécifier tous les behaviors I18n sur les objets à internationaliser, j'ai mis à jour la base de données avec des scripts de migration Doctrine, j'ai re-généré les classes, vidé le cache, mais cela semble ne pas suffire.

Faut-il aussi ré-écrire toutes les requêtes pour que ça fonctionne ?

Je précise aussi que j'ai bien ajouté un use_helper('I18N') dans toutes les templates et que la culture de l'utilisateur est bien définie.

Lorsque j'utilise l'internationalisation sur les chaînes de caractère en les écrivant avec le helper __(), les chaînes sont bien remplacées, mais c'est du côté du bahavior de Doctrine que ça bloque...

Il faudrait plus de renseignements :

• un bout du shema.yml
• comment tu initialises la culture du user
• comment tu récupères les données
• que te donnes les requêtes SQL quant tu est en mode DEV dans les outils SF ?

Après quelques tests, je me suis rendu compte que c'est en fait un de mes objets qui a une clé primaire basée sur 2 champs que je ne parviens pas à internationaliser.

Citation:

---

un bout du shema.yml

---

=> Voici mon schema :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

options: type: INNODB collate: utf8_general_ci charset: utf8   Enseigne: connection: doctrine columns: id: type: integer(8) primary: true autoincrement: true nom: type: string(255)   TypeContenu: connection: doctrine actAs: I18n: fields: [libelle] i18nField: culture length: 5 columns: id: type: integer(8) primary: true autoincrement: true libelle: type: string(255)   Contenu: connection: doctrine actAs: I18n: fields: [libelle] i18nField: culture length: 5 columns: id_enseigne: type: integer(8) primary: true id_type_contenu: type: integer(8) primary: true libelle: type: string(20) relations: Enseigne: local: id_enseigne foreign: id type: one foreignAlias: EnseigneContenus foreignType: many TypeContenu: local: id_type_contenu foreign: id type: one foreignAlias: EnseigneContenus foreignType: many

---

L'internationalisation fonctionne bien sur TypeContenu mais pas sur Contenu à cause apparemment de ses 2 champs en clé primaire...

Citation:

---

comment tu initialises la culture du user

---

=> J'ajoute simplement un $this->setCulture('fr_FR') dans la méthode initialize de la classe myUser.

Code:

---

1 2 3 4 5 6 7

public function initialize(sfEventDispatcher $dispatcher, sfStorage $storage, $options = array()) { parent::initialize($dispatcher, $storage, $options);   $this->setCulture('fr_FR'); }

---

Citation:

---

comment tu récupères les données

---

=> Directement avec le code généré par symfony :

Code:

---

1 2 3 4 5 6 7

public function executeIndex(sfWebRequest $request) { $this->contenus = Doctrine::getTable('Contenu') ->createQuery('a') ->execute(); }

---

Citation:

---

que te donnes les requêtes SQL quant tu est en mode DEV dans les outils SF ?

---

=> Les requêtes que j'obtiens sont bien correctes mais c'est au niveau de l'objet que la propriété n'existe pas :

Code:

---

1 2 3 4 5 6 7 8 9

1. SET NAMES 'UTF8'   2. SELECT c.id_enseigne AS c__id_enseigne, c.id_type_contenu AS c__id_type_contenu FROM contenu c   3. SELECT c.id_enseigne AS c__id_enseigne, c.id_type_contenu AS c__id_type_contenu, c.libelle AS c__libelle, c.culture AS c__culture FROM contenu_translation c WHERE (c.id_enseigne IN ('1'))

---

Aurais-tu plus d'infos sur le behavior I18n appliqué sur un objet dont la clé primaire porte sur 2 champs ?

C'est pas gagné.

Doctrine ne sait clairement pas gérer correctement des tables avec plus d'une clef primaire, à l'exception des tables qui font les liaisons entre deux tables "normales" pour le cas des liaisons n-n (Et encore, quant il n'y a pas d'argument sur ce type de liaison).

Donc la solution consiste à supprimer la double clef primaire.

Je te propose :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

options: type: INNODB collate: utf8_general_ci charset: utf8   Enseigne: columns: nom: string(255)   TypeContenu: actAs: I18n: fields: [libelle] columns: libelle: string(255)   Contenu: actAs: I18n: fields: [libelle] columns: enseigne_id: type: integer(8) type_contenu_id: type: integer(8) libelle: type: string(20) indexes: enstype: fields: [ enseigne_id, type_contenu_id ] type: unique relations: Enseigne: local: enseigne_id foreign: id foreignAlias: EnseigneContenus TypeContenu: local: itype_contenu_id foreign: id foreignAlias: EnseigneContenus

---

• J'ai viré ce qui n'était pas utile ou déjà défini par défaut.
• J'ai mis les nom des champs de liaison à la coutume
• S'il n'y a pas de clef primaire définie, doctrine crée un id primaire integer donc on le laisse faire
• J'ai créé un index unique pour s'assurer qu'il n'y ai pas de doublon dans les clefs, comme s'il y avait un index unique.

Merci mimi, effectivement ça fonctionne en remplaçant la clé primaire sur 2 champs par une nouvelle clé primaire sur un champ 'id' en incrément auto.

Il me reste un problème sur les requêtes Doctrine qui comportent une jointure avec un autre objet internationalisé : les champs de l'objet lié ne sont pas reconnus. Par contre, quand j'ajoute une jointure avec Translation, ça fonctionne.

Faut-il systématiquement ajouter une jointure de ce type pour que ça fonctionne ?

Code:

---

1 2 3

->leftJoin('b.Translation t') ->addWhere('t.culture = ?', $culture)

---

Citation:

---

Envoyé par nsoinard

Il me reste un problème sur les requêtes Doctrine qui comportent une jointure avec un autre objet internationalisé : les champs de l'objet lié ne sont pas reconnus. Par contre, quand j'ajoute une jointure avec Translation, ça fonctionne.

---

:( Je ne vois pas ce que tu veux faire ici..

Citation:

---

Envoyé par nsoinard

Faut-il systématiquement ajouter une jointure de ce type pour que ça fonctionne ?

Mais ça semble générer de nouvelles requêtes pour récupérer les libellés internationalisé... :?

---

Doctrine ne récupère que la première table, même pour les enregistrements internationalisés. Il faut donc rajouter les leftjoint si l'on ne veut pas se retrouver avec une foultitude de requêtes SQL.

Ce que je voulais dire, c'est que pour internationaliser une application, il faut faire des modifications sur certaines requêtes Doctrine alors que le behavior I18n aurait pu être prévu pour faire tout le travail tout seul sans qu'on ai besoin de modifier le code.

Par exemple si je prends un objet Article dont le champ "libelle" est internationalisé :

Exemple 1: ce code fonctionne

Code:

---

1 2 3 4 5 6

$articles = Doctrine::getTable('Article')->findAll(); foreach($articles as $article) { echo $article->getId() . ' ' . $article->getLibelle() . '<br />'; }

---

Exemple 2: ce code ne fonctionne pas :

Code:

---

1 2 3 4 5 6 7 8 9

$q = Doctrine_Query::create() ->select('a.id, a.libelle') ->from('Article a'); $articles = $q->execute(); foreach($articles as $article) { echo $article->getId() . ' ' . $article->getLibelle() . '<br />'; }

---

Exemple 3: ce code fonctionne, mais il aura fallu ajouter une jointure :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$q = Doctrine_Query::create() ->select('a.id, t.libelle') ->from('Article a') ->leftJoin('a.Translation t') ->where('t.culture = ?', $culture); $articles = $q->execute(); foreach($articles as $article) { echo $article->getId() . ' ' . $article->getLibelle() . '<br />'; }

---

Maintenant, si on initialise la culture par défaut à "fr_FR" et la culture de l'utilisateur à "en_UK", en admettant qu'on ai 10 articles dans la base de données, tous traduits en français mais un seul traduit en anglais :

- L'exemple 1 retournera les 10 articles, celui qui est traduit en anglais apparaitra en anglais et les 9 autres seront affichés en français.
- L'exemple 2 retournera une erreur sur la propriété "libelle"
- L'exemple 3 ne retournera qu'un seul article : celui qui est traduit en anglais.

Ce qui veut dire que l'application ne fonctionnera pas partout de la même façon selon qu'on utilise des findAll() ou des Doctrine_Query pour récupérer les données...

A moins qu'il y ai un point que je n'ai pas compris ?

Hélas non.

Par contre,

Code:

---

1 2 3 4 5 6 7 8

$q = Doctrine_Query::create() ->from('Article a'); $articles = $q->execute(); foreach($articles as $article) { echo $article->getId() . ' ' . $article->getLibelle() . '<br />'; }

---

Devrait marcher. Mais présente l'inconvénient de générer, pour 10 enregistrements, 11 requêtes !

Reste la possibilité de faire une liaison en croix :

Code:

---

1 2 3 4 5 6 7 8

$q = Doctrine_Query::create() ->from('Article a, ArticleTranslate t'); $articles = $q->execute(); foreach($articles as $article) { echo $article->getId() . ' ' . $article->getLibelle() . '<br />'; }

---

(a vérifier)

qui doit retourner tous les enregistrements, le modèle objet retrouvant ces petits.

Mais au prix d'une requête qui peut très vite devenir énorme !

Jusqu'à présent, dans les applications que j'ai géré, les tables avec traduction étaient des tables "système" et donc intégralement traduites. Là, le problème ne ce pose pas.

Je pense qu'il y a une réflexion a faire au niveau de l'application, après tous, dans une application en fr, il est possible qu'un user en crée un enregistrement uniquement en en... et rende la requête de traduction encore plus difficile a réaliser.