Localisation de logiciels et d'applications

La localisation de logiciels semble simple jusqu'au déploiement. Une équipe rédige en.json et suppose que l'espagnol, l'allemand et l'arabe suivront le même chemin. Ce ne sera pas le cas. Chaque format de fichier comporte une particularité qui casse le build d'une agence non préparée. Après 14 ans et plusieurs milliers de versions SaaS, nous avons une courte liste des cas qui piègent même les équipes d'ingénierie matures.

JSON, YAML et le problème de l'apostrophe

Le JSON brut n'a pas de commentaires ni de prise en charge du pluriel - acceptable pour l'anglais, fragile en production dès que les traducteurs ajoutent des apostrophes courbes (’ vs '), des espaces insécables fines autour de la ponctuation française, ou des guillemets allemands (», «). Un traducteur français qui écrit le correct L'application avec une apostrophe typographique passera la QA linguistique et cassera un analyseur JSON fragile. Nous normalisons les apostrophes à l'importation, validons la présence du BOM UTF-8 et effectuons un contrôle syntaxique avant l'expédition de toute locale.

Android strings.xml : l'échappement silencieux

Android stocke les apostrophes comme \' et les esperluettes comme &. Les traducteurs collent régulièrement les caractères courbes de Microsoft Word qui semblent identiques et expédient - jusqu'à ce que la mise en page affiche du mojibake à l'exécution. Nous utilisons un aller-retour XLIFF personnalisé pour les ressources Android afin que le traducteur ne voie jamais le XML brut, et nous ré-échappons à l'exportation.

iOS .strings et .stringsdict

Le problème classique concerne les règles de pluriel. iOS utilise les catégories de pluriel CLDR (zero, one, two, few, many, other) via .stringsdict. Un traducteur naïf traitera le fichier comme un un-pour-un et perdra les variantes de pluriel - votre application allemande dira alors "1 Nachrichten". Nous utilisons un éditeur sensible au pluriel qui expose chaque catégorie CLDR requise pour la locale cible et refuse l'exportation si une catégorie manque.

.NET .resx et Java .properties

.resx accepte les commentaires XML et les références de code intégrées ; .properties utilise ISO-8859-1 par défaut (les chaînes d'outils modernes prennent en charge UTF-8, mais la mauvaise combinaison expédie toujours des échappements \uXXXX qui déroutent les traducteurs). Nous forçons UTF-8 à l'importation et n'émettons les échappements natifs qu'au moment du build.

L'aller-retour XLIFF

Chaque fois que possible, nous extrayons les fichiers source vers XLIFF 1.2 ou 2.0, traduisons dans notre éditeur avec le contexte attaché, et fusionnons à nouveau. Cela permet aux traducteurs de voir le commentaire source, la capture d'écran et la contrainte (limite de caractères, forme plurielle ICU, indicateur de miroir RTL) sans jamais toucher au fichier source. Le pipeline de build fusionne dans le format que vos développeurs ont commité.

Si votre produit a un slogan comme "Marie a invité 3 amis à votre événement", vous êtes sur le point de découvrir ICU MessageFormat. L'anglais nécessite trois variables. Le russe nécessite quatre formes de pluriel (1, 2-4, 5+, fractionnaire). L'arabe en nécessite six. Le polonais a encore d'autres règles. De nombreux produits sont livrés avec une chaîne plate comme {name} invited {count} friends et acceptent tranquillement une grammaire cassée dans 80 % des locales.

Le motif correct

{count, plural,
  one {# friend}
  few {# friends}
  many {# friends}
  other {# friends}
}

C'est correct en anglais, français et allemand. En arabe, vous avez besoin de zero, one, two, few, many, other. En polonais, few couvre 2-4 uniquement lorsque le dernier chiffre est 2-4 et que le nombre n'est pas 12-14 - le polonais compte environ 5 catégories de pluriel. Le gallois a les siennes. Nous traduisons selon l'ensemble de règles de pluriel CLDR pour chaque locale, pas selon le modèle anglais.

Sujets genrés

L'espagnol, l'italien et le russe ont tous besoin de savoir si le sujet est masculin, féminin ou neutre pour conjuguer le verbe. Une traduction naïve de "You are invited" se met par défaut au masculin ; une utilisatrice voit une grammaire cassée dans 50 % des locales. Le select d'ICU gère ceci :

{gender, select,
  female {Estás invitada}
  male {Estás invitado}
  other {Te han invitado}
}

Si votre modèle de données ne suit pas le genre, la voie sûre est la branche other neutre. Nous signalons les chaînes genrées lors de la révision source afin que votre équipe puisse décider de capturer le genre, de passer au neutre par défaut ou d'expédier des variantes - avant que le budget de traduction ne soit engagé.

Pourquoi cela compte pour le SEO et la confiance

Les avis App Store et Google Play signalent régulièrement les pluriels cassés : "L'application est boguée, elle dit '1 messages'". Les avis une étoile s'accumulent et dégradent le classement. Corriger les pluriels après le lancement coûte plus cher qu'une traduction sensible à ICU en amont.

Le droite-à-gauche est la catégorie la plus cassée en localisation logicielle. Nous avons 14 ans d'expérience en arabe - c'est notre plus grande paire - et nous voyons toujours des produits SaaS soignés livrés avec des erreurs de deux caractères qui rendent l'interface inutilisable au MENA. La liste ci-dessous provient d'audits réels que nous avons menés pour des clients avant qu'ils ne nous engagent.

Propriétés CSS logiques

Le bug de production le plus courant : les développeurs écrivent margin-left: 16px au lieu de margin-inline-start: 16px. Dans une locale gauche-à-droite, ils sont identiques. En arabe, le premier épingle la marge à gauche de l'écran ; le second bascule correctement à droite. Nous auditons votre feuille de style pour les propriétés physiques (left, right, padding-left, border-right) avant de toucher aux chaînes.

Texte bidirectionnel dans les paragraphes

Un paragraphe arabe qui mentionne un nom de marque anglais, une URL ou un chiffre devient une chaîne à direction mixte. Les navigateurs gèrent cela avec l'algorithme bidirectionnel Unicode, mais l'algorithme est heuristique et se trompe dans des cas prévisibles - le plus souvent lorsqu'une phrase se termine par un chiffre latin ou une ponctuation. Nous insérons des marques U+202A/U+202C (LRE/PDF) ou utilisons des balises <bdi> autour de jetons opaques comme les noms d'utilisateur et les ID de produit.

Icônes qui ont une direction

Icônes de flèche, le chevron « retour », annuler et refaire, directions de curseur, barres de progression - chaque icône directionnelle nécessite une variante RTL ou une transformation CSS. Lucide et Heroicons ont des variantes sensibles RTL ; le jeu d'icônes de Material nécessite une classe miroir. Nous cataloguons chaque icône directionnelle dans votre système de design et signalons celles qui ne sont pas mises en miroir lors de l'audit.

Polices et rendu

Les piles de polices occidentales manquent régulièrement de glyphes arabes - Helvetica Neue, Inter et Roboto nécessitent tous un fallback arabe. La valeur par défaut du système (Geeza Pro sur iOS, Noto Naskh Arabic sur Android) s'affiche, mais la hauteur de ligne est incorrecte et le crénage est médiocre. Nous testons le rendu sur les appareils réels qu'ont vos utilisateurs - pas seulement Chrome sur macOS - et signalons les corrections de pile de polices dans le cadre de la révision pseudo-locale.

Pourquoi c'est notre terrain de prédilection

L'arabe est notre plus grande paire de langues unique. Notre marque sœur arabictranslation.co.uk livre de la localisation arabe depuis 2012. Les suppléments RTL que la plupart des agences britanniques ajoutent (20-30 %) reflètent que c'est un travail inhabituel pour elles ; c'est le travail que nous faisons le plus. Nous ne facturons pas de supplément RTL.

Si votre équipe d'ingénierie livre l'anglais chaque mardi, votre allemand, français et arabe devraient être livrés chaque mardi aussi. Tout le reste est un problème de coordination de version déguisé en problème de traduction. Il existe trois modèles d'intégration que nous prenons en charge ; le bon dépend de la structure de votre dépôt.

Modèle 1 : Flux de travail PR piloté par webhook

Convient à la plupart des équipes SaaS. Un webhook GitHub se déclenche à chaque push vers main. Notre service inspecte le diff pour les chaînes nouvelles ou modifiées, ébauche les locales, les envoie à un linguiste pour révision, et ouvre une PR de retour. La protection de branche garantit que la PR ne peut pas fusionner avant révision. Temps de bout en bout typique : 18-24 heures pour 35 langues sur un commit de 200 chaînes.

Modèle 2 : Étape CI dans votre build

Si votre équipe préfère que les modifications de locale passent par votre système de build (CircleCI, GitHub Actions, GitLab Runners), nous exposons un CLI : lingosecure pull tire les dernières traductions dans votre dépôt comme étape de build, lingosecure push télécharge toute modification de chaîne source pour traduction. Utilisé par les équipes qui exécutent des trains de version et ne veulent pas de PR de traduction dans leur flux.

Modèle 3 : Sync TMS (Phrase / Lokalise / Crowdin)

Si vous avez déjà un TMS, nous sommes heureux d'agir comme couche linguiste à l'intérieur - vos développeurs continuent de pousser les chaînes vers le TMS, nos linguistes traduisent dans le TMS, et la synchronisation TMS s'exécute comme elle l'a toujours fait. Zéro changement de flux de travail pour vos ingénieurs. L'avantage : un fournisseur unique au lieu d'assembler un abonnement TMS, une liste de freelances et un fournisseur pour les éléments réglementés.

Mémoire de traduction et base terminologique

Les trois modèles partagent un principe : votre mémoire de traduction vous appartient. Chaque segment traduit est enregistré dans votre TM, que nous hébergeons dans LingoSecure ou exportons vers votre TMS sur demande. Si vous changez de fournisseur l'année prochaine, la TM vous suit. Il n'y a pas de verrouillage.

Versionnage et rollback

Nous épinglons la mémoire de traduction par version à la version produit. Votre v4.2 ne sera jamais livrée accidentellement avec les chaînes traduites de v4.1. Si votre équipe doit annuler une version, la TM s'annule avec elle. Cela compte pour les produits réglementés où une divulgation traduite doit correspondre à la version anglaise contre laquelle elle a été approuvée.

Avant d'envoyer une chaîne à un traducteur, nous faisons passer votre produit par un build pseudo-locale. Chaque chaîne anglaise est enveloppée d'accents et complétée de 30 % : "Submit" devient "[Ŝûbmît⏎ⓅⒶⒹ]". Le but n'est pas de tester la qualité de traduction ; c'est de tester votre produit. Le remplissage simule l'expansion de 30-40 % de l'allemand ; les accents forcent un chemin de rendu Unicode ; les crochets révèlent les chaînes concaténées (un fragment anglais codé en dur apparaîtra non enveloppé).

Ce que la pseudo-locale détecte

• Troncature - boutons qui s'adaptent à "OK" mais pas à "Aceptar"
• Chaînes codées en dur - tout ce qui n'est pas enveloppé dans t()
• Bugs de concaténation - "Hello " + username cassera dans les langues avec un ordre de mots différent
• Hypothèses de largeur fixe - sélecteurs de date, listes déroulantes, onglets de navigation
• Fallbacks de police - texte qui se transforme en rectangles parce que la police ne couvre pas Latin Extended-A
• Bugs de flip RTL - chaque icône directionnelle et mise en page bascule en pseudo-RTL

Nous livrons le build pseudo-locale comme déploiement Storybook ou branche de fonctionnalité que votre équipe QA peut tester. Le journal de défauts va directement dans votre Linear, Jira ou GitHub Issues. Nous corrigeons les problèmes côté locale ; votre équipe corrige ceux côté produit, avant de payer un seul mot de traduction humaine.

QA visuelle avec diffing de captures d'écran

Pour les produits matures, nous effectuons un passage supplémentaire : chaque écran est capturé en anglais, pseudo-EN, allemand, arabe et chinois, et les différences sont comparées. Les régressions de mise en page apparaissent immédiatement. Le même flux de travail s'exécute sur chaque PR si vous le souhaitez comme GitHub Action.

Les tests en pseudo-locale détectent ce qui casse avant la traduction ; la LQA détecte ce qui casse après. Une fois les chaînes traduites fusionnées, un testeur natif parcourt le build réel, et non un tableur, sur de vrais appareils : chaque écran, chaque boîte de dialogue, chaque état vide et chaque message d'erreur, dans la langue testée. Les défauts linguistiques (un mot composé allemand tronqué, un format de date que personne n'a localisé, une chaîne qui se lit bien isolément mais sonne faux à côté du bouton qu'elle accompagne) sont consignés avec les défauts fonctionnels (formulaires qui rejettent les saisies non latines, liens qui renvoient une erreur 404 dans le build localisé, mises en page qui s'effondrent en RTL).

Comment se déroule la phase de test

• Révision linguistique en contexte - un linguiste natif révise chaque chaîne affichée dans l'interface, là où les contraintes d'espace et les collisions de sens sont réellement visibles
• Vérifications fonctionnelles par locale - navigation, formulaires, paiement et parcours de compte testés dans chaque langue cible sur iOS, Android et navigateurs de bureau
• Défauts consignés là où votre équipe travaille - Linear, Jira ou GitHub Issues, avec capture d'écran, locale, appareil et niveau de gravité sur chaque ticket ; nous corrigeons les problèmes côté locale, votre équipe corrige ceux côté produit
• Cadence compatible avec vos sprints - la LQA s'exécute comme une étape de votre pipeline de release plutôt que comme un audit ponctuel, à £40-£60 de l'heure ou chiffrée par release

La même vérification couvre les jeux vidéo. Les dialogues à embranchements, les textes de quêtes, les bases de données d'objets et les fiches des stores sont testés dans le build réel sous NDA, avec le même processus de gestion des défauts, et c'est encore plus important dans ce cas, car les joueurs font des captures d'écran des mauvaises traductions et ces captures survivent au correctif. La LQA de jeux EFIGS, CJC, portugais brésilien, russe et arabe passe par la même équipe de spécialistes.

La plupart des équipes SaaS choisissent entre trois voies pour la localisation. Aucune n'est fausse ; chacune a un coût sur lequel nous voulons être explicites, car choisir la mauvaise est l'erreur la plus coûteuse dans cet espace.

Le bon choix dépend de votre stade. Un SaaS en phase de démarrage avec 3-5 marchés tire le meilleur parti de LingoSecure et d'un forfait mensuel fixe. Les Série-B et au-delà avec 12+ langues conservent généralement leur TMS existant et nous utilisent comme couche linguiste. Les plateformes réglementées avec audits de conformité veulent le portail LingoSecure et la piste d'audit par segment. Nous vous dirons honnêtement quelle voie convient.

La définition honnête du périmètre compte plus qu'un pitch agressif. Il y a trois choses que notre service de localisation de logiciels ne fait pas, et nous préférons être clairs dès le départ plutôt que de sur-promettre.

Nous ne livrons pas de traduction automatique non révisée

Chaque chaîne passe sous l'œil d'un linguiste qualifié avant de quitter le portail. Notre espace de travail LingoSecure accélère la première ébauche, pour que le linguiste consacre son temps aux nuances, à la terminologie et au ton, mais aucune chaîne n'est jamais livrée sans approbation humaine. Si vous ne voulez qu'une sortie automatique non révisée pour des raisons de coût, c'est un autre service, que nous ne proposons pas ; nous pouvons vous orienter vers un prestataire de traduction purement automatique si cela correspond à votre besoin.

Nous ne faisons pas de délai le jour même à volume entreprise

Une correction d'urgence de 50 chaînes en 4 heures est réaliste dans la plupart des locales majeures. Un lancement de produit de 5 000 chaînes en 24 heures n'est pas réaliste et nous ne nous y engagerons pas. Nous planifions à rebours à partir de votre date de version avec une marge de QA intégrée ; si votre calendrier est plus court, nous vous dirons ce qui est réellement réalisable.

Nous ne sous-traitons pas l'arabe

La plupart des agences britanniques acheminent l'arabe vers un studio au Caire ou à Beyrouth. Nous traduisons en interne avec des linguistes nommés. La même personne qui a traduit vos chaînes v1 est la personne qui traduit v4.7. La cohérence terminologique est fonction de la continuité ; la continuité nécessite de ne pas sous-traiter.