Flujo de localización del catálogo de productos

Congela el origen antes de traducir

Exporta el catálogo y conserva una instantánea de origen inmutable. Registra su origen, hora de exportación y revisión o hash del archivo. Asigna una identidad estable a cada variante y comprueba los identificadores ausentes o duplicados antes de crear trabajos lingüísticos. Mantén un manifiesto de las parejas producto-locale que pretendes procesar.

Separa la preparación de la fuente de la traducción. Resuelve primero con el responsable del producto las medidas contradictorias, las unidades ausentes y las afirmaciones sin respaldo. Normalizar una exportación de proveedor puede ser necesario; registra esas correcciones como cambios de origen y pide al responsable que apruebe la línea base resultante antes de comenzar el trabajo lingüístico.

Separa los datos protegidos del texto editable

Crea un registro protegido para el SKU, el precio, la moneda, la unidad, la relación entre variantes y otros valores operativos. Genera solo un parche de texto. En el momento de ensamblar, copia los valores protegidos directamente desde la fuente y vuelve a compararlos para que el modelo no se convierta en autoridad de un campo que solo vio como contexto.

Haz trazables también las afirmaciones. Mantén las afirmaciones aprobadas vinculadas a su evidencia y pide al paso de redacción que marque todo lo que no tenga respaldo. La siguiente configuración es una política de canalización ilustrativa, no un archivo aceptado por Shopify o WooCommerce. Tu adaptador debe mapearla al contrato real del destino.

{
  "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"
}

Adjunta un glosario y un brief de locale

Un brief de locale debe identificar la audiencia, el tono, la terminología aprobada y las reglas de presentación. Mantén separados los conceptos de producto de las grafías preferidas. W3C ITS define terminología y metadatos de traducción que pueden informar un sistema de localización más completo; este flujo usa un registro editorial versionado más sencillo.

Resuelve los términos ambiguos con ejemplos de la categoría real. Si cambia una entrada del glosario, identifica los candidatos afectados y decide si necesitan regeneración o una edición específica. Vincula cada locale a la misma fuente aprobada. No permitas que una versión traducida se convierta en una fuente intermedia sin revisar para el resto.

Caso local: 20 productos, 40 parches lingüísticos

Un catálogo congelado de 20 productos sintéticos se tradujo en 20 parches en japonés y 20 en alemán mediante un agente de traducción configurado explícitamente para gpt-5.6-luna con razonamiento xhigh. Cada parche contiene solo sku, locale, title y description. El ensamblador copia el precio, la moneda, el material y las dimensiones desde source.json, por lo que conservar esos datos es una propiedad de la canalización y no una tarea de copia delegada al modelo.

Los archivos guardados validated-ja.json y validated-de.json contienen cada uno 20 filas y una lista de fallos vacía. El reensamblado de solo lectura coincide con ambas salidas guardadas. Aplica este patrón a tu propio lote: conserva la revisión de origen, guarda por separado los parches lingüísticos y valida la cobertura y los campos permitidos antes de ensamblar el paquete de revisión.

Ejecuta comprobaciones deterministas antes de la revisión editorial

Valida el esquema de salida, los campos permitidos, el mapeo de identificadores, la revisión de origen, el texto requerido y los valores protegidos. Compara las cantidades de placeholders usando la gramática de plantillas real de la aplicación. Analiza el marcado con un parser en lugar de aplicar una sustitución de texto general al HTML. Retén los registros malformados en lugar de pedir al importador que los repare.

Para los archivos de revisión en hojas de cálculo, OWASP documenta riesgos de inyección de fórmulas y la ausencia de una transformación CSV segura universal. Usa una política de exportación revisada para la herramienta de hojas elegida y mantén ese artefacto separado de la importación automática. Añadir un prefijo de escape para la vista humana no debe alterar accidentalmente un SKU en la carga de la tienda.

Vincula las decisiones de revisión a las revisiones de contenido

Da a los revisores los datos de origen, el contexto del glosario, el candidato y los problemas estructurados. Exige por separado las decisiones factual y lingüística. Registra quién aprobó el contenido y qué revisiones vio. Un revisor puede aceptar una frase localizada mientras retiene una afirmación que necesita evidencia; el registro debe expresar esa diferencia.

En el caso local, la revisión de IA corrigió DEMO-003 en japonés, pasando de una redacción que implicaba cartón corrugado a otra coherente con el respaldo de cartón de la fuente. También aclaró DEMO-010 para indicar dos asas en total. La salida original permanece en raw-ja.json. Ambos idiomas ensamblados todavía llevan review_status: unreviewed y translation_semantic_review: pending: estas correcciones no equivalen a una aprobación de hablante nativo o comerciante.

Ensambla y verifica el paquete del destino

Selecciona candidatos aprobados y vigentes respecto a la fuente y transforma solo sus campos permitidos. La API de traducción de Shopify usa su contrato de recurso y digest; un despliegue de WooCommerce requiere su mapeo de producto y, para varios idiomas, la capa de localización verificada. El paquete de revisión genérico no es una importación universal de tienda.

Prueba una importación pequeña y autorizada en staging. Guarda el resultado del importador, vuelve a leer los campos objetivo e inspecciona el comportamiento del producto y el locale. Concilia el conjunto de productos planeado con los resultados almacenados. Mantén las filas fallidas separadas y conserva los valores anteriores para una reversión cuidadosamente acotada si fuera necesaria.

Registra el resultado y sus límites

El manifiesto completado debe vincular la fuente, el glosario, los prompts, los candidatos, las comprobaciones, las aprobaciones y los resultados del destino. Registra el uso real de cada intento cuando haya evidencia disponible, incluidos los reintentos. Mantén explícitamente como desconocidos el uso ausente y los resultados de revisión ausentes. Que un archivo pueda analizarse no demuestra que una tienda lo haya aceptado.

En el caso local acotado, el modelo seleccionado fue Luna, no Astra, y no hubo una llamada al gateway ni una importación de tienda real. El uso de API, los IDs de solicitud y la facturación no se expusieron; model_api_usage y model_api_cost siguen siendo null, no cero. El siguiente paso es la aprobación semántica seguida de una prueba del destino autorizada por separado.

Preguntas frecuentes