How to Build and Launch a Successful Globalized App from Day One (or All the Crap You Forget to Do). C'est le titre d'une présentation donnée à la conférence OSCON 2008 par Andy Clark de Zimbra sur le thème des points à prendre en compte lors de la création d'une application visant un public international. Je viens de parcourir le support, et vais essayer de résumer ici quelques points que j'y ai trouvés, juste comme pense-bête pour le chantier de gestion de l'internationalisation de Couac auquel il faudra bien que je m'attaque un jour[1].

  • i18n + l10n = g11n (je ne le savais pas, g11n, pour globalization, est une bonne abbréviation pour regrouper l'internationalisation et la localisation d'une application)
  • utiliser pour l'ensemble des composants du système (code, données, templates...) un encodage de caractères supportant toutes les langues: Unicode par exemple. Et indiquer partout l'encodage utilisé.
  • penser à tout rendre globalisable, non seulement les textes, mais aussi tout ce qui peut avoir un sens: les images, sons, couleurs, les raccourcis claviers, tous les messages, y compris système, du serveur.
  • il existe des librairies qui gèrent ça très bien, inutile de ré-inventer la roue
  • ne jamais composer de messages en concaténant des chaînes, mais utiliser des chaînes paramétrables.
  • penser à la g11n en réalisant l'interface: supportera-t-elle l'écriture dans une autre direction ? L'affichage de messages plus longs que prévus, ou dans des polices "exotiques" ?
  • chaque message à traduire doit tenir compte du contexte. Là où une langue utilise le même mot pour désigner une chose, d'autre langues pourront utiliser des mots distincts.
  • faciliter la tâche des traducteurs en utilisant des messages ou des noms de clés explicites.
  • ne pas oublier de planifier et de budgétiser la gestion de la globalisation: elle complexifie la programmation et les tests, et nécessite de faire appel à des traducteurs pour la moindre modification.
  • offrir un mécanisme pour permettre aux utilisateurs de corriger / compléter les traductions
  • lors du développement, identifier tous les messages non traduits, pour qu'ils soient plus simple à retrouver dans le code et facilement identifiables à l'écran
  • ne pas oublier les problématiques de format de date, notamment au niveau du poste client (javascript est-il capable de détecter la locale et de formater les dates correctement ?)

Question subsidiaire: vous utilisez quelles librairies pour gérer ça en PHP et en javascript ?

Notes

[1] il y a déjà quelques briques, mais je ne travaille vraiment pas sérieusement sur le sujet