Qu’est-ce que la pseudo-localisation ?

La pseudo-localisation remplace votre texte source par une variante générée automatiquement qui reste lisible mais manifestement transformée. Vous faites alors tourner l’application dans cette fausse locale et vous l’observez.

Original:      Save changes
Pseudo:        [Šàávè çhàángéés ~~~~~]

Tout ce que vous pouvez encore lire en anglais brut sans accent est une chaîne codée en dur qui n’a jamais été extraite. Tout ce qui est coupé, qui passe à la ligne ou qui déborde est une mise en page qui cassera à l’arrivée des vraies traductions. Les deux se trouvent en une après-midi, avant qu’un centime ne soit dépensé pour la traduction.

Ce que fait la transformation#

Trois procédés distincts, chacun attrapant une catégorie différente de bug.

Accentuer chaque caractère. Save devient Šàávè. Toujours lisible pour un lecteur anglophone, immédiatement distinguable d’un texte non transformé. C’est ce qui fait ressortir les extractions manquées — votre œil saute le texte accentué et se pose sur le mot brut.

Cela exerce aussi le chemin d’encodage de bout en bout. Si un élément de votre stack n’est pas propre en Unicode — une colonne de base de données, un moteur de template, un générateur de PDF, un e-mail — cela se manifeste ici sous forme de caractères mal encodés plutôt qu’en production en polonais.

Remplir la chaîne. Šàávè ~~~~~~ simule l’expansion du texte. L’allemand et le finnois font régulièrement 20 à 30 % de plus que l’anglais, donc un remplissage de 30 à 40 % est le réglage habituel. Tout ce qui se coupe, se tronque avec des points de suspension, passe à la ligne dans une mise en page cassée ou repousse un élément voisin hors écran est un vrai bug que vous venez de trouver gratuitement.

Les chaînes courtes ont besoin de proportionnellement plus de remplissage. Un libellé de trois caractères peut tripler ; un paragraphe grandit rarement de plus d’un tiers.

Mettre la chaîne entre crochets. [Šàávè ~~~~~~] marque les limites. Des crochets manquants signifient que la chaîne a été tronquée quelque part dans le pipeline ; des crochets adjacents comme ][ signifient que deux chaînes ont été concaténées, ce qui est un bug d’internationalisation qui ne survivra à la traduction dans aucune langue à ordre des mots différent.

Certains générateurs ajoutent un quatrième procédé : préfixer chaque chaîne par sa clé, pour voir d’un coup d’œil quelle clé de traduction a produit quel élément d’interface. Précieux quand vous essayez de trouver où vit une chaîne.

Ce qu’elle attrape#

Cette dernière ligne est celle qui surprend le plus. C’est généralement un panneau d’administration, un export PDF, un e-mail transactionnel ou une page d’erreur — des surfaces construites à un autre moment, par une autre personne, qui n’ont jamais traversé la passe d’extraction.

Ce qu’elle n’attrape pas#

Pour être clair sur les limites :

• Rien de linguistique. Elle ne peut pas vous dire qu’une traduction est fausse, maladroite ou offensante.
• Les problèmes de mise en page de droite à gauche. Les pseudo-locales standards restent de gauche à droite. Testez le RTL avec une véritable locale RTL, ou utilisez une pseudo-locale bidirectionnelle dédiée qui inverse le sens du texte.
• Les structures plurielles réellement différentes. Elle ne génère pas les six formes plurielles arabes.
• Les problèmes culturels — imagerie, couleur, iconographie.

C’est une vérification mécanique, et sa valeur vient précisément de là : elle fonctionne de la même façon à chaque fois et ne nécessite aucun linguiste.

La générer#

La plupart des bibliothèques et chaînes d’outils i18n disposent d’un générateur de pseudo-locale, et la transformation est assez simple pour l’écrire soi-même :

ACCENTS = {
  "a" => "àá", "e" => "éè", "i" => "ìí", "o" => "òó", "u" => "ùú",
  "c" => "çĉ", "n" => "ñń", "s" => "šś", "y" => "ýÿ"
}.freeze

def pseudo(text, padding: 0.4)
  # Laisser les placeholders tranquilles — les altérer ne teste rien et casse le rendu.
  parts = text.split(/(%\{[^}]+\}|\{\{[^}]+\}\}|%\d*\$?[sdf@]|\{\d+\})/)
  accented = parts.map.with_index { |part, i|
    i.odd? ? part : part.chars.map { |c| ACCENTS[c.downcase]&.chars&.sample || c }.join
  }.join
  "[#{accented} #{'~' * (text.length * padding).ceil}]"
