Discussion :

[captainIglo]

Bonjour,

J'ai un projet qui fonctionne en 6 langues (fr nl en zh ru es)
Dans le projet , la culture est sur 2 caractères (fr nl en zh ru es)
Trois 'blocs' différents se 'traduisent' :
-> une gestion de menu développée 'maison'
-> les messages I18n (messages.xml)
-> des articles dont le texte est international avec un slug unique.

Je dois passer à une gestion intégrant le pays.
Les menus 'maison' et les messages supportent très bien de voir arriver une culture sur 5 de type fr_BE ou en_GB

Par contre, les textes des articles ne 'remontent' pas.
Bien sûr, les textes des articles sont par langue (fr en ...) et pas par culture (en_GB en_US), ce qui n'aurait pas de sens.

J'ai fait un 'hack pourri' :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php $cultureInit = $sf_user->getCulture() ;$sf_user->setCulture(substr($sf_user->getCulture(), 0, 2)); ?>
<div id="articleTop">&nbsp;</div>
<div class="article">
  <div class="articleInner">
    <?php echo htmlspecialchars_decode($homepagearticle->texte) ?>
  </div>
</div>
<?php $sf_user->setCulture($cultureInit) ?>

càd :
Je stocke la culture sur 5, je la force à 2 (langue uniquement), j'affiche ce qu'il me faut, je remets 'tout bien' pour que le reste fonctionne.

Est-ce que on pourrait me dire quelle marche j'ai loupé ?

MERCI

Oui, parce que le hack est vraiment vilain

[Michel Rotta]

J'ai commencé par me dire qu'effectivement ton hack est "vraiment vilain".

J'ai une application internationalisée, qui date un peu, et ne m'a posé aucun problèmes. Puis j'ai pris la peine d'aller y re-regarder de plus près et me suis rendu compte que, dans la culture de l'utilisateur, je ne stockais que la langue. Ainsi, les traductions et la base fonctionnent, pas les champs sensibles à la cultures, mais, sur cette application, je n'en utilisais pas.

J'ai donc cherché sur internet et dans le code, j'en arrive à la réponse suivante, il y a un bug dans l'objet sfDoctrineRecord de symfony. En effet, la méthode listenToChangeCultureEvent() est à l'écoute d'un événement de changement de culture pour l'utilisateur et l'enregistre dans l'objet record. Seul problème, cette méthode prend tous le contenu du champ culture, sans chercher à en extraire la partie langue et l'objet sfDoctrineRecord, l'utilise, tel quel, pour rechercher la langue dans le tableau des traductions.

Dons, il y a plusieurs solutions :

1. tous mettre en langue, sans prendre la culture en compte.
2. garder la langue et la culture et modifier le code de l'objet sfDoctrineRecord pour en sortir la langue
3. garder ton hack (à la hussard) (mais qui va faire du code redondant)
4. Modifier le sfUser, la partie du code qui va générer l'événement, capturé par sfDoctrineRecord pour qu'il ne prennent que la langue et pas le doublon.

J'ai utilisé la 1. J'utiliserais bien la 2 dans ma prochaine application. Je n'aime pas la redondance qu'implique la 3. J'ai un peu peur pour la 4, rien ne dit que d'autre objets utilisent le même événement pour, eux, récupérer la culture (je pense aux widget avec un i18n. Mais je n'ai pas creusé dans ces codes là.

Si tu pars sur la deux, on peut creuser la modification à prendre en compte. Et la poster comme modification proposée sur le site de symfony.

[stealth35]

c'est pas la "culture" mais la "region"

[captainIglo]

En suivant la piste 2, j'ai modifié la méthode filterGet de la classe sfDoctrineRecordI18Filter:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  public function filterGet(Doctrine_Record $record, $name)
  {
    $culture = sfDoctrineRecord::getDefaultCulture();
    //* ajout CT pour ne récupérer que la langue
    $culture = substr($culture, 0, 2);
 
    if (isset($record['Translation'][$culture]))
    {
      return $record['Translation'][$culture][$name];
    }
    else
    {
      $defaultCulture = sfConfig::get('sf_default_culture');
      return $record['Translation'][$defaultCulture][$name];
    }
  }

Du coup, le hack est moins vilain puisque non redondant mais risque d'avoir des effets de bord.
Je vais déjà enlever le précédent et je vais procéder à quelques vérifications.
Par contre, je n'ai vraiment pas le recul suffisant pour savoir si cette modification est:
- incongrue
- dangereuse
- acceptable

Qu'en penses-tu ?

J'ai commencé par me dire qu'effectivement ton hack est "vraiment vilain".

J'ai une application internationalisée, qui date un peu, et ne m'a posé aucun problèmes. Puis j'ai pris la peine d'aller y re-regarder de plus près et me suis rendu compte que, dans la culture de l'utilisateur, je ne stockais que la langue. Ainsi, les traductions et la base fonctionnent, pas les champs sensibles à la cultures, mais, sur cette application, je n'en utilisais pas.

J'ai donc cherché sur internet et dans le code, j'en arrive à la réponse suivante, il y a un bug dans l'objet sfDoctrineRecord de symfony. En effet, la méthode listenToChangeCultureEvent() est à l'écoute d'un événement de changement de culture pour l'utilisateur et l'enregistre dans l'objet record. Seul problème, cette méthode prend tous le contenu du champ culture, sans chercher à en extraire la partie langue et l'objet sfDoctrineRecord, l'utilise, tel quel, pour rechercher la langue dans le tableau des traductions.

Dons, il y a plusieurs solutions :

1. tous mettre en langue, sans prendre la culture en compte.
2. garder la langue et la culture et modifier le code de l'objet sfDoctrineRecord pour en sortir la langue
3. garder ton hack (à la hussard) (mais qui va faire du code redondant)
4. Modifier le sfUser, la partie du code qui va générer l'événement, capturé par sfDoctrineRecord pour qu'il ne prennent que la langue et pas le doublon.

J'ai utilisé la 1. J'utiliserais bien la 2 dans ma prochaine application. Je n'aime pas la redondance qu'implique la 3. J'ai un peu peur pour la 4, rien ne dit que d'autre objets utilisent le même événement pour, eux, récupérer la culture (je pense aux widget avec un i18n. Mais je n'ai pas creusé dans ces codes là.

Si tu pars sur la deux, on peut creuser la modification à prendre en compte. Et la poster comme modification proposée sur le site de symfony.

[stealth35]

t'as pas l'extension Intl ?

[captainIglo]

t'as pas l'extension Intl ?

Dans Doctrine ?

[stealth35]

Dans Doctrine ?

non Intl l'extension PHP : http://php.net/manual/fr/book.intl.php