Pourquoi utiliser la base de données ?

En effet, pourquoi utiliser la base de données au lieu d’éditer directement les fichiers de traduction ? Lorsque votre site sera en production des modifications pourront être faites grâce à l’interface d’édition, cependant les développeurs seront potentiellement amenés à ajouter de nouvelles traductions dans les fichiers. Donc si on édite directement les fichiers de traduction un problème risque de se présenter: lors des mises en ligne, comment ajouter les nouvelles traductions sans perdre les modifications faites depuis l’interface d’édition ? (sans compter le fait que Apache devra avoir les droits en écriture sur les fichiers).
C’est pour cela que nous avons choisi de charger les traductions en base de données. De cette façon l’administrateur du site peut modifier les traductions à son gré et les développeurs peuvent à tout moment ajouter de nouvelles entées dans les fichiers.

Fonctionnement

Le bundle redéfinit le service de traduction de Symfony (translator) et fournit un loader pour charger les traductions depuis la base de données.
Les traductions présentes en base de données sont chargées en dernier, elles prennent donc le dessus sur les traductions des fichiers xliff, yml ou php. Le bundle fournit aussi une interface d’édition et d’ajout de traductions avec une intégration de jqGrid 4.2.0.
L’ajout de traduction dans la base de données se fait soit par l’interface, soit en ligne de commande avec une tâche qui va importer vos fichiers de traduction dans la base de données.

Utilisation

Lors de votre développement créez vos fichiers de traductions au moins pour une langue (la langue par défaut du site par exemple). Ensuite lancez la tâche d’import pour ajouter les nouvelles traductions en base de données. Une fois importées les traductions sont éditables dans l’interface, vous pouvez donc modifier les traductions pour toutes les langues gérées par le bundle.
Une traduction n’est éditable que si elle est présente dans la base de données, donc si vous ajoutez de nouvelles entées dans vos fichiers de traduction il faudra relancer la tache d’import.

Note: lors de la modification d’une traduction via l’interface il sera nécessaire de cliquer sur le bouton « invalidate cache » afin de prendre en compte le changement de la traduction (surtout en environnement de production).

Installation et configuration

L’installation se fait comme pour tous les autres bundle Symfony2 à l’aide des fichiers deps et deps.lock.
Au niveau de la configuration il vous faudra au minimum définir la langue par défaut (fallback_locale) et les langues que le bundle doit gérer (managed_locales), comme ci-dessous :

# app/config/config.yml
lexik_translation:
    fallback_locale:  fr
    managed_locales:  [fr, en]

Il est aussi possible de configurer certaines classes utilisées par le bundle dans le cas où vous souhaitez redéfinir des éléments (entité et/ou service).

Pour plus de détail sur cette partie je vous invite à lire la doc sur le dépot Github.

$this->embedI18n(array('en', 'fr',...));
$this->widgetSchema->setLabel('en', 'Anglais');
$this->widgetSchema->setLabel('fr', 'Français');
...
...
...

Il y aura donc autant de lignes que de langues à ajouter.

Imaginons maintenant la situation suivante :

Je suis développeur web, et je réalise un site international pour un client Mr Gui, il me donne la liste des langues, je code tous mes formulaires, et le lendemain, Mr Gui m’appelle, et me dit qu’il est désolé, il a oublié 3 langues, seulement voilà, j’ai 27 formulaires dans mon appli… (et oui il s’agit d’un énorme site, Mr Gui est un très gros client…). Je reprend donc mes 27 formulaires, et je rajoute mes embedForm et mes setLabel.
Mais, le lendemain, Mr Gui me rappelle pour me dire que finalement, le finlandais c’est pas la peine de le mettre, je dois donc r’ouvrir mes 27 formulaires et supprimer dans chacun le finlandais dans le embedI18n et dans le setLabel.

En résumé, même si une situation pareil est exagérée, il serait quand même pratique de centraliser les cultures, et d’automatiser les embedI18n et setLabel.

Voilà donc la solution que je propose aujourd’hui, en 2 étapes :

Etape 1 : centraliser les cultures

On sait déjà que Symfony permet l’utilisation dans les apps des fichier de configuration app.yml pour tout ce qui est options du site, et paramètres globaux. Nous allons donc utiliser ce principe pour définir toutes les langues.
Sachant que ces langues ne sont pas forcément propres à une application en particulier (frontend, backend, etc.) il convient de placer le fichier des langues dans un dossier plus haut placé. Créons donc un dossier config dans le dossier apps, et plaçons y un fichier app.yml (il pourra éventuellement contenir d’autres infos que les langues, on ne l’appellera donc pas languages.yml ou cultures.yml, …)

