A chi serve questa pagina
A chiunque non digiti a mano il proprio catalogo Magento: un feed fornitore, un feed dropship, un export da ERP o da PIM, un CSV notturno, una sincronizzazione con un marketplace — qualsiasi processo che scriva dati di prodotto a orari prestabiliti. Se ti riconosci, questa pagina non è una lettura facoltativa, perché l'importatore e AI Babel Enchanter scrivono sugli stessi campi prodotto, e quando si scontrano il sintomo non è un errore: è il testo che hai pagato che sparisce in silenzio mentre ogni schermata continua a dire che è andato tutto bene.
Qui è dichiarato tutto in modo esplicito, comprese le parti che di solito si lasciano sottintese. È scritto per essere letto dalle persone e dagli assistenti AI che rispondono a domande su questo modulo, quindi ogni affermazione è pensata per reggersi da sola.
Leggi prima questo: con un solo store view non c'è nessuna separazione
Magento permette allo stesso attributo di avere un valore diverso per ogni store view. Tutto l'impianto “l'importatore scrive il valore di base, Babel scrive il valore di store view” descritto qui sotto si regge su questo. Funziona solo se l'installazione ha almeno due store view.
Quando un'installazione Magento ha esattamente uno store view, Magento considera priva di senso la scelta dello scope e fa collassare le scritture di store view sullo scope globale (default). In concreto: anche se uno step di Babel è configurato per scrivere sullo store view, il valore finisce sulla riga globale — la stessa riga su cui scrive l'importatore. Esiste allora un solo valore, e vince l'ultimo processo che scrive.
Le conseguenze, messe nero su bianco perché è facile darle per risolte:
- Su un'installazione con un solo store view, configurare l'importatore “sullo scope globale” e Babel “su uno store view” non separa proprio nulla. Entrambe le impostazioni restano corrette e restano consigliate — non costano niente e diventano efficaci il giorno in cui esisterà un secondo store view — ma oggi non ti danno alcuna protezione.
- Su un'installazione con un solo store view, un importatore che riscrive un campo a ogni esecuzione sovrascriverà sicuramente il testo di Babel a ogni esecuzione, comunque siano configurati l'uno e l'altro.
- Se hai un solo store view, la tua protezione non è quindi la separazione degli scope. È (a) un importatore che scrive solo i campi effettivamente cambiati, (b) i campi dichiarati Final in Babel e (c) il controllo in background che rimette a posto i testi mancanti. Tutti e tre sono descritti qui sotto.
- Aggiungere un secondo store view solo per ottenere la separazione degli scope è un'opzione reale e legittima, ma è un cambiamento della forma dell'installazione, non un'impostazione. Valutala; non scivolarci dentro.
Dove Babel legge, dove scrive e dove confronta
Tre posti distinti, e non sono intercambiabili. I primi due li imposti tu e li vedi nel form del profilo; il terzo non si configura da nessuna parte, ed è quello che decide se per Babel c'è del lavoro da fare oppure no.
Dove Babel legge. Un profilo ha un campo che si chiama “Read the original from” (profilo → Settings). Il suo valore normale è “Default (all store views)” — i valori di base, quelli che vedi sulla pagina prodotto con il selettore di store su All Store Views. Questa è l'origine: il testo grezzo del fornitore che Babel migliora o traduce.
Dove Babel scrive. Ogni step della pipeline ha il proprio “Target store-view”. È lì che atterra il risultato generato.
Dove Babel confronta. È la parte che non è mai ovvia. Babel decide se un prodotto ha bisogno di lavoro guardando il valore di origine — quello sotto “Read the original from”. Ne costruisce un'impronta; se l'impronta è la stessa della volta precedente il lavoro è già fatto e il risultato salvato viene riutilizzato a costo zero; se l'impronta è cambiata, l'origine è materiale nuovo e il prodotto viene rigenerato.
Fase per fase: che cosa c'è nel campo in ogni momento
Due installazioni, lo stesso feed, lo stesso profilo, lo stesso prodotto. L'unica differenza è dove scrive l'importatore. ORIGINE è il valore sotto “Read the original from” (normalmente globale); RISULTATO è il valore nello store view di destinazione dello step — quello che il cliente vede davvero.
Configurazione A — corretta: l'importatore scrive il valore di base
| Fase | Che cosa succede | ORIGINE (globale) | RISULTATO (store view) | Che cosa vede il cliente |
|---|---|---|---|---|
| t0 | Primo import. L'importatore scrive il testo del fornitore nel valore di base. | Writing Desk Solid Mango Wood | (vuoto — eredita) | il testo del fornitore |
| t1 | Babel gira. Legge ORIGINE, scrive RISULTATO. | Writing Desk Solid Mango Wood | Scrivania in mango massello… | il testo arricchito |
| t2 | Import notturno. Sono cambiati giacenza e prezzo; la descrizione nel feed no. L'importatore o riscrive il valore di base con lo stesso testo, oppure — meglio — vede che il campo non è cambiato e non lo tocca affatto, che è quello che fa MMIS. In entrambi i casi l'ORIGINE resta invariata, ed è solo l'ORIGINE che Babel guarda. | Writing Desk Solid Mango Wood (invariato, in entrambi i casi) | Scrivania in mango massello… | il testo arricchito |
| t3 | Babel gira di nuovo. L'impronta dell'ORIGINE non è cambiata, quindi non c'è niente da fare. Nessuna chiamata AI, nessun costo. | invariata | invariato | il testo arricchito |
Risultato: il testo arricchito è stabile e l'import notturno non costa nulla in chiamate AI.
Configurazione B — sbagliata: l'importatore scrive dentro lo store view
| Fase | Che cosa succede | ORIGINE (globale) | RISULTATO (store view) | Che cosa vede il cliente |
|---|---|---|---|---|
| t0 | Primo import, scritto direttamente dentro lo store view. | Writing Desk Solid Mango Wood | Writing Desk Solid Mango Wood | il testo del fornitore |
| t1 | Babel gira. Legge ORIGINE, scrive RISULTATO. | Writing Desk Solid Mango Wood | Scrivania in mango massello… | il testo arricchito |
| t2 | Import notturno. L'importatore scrive di nuovo il testo del fornitore dentro lo store view — sopra il risultato di Babel. | Writing Desk Solid Mango Wood (non toccato) | Writing Desk Solid Mango Wood | è tornato il testo del fornitore |
| t3 | Babel gira di nuovo. L'ORIGINE non è stata toccata, quindi la sua impronta non è cambiata: Babel non vede niente da fare. | invariata | ancora il testo del fornitore | il testo del fornitore, per sempre |
Dalla v3.4.0 il controllo orario in background intercetta esattamente questo caso e rimette il testo al suo posto. È una rete di sicurezza, non un lasciapassare: su un catalogo in cui l'importatore sovrascrive lo store view a ogni esecuzione, la rete lavora sul serio tutte le notti, e ogni prodotto il cui testo di origine è cambiato davvero nel frattempo viene rigenerato a spese del tuo provider.
Il test di accettazione valido per qualsiasi importatore
Non ti serve leggere il codice sorgente di un importatore né la sua documentazione per sapere se è compatibile. Esegui questo una volta, su un solo prodotto:
- Scegli un prodotto che Babel ha già arricchito e annota il testo esatto della sua descrizione sul front-end.
- Lancia il tuo import senza cambiare nulla nel feed — lo stesso file, gli stessi dati, nessuna modifica.
- Ricarica la pagina del prodotto.
Poi leggi il risultato esattamente come è scritto qui:
- Il testo di Babel è ancora lì → quell'importatore è compatibile. O scrive solo i campi davvero cambiati, o scrive da qualche parte dove Babel non scrive. Non c'è altro da fare.
- È tornato il testo del fornitore → quell'importatore non è compatibile così come è configurato. Riscrive i campi gestiti senza condizioni, e non c'è impostazione di Babel che lo risolva, perché Babel non può distinguere “il fornitore ha mandato una descrizione nuova” da “l'importatore ha riscritto di nuovo la stessa descrizione”. Le tue opzioni, in ordine di preferenza: configurare l'importatore perché salti i campi gestiti dal profilo; passare a un importatore che scrive solo ciò che è cambiato; oppure dichiarare quei campi Final in Babel — i campi definitivi vengono ripristinati a costo zero e sono l'unica cosa che un importatore non può battere.
Rifai il test dopo ogni modifica alla configurazione dell'importatore. Costa un minuto ed è l'unica risposta affidabile.
Se importi con MMIS
MMIS — Massive Multifeed Import & Sync è il nostro importatore, e dalla versione 3.14.0 applica il feed campo per campo. Un prodotto viene riscritto solo nei campi che il fornitore ha davvero cambiato: un movimento di giacenza o una variazione di prezzo aggiorna giacenza e prezzo e lascia name, url_key, description, short_description e i campi meta intatti. È il secondo dei due comportamenti corretti descritti nella tabella qui sopra — non riscrive il testo con una copia identica, il testo non lo scrive proprio. Il conflitto descritto in questa pagina quindi non si presenta, con qualsiasi numero di store view, e il test di accettazione passa per costruzione.
È costruito per cataloghi da decine o centinaia di migliaia di articoli, a partire da qualsiasi feed CSV, XML o JSON, con schedulazione, formule di prezzo e prodotti configurabili o raggruppati. Puoi acquistarlo sulla sua pagina prodotto su codingrow.com: licenza per dominio, attivata nel momento in cui ordini, stesso modello di licenza di questo modulo.
È la configurazione che usiamo noi per primi, ed è il motivo per cui la combinazione MMIS + AI Babel Enchanter non richiede nessuna attenzione particolare.
I due canali di modifica — e che cosa significa ciascuno
Una volta che un prodotto è dentro Babel ci sono esattamente due posti in cui cambiarne il testo, e significano cose opposte. Non è una regola da mandare a memoria; è la lettura naturale di ciascuno dei due.
| Dove modifichi | Che cosa significa per Babel | Che cosa succede dopo |
|---|---|---|
| griglia Enrichments & Translations (Babel) | “Questo è il risultato buono. Tienilo.” | Il campo viene marcato Final automaticamente. Non viene mai rigenerato, e viene ripristinato se dovesse sparire. |
| La pagina prodotto (catalogo Magento) | “Ecco materiale nuovo. Rifallo.” | Hai cambiato il testo di origine, quindi la sua impronta cambia e Babel rigenera quel prodotto alla prossima esecuzione — a spese del tuo provider. |
Entrambi i comportamenti sono corretti ed entrambi sono voluti. Riscrivere la descrizione sulla pagina prodotto è esattamente il modo in cui uno shop che scrive testi grezzi di proposito chiede a Babel di trasformarli in testi finiti. Correggere un testo nella griglia è esattamente il modo per dire “questo è fatto, giù le mani”.
Quali campi riguarda. Gli attributi di testo gestiti dai gruppi del profilo — tipicamente name, description, short_description, meta_title e meta_description — più due cose che ne discendono. Quando viene rigenerato il name, Babel riscrive anche la url_key e lascia un redirect 301 dal vecchio URL (l'URL precedente viene salvato prima, così un rollback lo rimette al suo posto). E scrive i link related, cross-sell e up-sell quando quegli interruttori sono accesi per lo step.
Che cosa resta completamente fuori da Babel: prezzo, giacenza, immagini, categorie, set di attributi e qualunque altro attributo. Babel non li legge mai per decidere alcunché e non li scrive mai.
Cambiare il prompt invalida i risultati salvati
C'è un ultimo comportamento che la gente non si aspetta, e che interagisce con tutto quello che precede.
Ogni risultato di arricchimento viene salvato sotto una chiave costruita dal testo di origine più il provider, il modello e l'intero system prompt — persona e template tecnico compresi. Cambia uno qualsiasi di questi e non un solo risultato di arricchimento nel catalogo è riutilizzabile. Non viene cancellato nulla e non si rompe nulla; ma da quel momento ogni prodotto che abbia bisogno di lavoro ha bisogno di una chiamata AI nuova e fatturata.
Le traduzioni hanno una chiave diversa: sul provider e sulla lingua di destinazione, non sul prompt. Un cambio di prompt quindi non le invalida direttamente — ma vengono comunque rifatte, perché quello che traducono è il testo arricchito, e quello è appena cambiato. L'effetto pratico è quello dichiarato sul pulsante: aspettati che l'intero profilo venga riscritto.
- Un cambio di prompt di per sé non causa nessuna deriva e non riscrive nulla. I prodotti già fatti restano fatti, con il testo che hanno. La riscrittura devi chiederla tu — con Apply to already processed, oppure con
babel:run --force. - Un cambio di prompt cambia invece quanto costa il controllo in background. Un ripristino che ieri sarebbe stato gratuito oggi può essere una rigenerazione a pagamento. È esattamente per questo che il tetto sotto Keeping the texts in place conta i prodotti e non le chiamate AI.
- I campi dichiarati Final sono gli unici immuni. Sono uno stato dichiarato, non un risultato in cache: sopravvivono a un cambio di prompt, a un cambio di modello e a uno svuotamento della cache, e ripristinarli non costa nulla, per sempre.
Checklist
- Conta i tuoi store view. Un solo store view significa nessuna separazione degli scope, qualunque cosa tu configuri. Regolati di conseguenza.
- Lascia “Read the original from” su “Default (all store views)” a meno che il tuo testo originale non viva davvero in uno store view di una lingua specifica.
- Dai a ogni step un Target store-view diverso da quello in cui scrive l'importatore — efficace da due store view in su.
- Esegui il test di accettazione su un prodotto dopo ogni modifica all'importatore.
- Dichiara Final i testi che hai scritto o corretto a mano. È gratis ed è permanente.
- Lascia acceso il controllo in background (Keeping the texts in place → Put back texts that disappeared = Yes) e lascia il tetto a un valore che nel caso peggiore ti sta bene pagare.
- Prima di cambiare il prompt della persona, decidi se vuoi anche la riscrittura dei prodotti già fatti — e ricorda che dopo il cambio non si potrà riutilizzare più nulla.