De la difficulté d'internationaliser une application

Cet article a été écrit il y a plus d'un an : son contenu peut être dépassé.

L’application sur laquelle vous travaillez marche du tonnerre de Dieu et les sirènes de l’international vous appellent. Pas de problème, en tant que bon développeur, vous aviez anticipé le coup en gérant les libellés via une jolie lib i18n. Internationaliser ne devrait pas prendre trop de temps, ce ne sont que quelques libellés à traduire, non ?

Non ? C’est plus compliqué ?

Quand on parle d’internationalisation d’application ou de site web, on ne voit souvent que la partie émergée de l’iceberg, celle qui traite d’i18n. Bon nombre de tutos existent pour expliquer comment mettre en place des librairies de traduction, comment structurer un projet, comment détecter la langue.

Mais ils oublient une chose : internationaliser une application, ce n’est pas juste changer des libellés !

Les textes

Bien évidemment, le premier point qui vient à l’esprit quand on parle d’internationalisation, ce sont les textes. Sauf que même là, ce n’est pas aussi simple que ça en à l’air.

Traduction

Traduire les textes et les remplacer en fonction de langue utilisateur, en général, ça se fait assez facilement. Mais il faut quand même prêter attention à certains points :

• Les formules de politesse. Par exemple, le « you » d’une application US, vous le traduisez en « vous » ou en « tu » pour l’application française ?
• Les différences locales. Parce que ce n’est pas parce qu’il parlent théoriquement la même langue que tout est pareil. Par exemple, au Royaume Uni, le concierge est un caretaker. Aux États-Unis, c’est un janitor. Il en est de même pour le français du Québec, le français de France et le français de Belgique.
• La ponctuation. Grand classique : en France, les : ont un espace avant et après. Pas au Royaume Uni où il n’y a qu’un espace après.
• Les genres : en français, on a le féminin et le masculin. En allemand, on retrouve le féminin, le masculin et le neutre. En français, un objet est genré (par exemple : ma voiture). Pas en anglais, où le genre va dépendre du propriétaire (her car pour une voiture appartenant à une femme, his car pour une voiture appartenant à un homme). Et je ne parle pas d’écriture inclusive…
• Les pluriels.
• Les majuscules. En allemand, par exemple, les majuscules ne servent pas juste en début de phrase ou pour les noms propres.
• Etc.

Bien entendu, il faut faire appel à un traducteur pour pouvoir correctement gérer ces subtilités.

Gestion de la langue

Bien entendu, faire traduire ses textes par un professionnel, c’est bien, encore faut-il que ça puisse être géré techniquement.

Reprenons le cas des genres et l’exemple de la voiture : her car pour une voiture appartenant à une femme, his car pour une voiture appartenant à un homme, au contraire du français où le genre sera toujours le même. Sauf que techniquement, il faut pouvoir récupérer la subtilité si l’information est présentée de façon dynamique.

Par exemple, vous avez un site de vente entre particulier avec ce genre de libellé : « Madame Michue veut vous vendre sa voiture ». Au masculin, pas de soucis « Monsieur Michue veut vous vendre sa voiture ». Mais en anglais, il faut faire la différence entre « Ms. Michue wants to sell you her car » et « Mr. Michue wants to sell you his car » : on ne peut pas utiliser le même libellé !

Il est en bien évidemment de même pour les pluriels et autres subtilités du genre.

Encodage et caractères

Jusque là, nous sommes restés sur des langues occidentales avec le même alphabet, à quelques subtilités prêt (on va dire que les caractères accentués, on gère). Attaquons-nous maintenant à la Chine ou au Japon ! Et donc, vous allez proposer votre application avec des Sinogrammes ou des Kanjis : êtes-vous certain que votre application gère leur encodage ?

À l’heure actuelle, la plupart des applications/site web utilisent de l’UTF-8 et, pour ce genre de caractère, ça fonctionne (avec quelques subtilités qui peuvent être comblées par Unicode). Mais si votre application est en Iso-8859-1 par exemple, il va vous falloir faire une mise à jour car ça ne passera pas. Et là, ça peut être lourd de conséquence car changer l’encodage d’une base de données, ce n’est pas très simple…

