Sept langues : pourquoi la localisation est une fonctionnalite de fiabilite

Tactic Remote est desormais livre avec un support complet pour sept langues : anglais, chinois (simplifie), japonais, coreen, espagnol, allemand et francais. Ce n'est pas une annonce du type "nous avons passe les chaines dans une API de traduction". La localisation d'un outil de developpement qui gere la configuration reseau, la sortie du terminal et les operations au niveau systeme exige un standard different de celui de la traduction d'applications grand public.

Cet article presente notre approche technique, les bugs qui nous ont appris a traiter la localisation comme de l'ingenierie de fiabilite, et ce que nous observons en matiere d'adoption internationale.

Les sept langues

Notre selection de langues a ete guidee par les donnees utilisateurs et le volume de demandes pendant la beta privee :

Nous avons priorise les langues pour lesquelles nous avions a la fois une demande utilisateur et un acces a des developpeurs natifs capables de valider la precision technique. La localisation d'outils de developpement necessite une expertise du domaine — traduire "session", "tunnel" ou "hook" en japonais requiert de comprendre le sens technique du terme, pas seulement sa definition dans le dictionnaire.

Au-dela de la traduction de chaines

L'approche standard de la localisation iOS est simple : extraire les chaines visibles par l'utilisateur dans des fichiers .strings ou .xcstrings, fournir les traductions et laisser le systeme gerer l'affichage. Nous faisons cela, mais l'ingenierie interessante se situe dans les couches sous la substitution de chaines.

Gestion des entrees sensible au locale

Le bug qui a change notre philosophie de localisation : les utilisateurs en locale allemand ne pouvaient pas saisir d'adresses IP lors de la configuration.

Le clavier iOS en locale allemand utilise par defaut une virgule comme separateur decimal. Quand un utilisateur en locale allemand appuie sur la zone de la touche "." du clavier numerique, il obtient une virgule. Une adresse IPv4 comme 192.168.1.100 etait saisie comme 192,168,1,100 — que notre validation rejetait comme mal formee.

Ce n'est pas un bug de traduction. C'est un bug de comportement du locale. Les chaines de l'interface etaient correctement traduites, mais le mecanisme de saisie etait casse par une hypothese sur la disposition du clavier. Nous avons corrige cela en normalisant la virgule en point dans les champs de saisie d'adresses IP et en presentant une configuration de clavier personnalisee qui affiche toujours une touche point pour les saisies d'adresses reseau.

Ce seul bug representait environ 23% des echecs de configuration parmi les utilisateurs en locale allemand avant la correction. Apres le deploiement, les taux de completion de la premiere execution en locale allemand ont rejoint la reference anglaise en un cycle de publication.

Pluralisation et accord grammatical

L'interpolation de chaines avec des nombres est un piege classique de la localisation. L'anglais le gere simplement : "1 session" vs. "2 sessions." Les autres langues ont des regles de pluriel plus complexes :

• Le japonais et le coreen n'ont pas de pluriel grammatical — la meme forme est utilisee quel que soit le nombre.
• Le francais pluralise la plupart des noms a partir de 2, mais certaines expressions se comportent differemment.
• Les mots composes allemands peuvent changer de forme selon le cas grammatical et la pluralite.

Nous utilisons le systeme de regles de pluriel stringsdict d'iOS, qui prend en charge les categories de pluriel CLDR (zero, one, two, few, many, other). Chaque chaine visible par l'utilisateur incluant un nombre passe par un formatage sensible au pluriel plutot que par une simple concatenation de chaines.

Preparation pour l'ecriture de droite a gauche

Aucune de nos sept langues actuelles ne necessite une disposition RTL, mais notre architecture UI en tient compte. Toutes les contraintes de mise en page utilisent des ancres leading/trailing plutot que left/right. L'alignement du texte est defini sur .natural. Cela signifie que lorsque nous ajouterons le support de l'arabe ou de l'hebreu — deux langues avec des communautes de developpeurs actives — le travail de mise en page sera minimal.

Localisation du contenu MDX

Le site web et la documentation de Tactic Remote sont construits avec MDX. La localisation du contenu documentaire a necessite une strategie differente de la localisation des chaines de l'application.

