Localisation de logiciels et d'applications

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 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.

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.

.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.

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é.

{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.

L'espagnol, l'italien et le pachto ont tous besoin de connaître 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é.

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 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.

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 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.

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.

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.

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.

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.

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.

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.

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.

• 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.

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.

Chaque chaîne passe sous l'œil d'un linguiste qualifié avant de quitter le portail. Nous utilisons nos linguistes spécialisés pour accélérer la première ébauche, mais aucune chaîne n'est jamais livrée sans approbation humaine. Si vous voulez de la MT brute pour des raisons de coût, AWS Translate et l'API notre pipeline sont excellents — nous vous aiderons à les configurer, mais nous ne mettrons pas notre nom sur la sortie.

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.

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.