Lorsque vous utilisez une librairie javascript, comme un date picker par exemple, il est bien souvent nécessaire de charger un fichier supplémentaire qui contient les traductions. Fort heureusement, ces fichiers sont nommés avec la « locale » (fr, nl, en, etc…), il est donc assez simple de les charger.
|
1 2 3 4 5 6 7 8 |
{% javascripts '@AcmeFooBundle/Resources/public/datepicker/datepicker.js' %} <script type="text/javascript" src="{{ asset_url }}"></script> {% endjavascripts %} <script type="text/javascript" src="{{ asset('bundles/acme/foo/datepicker/locales/i18n.' ~ app.request.locale ~ '.js') }}"> </script> |
Le problème, dans ce cas-ci, c’est que 2 fichiers sont chargés séparément, alors qu’on favorise plutôt la concaténation.
On pourrait essayer de combiner les fichiers, mais ce n’est pas si simple. Ce code, par exemple, donne l’erreur suivante: Unexpected token « operator » of value « ~ ».
|
1 2 3 4 5 6 7 8 |
{% javascripts '@AcmeFooBundle/Resources/public/datepicker/datepicker.js' 'bundles/acme/foo/datepicker/locales/i18n.' ~ app.request.locale ~ '.js' combine=true %} <script type="text/javascript" src="{{ asset_url }}"></script> {% endjavascripts %} |
Il existe, cependant, un moyen d’utiliser des variables grâce à ces deux classes (je vous ai surligné les lignes importantes):
Comme vous pouvez le constater, Assetic gère deux variables par défaut: « locale » et « env ». Voyons comment on peut les utiliser…
Configuration
Tout d’abord, il faut les spécifier dans le fichier config.yml, dans la partie twig:
|
1 2 3 |
twig: globals: locales: [fr, nl, en] |
Il est indispensable d’indiquer toutes les valeurs possibles que pourrait avoir la variable au risque de reçevoir une grosse exception! Petit conseil pour la « locale », utilisez un paramètre (%available_locales% par exemple) dans votre parameters.yml afin de ne pas avoir à gérer la liste de vos locales dans plusieurs fichiers différents.
On va ensuite indiquer à Assetic le même tableau de langues et empêcher l’utilisation des controllers pour la génération des assets. Ce deuxième point est malheureusement indispensable.
|
1 2 3 4 5 |
assetic: debug: "%kernel.debug%" use_controller: false variables: locale: [fr, nl, en] |
Utilisation
Le plus dur est fait, vous pouvez maintenant combiner vos javascript classiques et « dynamiques » comme ceci:
|
1 2 3 4 5 6 7 8 9 |
{% javascripts '@AcmeFooBundle/Resources/public/datepicker/datepicker.js' 'bundles/acme/foo/datepicker/locales/i18n.{locale}.js' vars=['locale'] combine=true %} <script type="text/javascript" src="{{ asset_url }}"></script> {% endjavascripts %} |
- {locale} sera remplacer par la langue en cours
- vars est utilisé pour indiquer à Assetic quelles variables il doit gérer dans sa liste d’assets (souvenez-vous, il peut aussi gérer « env »)
Génération des fichiers
On a presque fini! Vu que, pour certains fichiers, on utilise le chemin direct (« bundles/acme/foo » au lieu de « @AcmeFooBundle »), il faut lancer l’installation de vos assets dans le dossier « /web »:
|
1 |
php app/console assets:install |
Il ne reste plus qu’à générer les fichiers « à la main ». Cette commande va parcourir tous vos twigs et générer toutes les combinaisons possibles. Dans notre cas, 3 fichiers seront créés et contiendront chacun le datepicker avec la traduction.
|
1 |
php app/console assetic:dump |
En dev, il est préférable d’utiliser un –watch si vous modifiez régulièrement un de ces fichiers.
|
1 |
php app/console assetic:watch |
Customisation
Si « locale » et « env » ne vous suffisent pas, vous pouvez écrire vous-même votre classe qui gérera d’autres variables. Pour cela rien de plus simple:
- Créez une classe qui implémente l’interface « AsseticValueSupplierInterface ».
- Changer la classe de la clé « assetic.value_supplier.class » par la votre
|
1 |
<parameter key="assetic.value_supplier.class">Acme\FooBundle\MyValueSupplier</parameter> |
Et voilà le travail!