Chaque document MDX peut avoir des variantes specifiques au locale en utilisant une convention de suffixe de nom de fichier : product-update.mdx (anglais par defaut), product-update.zh-CN.mdx (chinois), product-update.ja.mdx (japonais), et ainsi de suite. Le routeur de contenu detecte la langue preferee de l'utilisateur et sert la variante appropriee, avec un fallback vers l'anglais lorsqu'une version localisee n'existe pas.

Cette approche comporte un compromis delibere : nous ne traduisons pas chaque page de documentation dans chaque langue. Les guides de configuration technique et les references API restent en anglais car ils contiennent des exemples de code, des instructions en ligne de commande et des valeurs de configuration qui sont independantes de la langue. Nous concentrons l'effort de localisation sur le contenu ou les barrieres linguistiques bloquent reellement la comprehension : annonces de produit, presentations conceptuelles et parcours d'integration.

Actuellement, 34% de notre contenu MDX possede au moins une variante non anglaise. Nous priorisons en fonction du trafic des pages et de la correlation avec les tickets de support — si une page genere des questions de support de maniere disproportionnee a partir d'un groupe linguistique specifique, cette page est localisee en priorite.

L'argument de la fiabilite

Nous traitons la localisation comme une fonctionnalite de fiabilite pour une raison precise : un developpeur qui ne peut pas terminer la configuration a cause d'un bug de saisie lie au locale est dans le meme etat qu'un developpeur qui ne peut pas se connecter a cause d'une erreur reseau. Le produit est casse pour lui. Que la cause profonde soit "nous avons suppose une disposition de clavier anglais" plutot que "nous avons un bug TCP" ne change pas l'experience utilisateur.

Ce cadrage a des consequences pratiques pour notre processus d'ingenierie :

Matrice de tests specifique au locale. Notre CI execute des tests de chemin critique (flux de configuration, etablissement de connexion, flux d'approbation) sous six configurations de locale non anglais. Une regression dans la saisie d'IP en locale allemand serait detectee avant la fusion.

Les bugs de localisation recoivent un triage de severite 1 lorsqu'ils bloquent une fonctionnalite essentielle. Un libelle mal traduit est cosmetique. Un echec de saisie dependant du locale est un incident de production.

Gel des chaines avant la publication. Nous gelons les chaines anglaises 72 heures avant chaque publication, donnant aux traducteurs une cible stable. Les traductions sont validees par des developpeurs natifs de l'equipe, pas seulement par des linguistes.

Adoption internationale

Depuis le lancement du support multilingue, nous avons observe des changements mesurables dans notre base d'utilisateurs :

• Les utilisateurs de locales non anglais sont passes de 18% a 41% des utilisateurs actifs hebdomadaires en six semaines.
• Les utilisateurs de chinois (simplifie) sont desormais le deuxieme plus grand groupe linguistique, representant 15% des actifs hebdomadaires.
• Les utilisateurs japonais ont la duree moyenne de session la plus elevee parmi tous les groupes linguistiques — 52 minutes contre 47 minutes en moyenne.
• Le taux de completion de la configuration dans tous les locales est maintenant a moins de 2 points de pourcentage de la reference anglaise. Avant le travail de localisation, certains locales avaient des taux de completion 15 a 20% inferieurs a l'anglais.

La convergence du taux de completion de la configuration est la metrique qui nous importe le plus. Elle valide que la localisation comble des lacunes de fiabilite, et non qu'elle ajoute simplement des libelles traduits.

Prochaines etapes

Nous etendons le support linguistique selon les memes criteres : demande des utilisateurs et acces a des relecteurs techniques natifs.

• Des langues supplementaires sont en cours d'evaluation en fonction de la demande des utilisateurs et de la disponibilite de relecteurs techniques natifs.
• Nous construisons un workflow de contribution communautaire pour les traductions, avec un processus de revue qui garantit la precision technique avant la fusion.

Pour les details sur le fonctionnement de la detection de langue et du fallback, consultez Architecture de localisation. Si vous souhaitez contribuer des traductions pour une langue non supportee, contactez-nous via la page de Support.