Recherche sur le workflow de traduction de produits Shopify par l'IA

Choisissez la voie de traduction nécessaire

Utilisez les outils marchands Shopify lorsqu'un éditeur peut gérer directement les traductions. Utilisez l'Admin API GraphQL lorsque vous avez besoin d'une file de revue externe récurrente et qu'un développeur peut maintenir l'application. Dans la voie API, un client de modèle distinct rédige le texte tandis que Shopify gère les traductions stockées.

Commencez avec une boutique de développement et un produit. Lisez ses champs traduisibles, préparez une candidate, obtenez la revue et ne soumettez qu'ensuite les changements prévus. Gardez séparés les paramètres du modèle, les identifiants boutique et les permissions de publication afin que chaque étape puisse être inspectée et corrigée indépendamment.

Choisissez un workflow marchand ou une application

La documentation Shopify de Translate & Adapt décrit l'édition manuelle et la traduction automatique, avec une revue avant publication. Cela peut suffire lorsque le marchand veut un contrôle éditorial direct sans construire d'application. Une intégration personnalisée n'a de sens que lorsqu'une exigence précise, comme une file de revue externe, justifie la responsabilité du connecteur.

Choisissez selon la personne qui maintiendra la file de revue et le mapping des champs. Pour une application tierce, inspectez sa configuration documentée, ses permissions et son comportement d'export avant installation. Un éditeur destiné au marchand et une application avec rédaction par modèle externe répondent à des besoins opérationnels différents.

Planifiez les limites d'authentification et de version

La référence translatableResource exige read_translations ; translationsRegister exige write_translations. Utilisez une boutique de développement et enregistrez l'installation de l'application, la version d'API et les scopes accordés lors du test. Un identifiant de passerelle LLM n'authentifie pas une requête Shopify Admin API et un token Shopify ne doit pas être envoyé à l'endpoint du modèle.

Commencez par un accès en lecture pour la découverte lorsque la conception de l'application le permet. N'ajoutez que les permissions nécessaires au workflow autorisé ultérieur. Figez une version d'API prise en charge après lecture de sa référence au lieu de déployer vers un alias latest non enregistré. Gardez les tokens côté serveur et excluez-les des exports de revue et des journaux de requêtes.

Lisez les champs traduisibles avec leurs digests

La requête documentée renvoie un identifiant de ressource et des entrées traduisibles avec une clé, une valeur, un digest et une locale. Conservez ces digests propres à chaque champ avec l'instantané source. Ils relient une traduction proposée au contenu réellement lu, plutôt qu'à un titre produit copié depuis un tableur.

La requête ci-dessous est adaptée du schéma officiel comme exemple en lecture seule. Fournissez un GID produit autorisé dans un environnement de développement. Inspectez les clés renvoyées et utilisez une allowlist explicite de champs ; utilisez la locale source renvoyée au lieu de la déduire de la langue du navigateur.

query TranslationSource($resourceId: ID!) {
  translatableResource(resourceId: $resourceId) {
    resourceId
    translatableContent {
      key
      value
      digest
      locale
    }
  }
}

Générez une candidate de traduction en dehors de Shopify

Construisez un enregistrement candidat interne contenant l'ID de ressource, la clé de champ, le digest source, la locale cible, la révision du glossaire et la valeur brouillon. N'envoyez au modèle que le texte et le contexte produit nécessaire. Gardez le SKU, le prix, la devise, l'inventaire et l'identité de variante hors du patch généré.

Validez le texte requis, les placeholders et la terminologie approuvée avant de montrer la candidate à un relecteur bilingue. Demandez à un relecteur produit de contrôler les affirmations et avertissements par rapport à la source originale. Une extension navigateur qui traduit la boutique ne crée pas cet enregistrement et n'établit pas que Shopify a stocké une traduction ; elle sert uniquement d'aide à l'inspection.

Enregistrez uniquement les traductions approuvées et actuelles

La mutation translationsRegister accepte des champs traduits avec translatableContentDigest. Son résultat documenté comprend userErrors. Un connecteur doit inspecter ce résultat au lieu de traiter une réponse HTTP seule comme preuve d'un enregistrement réussi.

Avant une écriture autorisée, comparez la source actuelle à l'instantané relu. Si elle a changé, maintenez la candidate en attente et obtenez une nouvelle revue. Gardez une liste explicite des changements de champs prévus et des traductions précédentes pour la récupération. Commencez par un seul champ dans la boutique de développement et relisez-le avant d'étendre le patch.

Vérifiez séparément la boutique

La traduction stockée et sa disponibilité dans la boutique sont deux contrôles distincts dans le workflow Shopify documenté. Planifiez la configuration de la locale et les contrôles du thème avec le marchand. Enregistrer une valeur traduite ne doit pas autoriser automatiquement la publication d'une langue ni la modification des paramètres de marché.

Dans la boutique de développement, inspectez le produit cible, le sélecteur de locale, le contenu de fallback, les liens et les libellés de variantes. Relisez la traduction stockée et comparez-la à la valeur approuvée. Si un champ manque, étudiez la prise en charge de la ressource ou le rendu du thème avant de générer une autre traduction. Conservez les observations sans présenter une boutique de développement comme une réussite marchande en production.

Preuves et limites du connecteur

Les références officielles établissent les interfaces de traduction Shopify. Une application connectée à APIsRouter n'a pas été testée ici et les sources examinées n'établissent pas de paramètre baseURL de passerelle arbitraire dans Shopify ou Translate & Adapt. Traitez le chemin d'application personnalisée comme une recherche de connecteur jusqu'à l'obtention d'un résultat dans une boutique de développement.

Pour un test complet, conservez la version de l'application, l'enregistrement d'authentification limité, la requête source, la candidate, l'approbation, le résultat d'enregistrement et la comparaison de relecture. Incluez un conflit dû à un changement de source et une requête rejetée. Enregistrez séparément l'identité du modèle et l'utilisation par rapport aux opérations boutique afin que l'affirmation de compatibilité ait un périmètre clair.

Questions fréquentes