Ne refaites pas le bug de l’an 2000 !

Bien souvent les développeurs du XXI° siècle reproduisent les erreurs de leurs aînés…

…peut-être en se disant que quelqu’un d’autre trouvera la solution quand il y en aura besoin !

Les développeurs des années 70, par économie d’espace mémoire (qui a dit par flemme?), avaient codé les années sur 2 chiffres au lieu de 4. Ils s’étaient sans doute dit que les suivants allaient résoudre ça en temps voulu ; ils avaient quand même 30 ans devant eux ! Le problème c’est qu’en fait on a continué à utiliser les mêmes standards de facto jusqu’aux années 90 (difficile de changer les habitudes, et les programmes informatiques ont une inertie importante une fois qu’ils sont mis en production).

Du coup, il a fallu déployer beaucoup d’effort pour corriger ça dans l’urgence, juste avant que le bug de l’an 2000 déclenche le lancement accidentel d’un missile balistique ou, pire, vous empêche d’allumer la télé.

Aujourd’hui, le bug de l’an 2000 fait sourire ; c’est de l’histoire ancienne !

Et alors maintenant, c’est bon, y’a plus de souci ?ça serait trop beau !

Ma théorie ? selon moi, LE vrai défi des développeurs d’aujourd’hui, c’est d’avoir des logiciels utilisables dans tous les pays. Avec internet, ce défi est valable pour tous ceux qui prétendent avoir un site dont l’audience dépasse leur pays d’origine !

Et il faut dire que c’est pas un sujet facile…

Passons en revue quelques unes des problèmatiques :

On ne lit pas tous dans le même sens

Le sens de lecture est un des premiers éléments d’ergonomie – il faut bien avouer que Google est assez fort là dessus…

Avez-vous déjà essayé Google Arabic ?Le curseur est placé à droite dans le champ !

Faites une recherche, et les résultats sont alignés à droite de la page. Le seul défaut que j’ai identifié, c’est qu’en bas de la page de résultats, la flèche va vers la droite (alors qu’en tout logique je m’attendais à ce qu’elle soit vers la gauche, vu qu’on lit les livres dans l’autre sens, non ?)

Donc il y a toute une partie du monde qui lit dans le sens inverse du notre, et ça n’est pas près de changer. C’est déjà une sacré difficulté car suivant comment vous avez codé votre site, il faudra peut-être tout réécrire pour s’y adapter !

Les claviers ne sont pas les mêmes

Ceux qui ont voyagé l’ont sans doute remarqué : les étrangers ont des claviers étranges. Sinon, j’imagine que la plupart d’entre vous utilise des claviers pour PC – si vous avez eu l’occasion d’utiliser un clavier apple ça vous donne un aperçu 🙂

Les touches qu’on connaît ne sont pas au même endroit. En plus il en manque plein ! Notamment les accents, la cédille, etc.

Ca entraine pleins de trucs etranges – et quand vous envoyez un email depuis un clavier QWERTY, vous apprendrez à faire Alt+130 pour faire un é ou d’autres codes ASCII pour les differents caracteres

Avez-vous remarqué que la phrase précédente ne contient aucune caractère spécial ? Peut-être pas si vous êtes habitués aux SMS 😉

Ma plus grande frousse, c’est de choisir un mot de passe tellement puissant (avec des caractères spéciaux et tout et tout) que je ne puisse plus accéder à ma boite email depuis l’étranger !

Imaginez l’angoisse : « comment je le tape le ù ??? »
La crise…

Dernièrement, des collègues anglais de ma boite m’ont demandé de leur faire passer les CDs de la version française de Windows et Office, avec un clavier français, car l’application financière sur laquelle ils travaillent a un comportement anormal sur les PC français (damned!) mais ils n’arrivaient pas à le reproduire sur des PCs anglais ! Apparemment il y a des petites fonctions développées par nos amis de chez Microsoft qui ont un comportement différent suivant la langue utilisée…

Comme quoi ça peut arriver à n’importe qui, même aux plus grands !

Versions multilingues

La question semble simple, mais comment avoir un site web (ou une appli) dispo en plusieurs langues ?

option 1 : vous dupliquez tout dans le code (une page en français, et une page en anglais, par exemple)

option 2 : vous utilisez des fichiers de localisation

en clair : dans votre code, vous n’écrivez pas « MENU PRINCIPAL » mais vous mettez une balise AFFICH_MENU_PRINCIPAL qui sera remplacée par le texte dans la langue appropriée suivant le choix de l’utilisateur : « MENU PRINCIPAL » ou « MAIN MENU »

Ce blog utilise WordPress, et ce moteur utilise un système de fichiers .po et .mo ; voici brièvement comment ça marche :

dans votre code, au lieu de mettre (en php) :

echo « main menu »;

vous écrivez :

_e(« main menu »);

En voyant ça, wordpress va aller chercher le fichier xx.mo (xx étant le code de la langue choisie dans WordPress : par exemple fr.mo pour le français). Ces fichiers .mo sont des fichiers .po compilés pour être lus par WordPress ; les fichiers .po peuvent simplement être ouverts par un éditeur de texte et contiennent des choses telles que :

#: machin.php:46
msgid « main menu »
msgstr « menu principal »

ce qui signifie qu’à la ligne 46 du fichier machin.php, vous avez utilisé la balise « main menu » qui doit être affichée « menu principal » si on est en français. Et en fait, ça marchera partout où on mettra _e(« main menu »);

Pourquoi je dis tout ça ? Parceque si vous développez complètement votre site en écrivant echo « main menu »; partout (option 1), le jour où vous voulez mettre une deuxième langue, il faudra reprendre chaque ligne de code et remplacer ces choses écrites en dur pour passer à l’option 2 !

