La galère des sites multilangues…
Publié le 23 October 2007, par Babozor dans la catégorie Développement, Gestion de projet
[illustration honteusement volé sur le martine cover generator]
Ça commence souvent de façon anodine, le client veut juste un petit site en français, rien de bien compliqué…
On lui fait donc un petit site dynamique avec une seule langue.
Le client est content, mais maintenant il a besoin de mettre d’autres langues: l’anglais c’est obligé (tout le monde parle anglais), l’allemand et l’espagnol ça peut aussi être utile, puisqu’il essaye de s’implanter là bas, et allez rajoutez moi le bulgare et le vietnamien, juste pour rigoler… bon il sait que c’était pas prévu au départ, mais ça doit pas bien être compliqué d’ajouter des langues à son joli petit site web.
Là, vient deux galères:
1. Modification du modèle de donnée et du backoffice
La galère commence, vous allez devoir ajouter une table langue (voir une table pays/marché lié à la langue) et modifier tout votre modèle de donnée pour rattacher les différentes données à une langue ou à un site spécifique pour tel pays ou tel marché.
Cela paraît un travail simple et rapide, mais cela ne l’est pas…
Outre le modèle de données, vous allez devoir modifier toutes les requêtes de récupération, insertion, modification de données.
Vous allez devoir aussi modifier votre backOffice pour prendre en compte ce nouveau paramètre de langue.
Vous voyez donc les implications d’un malheureux ajout de langue.
2. Passage des données en UTF8
Si vous n’avez pas été prudent, votre base de donnée a été créée sans encodage UTF8… si vos données sont toutes au même format, pas de panique, vous modifiez votre mode et vous créez une petite routine qui prend vos données, les convertit en utf8 et le remets proprement dans la base.
Là où ça se complique c’est quand vous avez des données mixées:
- données iso et utf8 dans une base iso
- données iso et utf8 dans une base utf8
dans les deux cas c’est une pure galère (hein Tim…)
Vous allez devoir détecter le format de chaque donnée (iso ou utf8) convertir les données non utf8 et ensuite insérer en base, avec un grand risque de merdasse et de données pétées…
Pour éviter cela:
1. toujours prévoir dans le modèle de donnée un identifiant de langue (que vous mettez toujours avec la même valeur, comme ça vous pouvez rajouter une table langue et hop le tour est jouée)
2. toujours, toujours gérer aussi bien les fichiers, le contenu, le format de la base, le meta-tag charset en UTF8 toujours! cela vous évitera d’énormes galères de conversion de données.
Et vous, déjà eut des galères d’ajout de langue ou de données corrompues en UTF8?
le 23 October 2007 à 17h05
Oh oui j’en ai eu des problèmes avec UTF-8. Heureusement depuis que j’utilise Rails, ça va mieux, j’ai plus à me préoccuper de ça.
C’est sympa un client qui fait ce coup-là quand le site est déjà bien avancé ^^
le 24 October 2007 à 00h00
Quelle galère les traductions, on bosse sur une grosse plate forme multi-langues et là on bosse sur un site en estonien… c’est que du bonheur, le pire c’est que tu ne comprends rien de cette langue et du coup tu te tapes 40 retours client car tu fais forcément des fautes de traduction dans le sens des textes. Enfin… l’estonien c’est pas le pire, on va surement devoir passer notre plateforme en arabe… ^^
le 24 October 2007 à 00h01
ps : Enorme la couverture Martine je suis fan
le 24 October 2007 à 11h03
Ouais ça arrive (et plus souvent qu’on le pense… malheureusement)
@Rémi: ouais, je me souviens du passage d’un site en polonais… le nombre de corrections qu’on a du faire. Le mieux est encore de laisser la main au client final sur son contenu, comme ça plus de galère (ou en tout cas plus les même)
le 26 October 2007 à 14h06
En ce qui concerne Martine, il me semble que l’image vient de là:
http://martine.logeek.com/index.php?f=3
Et en ce qui concerne l’objet même du billet, je remerci chaque jour que Bill fait pour, ô joie, les fichiers de type RESX (ressources) fournis par le Framwork .Net 2.0.
Un répertoire RessourcesGlobales, un fichier par langue, et au sein du code, aucun texte en dure, uniquement des références aux ressources stockées dans les fichiers .resx, et le tour est joué…
Restent cependant les problèmes liés à la traduction. J’ai beau parler français, anglais et espagnol, je ne maîtrise pas le vocabulaire technique de l’ingéniérie bio-moléculaire… et dois, comme tout le monde, faire appel à des services de traduction; pas facile.