Mais votre site web est en UTF-8 donc tout va bien. Au fait, est-ce que la super police de caractère que vous utilisez supporte bien les Kanjis ? Bien souvent, les polices ne couvrent pas tous les caractères (il n’y a qu’à voir le œ français qui n’est pas tout le temps supporté) et c’est particulièrement vrai pour les Kanjis. Il va peut-être falloir charger des polices différentes en fonction de la langue !

Et même si vos polices et votre encodage sont bons, est-ce compatible partout ? Votre site web, il s’affiche avec un navigateur web, en général, pas de souci. Mais vous pouvez aussi envoyer des newsletters : là, la gestion de l’encodage est plus aléatoire, selon le client mail utilisé.

Vous pouvez aussi envoyer des SMS, pour valider un paiement par exemple. Et là, c’est plus complexe parce qu’il y a plusieurs normes d’encodage à gérer, selon la langue. Selon les pays, certaines normes ne sont pas bien supportées, obligeant à utiliser d’autres encodages. Et selon l’encodage, le nombre de caractères autorisés change. De 160 caractères pour un SMS avec des caractères ASCII, on peut être réduit à 70 caractères pour les Kanjis : au lieu d’envoyer un message, il faut en envoyer deux (et donc double facturation).

Sens de lecture

Et si on allait faire un tour dans un pays où l’arabe est la langue officielle ? Ok, les caractères différents sont gérés, tout va bien.

Sauf que l’arabe se lit de droite à gauche et non de gauche à droite comme les langues occidentales. Il faut donc penser à inverser tous les libellés pour que le premier caractère se retrouve à droite et non plus à gauche.

Mais ça ne s’arrête pas là, puisqu’il faut aussi revoir tout le système d’alignement : les alignés à gauche doivent devenir des alignés à droite, etc.

Les formats

Vous avez traduit vos textes correctement, avec une bonne gestion de l’encodage, du sens de lecture, etc. Chouette. Mais avez-vous pensé aux formats de vos données ?

Argent

Par exemple, l’argent. En Union Européenne, on utilise l’euro €, au États-Unis le dollar $. Facile, il suffit de changer l’unité en même temps que les textes ! Vraiment ? Pas si simple.

En France, on écrira un prix avec l’unité après (par exemple : 3 $) mais aux États-Unis, l’unité monétaire se place avant ($3). Attention donc à l’ordre de vos libellés si vos chaînes de caractères sont séparées.

Mètre et pouce

Et que dire des unités de mesure ? Même si l’on a des unités internationales, il faut bien s’adapter au pays. Ainsi, si en France on exprime la vitesse en km/h, au Royaume-Uni, ce sont des mph : il ne faut donc pas oublier de faire les conversions !

Mais attention à ne pas se tromper : par exemple, le Royaume-Uni et les États-Unis utilisent tous deux le Gallon comme mesure mais un Gallon US est différent d’un Gallon Uk (le Us = 3,785411784 litres, le Uk = 4,54609 litres). Et nous sommes sur des pays avec des différences culturelles assez faibles !

Date et heure

Autre point problématique : les dates et heures. Déjà, rien que pour trouver la bonne heure, c’est une galère sans nom. Vous êtes aux États-Unis ? C’est bien, mais sous quel fuseau horaire (il y en a 5) ? Vous êtes en France : heure d’été ou heure d’hiver ? Au fait, on est en année bissextile ou pas ? En général, on utilise une librairie qui fait le boulot parce que tout gérer à la main, c’est très difficile.

Sauf qu’en plus de trouver la bonne heure, il faut aussi l’afficher dans le bon format. Mais si, vous savez, les fameux dd-mm-yyyy et autre mm/dd/yyyy. Là encore, attention à ne pas se tromper car il est facile d’inverser le mois et le jour et de prévoir un rendez-vous le 4 août (04/08) au lieu du 8 avril (08/04).

S’ajoutent aussi les problèmes de premier jour du calendrier (dimanche ? lundi ?), les dates relatives (il y a 10 minutes – il faut bien le traduire aussi), les différents calendriers, etc. Parce que même si une jolie norme ISO 8601 qui définit un format international existe, en pratique, ce n’est pas toujours ça.

