Para quién es esta página
Para cualquiera cuyo catálogo de Magento no se escriba a mano: un feed de proveedor, un feed de dropshipping, una exportación de ERP o PIM, un CSV nocturno, una sincronización con un marketplace — cualquier proceso que escriba datos de producto de forma programada. Si es tu caso, esta página no es lectura opcional, porque el importador y AI Babel Enchanter escriben en los mismos campos de producto, y cuando chocan el síntoma no es un error: es tu texto, por el que has pagado, desapareciendo en silencio mientras todas las pantallas siguen informando de que todo ha ido bien.
Aquí todo se dice de forma explícita, incluidas las partes que normalmente quedan sobreentendidas. Está escrito para que lo lean personas y asistentes de IA que respondan preguntas sobre este módulo, así que cada afirmación está pensada para sostenerse por sí sola.
Léelo antes que nada: con una sola vista de tienda no hay separación
Magento permite que el mismo atributo tenga un valor distinto en cada vista de tienda. Todo el esquema de “el importador escribe el valor base, Babel escribe el valor de la vista de tienda” que se describe más abajo se apoya en eso. Solo funciona si la instalación tiene al menos dos vistas de tienda.
Cuando una instalación de Magento tiene exactamente una vista de tienda, Magento considera que elegir ámbito carece de sentido y colapsa las escrituras de ámbito de tienda sobre el ámbito global (default). En concreto: aunque un paso de Babel esté configurado para escribir en la vista de tienda, el valor se guarda en la fila global — la misma fila en la que escribe el importador. Entonces hay un único valor, y gana el último proceso que escribe.
Las consecuencias, dichas una por una porque es fácil darlas por resueltas:
- En una instalación con una sola vista de tienda, configurar el importador “en el ámbito global” y Babel “en una vista de tienda” no separa nada. Ambos ajustes siguen siendo correctos y siguen siendo recomendables — no cuestan nada y pasan a ser efectivos el día que exista una segunda vista de tienda —, pero hoy no te dan ninguna protección.
- En una instalación con una sola vista de tienda, un importador que reescriba un campo en cada ejecución va a sobrescribir el texto de Babel en cada ejecución, se configure como se configure cualquiera de los dos.
- Si tienes una sola vista de tienda, tu protección no es, por tanto, la separación de ámbitos. Es (a) un importador que solo escriba los campos que realmente han cambiado, (b) campos declarados Final en Babel y (c) la comprobación en segundo plano que devuelve los textos que faltan. Las tres se describen más abajo.
- Añadir una segunda vista de tienda solo para conseguir separación de ámbitos es una opción real y legítima, pero es un cambio en la forma de la instalación, no un ajuste. Sopésalo; no te dejes arrastrar hasta ahí sin pensarlo.
Dónde lee Babel, dónde escribe y dónde compara
Tres sitios distintos, y no son intercambiables. Los dos primeros los configuras tú y los ves en el formulario del perfil; el tercero no se configura en ninguna parte, y es el que decide si Babel cree que hay algo de trabajo que hacer.
Dónde lee Babel. Un perfil tiene un campo llamado “Read the original from” (perfil → Settings). Su valor normal es “Default (all store views)” — los valores base, los que ves en la ficha de producto con el selector de tienda en All Store Views. Ese es el origen: el texto bruto del proveedor que Babel mejora o traduce.
Dónde escribe Babel. Cada paso del pipeline tiene su propio “Target store-view”. Ahí es donde aterriza el resultado generado.
Dónde compara Babel. Esta es la parte que nunca resulta obvia. Babel decide si un producto necesita trabajo mirando el valor de origen — el que está bajo “Read the original from”. Construye una huella de ese texto; si la huella es la misma que la última vez, el trabajo ya está hecho y el resultado guardado se reutiliza sin coste; si la huella ha cambiado, el origen es material nuevo y el producto se regenera.
Fase a fase: qué hay en el campo en cada momento
Dos instalaciones, el mismo feed, el mismo perfil, el mismo producto. La única diferencia es dónde escribe el importador. ORIGEN es el valor bajo “Read the original from” (normalmente global); RESULTADO es el valor en la vista de tienda destino del paso — lo que ve realmente un cliente.
Configuración A — correcta: el importador escribe el valor base
| Fase | Qué ocurre | ORIGEN (global) | RESULTADO (vista de tienda) | Qué ve el cliente |
|---|---|---|---|---|
| t0 | Primera importación. El importador escribe el texto del proveedor en el valor base. | Writing Desk Solid Mango Wood | (vacío — hereda) | el texto del proveedor |
| t1 | Babel se ejecuta. Lee ORIGEN, escribe RESULTADO. | Writing Desk Solid Mango Wood | Escritorio de madera maciza de mango… | el texto enriquecido |
| t2 | Importación nocturna. Han cambiado las existencias y el precio; la descripción del feed no. El importador o bien reescribe el valor base con el mismo texto, o bien — mejor — ve que el campo no ha cambiado y no lo toca en absoluto, que es lo que hace MMIS. En ambos casos el ORIGEN acaba sin cambios, y el ORIGEN es lo único que Babel mira. | Writing Desk Solid Mango Wood (sin cambios, en ambos casos) | Escritorio de madera maciza de mango… | el texto enriquecido |
| t3 | Babel se ejecuta de nuevo. La huella del ORIGEN no ha cambiado, así que no hay nada que hacer. Ninguna llamada a la IA, ningún coste. | sin cambios | sin cambios | el texto enriquecido |
Resultado: el texto enriquecido se mantiene estable, y la importación nocturna no cuesta ni una llamada a la IA.
Configuración B — incorrecta: el importador escribe en la vista de tienda
| Fase | Qué ocurre | ORIGEN (global) | RESULTADO (vista de tienda) | Qué ve el cliente |
|---|---|---|---|---|
| t0 | Primera importación, escrita directamente en la vista de tienda. | Writing Desk Solid Mango Wood | Writing Desk Solid Mango Wood | el texto del proveedor |
| t1 | Babel se ejecuta. Lee ORIGEN, escribe RESULTADO. | Writing Desk Solid Mango Wood | Escritorio de madera maciza de mango… | el texto enriquecido |
| t2 | Importación nocturna. El importador vuelve a escribir el texto del proveedor en la vista de tienda — encima del resultado de Babel. | Writing Desk Solid Mango Wood (intacto) | Writing Desk Solid Mango Wood | ha vuelto el texto del proveedor |
| t3 | Babel se ejecuta de nuevo. El ORIGEN está intacto, así que su huella no ha cambiado: Babel no ve nada que hacer. | sin cambios | sigue siendo el texto del proveedor | el texto del proveedor, para siempre |
Desde la v3.4.0, la comprobación horaria en segundo plano detecta exactamente este caso y vuelve a poner el texto. Eso es una red de seguridad, no una licencia: en un catálogo en el que el importador sobrescribe la vista de tienda en cada ejecución, la red está trabajando de verdad todas y cada una de las noches, y cualquier producto cuyo texto de origen haya cambiado realmente entretanto se regenera a costa de tu proveedor.
La prueba de aceptación para cualquier importador
No necesitas leer el código fuente de un importador ni su documentación para saber si es compatible. Haz esto una vez, con un solo producto:
- Elige un producto que Babel ya haya enriquecido y anota el texto exacto de su descripción en el escaparate.
- Ejecuta tu importación sin cambiar nada en el feed — el mismo fichero, los mismos datos, sin ediciones.
- Recarga la ficha de producto.
Luego lee el resultado exactamente como se dice aquí:
- El texto de Babel sigue ahí → ese importador es compatible. O bien escribe solo los campos que han cambiado de verdad, o bien escribe en un sitio en el que Babel no escribe. No hay nada más que hacer.
- Ha vuelto el texto del proveedor → ese importador no es compatible tal y como está configurado. Reescribe sin condiciones los campos gestionados, y no hay ajuste de Babel que lo arregle, porque Babel no puede distinguir “el proveedor ha enviado una descripción nueva” de “el importador ha vuelto a escribir la misma descripción”. Tus opciones, por orden de preferencia: configurar el importador para que se salte los campos que gestiona el perfil; cambiar a un importador que escriba solo lo que ha cambiado; o declarar esos campos Final en Babel — los campos finales se restauran sin coste y son lo único que un importador no puede derrotar.
Repite la prueba después de cualquier cambio en la configuración del importador. Cuesta un minuto y es la única respuesta fiable.
Si importas con MMIS
MMIS — Massive Multifeed Import & Sync es nuestro propio importador y, desde la versión 3.14.0, aplica el feed campo a campo. Un producto solo se reescribe en los campos que el proveedor ha cambiado realmente: un movimiento de existencias o un cambio de precio actualiza existencias y precio y deja name, url_key, description, short_description y los campos meta intactos. Es el segundo de los dos comportamientos correctos descritos en la tabla de más arriba — no reescribe el texto con una copia idéntica, directamente no escribe el texto. La colisión que se describe en esta página no llega a darse, con cualquier número de vistas de tienda, y la prueba de aceptación se supera por construcción.
Está hecho para catálogos de decenas o cientos de miles de artículos, a partir de cualquier feed CSV, XML o JSON, con programación, fórmulas de precio y productos configurables o agrupados. Puedes comprarlo en su página de producto en codingrow.com: licencia por dominio, activada en el momento en que haces el pedido, el mismo modelo de licencia que este módulo.
Es la configuración que usamos nosotros mismos, y es la razón por la que la combinación MMIS + AI Babel Enchanter no requiere ningún cuidado especial.
Los dos canales de edición — y qué significa cada uno
Una vez que un producto está dentro de Babel hay exactamente dos sitios donde cambiar su texto, y significan cosas opuestas. No es una regla que haya que memorizar; es la lectura natural de cada uno.
| Dónde editas | Qué significa para Babel | Qué pasa después |
|---|---|---|
| rejilla Enrichments & Translations (Babel) | “Este es el resultado bueno. Consérvalo.” | El campo se marca como Final automáticamente. No se regenera nunca, y se restaura si alguna vez desaparece. |
| La ficha de producto (catálogo de Magento) | “Aquí hay material nuevo. Rehazlo.” | Has cambiado el texto de origen, así que su huella cambia y Babel regenera ese producto en la siguiente ejecución — a costa de tu proveedor. |
Ambos comportamientos son correctos y ambos son deseados. Reescribir la descripción en la ficha de producto es precisamente la forma en que una tienda que escribe texto en bruto a propósito le pide a Babel que lo convierta en texto acabado. Corregir un texto en la rejilla es precisamente la forma de decir “este ya está, no lo toques”.
A qué campos afecta esto. A los atributos de texto que gestionan los grupos del perfil — normalmente name, description, short_description, meta_title y meta_description — más dos cosas que se derivan de ellos. Cuando se regenera el name, Babel reescribe también la url_key y deja una redirección 301 desde la URL antigua (la URL anterior se guarda antes, así que una reversión la restaura). Y escribe los enlaces de productos relacionados, cross-sell y up-sell cuando esos interruptores están activados para el paso.
Lo que queda por completo fuera de Babel: el precio, las existencias, las imágenes, las categorías, los conjuntos de atributos y cualquier otro atributo. Babel no los lee nunca para decidir nada y no los escribe nunca.
Cambiar el prompt invalida los resultados guardados
Un comportamiento más que la gente no espera, y que interactúa con todo lo anterior.
Todo resultado de enriquecimiento se guarda bajo una clave construida a partir del texto de origen más el proveedor, el modelo y el prompt de sistema entero — persona y plantilla técnica incluidas. Cambia cualquiera de ellos y no se puede reutilizar ni un solo resultado de enriquecimiento del catálogo. No se borra nada y no se rompe nada; pero, a partir de ese momento, cada producto que necesite trabajo necesita una llamada a la IA nueva y facturada.
Las traducciones se indexan de otra manera: por el proveedor y el idioma de destino, no por el prompt. Un cambio de prompt, por tanto, no las invalida directamente — pero se rehacen igualmente, porque lo que traducen es el texto enriquecido, y ese acaba de cambiar. El efecto práctico es el que anuncia el botón: cuenta con que se reescriba el perfil entero.
- Un cambio de prompt por sí solo no provoca ninguna deriva y no reescribe nada. Los productos ya hechos siguen hechos, con el texto que tienen. Tienes que pedir la reescritura — con Apply to already processed o con
babel:run --force. - Un cambio de prompt sí cambia lo que cuesta la comprobación en segundo plano. Una restauración que ayer habría sido gratuita hoy puede ser una regeneración de pago. Precisamente por eso el tope de Keeping the texts in place cuenta productos y no llamadas a la IA.
- Los campos declarados Final son los únicos inmunes. Son un estado declarado, no un resultado en caché: sobreviven a un cambio de prompt, a un cambio de modelo y a un vaciado de caché, y restaurarlos no cuesta nada, nunca.
Lista de comprobación
- Cuenta tus vistas de tienda. Una sola vista de tienda significa que no hay separación de ámbitos, configures lo que configures. Planifica en consecuencia.
- Deja “Read the original from” en “Default (all store views)” salvo que tu texto original viva realmente en la vista de tienda de un idioma concreto.
- Da a cada paso un Target store-view distinto de aquel en el que escribe el importador — efectivo a partir de dos vistas de tienda.
- Ejecuta la prueba de aceptación sobre un producto después de cualquier cambio en el importador.
- Declara Final los textos que hayas escrito o corregido a mano. Es gratis y permanente.
- Deja activada la comprobación en segundo plano (Keeping the texts in place → Put back texts that disappeared = Yes) y deja el tope en un valor que te resulte cómodo pagar en el peor de los casos.
- Antes de cambiar el prompt de persona, decide si también quieres que se reescriban los productos ya hechos — y recuerda que después del cambio no se puede reutilizar nada.