02-03-2013, 01:09 PM
(Modification du message : 02-03-2013, 05:28 PM par Sephi-Chan.)
Tu ne le précises pas dans ton sujet, mais je suppose qu'on parle ici de faciliter l'internationalisation.
Je connais et utilise trois solutions selon mes cas d'utilisation :
Utiliser un outil d'internationalisation
Mon outil d'internationalisation est Ruby I18n, très bien intégré dans Ruby on Rails. Il permet d'écrire (que ce soit dans les vues, les contrôleurs et les modèles, bien que ces derniers ne devraient pas être concernés) des choses comme :
Et les traductions sont stockées (par défaut dans des fichiers YAML, mais on peut utiliser la base de donnée, Redis, etc.) de la forme suivante :
On a donc des namespaces bien définis et on peut bien sûr les définir dans plusieurs fichiers.
Je vous invite à jeter un œil au dépôt communautaire de traductions, c'est intéressant de voir comment sont stockées toutes les choses un peu spéciales comme les pluriels, les dates et heures, les mécanismes pour générer des phrases comme "Il y a 5 minutes".
Ruby charge les bonnes traductions selon la valeur de de l'expression
Avoir des templates pour chaque langue
La deuxième solution est d'utiliser des templates localisés. C'est très utile pour les emails ou les pages de contenu, où on a pas une équivalence exacte entre les différents contenus selon les langues ou qu'on utilise des images différentes.
Cela repose sur le système de rendu de Rails, qui utilise les conventions de nommage des fichiers de vues. Par exemple, si l'application utilise la locale
Ainsi, si une vue nommée
D'ailleurs, ce système est poussé plus en avant pour les mails grâce au mécanisme de multipart, qui permet d'envoyer dans le même mail le format texte et le format HTML !
Faire ça uniquement côté Javascript
La dernière solution est très utile quand on développe une application riche basée sur Javascript (Backbone, Angular, etc.). Elle consiste à transformer les fichiers de configuration YAML en fichiers Javascript pour envoyer les traductions au navigateur et laisser Javascript faire la substitution.
Des outils comme I18n JS permettent ça et peuvent être utilisés avec n'importe quel langage (cf. le bas de la page du projet) !
Je connais et utilise trois solutions selon mes cas d'utilisation :
- Utiliser un outil d'internationalisation (directement ou via un wrapper) ;
- Avoir des templates pour chaque langue ;
- Faire ça uniquement côté Javascript ;
Utiliser un outil d'internationalisation
Mon outil d'internationalisation est Ruby I18n, très bien intégré dans Ruby on Rails. Il permet d'écrire (que ce soit dans les vues, les contrôleurs et les modèles, bien que ces derniers ne devraient pas être concernés) des choses comme :
<!-- Une traduction toute simple. -->
<h1><%= t('title') %></h1>
<div>
<!-- La traduction contient du HTML. -->
<%= t('presentation') %>
</div>
<div>
<!-- On peut aussi traduire des dates. -->
<%= l(Time.now, { format: :long }) %>
</div>
<div>
<!-- On peut interpoler des valeurs dans les traductions. -->
<%= t('user.welcome', { name: current_user.name }) %>
</div>
<div>
<!-- Y compris des dates traduites ! -->
<%= t('user.last_connection', { date: l(current_user.last_connection_at) }) %>
</div>
<div>
<!-- Les pluriels sont bine supportés. -->
<%= t('user.messages_count', { count: messages.count }) %>
</div>
Et les traductions sont stockées (par défaut dans des fichiers YAML, mais on peut utiliser la base de donnée, Redis, etc.) de la forme suivante :
fr:
title: "Seelies"
presentation_html: "Seelies est un <strong>jeu de stratégie communautaire</strong> par navigateur."
date:
formats:
default: "%e %b"
long: "%e %B %Y"
user:
welcome: "Bienvenue ${name}"
last_connection: "Votre dernière connexion remonte au ${date}."
messages_count:
zero: "Vous n'avez aucun nouveau message."
one: "Vous avez un nouveau message."
other: "Vous avez %{count} nouveaux messages."
On a donc des namespaces bien définis et on peut bien sûr les définir dans plusieurs fichiers.
Je vous invite à jeter un œil au dépôt communautaire de traductions, c'est intéressant de voir comment sont stockées toutes les choses un peu spéciales comme les pluriels, les dates et heures, les mécanismes pour générer des phrases comme "Il y a 5 minutes".
Ruby charge les bonnes traductions selon la valeur de de l'expression
I18n.locale
.Avoir des templates pour chaque langue
La deuxième solution est d'utiliser des templates localisés. C'est très utile pour les emails ou les pages de contenu, où on a pas une équivalence exacte entre les différents contenus selon les langues ou qu'on utilise des images différentes.
Cela repose sur le système de rendu de Rails, qui utilise les conventions de nommage des fichiers de vues. Par exemple, si l'application utilise la locale
fr
et qu'on accède à la page home
, Rails va chercher les vues dont le nom commence par home
et — s'il y en a plusieurs — se décider.Ainsi, si une vue nommée
home.fr.html.erb
est composés de plusieurs morceaux (tous optionnels en dehors du premier) que Rails comprend grâce à leur ordre. Il sait que fr
correspond à la locale, que html
correspond au format de réponse attendue (on aura souvent des templates différents quand la page est appelée en JSON ou en HTML, par exemple) et que erb
correspond au moteur de template (Haml, Slim, ERB, etc.) utilisé pour interpréter le code.D'ailleurs, ce système est poussé plus en avant pour les mails grâce au mécanisme de multipart, qui permet d'envoyer dans le même mail le format texte et le format HTML !
Faire ça uniquement côté Javascript
La dernière solution est très utile quand on développe une application riche basée sur Javascript (Backbone, Angular, etc.). Elle consiste à transformer les fichiers de configuration YAML en fichiers Javascript pour envoyer les traductions au navigateur et laisser Javascript faire la substitution.
Des outils comme I18n JS permettent ça et peuvent être utilisés avec n'importe quel langage (cf. le bas de la page du projet) !