Workflow de localisation du catalogue produit

Figez la source avant de traduire

Exportez le catalogue et conservez un instantané source immuable. Enregistrez son origine, son heure d'export et sa révision ou son hash de fichier. Attribuez à chaque variante une identité stable et contrôlez les identifiants manquants ou en double avant de créer les tâches linguistiques. Gardez un manifeste des paires produit-locale que vous comptez traiter.

Séparez la préparation de la source de la traduction. Résolvez d'abord avec le responsable produit les mesures contradictoires, les unités manquantes et les affirmations non étayées. La normalisation d'un export fournisseur peut être nécessaire ; enregistrez ces corrections comme des changements de source et faites approuver la base obtenue avant le début du travail linguistique.

Séparez les faits protégés du texte modifiable

Créez un enregistrement protégé pour le SKU, le prix, la devise, l'unité, la relation de variante et les autres valeurs opérationnelles. Générez uniquement un patch de texte. Lors de l'assemblage, recopiez directement les valeurs protégées depuis la source et comparez-les encore une fois, afin qu'un modèle ne puisse pas devenir l'autorité d'un champ qu'il n'a fait que voir comme contexte.

Rendez aussi les affirmations traçables. Reliez les assertions approuvées à leurs preuves et demandez à l'étape de rédaction de signaler tout élément non étayé. La configuration suivante est une politique de pipeline illustrative, et non un fichier accepté par Shopify ou WooCommerce. Votre adaptateur doit la mapper au contrat réel de la destination.

{
  "identity": ["product_id", "variant_id", "locale"],
  "protected": ["sku", "price_minor", "currency", "unit", "parent_id"],
  "editable": ["title", "description", "care_text"],
  "revisionInputs": ["source", "glossary", "prompt"],
  "releaseRequires": ["field_checks", "fact_review", "language_review"],
  "destinationWrite": "separate_authorization"
}

Joignez un glossaire et un brief de locale

Un brief de locale doit identifier le public, le ton, la terminologie approuvée et les règles de présentation. Gardez les concepts produit séparés des orthographes préférées. W3C ITS définit une terminologie et des métadonnées de traduction pouvant informer un système de localisation plus riche ; ce workflow utilise un enregistrement éditorial versionné plus simple.

Résolvez les termes ambigus avec des exemples de la catégorie réelle. Si une entrée du glossaire change, identifiez les candidates affectées et décidez si elles nécessitent une régénération ou une modification ciblée. Gardez chaque locale liée à la même source approuvée. Ne laissez pas une version traduite devenir une source intermédiaire non relue pour toutes les autres.

Cas local : 20 produits, 40 patches linguistiques

Un catalogue gelé de 20 produits synthétiques a été traduit en 20 patches japonais et 20 patches allemands par un agent de traduction explicitement configuré pour gpt-5.6-luna avec un raisonnement xhigh. Chaque patch ne contient que sku, locale, title et description. L'assembleur recopie le prix, la devise, le matériau et les dimensions depuis source.json ; la préservation de ces faits est donc une propriété du pipeline, et non une tâche de copie déléguée au modèle.

Les fichiers sauvegardés validated-ja.json et validated-de.json contiennent chacun 20 lignes et une liste failures vide. Une ré-assemblage en lecture seule correspond aux deux sorties sauvegardées. Utilisez ce modèle dans votre propre lot : conservez la révision source, sauvegardez séparément les patches linguistiques et validez la couverture et les champs autorisés avant d'assembler le paquet de revue.

Exécutez les contrôles déterministes avant la revue éditoriale

Validez le schéma de sortie, les champs autorisés, le mapping des identifiants, la révision de source, le texte requis et les valeurs protégées. Comparez le nombre de placeholders avec la vraie grammaire de template de l'application. Analysez le markup au lieu d'appliquer une substitution textuelle générale au HTML. Maintenez les enregistrements mal formés en attente au lieu de demander à l'importateur de les réparer.

Pour les fichiers de revue tableur, OWASP documente les risques d'injection de formules et l'absence de transformation CSV universellement sûre. Utilisez une politique d'export relue pour l'outil tableur choisi et gardez cet artefact distinct de l'import machine. L'ajout d'un préfixe d'échappement pour l'affichage humain ne doit pas modifier accidentellement un SKU dans la charge utile de la boutique.

Liez les décisions de revue aux révisions du contenu

Donnez aux relecteurs les faits sources, le contexte du glossaire, la candidate et les problèmes structurés. Exigez séparément les décisions factuelles et linguistiques. Enregistrez qui a approuvé le contenu et quelles révisions ont été vues. Un relecteur peut accepter une expression localisée tout en maintenant une affirmation qui nécessite des preuves ; l'enregistrement doit exprimer cette distinction.

Dans le cas local, la revue IA a corrigé DEMO-003 japonais, en remplaçant une formulation impliquant du carton ondulé par une formulation conforme au support en carton indiqué par la source. Elle a aussi précisé DEMO-010 pour signifier deux poignées au total. La sortie originale reste dans raw-ja.json. Les deux langues assemblées portent encore review_status: unreviewed et translation_semantic_review: pending : ces corrections ne constituent ni une approbation par locuteur natif ni une approbation marchande.

Assemblez et vérifiez le paquet de destination

Sélectionnez les candidates approuvées et actuelles par rapport à la source et ne transformez que leurs champs autorisés. L'API de traduction de Shopify utilise son contrat de ressource et de digest ; un déploiement WooCommerce exige son mapping produit et, pour plusieurs langues, la couche de localisation vérifiée. Le paquet de revue générique n'est pas en lui-même un import universel de boutique.

Testez un petit import autorisé en staging. Enregistrez le résultat de l'importateur, relisez les champs ciblés et inspectez le comportement du produit et de la locale. Rapprochez l'ensemble de produits prévu des résultats stockés. Gardez les lignes échouées séparées et préservez les valeurs précédentes pour une annulation soigneusement délimitée si nécessaire.

Enregistrez le résultat et ses limites

Le manifeste terminé doit relier la source, le glossaire, les prompts, les candidates, les contrôles, les approbations et les résultats de destination. Enregistrez l'utilisation réelle de chaque tentative lorsque des preuves sont disponibles, y compris les nouvelles tentatives. Gardez explicitement inconnus l'utilisation manquante et les résultats de revue manquants. Un fichier analysable ne prouve pas qu'une boutique l'a accepté.

Pour le cas local délimité, le modèle sélectionné était Luna, et non Astra, et il n'y a eu ni appel de passerelle ni import réel en boutique. L'utilisation API, les IDs de requête et la facturation n'étaient pas exposés ; model_api_usage et model_api_cost restent null, et non zéro. L'étape suivante est l'approbation sémantique, suivie d'un test de destination autorisé séparément.

Questions fréquentes