end

pseudo("Save changes")        # => "[Šàvé çhàñgés ~~~~~]"
pseudo("Hello, %{name}!")     # => "[Héllò, %{name}! ~~~~~~]"

Le détail important est la première ligne de la méthode : ne transformez pas les placeholders. Accentuer %{name} en %{ñàmé} casse l’interpolation et ne teste rien d’utile — vous savez déjà que les placeholders doivent survivre à la traduction, et la fiche des placeholders couvre les syntaxes à protéger.

Soyez déterministe si possible. Des accents échantillonnés au hasard signifient que la même chaîne a un aspect différent à chaque exécution, ce qui rend la comparaison de captures d’écran inutile.

L’intégrer à un projet#

Traitez la pseudo-locale comme une véritable locale afin qu’elle traverse la même machinerie que tout le reste.

Donnez-lui un code de locale. en-XA est une convention largement utilisée (Android et Chrome utilisent en-XA et ar-XB), et qps-ploc est l’équivalent Windows. Les deux se trouvent dans des plages réservées à un usage privé ou non attribuées, donc ni l’une ni l’autre n’entre en collision avec une véritable langue.

Sur WebTranslateIt, il s’agit d’une langue personnalisée : prenez l’anglais comme base et ajoutez un code de suffixe et une description, ce qui donne quelque chose comme en_ploc nommé « English (pseudo) ». Elle apparaît alors à côté de vos véritables langues cibles, avec ses propres fichiers générés automatiquement.

Générez-la, ne la traduisez pas. La pseudo-locale devrait être produite à partir du fichier source actuel par un script, chaque fois que la source change. Si elle dérive, elle arrête d’attraper les nouvelles chaînes — ce qui est précisément sa raison d’être.

Faites-la tourner en CI. Générez la pseudo-locale, démarrez l’application dans cette locale, capturez les principaux flux, et comparez avec l’exécution précédente. Les régressions de mise en page dues à une nouvelle chaîne longue deviennent un build en échec plutôt qu’une découverte en semaine trois de traduction.

Rendez-la facile à activer. Un paramètre de requête ou un élément de menu développeur. Si l’activer nécessite une recompilation, elle ne sera utilisée qu’une fois.

Tester la direction droite-à-gauche séparément#

Une pseudo-locale standard reste de gauche à droite, elle ne vous dit donc rien sur la capacité de votre mise en page à survivre à l’arabe ou à l’hébreu. Cela demande sa propre passe, et il y a deux façons de l’obtenir.

Une pseudo-locale bidirectionnelle enveloppe chaque chaîne dans des caractères Unicode de forçage droite-à-gauche, si bien que le texte s’affiche inversé tout en restant votre propre copy. Android fournit ar-XB exactement pour cela. Elle exerce la mise en page sans nécessiter de traduction.

Une véritable locale RTL avec du vrai texte est le test le plus solide, car elle attrape aussi les cas à direction mixte — un nom de produit anglais à l’intérieur d’une phrase arabe, un numéro de téléphone, un extrait de code — où l’algorithme bidirectionnel produit des résultats qui surprennent les gens.

Ce qu’il faut chercher dans les deux cas : les icônes qui devraient se refléter (flèches de retour, indicateurs de progression) et celles qui ne le devraient pas (lecture multimédia, coches), les marges et remplissages écrits en left/right plutôt qu’en logique start/end, et toute mise en page construite sur un positionnement absolu.

Où elle s’inscrit#

L’enchaînement est tout l’argument en sa faveur :

1. Internationaliser — extraire les chaînes, retirer la concaténation, corriger les formats codés en dur.
2. Pseudo-localiser — prouver que l’étape 1 a réellement fonctionné.
3. Corriger ce qu’elle a trouvé.
4. Envoyer aux traducteurs.

Sauter l’étape 2 n’évite pas le travail. Elle le repousse après que vous avez payé pour la traduction, moment où chaque correction implique de retraduire, et où les rapports de bugs arrivent de relecteurs travaillant dans des langues que personne dans votre équipe ne peut lire.

Une demi-journée de pseudo-localisation est l’investissement qualité le moins coûteux de tout le processus de localisation, et c’est l’étape que les équipes sautent le plus souvent.