/apps/config/app.yml :

1
2
3
4
5
6

all:
  cultures:
    enabled:
      fr: Français
      en: English
      es: Español

Facile pour l’instant non ?
La syntaxe globale est en fait la suivante :

1
2
3
4

environnement:
  cultures:
    enabled:
      clé: label

Etape 2 : automatisation dans les formulaires

Maintenant que les langues sont centralisées, reste plus qu’à automatiser les formulaires, la méthode est la suivante:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public function configure()
{
  $array = sfYaml::load(sfConfig::get('sf_apps_dir').'/../config/app.yml'); /* 1 */
  $languages = $array['all']['cultures']['enabled']; /* 2 */
  $keys = array_keys($languages); /* 3 */
  $this->embedI18n($keys); /* 4 */
 
  /* 5 */
  foreach($languages as $key=>$lang)
  {
    $this->widgetSchema->setLabel($key, $lang);
  }
  parent::configure();    
}

Explications :
1 : le sfConfig::get() n’est pas joignable depuis les formulaires, et puis de toutes façons, le fichier n’est pas placé dans une app, il faut donc le charger autrement.
Le framework Symfony dispose d’un Yaml Loader qui le permet.

2 : les fichiers *.yml sont chargé par le loader Symfony comme des tableaux, construits de la manière suivante :

1
2
3
4
5

tableau:
  clé1: valeur
  sous-tableau:
    sous-clé1: valeur
    sous-tableau2 : { sous-sous-clé1: valeur, sous-sous-clé2: valeur }

Tout ceci sera chargé comme suit par le loader :

1
2
3
4
5
6
7
8
9
10
11
12

array(
  'tableau' => array(
    'clé1' => valeur,
    'sous-tableau' => array(
      'sous-clé1' => valeur,
      'sous-sous-tableau' => array(
        'sous-sous-clé1' => valeur,
        'sous-sous-clé2' => valeur
      ),
    ),
  ),
);

La lige marquée /* 2 */ permet donc de stocker dans la variable $languages un tableau de la forme :

1
2
3
4
5
6

array(
  'fr' => 'Français',
  'en' => 'English',
  ...,
  ...
);

3 : cette ligne permet des ranger les clés du tableaux languages (donc ‘fr’, ‘en’, etc.) dans un tableaux où elles seront valeurs, et non clés.
4 : cette ligne embed donc toutes les langues présentes dans le yml
5 : le foreach permet donc de set tous les labels, en correspondance avec les langues.

Et voilà !

Pré-requis

• Plugin sfFormExtraPlugin installé : sfFormExtraPlugin

Fichiers externes

• Télécharger jQuery UI
  (jquery-1.3.2.min.js, jquery-ui-1.7.1.custom.min.js)

  Vous pouvez télécharger une version « customizée » de jQuery UI ici :
  Télécharger JQuery UI

• Version française
  (uidatepicker-fr.js)

  Vous trouverez le patch français de ce plugin ici :

  Datepicker jQuery en français