Numéro de téléphone

Encore un piège assez classique (je me suis fait avoir plusieurs fois) : les numéros de téléphone !

Demandez à un utilisateur son numéro de téléphone : il va vous le donner dans le format de son pays. Typiquement, pour la France, un numéro de portable commencera par 06 ou 07.

Tant que vous êtes dans le pays originel, ça fonctionne : vous pouvez envoyer votre sms de validation sans problème. Mais si votre provider est à l’étranger ou si vous voulez envoyer votre message dans un autre pays, ça ne fonctionnera pas.

La solution : utiliser les préfixes internationaux. Sauf que ça suppose que vous connaissiez le pays d’origine de l’utilisateur. Utiliser la géolocalisation ? Si la personne est en déplacement à l’étranger, ça ne fonctionne pas. La langue ? Possible mais ça suppose que l’appareil est zoné et l’interface identifie clairement la langue (par exemple français belge et pas juste français).

Et il ne faut pas oublier que certaines personnes, pour éviter les soucis, donnent leur numéro de téléphone avec le préfixe international directement (le +33 pour la France, par exemple) : il ne faudrait pas le leur rajouter !

Autres formats

Je ne vais pas m’étendre dessus plus longtemps mais tout ce qui a trait aux formats et aux mesures est susceptible de poser problèmes :

• Les mesures de façon générale : tout le monde n’utilise pas le kilogramme ou le litre.
• Le sens de la conduite : oui, tout le monde ne roule pas à droite.
• Le format des adresses postales.
• Etc., etc., etc.

Le design

Jusque là, je me suis concentré sur le texte parce que c’est souvent vu comme LE gros morceau. Mais il y a pas mal de petites choses à voir en dehors.

Sens de lecture

Vous vous rappelez le sens de lecture des textes ? On aligne à droite et plus à gauche ? Figurez-vous que ça a aussi un impact sur la mise en page. Parce que votre menu secondaire à droite et votre contenu principal à gauche, il faut les inverser si on veut rester cohérent !

Plus subtil : les icônes. Les jolies flèches par exemple, n’‘‘oubliez pas de les inverser !

Mais attention à l’excès de zèle : tout n’est pas forcément à inverser. L’icône de lecture d’une vidéo par exemple, bien qu’orienté, n’est pas à inverser.

Pas simple.

Images et couleurs

Attention aux images et couleurs que vous utilisez également. L’exemple classique est la couleur blanche dans les mariages : dans les contrées occidentales, c’est la couleur de la pureté/bonheur. Mais en Chine, c’est la couleur du deuil. Donc si votre site propose des photos de mariage en illustration, n’oubliez pas de les adapter au pays.

De la même façon, n’illustrez pas une page avec une photo de maison typiquement française avec jardin si vous allez dans un pays majoritairement désertique. Évitez les photos avec des gens qui boivent de l’alcool dans les pays musulmans. Faites attention aux photos de vache si vous diffusez en Inde, l’animal étant sacré là-bas, ce pourrait être mal perçu selon la photo.

L’état du marché

Alors oui, on est plus sur du marketing que sur du développement : pourquoi j’en parle dans un article plutôt orienté développeur ? Parce que l’impact peut être important sur les développeurs. Je passe donc volontairement sur les questions marketing du genre « ai-je un intérêt à lancer mon guide des cocktails alcoolisés dans un pays musulman ? » pour me concentrer sur les problématiques techniques.

Le matériel

On part souvent du postulat que tout le monde dispose de matériel équivalent au nôtre. Et c’est plutôt vrai pour les pays occidentaux : entre la France, l’Allemagne et les États-Unis, on retrouve sensiblement les mêmes pré-conditions (je dis bien sensiblement parce qu’il y a des écarts aussi).

Mais qu’en est-il de l’Afrique par exemple ? Les conditions ne sont plus du tout les mêmes. On arrive dans des pays où la fourniture même d’électricité pose problème et où les coupures sont fréquentes. Paradoxalement, dans les zones couvertes, vous avez beaucoup plus de chance d’avoir accès à internet via réseau 4G que via réseau câblé (le continent africain n’est que très très faiblement câblé, il est plus facile de couvrir une zone avec une antenne 4G que de tirer des câbles vers chaque habitation).

