Une petite définition avant de commencer : l’internationalisation, que les geeks abrègent en i8n, c’est préparer un logiciel pour qu’il puisse être traduit. C’est donc un travail sur la structure de ce logiciel, et le traitement des chaines des caractères, qui permet ensuite de passer à la localisation (l10n) qui est elle, la véritable traduction. On peut donc très bien avoir un CMS internationalisé, mais pas localisé.

Le CMS a t il été internationalisé ?

Question de base à se poser, la réponse est dans 99% des cas, « oui ».
Question suivante : dans quelle mesure, et selon quelle logique ? Cette question va permettre de voir si toutes les fonctionnalités de votre CMS peuvent être traduites.
Il faut regarder à la fois le core du système, mais aussi les extensions, en tout cas celles que vous prévoyiez d’utiliser.

Il faut aussi regarder comment sont gérées les urls des articles traduits, si vous pouvez faire ce que vous voulez ou si vous êtes contraints par un système rigide (et dans ce cas là, ces contraintes vous conviennent-​​elles ?

Des localisations existent-​​elles ?

Si la traduction du core du système est faite pour les trois CMS en question, (et très rapidement pour WordPress grâce à l’équipe de WordPress-​​fr), il faut aussi regarder ce qu’il en est pour les thèmes et les modules ? Sont-​​ils le plus souvent déjà internationalisés, voir traduits, ou aurez vous tout le travail de les préparer pour la traduction et de les traduire ?
Et y a-​​t-​​il une communauté dans votre/​vos langue(s) qui assure rapidement ces traductions ?

Testez, retestez, et recommencez les tests

Dans ce domaine plus qu’ailleurs, « Der Teufel steckt im Detail ».

Pour donner un exemple récent, je suis en train de préparer un site trilingue, allemand — anglais — français. Le client est allemand, donc la page d’accueil par défaut doit être en allemand. Mais comme je ne parles pas parfaitement allemand, et que le client devait fournir les textes dans cette langue, j’ai naturellement commencé par faire le site en anglais, notre langue commune.

Seulement gros problème au moment d’activer l’internationalisation (dans ce cas WPML pour WordPress) : le plugin fonctionne en attribuant l’url « de base » à la langue par défaut, et les « autres » url aux autres langues (que ce soit sous-​​répertoire, sous-​​domaine ou un autre système). Donc il fallait repasser à travers tous les articles et catégories pour indiquer qu’ils étaient écrits en anglais, et pas en allemand.

Cela n’est pas un problème sur un site de test… sur un gros site, si.
J’ai par ailleurs découvert d’autres limitations du plugin, qui font que je ne compte pas l’utiliser. J’en parlerai dans l’article sur WordPress.

Tester en configuration complète

Il est essentiel de vérifier que les plugins, modules ou extensions que vous voulez utiliser sont compatibles avec le système de traduction. Si ce n’est pas le cas, et que vous n’arrivez pas à trouver une solution de remplacement, vous pouvez être amenés à développer certaines fonctionnalités vous-​​mêmes, ce qui à un impact certain sur votre budget.

Pour cela, il faut donc connaitre le CMS avec lequel vous voulez travaillez, connaître la configuration souhaitée. On ne commence pas la prise en main d’un CMS avec l’internationalisation (enfin si, c’est ce que j’ai fait avec Drupal, mais il est clair que cela prend plus de temps. Par ailleurs j’ai eu la chance d’identifier tout de suite ce qui était bloquant dans Joomla, et donc de partir vers « la bonne solution ». Mais c’est de la chance).

La configuration doit donc comprendre l’url rewriting, selon ce qui aura été décidé pour le site. Notamment, si vous souhaitez travailler avec des sous-​​domaines, et que vous êtes sur un serveur mutualisé, vérifiez bien que c’est possible.

Pour finir

Les prochains articles traiteront de Joomla, Drupal et WordPress. Cette revue n’est pas exhaustive. Lumière de Lune n’est pas une agence Web avec un personnel pléthorique pouvant se permettre de maîtriser de nombreux outils. Certains CMS, comme TYPO3, par exemple, ont été éliminés parce que le backend est extrêmement lourd, d’autres comme CMS Made Simple, parce que il ne semblait pas y avoir de solution — en gros si au bout d’une demi heure je ne trouve pas de début de piste, je laisse tomber.
La présélection a donc été faite sur les CMS que j’étais disposée à utiliser, pour des tas de raisons, et en excluant d’office certains. Si le sujet vous intéresse mais que vous ne trouver pas votre CMS préféré, pas la peine de m’incendier, mais faites le même travail.

Ma conclusion a été de choisir Drupal. C’est basé sur mes propres critères, et mes propres besoins. C’est un choix qui peut être différent pour vous, et cela ne vous dispense donc pas de tester !

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire