Localisation logicielle (i18n / l10n) en plus de 225 langues
Adaptation complète de plateformes SaaS, applications mobiles, applications desktop et jeux à chaque marché — ICU MessageFormat, CLDR, pseudo-localisation et intégration Git/CI
La localisation logicielle adapte un produit logiciel — plateforme SaaS, application mobile ou desktop, jeu — à la langue, à la culture et aux conventions techniques d'un marché cible. Au-delà de la traduction des chaînes : pluralisation CLDR, formats de date et de devise, sens de lecture (LTR/RTL), tri par locale et compatibilité ICU MessageFormat. Intégration directe avec votre workflow Git/CI. NDA sur chaque mission.
Un logiciel localisé qui se vit comme un build natif
Chaîne après chaîne, contexte après contexte — des spécialistes avec expérience logicielle ou i18n localisent votre logiciel selon ICU MessageFormat et les conventions CLDR. Intégrés à votre workflow Git/CI pour que chaque release soit prête en chaque langue le jour J.
Spécialistes avec expérience logicielle ou i18n
Pseudo-localisation QA et vérification contextuelle dans le build
ICU MessageFormat / CLDR plus prise en charge RTL par marché
Les défauts de localisation sont souvent petits mais coûteux : un libellé de bouton tronqué,
un format de date erroné, un radical pluriel incorrect en russe, ou une UI qui ne se reflète
pas en RTL. Notre workflow démarre par défaut avec une pseudo-localisation pour exposer les
chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation avant la
phase de traduction — les corrections d'ingénierie ont lieu dans le code, pas réparties
sur quinze traductions plus tard. Pour les releases continues, nous nous calons sur le
rythme de votre équipe via Git, CI/CD et intégration TMS.
Couverture linguistique
Localisation logicielle en plus de 225 langues
Des langues européennes principales à l'arabe, l'hébreu, le farsi et l'ourdou (RTL) — spécialistes avec expérience logicielle ou i18n par marché.
Nous analysons vos fichiers logiciels — gettext .po/.mo, XLIFF, JSON i18n, .resx, .properties, Apple .strings/.stringsdict, Android XML — et établissons un plan de localisation. Chaînes, variables, placeholders et éléments dépendants du contexte sont identifiés en amont.
02
Pseudo-localisation comme QA pré-traduction
Étape standard : la pseudo-localisation remplace temporairement les chaînes sources par des caractères allongés (par exemple "[!!! Säve čhängēs !!!]") pour exposer les chaînes codées en dur, les ruptures de mise en page, les bugs de concaténation et les chaînes non externalisées avant que les traducteurs ne commencent.
03
Infrastructure de localisation et intégration CI
Nous configurons un workflow efficace via Git, GitHub/GitLab Actions et TMS (Phrase, Lokalise, Crowdin, memoQ Server). Workflow piloté par pull-request avec gestion des versions et chaînes delta — seules les chaînes nouvelles ou modifiées repassent en traduction.
04
Localisation par un spécialiste avec expérience logicielle / i18n
Un traducteur spécialisé en logiciel ou avec expérience i18n localise toutes les chaînes UI en tenant compte du contexte : un libellé de bouton de trois mots exige une approche différente d'un texte d'aide détaillé ou d'un message d'erreur. ICU MessageFormat et catégories de pluriel CLDR sont appliqués correctement.
05
Contrôle qualité linguistique en contexte
Lorsque le périmètre, le risque ou le volume le justifie, un second spécialiste vérifie les traductions en contexte — avec captures d'écran ou un build live — pour s'assurer que les textes tiennent dans l'espace disponible, que l'intégrité des placeholders est préservée et que l'interface reste logique.
06
Livraison et collaboration continue
Nous livrons les fichiers localisés dans votre format source, prêts à l'import via PR ou via votre TMS. Pour les releases continues, nous devenons votre partenaire de localisation attitré — à chaque sprint, release ou hotfix.
Le contexte fait tout, en logiciel
Localiser sans contexte devient un pari. Nous rendons le contexte concret.
Une chaîne comme « Supprimer » peut être un bouton (impératif, court) ou un en-tête de confirmation (plus posé, expliqué). Sans contexte, un traducteur peut manquer le ton ou positionner un placeholder de travers. Notre approche s'appuie sur captures d'écran, accès au build live et QA UI — lorsque le périmètre, le risque ou le volume le justifie. Combiné avec une pseudo-localisation avant la phase de traduction, chaînes codées en dur et ruptures de mise en page sont corrigées dans le code en premier.
Le technique et le linguistique — à chaque release
De la prise en charge des formats à l'intégration sprint : notre localisation se cale sur votre équipe de développement, et non l'inverse.
Conformité ICU MessageFormat & CLDR
Pluralisation selon les catégories CLDR (zero/one/two/few/many/other), formats de date / nombre / devise par locale et validation des placeholders via ICU MessageFormat. Pas de concaténation de chaînes pour gérer les pluriels.
Pseudo-localisation QA avant traduction
Nous exécutons la pseudo-localisation avant la traduction réelle pour exposer les chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation. Les corrections d'ingénierie ont lieu avant la phase de traduction, pas après — évitant des cycles de re-traduction coûteux.
Plus de 225 langues, RTL en standard
Des langues européennes principales à l'arabe, l'hébreu, le farsi et l'ourdou (RTL) : localisation pour tous les marchés, avec miroir UI, rendu BiDi, formats de date / devise par locale et règles de tri CLDR.
Traduction contextualisée avec accès au build
Nous demandons systématiquement le contexte de chaque chaîne. Un message d'erreur, une infobulle et un libellé de bouton appellent chacun un ton et une longueur différents. Les traducteurs spécialisés en logiciel ou avec expérience i18n reçoivent captures d'écran ou accès direct au build.
Assurance qualité
Votre logiciel, notre responsabilité
Chaque localisation suit un processus qualité — de la vérification des formats à la QA contextuelle dans votre environnement de build live.
Spécialistes avec expérience logicielle / i18nSpécialisation par domaine
Conforme ICU MessageFormat / CLDRPluralisation, dates, nombres, tri par locale
Pseudo-localisation QA standardChaînes codées en dur et ruptures de mise en page exposées avant traduction
Intégration Git / CI/CDPhrase, Lokalise, Crowdin, memoQ Server
Protégé par NDACode source et chaînes en sécurité
Cas pratiques
Projets de localisation concrets
Des tableaux de bord SaaS aux applications fintech mobiles, jusqu'aux jeux AAA déployés dans de nombreuses langues.
01SaaS · B2B
Case Study
Tableau de bord SaaS B2B — multilingue, cadence sprint
Schéma type pour éditeurs SaaS : à chaque sprint, les chaînes nouvelles ou modifiées passent par l'intégration Git vers plusieurs langues. Workflow piloté par pull-request, mémoire de traduction par client, spécialistes avec sensibilité UX — uniquement les chaînes delta sprint après sprint, sans bloqueurs de release.
Git-PRworkflow
sprintcadence
par clientTM
02Fintech · Mobile
Case Study
Application mobile fintech — RTL plus devise par marché
Schéma type pour applications fintech sur plusieurs marchés incluant l'arabe et l'hébreu : localisation RTL complète de l'UI avec miroir, formats de devise et de date par locale, chaînes d'accessibilité incluses. QA contextuelle dans le build live avant release.
AR+HERTL
par marchéformats
build liveQA
03Jeux · AAA
Case Study
Éditeur de jeux — titre AAA, nombreuses langues
Schéma type pour la localisation de jeu AAA : dialogues, UI, menus et chaînes d'accessibilité localisés en parallèle dans de nombreuses langues. Captures d'écran contextuelles par scène, base terminologique pour le lore des personnages, lancement simultané sur tous les marchés.
AAAscope
capturescontexte
synclancement
Applications
Pour quel logiciel ?
8types de logiciel
Localisation pour chaque type de logiciel — du SaaS B2B aux jeux mobiles, RTL et tableaux de bord inclus.
Plateformes SaaS et applications web
Applications mobiles (iOS et Android)
Applications desktop et entreprise
Jeux et interfaces de jeu
Interfaces logicielles techniques
Tableaux de bord et outils analytics
Plateformes e-commerce
Documentation d'aide et de support
La confiance des institutions publiques, juridiques & grandes entreprises
HPMinistère de la JusticeASMLSiemensRocheAmazonINGCalvin KleinShellTribunal de CommerceBoschBMWAudiBASFDSM
HPMinistère de la JusticeASMLSiemensRocheAmazonINGCalvin KleinShellTribunal de CommerceBoschBMWAudiBASFDSM
BarreauPhilipsAdministration FiscaleVolkswagenBNP ParibasSanofiSAPMedtronicUniversité de StrasbourgTotalSociété GénéraleJohn DeereRitualsUnilever
BarreauPhilipsAdministration FiscaleVolkswagenBNP ParibasSanofiSAPMedtronicUniversité de StrasbourgTotalSociété GénéraleJohn DeereRitualsUnilever
En complément
Services connexes
Souvent choisis en combinaison avec la localisation logicielle — de la traduction de site web et la PAO à la gestion terminologique et la MTPE pour la documentation d'aide.
La localisation logicielle adapte un logiciel — SaaS, application mobile ou desktop, jeu — à la langue, à la culture et aux conventions techniques d'un marché cible : au-delà de la traduction des chaînes. Notre workflow respecte ICU MessageFormat / CLDR pour la pluralisation, les dates, les nombres et le tri par locale. La distinction entre internationalisation (i18n — préparer le code à plusieurs locales) et localisation (l10n — adapter contenus et conventions par marché) structure l'approche. Un logiciel bien localisé donne à l'utilisateur l'impression d'avoir été conçu nativement dans sa langue.
Quelle est la différence entre i18n et l10n ?
L'i18n (internationalisation) prépare le code pour gérer plusieurs locales ; la l10n (localisation) adapte ensuite le contenu et les conventions à chaque marché — l'i18n est en amont, la l10n en aval. Concrètement : extraction des chaînes vers des fichiers de ressources (.po, JSON, .strings), gestion des placeholders et de la pluralisation côté code, séparation entre logique applicative et contenu localisable. Sans une bonne i18n, la l10n bute sur des chaînes codées en dur, des concaténations et des layouts qui cassent — c'est précisément ce que la pseudo-localisation détecte avant la traduction.
Quels formats de fichiers prenez-vous en charge ?
Compatible avec les principaux formats : gettext .po/.mo, Apple .strings, .stringsdict, Android .xml, JSON i18n, YAML, XLIFF, RESX (.NET), Properties (Java), Qt .ts. Nous sommes compatible avec les principaux formats d'export CMS (WordPress XLIFF, Drupal i18n, Shopify Markets CSV), et nous nous alignons sur des formats personnalisés (Unity, Unreal Engine, schémas JSON propriétaires) après une brève concertation avec votre équipe d'ingénierie. outils TAO (SDL Trados, memoQ) avec gestion terminologique prennent en charge ces formats nativement, en préservant placeholders, contexte de commentaire et noms de clés. Livraison prête à l'import dans le format source.
Qu'est-ce que la pseudo-localisation ?
La pseudo-localisation avant traduction révèle les chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation — c'est un test de robustesse du code i18n. pseudo-localisation avant traduction : révèle les chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation. Les chaînes sources sont temporairement remplacées par des caractères allongés ("[!!! Säve čhängēs !!!]") pour simuler l'expansion (allemand +30 % vs anglais) et les exigences RTL. Les corrections d'ingénierie ont lieu avant la phase de traduction, pas après — ce qui évite des cycles de re-traduction coûteux.
Comment gérez-vous la pluralisation, les dates et le tri par locale ?
Nous respectons ICU MessageFormat et CLDR pour la pluralisation, les dates, les nombres, les devises et le tri par locale — incluant les règles particulières du russe, du polonais, de l'arabe et du chinois. CLDR distingue six catégories de pluriel (zero/one/two/few/many/other) — le polonais et le russe en utilisent trois, l'arabe six ; le français et l'anglais deux. La syntaxe ICU avec blocs plural et select est prise en charge nativement par nos outils. Notre workflow respecte ICU MessageFormat / CLDR pour la pluralisation, les dates, les nombres et le tri par locale.
Gérez-vous les langues RTL (arabe, hébreu, persan) ?
Oui — support complet RTL (droite-à-gauche) avec miroir d'interface, alignement et ponctuation adaptés, pour arabe, hébreu, persan et ourdou. Le rendu bidirectionnel suit l'algorithme Unicode BiDi ; pour les textes mixtes (arabe + noms de marques en alphabet latin), nous appliquons les conventions BiDi standard. Nos spécialistes RTL contrôlent la traduction et le rendu visuel — sens de lecture, alignement, position de la ponctuation et miroir des éléments UI — dans le build live.
Vous intégrez-vous à notre workflow Git/CI ?
Oui — nous travaillons directement sur les chaînes de ressources de votre dépôt, avec branches dédiées, pull requests et déclenchement par CI selon le workflow convenu. Intégration possible avec Git, GitHub/GitLab Actions, ou via un TMS partenaire (Phrase, Lokalise, Crowdin, memoQ Server). outils TAO (SDL Trados, memoQ) avec gestion terminologique construisent une mémoire de traduction réutilisée à chaque sprint — seules les chaînes delta atteignent le traducteur, ce qui réduit le coût par sprint au fil du temps.
01Qu'est-ce que la localisation logicielle ?
La localisation logicielle adapte un logiciel — SaaS, application mobile ou desktop, jeu — à la langue, à la culture et aux conventions techniques d'un marché cible : au-delà de la traduction des chaînes. Notre workflow respecte ICU MessageFormat / CLDR pour la pluralisation, les dates, les nombres et le tri par locale. La distinction entre internationalisation (i18n — préparer le code à plusieurs locales) et localisation (l10n — adapter contenus et conventions par marché) structure l'approche. Un logiciel bien localisé donne à l'utilisateur l'impression d'avoir été conçu nativement dans sa langue.
02Quelle est la différence entre i18n et l10n ?
L'i18n (internationalisation) prépare le code pour gérer plusieurs locales ; la l10n (localisation) adapte ensuite le contenu et les conventions à chaque marché — l'i18n est en amont, la l10n en aval. Concrètement : extraction des chaînes vers des fichiers de ressources (.po, JSON, .strings), gestion des placeholders et de la pluralisation côté code, séparation entre logique applicative et contenu localisable. Sans une bonne i18n, la l10n bute sur des chaînes codées en dur, des concaténations et des layouts qui cassent — c'est précisément ce que la pseudo-localisation détecte avant la traduction.
03Quels formats de fichiers prenez-vous en charge ?
Compatible avec les principaux formats : gettext .po/.mo, Apple .strings, .stringsdict, Android .xml, JSON i18n, YAML, XLIFF, RESX (.NET), Properties (Java), Qt .ts. Nous sommes compatible avec les principaux formats d'export CMS (WordPress XLIFF, Drupal i18n, Shopify Markets CSV), et nous nous alignons sur des formats personnalisés (Unity, Unreal Engine, schémas JSON propriétaires) après une brève concertation avec votre équipe d'ingénierie. outils TAO (SDL Trados, memoQ) avec gestion terminologique prennent en charge ces formats nativement, en préservant placeholders, contexte de commentaire et noms de clés. Livraison prête à l'import dans le format source.
04Qu'est-ce que la pseudo-localisation ?
La pseudo-localisation avant traduction révèle les chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation — c'est un test de robustesse du code i18n. pseudo-localisation avant traduction : révèle les chaînes codées en dur, les ruptures de mise en page et les bugs de concaténation. Les chaînes sources sont temporairement remplacées par des caractères allongés ("[!!! Säve čhängēs !!!]") pour simuler l'expansion (allemand +30 % vs anglais) et les exigences RTL. Les corrections d'ingénierie ont lieu avant la phase de traduction, pas après — ce qui évite des cycles de re-traduction coûteux.
05Comment gérez-vous la pluralisation, les dates et le tri par locale ?
Nous respectons ICU MessageFormat et CLDR pour la pluralisation, les dates, les nombres, les devises et le tri par locale — incluant les règles particulières du russe, du polonais, de l'arabe et du chinois. CLDR distingue six catégories de pluriel (zero/one/two/few/many/other) — le polonais et le russe en utilisent trois, l'arabe six ; le français et l'anglais deux. La syntaxe ICU avec blocs plural et select est prise en charge nativement par nos outils. Notre workflow respecte ICU MessageFormat / CLDR pour la pluralisation, les dates, les nombres et le tri par locale.
06Gérez-vous les langues RTL (arabe, hébreu, persan) ?
Oui — support complet RTL (droite-à-gauche) avec miroir d'interface, alignement et ponctuation adaptés, pour arabe, hébreu, persan et ourdou. Le rendu bidirectionnel suit l'algorithme Unicode BiDi ; pour les textes mixtes (arabe + noms de marques en alphabet latin), nous appliquons les conventions BiDi standard. Nos spécialistes RTL contrôlent la traduction et le rendu visuel — sens de lecture, alignement, position de la ponctuation et miroir des éléments UI — dans le build live.
07Vous intégrez-vous à notre workflow Git/CI ?
Oui — nous travaillons directement sur les chaînes de ressources de votre dépôt, avec branches dédiées, pull requests et déclenchement par CI selon le workflow convenu. Intégration possible avec Git, GitHub/GitLab Actions, ou via un TMS partenaire (Phrase, Lokalise, Crowdin, memoQ Server). outils TAO (SDL Trados, memoQ) avec gestion terminologique construisent une mémoire de traduction réutilisée à chaque sprint — seules les chaînes delta atteignent le traducteur, ce qui réduit le coût par sprint au fil du temps.
Témoignages
Témoignages clients
Ce que disent nos clients de leur collaboration avec Ecrivus — des startups SaaS aux éditeurs de jeux AAA.
“
★★★★★
Les traductions certifiées pour nos affaires internationales sont livrées rapidement et avec soin. Notre chef de projet connaît notre dossier sur le bout des doigts.
01 / 03
Besoin de localiser un logiciel ?
Sans engagement — réponse sous une heure les jours ouvrés