• Intégration dans Symfony
  1. JS
     Copiez les fichiers :
     [jquery UI]/js/jquery-1.3.2.min.js
     [jquery UI]/js/jquery-ui-1.7.1.custom.min.js
     uidatepicker-fr.js
     directement dans [votre_projet]/web/js
  2. CSS
     • Copiez le fichier :
       [jquery UI]/css/jquery-ui-1.7.1.custom.css dans :
       [votre_projet]/web/css.
     • !! Attention !! :
       J’ai dû remplacer toutes les occurrences de :
       url(images/ par :
       url(../images/
  3. Images
     N’oubliez pas de copier le contenu de :
     [jquery UI]/css/smoothness/images dans :
     [votre_projet]/web/images

View.yml

N’oubliez pas de faire référence aux fichiers externes dans le view :

default:
  http_metas:
    content-type: text/html
 
  metas:
    #title:        symfony project
    #description:  symfony project
    #keywords:     symfony, project
    #language:     en
    #robots:       index, follow
 
  stylesheets:    [main.css, jquery-ui-1.7.1.custom.css]
 
  javascripts:    [jquery-1.3.2.min.js, uidatepicker-fr.js, jquery-ui-1.7.1.custom.min.js]
 
  has_layout:     on
  layout:         layout

sfWidgetFormJQueryI18nDate.class.php

J’ai modifié la classe sfWidgetFormJQueryDate pour qu’elle soit compatible avec un format de date français.
De plus, on peut facilement configurer les options du widget jQuery.

• Code source :
  Fichier : sfWidgetFormJQueryI18nDate.class.php
  Chemin : /plugins/sfFormExtraPlugin/lib/widget/
  ^?View Code PHP

  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 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112

  <?php /* * This file is part of the symfony package. * (c) Fabien Potencier <fabien.potencier@symfony-project.com> * * For the full copyright and license information, please view the LICENSE * file that was distributed with this source code. */   /** * sfWidgetFormJQueryDate represents a date widget rendered by JQuery UI. * * This widget needs JQuery and JQuery UI to work. * * @package symfony * @subpackage widget * @author Fabien Potencier <fabien.potencier@symfony-project.com> * @version SVN: $Id: sfWidgetFormJQueryDate.class.php 12875 2008-11-10 12:22:33Z fabien $ */ class sfWidgetFormJQueryI18nDate extends sfWidgetFormI18nDate { /** * Configures the current widget. * * Available options: * * * image: The image path to represent the widget (false by default) * * config: A JavaScript array that configures the JQuery date widget * * culture: The user culture * * @param array $options An array of options * @param array $attributes An array of default HTML attributes * * @see sfWidgetForm */   protected function configure($options = array(), $attributes = array()) { $this->addOption('image', false); $this->addOption('config', $options["config"]); $this->addOption('culture', $options["culture"]); $this->addOption('years', $options["years"]);   parent::configure($options, $attributes);   if ('en' == $this->getOption('culture')) { $this->setOption('culture', 'en'); } }   /** * @param string $name The element name * @param string $value The date displayed in this widget * @param array $attributes An array of HTML attributes to be merged with the default HTML attributes * @param array $errors An array of errors for the field * * @return string An HTML tag string * * @see sfWidgetForm */ public function render($name, $value = null, $attributes = array(), $errors = array()) { $prefix = $this->generateId($name);   $image = ''; if (false !== $this->getOption('image')) { $image = sprintf(', buttonImage: %s, buttonImageOnly: true', $this->getOption('image')); } return parent::render($name, $value, $attributes, $errors). $this->renderTag('input', array('type' => 'hidden', 'size' => 10, 'id' => $id = $this->generateId($name).'_jquery_control', 'disabled' => 'disabled')). sprintf(<<<EOF <script type="text/javascript">   function %s_read_linked() { \$("#%s").val(\$("#%s").val() + "/" + \$("#%s").val() + "/" + \$("#%s").val());   return {}; }   function %s_update_linked(date) { \$("#%s").val(date.substring(0, 2)); \$("#%s").val(parseInt(date.substring(3, 5), 10)); \$("#%s").val(date.substring(6, 10)); }   \$("#%s").datepicker(\$.extend({}, { minDate: new Date(%s, 1 - 1, 1), maxDate: new Date(%s, 12 - 1, 31), onSelect: %s_update_linked, beforeShow: %s_read_linked, %s showOn: "both" %s }, \$.datepicker.regional["%s"]));   </script> EOF , $prefix, $id, $this->generateId($name.'[day]'), $this->generateId($name.'[month]'), $this->generateId($name.'[year]'), $prefix, $this->generateId($name.'[day]'), $this->generateId($name.'[month]'), $this->generateId($name.'[year]'), $id, min($this->getOption('years')), max($this->getOption('years')), $prefix, $prefix, $this->getOption('config'), $image, $this->getOption('culture') ); } }

• Explication des modifications :
  1. Ligne 20 :
     Notre widget dérive désormais de sfWidgetFormI18nDate
     ^?View Code PHP

     20	class sfWidgetFormJQueryDate extends sfWidgetFormI18nDate

  2. Lignes 40, 41 et 42:
     On ajoute les options « config », « culture » et « years » avec le paramètre « options » de la fonction « configure » :
     ^?View Code PHP

     40 41 42

     $this->addOption('config', $options["config"]); $this->addOption('culture', $options["culture"]); $this->addOption('years', $options["years"]);

  3. Lignes 85 et 86
     • Il faut inverser l’ordre du jour et du mois pour être compatible avec un format français, ce qui revient dans un sprintf, à changer l’ordre des lignes dans le code.
     • Il faut faire un parseInt sur le mois pour transformer « 01″ en « 1″, parseInt est la fonction javascript permettant de caster une chaîne de caractères en Integer :
       Premier paramètre : la chaîne à caster (ici : date.substring(3, 5) )
       Deuxième paramètre : Le système numérique à utiliser (ici décimal : 10)
     ^?View Code PHP

     85 86

     \$("#%s").val(date.substring(0, 2)); \$("#%s").val(parseInt(date.substring(3, 5), 10));

  4. Lignes 95 et 109
     • On passe les options directement dans le premier argument.
       Le %s de la ligne 95 correspond au $this->getOption(‘config’) de la ligne 109
       Le %s de la ligne 98 correspond au $this->getOption(‘culture’) de la ligne 109
     • Ligne 109 : passage des options et da la culture au widget.
     ^?View Code PHP

     108	$prefix, $prefix, $this->getOption('config'), $image, $this->getOption('culture')

Exemple d’utilisation

• Schéma
  ^?View Code YML

  person: columns: [...] birthday: type: timestamp [...]

• Formulaire (Instanciation du widget)
  ^?View Code PHP

  [...] public function configure() { for($i = 1900; $i<2010; $i++) { $years[$i] = $i; } $this->widgetSchema['birthday'] = new sfWidgetFormJQueryI18nDate( array('config' => 'yearRange: \'1900:2009\', changeYear: true, changeMonth: true,', 'culture' => 'fr', 'years'=> array_combine($years, $years)) ); } [...]

• Aperçu
  

Sources

• Symfony Internationalisation and Localisation
• Symfony Widgets
• jQuery UI
• Remy Solnais jquery et datepicker en Français
• W3schools parseInt en Javascript
• PHP.net fonction sprintf
• ImageShack

Le but est d’obtenir un site (un bout de site) qui nous permette de faire un listing de recettes et cela dans différentes langues, on va se contenter du français et de l’anglais. Il faut d’abord commencer par le schéma :

 Recipe:
  actAs:
    I18n:
      fields: [name, body, is_activated]
    actAs:
      Sluggable: { fields: [name], uniqueBy: [lang, name] }
  columns:
    name: { type: string(255)}
    body: { type: clob}
    is_activated: { type:boolean, notnull: true, default: 0}

Le schema est très simple il n’y aucune relation avec d’autres tables, ce qui nous intéressent ici c’est le traitement I18N et les formulaires. Petite remarque : – Je passe le is_activated, qui indique si la recette est active ou non, dans le actAs I18N ainsi les recettes par langue seront totalement indépendantes. – Le sluggable est passé également en deuxième niveau d’actAs pour permettre à chaque langue d’avoir son propre slug. – Dernier point, il ne faut surtout pas mettre de unique : true dans la partie columns de notre schema, sinon on va se retrouver à ne pas pouvoir mettre à jour une langue indépendament de l’autre. Maintenant que l’on visualise le schéma et donc les classes qui en découlent on va parler code. Comme on en a l’habitude on va générer nos modèles, notre CRUD de recettes. On va maintenant s’attaquer à notre classe RecipeForm.class.php, on veut que l’utilisateur n’ai pas à rentrer les recettes dans les deux langues mais uniquement dans la sienne. Pour cela il faut lui afficher uniquement le formulaire rattaché à sa culture. Modifions notre classe:

 class RecipeForm extends BaseRecipeForm
 {
   private $lang; 
 
   public function __construct($lang = 'fr')
   {
      $this->lang = $lang; 
 
      parent::__construct();
   }
 }

La première étape est donc de redéfinir le constructeur de notre classe auquel on va soumettre une langue par défaut et de créer un attribut privé pour définir la langue ($lang). On va maintenant définir l’affichage de notre formulaire en modifiant la fonction configure()

public function configure()
{
  if (!is_array($this->lang))
  {
    $cultures = array($this->lang);
  }
  else
  {
    $cultures = $this->lang;
  } 
 
  foreach ($cultures as $culture)
  {
    $i18nObject = $this->object->Translation[$culture];
    $i18n = new RecipeTranslationForm($i18nObject);
    unset($i18n['id'], $i18n['lang'], $i18n['is_activated']);
    $i18n->widgetSchema['name'] = new sfWidgetFormInput(array(), array('size'=> 60));
    $i18n->widgetSchema['body'] = new sfWidgetFormTextarea(array(), array('cols'=> 58,'rows'=> 12));
    $this->embedForm($culture, $i18n);
  }
}

Dans notre action on va appeler ce formulaire comme suit :

public function executeNew(sfWebRequest $request)
{
  $this->culture = $this->getUser()->getCulture();
  $this->form = new RecipeForm($this->culture);
}

Vous noterez que l’on passe la culture en attribut ainsi on peut le récupérer dans le template :

render()

Il vous suffit de mettre désormais tout les champs et les label à afficher et le tour est joué.