{name} dans la copie de traduction est perdu, comment l'arrêter avant de se connecter

Dans la copie traduite, les variables telles que {name} sont souvent traduites ensemble, et la page ne signale souvent pas d'erreur tant que la valeur n'est pas effectivement renseignée. Si vous comptez uniquement sur des yeux humains ou des expressions régulières pour vérifier les accolades avant de vous connecter, il est facile de les manquer. Cet article est destiné aux développeurs et éditeurs responsables de la localisation, des modèles et des contrôles de livraison. Il présente comment utiliser la bibliothèque standard Python string.Formatter.parse pour effectuer une vérification structurée sur les espaces réservés et explique quelles situations nécessitent encore une révision manuelle.

Après lecture, vous pouvez avoir une idée de vérification qui peut être exécutée directement : vérifiez l'identité du champ, la fréquence des occurrences et les spécifications de format lorsque la traduction est livrée, au lieu d'attendre que le problème soit découvert en ligne. Les exemples utilisent des échantillons synthétiques et le code a été vérifié dans un environnement isolé, mais cela ne représente pas une garantie de tous les fichiers réels ou des performances du produit. Avant de traiter des documents importants, veuillez conserver les originaux et les examiner en fonction des limites et des éléments d'acceptation ci-dessous.

Espaces réservés perdus après la traduction ? Conclusion en une phrase

Tout d'abord, utilisez l'analyse structurée pour extraire les champs de la chaîne de format, puis comparez-les un par un avec les champs de la copie source ; si les noms de champs, les heures d'occurrence ou les spécifications de format sont incohérents, ils seront directement rejetés et l'ajustement de l'ordre des mots sera laissé à une révision manuelle.

Sélectionnez d'abord la syntaxe du format

Cet article ne traite que des espaces réservés de style Python str.format et ne couvre pas les chaînes de modèles JavaScript, ICU MessageFormat ou d'autres systèmes d'espaces réservés. Différents systèmes ont des règles d'imbrication, d'échappement et de pluralisation très différentes, et une expression régulière ne peut pas prétendre les prendre toutes en charge. L'exemple nécessite l'utilisation de champs nommés et rejette les champs numérotés automatiquement (tels que {}).

Une description complète de la syntaxe des champs peut être trouvée dans Documentation sur les chaînes Python et le formateur.

Les accolades échappées ne sont pas des variables

{{name}} représente le texte affiché {name} et ne doit pas être compté comme un champ. Il peut également y avoir des champs imbriqués dans la spécification de format, tels que {value:{width}}. Le code ci-dessous lit la spécification de manière récursive et compte les occurrences répétées du même champ.

from string import Formatter
from collections import Counter

def contract(text, depth=0):
    if depth > 5:
        raise ValueError("nested format budget")
    result = Counter()
    for literal, field, spec, conversion in Formatter().parse(text):
        if field is None:
            continue
        if not field or field != field.strip():
            raise ValueError("named field without surrounding whitespace required")
        result[(field, conversion, spec)] += 1
        if spec:
            result.update(contract(spec, depth + 1))
    return result

assert contract("Hi {name}, total {amount:.2f}") == contract("{name}：金额 {amount:.2f}")
assert contract("{{name}}") == Counter()
assert contract("{name} {name}") != contract("{name}")
assert contract("{value:{width}}")[("width", None, "")] == 1
assert contract("{amount:.2f}") != contract("{amount:.0f}")
for bad in ["Hi {name", "{ name}", "{}"]:
    try:
        contract(bad)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid template accepted")

Ce contrat est volontairement strict

Les spécifications de format sont également considérées ici comme du contenu protégé, donc la modification du nombre de décimales sera signalée. Certaines tâches de localisation nécessitent de modifier la façon dont les nombres sont présentés, auquel cas vous devez créer une règle distincte pour cela plutôt que d'annuler toutes les vérifications d'espaces réservés. La limite de profondeur d'imbrication dans l'exemple est un budget de démonstration et n'est pas une exigence de la spécification du langage.

Le tableau suivant répertorie plusieurs types courants de modifications et leurs méthodes de traitement correspondantes :

📊 Comparaison des noyaux

🎯 Quelle méthode te convient ?

Si vous êtes responsable de la livraison de la traduction

Avant la livraison, effectuez une vérification de structure pour retourner les entrées rejetées au traducteur et joindre les noms de champs manquants ou modifiés.

Si vous êtes responsable des modèles et interfaces

Précisez clairement quels noms de champs appartiennent au contrat d’interface et listez-les dans les notes de livraison pour faciliter la comparaison entre traducteurs et relecteurs.

Si tu dois changer la façon dont les chiffres sont présentés

Établissez un protocole de localisation séparé pour la spécification du format, puis ajoutez-le à la règle de validation, plutôt que de fermer la vérification globale.

❓ Foire aux questions (FAQ)

1. Cette méthode peut-elle gérer des modèles JavaScript ou un format de messages en soins intensifs ?

Non. Cet article ne traite que des champs nommés dans le style Python str.format ; les règles d’imbriquement, d’évasion et de pluriel dans d’autres systèmes doivent être traitées séparément.

2. {{name}} sera-t-il vérifié en tant que variable ?

Non. Il représente le texte d’affichage {name}, qui n’est pas compté comme un champ lorsqu’il est analysé.

3. Si vous ajustez simplement la position du champ dans la phrase, cela sera-t-il rejeté ?

Non. Les changements de position du champ sont acceptés dans cet exemple, puis lis manuellement si l’ordre des mots est naturel.

4. Peut-on contacter directement format pour vérifier la traduction ?

Le code de cet article est uniquement analysé et n’appelle pas réellement format pour remplir des objets ; il ne s’agit pas d’un bac à sable de sécurité de modèles. Le rendu ultérieur doit également restreindre les champs disponibles, l’accès aux objets et le contexte de sortie, en particulier les règles d’échappement dans les pages HTML.

📝 Résumé

Lors de la réalisation de traductions, l’utilisation d’une analyse syntaxique structurée pour vérifier les placeholders peut éviter des problèmes de noms de champs, de comptages et de spécifications de mise en forme avant la mise en ligne. La maîtrise de la langue nécessite encore un jugement supplémentaire de la part des correcteurs.

Faites l’expérience dès maintenant : téléchargez votre document pour commencer à traduire, tout en conservant la mise en forme originale