Et là c’est la grosse galère, un peu comme le bug de l’an 2000.

Et je ne parle même pas du contenu ! Puisque dans tous les cas il faudra dupliquer le contenu (à ce jour, je ne connais pas d’outil capable de traduire toutes une page avec succès : si vous voulez un site bilingue, il faudra vous taper la traduction à la main).

Le codage des caractères

pour ça, dans une certaine mesure, c’est (encore) la faute aux américains*.

Au départ, c’était assez simple : ils ont décidé de créer une table de caractères et ils l’ont appelé ASCII : chaque numéro de 0 à 255 correspond à un caractère, ce qui permet de stocket un caractère sur un octet.

Mais ensuite, ça se complique, car des boites différentes ont créé chacune leur table ASCII ; en plus, certains ont décidé de stocker les caractères de -128 à +127.

Enfin bref, ça a été vite le bazar ! Et pour le moment, ils ne parlaient qu’anglais !

Il a donc fallu décider comment on allait stocker les caractères spéciaux ; alors ils se sont mis plus ou moins d’accord pour que les caractères de 0 à 127 soient communs à tous, et qu’ensuite chaque « pays » puisse utiliser les 128 caractères restants pour mettre les leurs. Mais ce n’est pas les mêmes partout, et puis en plus, on a très vite manqué de place quand on s’est rendu compte qu’il y a *beaucoup* de caractères spéciaux !

Alors ils ont inventés « utf-8 » : un standard qui permet de gérer toutes les tables de caractères. Au début du document HTML, il y a une balise qui dit quelle table il faut utiliser.

Et ça marche !

A condition d’observer deux conditions :

• il faut enregistrer le document avec le bon encodage
• il faut que le lecteur soit capable de visualiser les tables de caractères correspondantes

Sur le premier point, c’est loin d’être anodin ! Car par défaut, ce n’est pas ce que fera votre éditeur de texte préféré avec lequel vous codez votre site 🙂

Et si vous commencez à faire votre site avec l’encodage ASCII par défaut (vous savez : ISO-8859-1), non seulement il faudra modifier l’entête de tous vos fichiers HMTL/PHP, mais en plus il faudra veiller à les modifier en mettant les bons codes de caractères et en les enregistrant au bon format !

C’est bien plus simple d’y faire attention depuis le début (sinon : bing ! vous êtes bon pour tout corriger, façon bug de l’an 2000 😛 )

Et je ne parle même pas de l’encodage des url qui rajoute encore à la complexité en ce qui concerne les sites web.

Ensuite, il faut que le visiteur soit capable de lire vos caractères.

Si votre site est en anglais : pas de problème ! Les caractères de l’alphabet latin sont présents dans toutes les tables, avec les codes correspondant aux vieux codes ASCII… ce qui signifie que les anglophones n’ont aucun effort à faire pour être lus dans le monde entier.

Mais si votre site est écrit en caractères cyrilliques, en arabe ou en japonais : c’est pas pareil !

Petit test : pour vous, qu’affiche Google sur cette page ?

Je n’ai aucun moyen de savoir ce que ça va afficher chez vous, car ça dépend des tables de caractères qui sont installées sur votre ordinateur !

Pour moi, ça marche pas trop mal, puisque je vois les résultats écrit (apparemment) en arable.

Mais tout en bas, je vois que Google a rajouté un message qui apparaît sous la forme de carrés blancs :

Et voila ! ça, ça veut dire que mon ordinateur ne comprend pas quelle table utiliser, et remplace les caractères par des « trucs » pour me dire que ça ne veut rien dire pour lui !

Aujourd’hui, de plus en plus, les navigateurs « cachent » ces problèmes et tentent d’appliquer le codage le plus adapté. Une fois, firefox m’a demandé de télécharger une table pour afficher une page en coréen.

Vous pouvez voir quel encodage est utilisé, et même le forcer ! Par exemple :

Essayez chez vous ! Et là, vous verrez que c’est le souk complet puisque firefox va appliquer la mauvaise table, et donc affiche des caractères qui ne correspondent pas à ce qui était voulu… Un peu comme si vous tapiez un texte dans Word et que vous appliquiez la police Dingbats 😉

Conclusion

Alors je suis sûr que j’oublie plein de trucs importants liés à l’internationalisation des programmes (n’hésitez pas à les donner en commentaires !), mais si on veut éviter que la situation devienne irréversible, il faut que nous fassions l’effort dès aujourd’hui d’écrire des programmes (et sites web) qui soient compatibles avec ce défi.

En plus des aspects techniques que j’ai décrit, vous aurez pleins d’autres challenges liés à l’internationalisation : au niveau fonctionnel (par exemple, si vous faites un logiciel de compta, les systèmes de compta analytiques ne sont pas les mêmes en France et en Angleterre), au niveau légal (par exemple au niveau de la conservation des données personnelles), etc.

Mais vous pouvez vous épargner pas mal de souci, et vous donner des chances pour plus tard si vous pensez à l’essort que pourrait prendre votre site dès que vous commencez à développer !

Ne vous dites pas que vous pourrez faire mieux plus tard : si votre produit marche vraiment bien (et je vous le souhaite), vous réutiliserez ces petits bouts de codes car vous aurez plein d’autres trucs à faire plutôt que de réécrire votre code (trouver des clients, ajouter des fonctions, etc.), et le problème vous reviendra dessus par surprise, comme le bug de l’an 2000 🙂

allez, à plus !

roland

* le contenu de ce paragraphe est une interprétation libre (et de mémoire) de ce qui s’est vraiment passé. Alors n’hésitez pas à aller demander à votre meilleur ami, ou à votre deuxième meilleur ami si vous voulez plus d’infos sur l’histoire des tables de caractères !