Symfony 1.1 beta, tour du propriétaire - L'internationalisation (i18n)
Par NiKo le jeudi 13 mars 2008, 11:52 - Dev
- Lien permanent -
9 commentaires -
Tags :
Dans la liste des tâches nouvellement ajoutées en Symfony 1.1, on remarque une section dédiée à l'internationalisation :
i18n :extract Extracts i18n strings from php files :find Finds non "i18n ready" strings in an application
Et oui, la fonctionnalité dont tous les gens qui ont un jour travaillé sur des applications internationalisées en Symfony 1.0 ont rêvé a enfin été ajoutée : une tâche d'extraction des chaînes de caractères à traduire, avec génération et mise à jour des fichiers de traductions XLIFF 
Si vous avez suivi les précédents tutoriels, vous devez disposer d'un projet sf11test, d'une application main et d'un module contact.
On va activer la gestion de l'internationalisation dans l'application en éditant le fichier de configuration apps/main/config/settings.yml comme suit :
[...]
all:
[...]
.settings:
[...]
i18n: on
[...]
standard_helpers: [Partial, Cache, Form, I18N]
[...]
default_culture: en
On part du principe que la langue par défaut sera l'anglais (en). Ajoutons quelques chaînes internationalisées dans le template apps/main/modules/contact/templates/indexSuccess.php au moyen du helper __() :
<h2><?php echo __('Contact us') ?></h2> <p><?php echo __('Drop us a message using the form below:') ?></p> <form action="<?php echo url_for('contact/index') ?>" method="post"> <table> <?php echo $form ?> <tr> <td></td> <td><input type="submit" value="<?php echo __('Send your message') ?>" /></td> </tr> </table> </form>
Maintenant, lançons la commande d'extraction des chaînes à traduire pour notre future version française, en lui demandant poliment de générer automatiquement le fichier de traduction et de supprimer automatiquement les entrées orphelines :
$ ./symfony i18n:extract --auto-save --auto-delete main fr >> i18n extracting i18n strings for the "main" application >> i18n found "3" new i18n strings >> i18n found "0" old i18n strings >> i18n saving new i18n strings >> i18n deleting old i18n strings
Le fichier apps/main/i18n/fr/messages.xml a été généré, examinons son contenu :
<?xml version="1.0"?> <xliff version="1.0"> <file source-language="EN" target-language="fr" datatype="plaintext" original="messages" date="2008-03-13T11:13:45Z" product-name="messages"> <body> <trans-unit id="1"> <source>Contact us</source> <target></target> </trans-unit> <trans-unit id="2"> <source>Drop us a message using the form below:</source> <target></target> </trans-unit> <trans-unit id="3"> <source>Send your message</source> <target></target> </trans-unit> </body> </file> </xliff>
Il ne nous reste plus qu'à traduire nos chaînes en remplissant les balises <target></target> en conséquence pour traduire notre application en français. Si l'on venait à modifier notre template en supprimant, modifiant ou ajoutant de nouvelles chaînes, la tâche d'extraction se chargerait de mettre à jour nos fichiers de traduction en conséquence, tout en préservant le travail déjà effectué 
9 commentaires (Ajouter un commentaire)
ha ouais ! je connaissais pas. merci bcp
Olivier
Olivier> En 1.0 t'avais toujours l'option "debug" dans le i18n.yml, qui te mettait [T][/T] autour des chaînes non-traduites. Feature pas très connue d'ailleurs, qui existe toujours en 1.1 sauf que la configuration de l'internationalisation se fait maintenant dans le fichier factories.yml
i18n:find me semble vraiment bien. Cela évite de chercher partout les __() manquant !
No' et les autres> on peut depuis maintenant bien longtemps utiliser d'autres formats de stockage des traductions que XLIFF- même s'il faut bien avouer que ce n'est pas là la partie la plus exhaustive de la documentation existante - on peut utiliser différents drivers, comme gettext, MySQL ou sqlite. Y'as une même une page sur le wiki pour la méthode gettext.
Bon pour être très honnête, je viens de tester la chose en 1.1 et ça marche pas avec le tâche d'extraction, j'en ai d'ailleurs profité pour saisir un ticket à ce sujet
Oncle Tom> Comme je l'ai évoqué dans le précédent tuto,
./symfonyetsymfony11ont strictement le même effet à la racine d'un projet Symfony 1.1, puisque les deux executables chargent l'environnement du projet courantL'exemple de ce billet passe bien dans xml2po ; est-ce que quelqu'un a un gros fichier en XLIFF pour tester plus en profondeur s'il-vous-plait ?
Sympa cette nouvelle fonctionnalité
Aïe les xml c'est la plaie à traduire ! Les balises etc, c'est un peu encombrant, et embêtant lorsque l'on passe le tout au correcteur orthographique. Est-ce que quelqu'un a tenté de les passer dans xml2po ?
Effectivement ça simplifie énormément la traduction.
Je me demandais aussi pourquoi utiliser XML au lieu de Gettext : plus performant, plus souple ? J'aime bien utiliser poEdit ou Gtranslate pour traduire mes chaines directement à partir du code.
À la limite l'outil de Symfony éclate les traductions en plusieurs fichiers j'imagine ?
Sinon remarque, c'est pas :
$ ./symfony11 i18n:extract --auto-save --auto-delete main fr
au lieu de
$ ./symfony i18n:extract --auto-save --auto-delete main fr
?
Promis, je trolle pas, mais pourquoi avoir utilisé XLIFF au lieu de gettext "comme tout le monde" ? Les fichiers XML, c'est "bien", mais je vois pas trop l'intérêt en l'occurrence, puisque la structure de données est assez "plate" :
* un chaine en anglais -> une chaîne en français.
Structurons des données structurées...