Et puis, bien entendu, le pays que vous ciblez a-t-il les dernières versions des navigateurs ? Ne resterait-il pas des IE6 qui traînerait en grand nombre ? Avez-vous bien testé les navigateurs cibles du pays que vous ciblez (coucou UC Browser en Asie) ?

Les impacts côté développeurs peuvent être importants : s’il faut vraiment attaquer ce genre de marché, il va peut-être falloir optimiser drastiquement l’application, voire carrément en proposer une version allégée. Donc de nouveaux développements, des doublons de code à maintenir, etc.

Plus complexe qu’il n’y paraissait au premier abord, n’est-ce pas ?

Les contraintes économiques

En plus des contraintes techniques propres à chaque pays, des contraintes économiques peuvent affecter le développement d’une application/site web.

Prenons par exemple le Canada. Un pays occidental, relativement riche, a priori sans trop de soucis côté matériel, bref, des conditions proches de la France. Sauf qu’internet au Canada, ce n’est pas la France. C’est moins bien et surtout, beaucoup plus cher.

Si l’on prend les premiers prix chez les fournisseurs internet là-bas (par exemple Bell ou Rogers), on est autour de 36$ pour moins de 5Mbits/s et surtout, entre 20 à 30Go de téléchargement ! Et ce ne sont pas les forfaits mobiles, ce sont bien les forfaits fixes. Pour commencer à approcher de l’illimité il faut quasiment doubler le prix du forfait.

Conséquence : les canadiens les moins aisés regardent à la consommation du forfait, même pour de la bureautique. Et donc il vaut mieux que votre application ou votre site web consomme peu de data, sous peine de ne pas être utilisé. Côté développement, ça oblige à réduire la taille des ressources, ajouter des optimisations, gérer des mises en cache locales, etc.

La législation

Souvent, quand on parle législation, on pense à la Chine et sa censure qui sont très contraignantes. Sauf qu’il n’y a pas forcément besoin d’aller aussi loin pour tomber sur des contraintes juridiques et légales.

Si l’on prend la France, il est obligatoire de présenter un bandeau d’informations sur les cookies s’ils sortent du cadre du bon fonctionnement de l’application (exemple : usage de Google Analytics). Ce n »est pas grand chose, mais pour une société US qui s’installe en France, ça fait un module à développer en plus.

De façon plus générale en Union Européenne, la G.D.P.R. (General Data Protection Regulation) est relativement contraignante pour les données privées (ce n’est pas un mal, mais ça peut parfois être prise de tête). Par exemple, la durée de rétention des données utilisateurs impliquent de faire du nettoyage à intervalle régulier, et donc potentiellement de mettre en place des outils pour le faire !

Et même sans chercher du côté des données personnelles, si vous traitez de l’argent, vous allez être confronté à des taxes, comme la TVA. Par exemple, le taux maximal de TVA en France est de 20%. En Allemagne, en ce début 2018, il est de 19% et en Belgique, il est de 21%. Et puis, en France, on a 4 taux de TVA : 2.1%, 5,5%, 10% et 20%. En Allemagne, il n’y en a que 2. Et en Belgique, il y en a 4, mais attention, ils ne s’appliquent pas sur les même produits qu’en France.

Bref, il ne faut pas oublier, lorsque vous proposez des objets en vente dans un autre pays (via par exemple une plateforme de e-commerce) d’être bien à jour avec vos taxes, sinon vous risquez de vendre plus cher ou moins cher un article (ce qui, dans les deux cas, est préjudiciable).

Bref, l’internationalisation c’est bien, mais ça reste un sujet extrêmement difficile et mieux vaut savoir dans quoi l’on met les pieds avant de s’engager.

Quelques liens :

• Design pour des utilisateurs arabes : https://medium.freecodecamp.org/designing-for-the-arab-user-basic-arabic-ux-for-business-6ff29d4c7c60-business-6ff29d4c7c60
• Retour d’expérience sur la vie de tous les jours en Afrique (fr) : https://www.24joursdeweb.fr/2014/un-web-en-voie-de-developpement/