Inventaire
Nous identifions chaînes, pages, ressources, captures, métadonnées, aide et autres éléments traduisibles.
Localisation de sites web avec un processus professionnel adapté au contenu, au domaine, au niveau de risque, aux exigences de confidentialité et au délai attendu.
Une phrase correcte peut être une mauvaise localisation. Nous tenons compte de la locale, de la longueur UI, des variables, placeholders, captures, contexte, ton, cadence de release et terminologie marché.
Sites, logiciels, API et flux continus ne sont pas de simples documents. La traduction doit préserver variables, balises, contraintes d’espace, structure des fichiers et contexte produit.
Nous identifions chaînes, pages, ressources, captures, métadonnées, aide et autres éléments traduisibles.
Variables, balises, syntaxe, clés, limites de caractères et éléments non traduisibles sont protégés.
Captures, descriptions de chaînes, produit, versions précédentes et terminologie évitent les erreurs liées aux chaînes isolées.
La révision vérifie sens, terminologie, ton, cohérence et utilisabilité en contexte.
Troncature, liens, direction du texte, encodage, variables, tri, dates et comportements locaux peuvent être testés.
Terminologie et mémoire facilitent les mises à jour, tandis que les chaînes modifiées restent soumises à révision.
Partagez le format source, les locales cibles, le contexte produit, les captures ou accès de test si pertinent, la date de sortie, les contraintes et le périmètre de QA.
Les sections ci-dessous précisent les décisions, contrôles et relais qui déterminent si la localisation de sites web reste réellement exploitable après traduction. Elles s’adressent aux acheteurs, experts métier et responsables de projet, pas seulement aux linguistes.
La localisation de site doit coordonner langue, parcours, SEO multilingue, CMS, formulaires, données structurées et QA responsive afin que le site localisé fonctionne comme une véritable expérience marché.
Le meilleur workflow traite ces points comme des contrôles explicites et non comme des suppositions.
Localiser l’intention de recherche, titres, descriptions, intertitres, liens internes, données structurées et signaux d’indexation. Un site traduit doit aussi être trouvable sur son marché cible.
Définir comment le contenu sort du CMS, comment les changements sont identifiés, comment les traductions reviennent, qui les approuve et comment les publications sont synchronisées.
Valider formats de date, heure, nombres, devises, adresses, tri, pluriels, genre et saisie pour chaque locale. La qualité de localisation inclut le comportement du produit.
Pour l’arabe et les interfaces de droite à gauche, tester miroir, alignement, texte bidirectionnel, icônes, chiffres, formulaires, tableaux, navigation et ordre de focus dans l’interface réelle.
| Zone de contrôle | Ce qu’un bon contrôle doit garantir |
|---|---|
| Tests appareils et responsive | Vérifier les mises en page traduites sur des appareils et tailles d’écran représentatifs. Expansion, retours à la ligne, troncature, largeur des boutons et zones tactiles peuvent révéler des défauts invisibles dans les fichiers source. |
| Public et usage prévu | Définir qui lira ou utilisera le contenu et ce que cette personne doit pouvoir en faire. Une même source peut exiger des choix différents pour des spécialistes, des clients, des autorités ou le public. |
| Gouvernance terminologique et mémoire de traduction | Traiter glossaires, mémoires, guides de style et références approuvées comme des actifs gouvernés, avec responsables, règles d’approbation, dates de mise à jour et exclusions de réutilisation. |
| États du workflow et approbations | Rendre explicites les états : reçu, préparé, en traduction, en révision, en attente client, contrôle final, livré et approuvé. La visibilité réduit les relances inutiles. |
Avant la production, le responsable du projet doit rendre les points suivants explicites.
Une remise professionnelle doit permettre de comprendre immédiatement ce qui a été livré, ce qui a changé et ce qui reste à valider par le client.
L’objectif n’est pas d’allonger la page, mais de rendre la spécification suffisamment claire pour discuter périmètre, risque, qualité et passation avant production plutôt que de les découvrir après livraison.
Un périmètre utile doit nommer les flux de contenu réellement traités. Cet inventaire évite que le mot « traduction » masque des livrables très différents.
Avant de considérer un projet prioritaire comme terminé, les jalons suivants doivent être vérifiés explicitement.
Cette structure est volontairement plus détaillée qu’une page de service classique. Elle permet de comparer les prestataires sur la conception du workflow plutôt que sur des slogans et donne aux équipes une base concrète pour préparer, réviser et accepter les livrables.
Utilisez la boîte à outils pour cadrer périmètre et acceptation, ou le guide d’intégration pour les workflows connectés.