Documentazione di AI Babel Enchanter

Installazione

Requisiti

Magento 2.4.x — testato su 2.4.9, compatibile con le release 2.4.* precedenti. PHP 8.1–8.5. Funziona sia con il tema predefinito Luma sia con il tema Hyvä — il modulo gira interamente nell'admin e scrive attributi di catalogo standard, così il tuo storefront mostra i contenuti migliorati senza modifiche ai template. Dipende dal modulo gratuito codingrow/module-core, installato automaticamente. Richiede una chiave API di almeno un provider AI per il passo di miglioramento/riscrittura (Anthropic, OpenAI, Google o OpenRouter) e, per la traduzione, una chiave di traduzione automatica (DeepL) oppure un LLM usato come traduttore. Tutto l'uso di AI e traduzione ti viene fatturato direttamente dal provider — Codingrow non applica mai un ricarico.

Passi di installazione

1. Aggiungi le credenziali che riceverai via email al file auth.json nella root del tuo progetto Magento: { "http-basic": { "repo.codingrow.com": { "username": "...", "password": "..." } } }
2. composer config repositories.codingrow composer https://repo.codingrow.com
3. composer require codingrow/module-ai-babel-enchanter
4. bin/magento module:enable Codingrow_BabelEnchanter
5. bin/magento setup:upgrade && bin/magento setup:di:compile && bin/magento cache:flush (setup:di:compile è necessario in un deploy di produzione; puoi saltarlo in un ambiente di sviluppo)
6. Incolla la tua chiave di licenza in Admin → Stores → Configuration → Codingrow → AI Babel Enchanter → License → License Key, salva, poi svuota la cache.

Configurazione

Stores → Configuration → Codingrow → AI Babel Enchanter.

Disinstallazione

Imposta Enable su No e salva per interrompere immediatamente ogni elaborazione — i contenuti del tuo catalogo restano esattamente come sono. Se prima vuoi tornare al testo originale, esegui un rollback (vedi la Guida utente). Per rimuovere del tutto il modulo: bin/magento module:disable Codingrow_BabelEnchanter poi composer remove codingrow/module-ai-babel-enchanter.

Provider & costi

Scelta dei provider

AI Babel Enchanter ha due slot provider indipendenti: uno per il passo di miglioramento/riscrittura (un LLM) e uno per la traduzione (un LLM o un servizio dedicato di traduzione automatica come DeepL). Porti le tue chiavi e tutto l'uso ti viene fatturato direttamente dal provider che scegli — Codingrow non applica mai un ricarico. Scegli il modello di miglioramento per la qualità e traduci con lo stesso LLM oppure con una chiave MT più economica per carattere.

Anthropic (modelli Claude)

1. Accedi su console.anthropic.com.
2. Vai su console.anthropic.com/settings/keys.
3. Clicca Create Key, dagli un nome (es. "AI Babel Enchanter") e copia il valore.
4. Incollalo nello slot provider con Provider impostato su Anthropic, poi usa Load models.

OpenAI (modelli GPT)

1. Accedi su platform.openai.com.
2. Vai su platform.openai.com/api-keys.
3. Clicca Create new secret key, dagli un nome e copialo subito — viene mostrato una sola volta.
4. Incollalo nello slot provider con Provider impostato su OpenAI, poi usa Load models.

Google (modelli Gemini)

1. Accedi su aistudio.google.com con un account Google.
2. Vai su aistudio.google.com/app/apikey.
3. Clicca Create API key, scegli o crea un progetto Google Cloud e copia la chiave.
4. Incollala nello slot provider con Provider impostato su Google, poi usa Load models.

OpenRouter (una chiave, i modelli di molti provider)

1. Accedi su openrouter.ai.
2. Vai su openrouter.ai/keys.
3. Clicca Create Key, dagli un nome e copia il valore.
4. Incollalo nello slot provider con Provider impostato su OpenRouter, poi usa Load models.

DeepL (traduzione automatica)

1. Accedi su deepl.com/pro-api.
2. Apri Account → API keys e copia la tua Authentication Key.
3. Incollala nello slot Translation provider con il traduttore impostato su DeepL.

DeepL ha un prezzo per carattere (circa €20 per 1M di caratteri), di solito più economico di un LLM per la sola traduzione. Puoi anche saltare del tutto DeepL e tradurre con lo stesso LLM del passo di miglioramento.

Load models — nessun id di modello da digitare

Dopo aver inserito la chiave API, salva la sezione e clicca Load models sotto il campo Model: il modulo chiama l'endpoint di elenco modelli del provider con la tua chiave e riempie un menu a tendina con ogni modello che la tua chiave può effettivamente usare — scegli dall'elenco invece di digitare un id. Rimane un campo di testo manuale come fallback per un id di modello non ancora presente nell'elenco. Un link subito sotto il campo punta sempre alla pagina delle chiavi corretta per il provider attualmente selezionato.

Stimare il costo di un'esecuzione sull'intero catalogo

Un passaggio completo ha due voci di costo che si sommano per prodotto: miglioramento (token LLM, a prezzo per milione) e traduzione (caratteri, a prezzo per milione, moltiplicati per il numero di lingue di destinazione). Usa il calcolatore qui sotto per dimensionare un'esecuzione prima di lanciarla — è una stima puramente indicativa; i numeri reali dipendono dalla lunghezza dei contenuti e dai modelli che scegli.

Guida utente

Profili e persona prompt

Tutto ciò che il modulo fa è organizzato in profili. Un profilo è una configurazione riutilizzabile che esegui su una porzione del catalogo: quali attributi può toccare, la pipeline di passi da applicare, un'eventuale categoria esclusiva così che il profilo operi solo sui prodotti di quella categoria, e un persona prompt — istruzioni in testo libero che impostano il tono di voce e le regole della riscrittura. I profili sono anti-revert: un prodotto già elaborato da un profilo viene saltato all'esecuzione successiva a meno che tu non lo resetti, quindi rieseguire è sicuro.

Gruppi e passi (la pipeline)

Dentro un profilo definisci gruppi di passi che vengono eseguiti in ordine. I due tipi di passo principali sono improve (riscrivi/arricchisci il testo sorgente con il provider di miglioramento) e translate (produci le versioni nella lingua di destinazione). La pipeline normale è improve → translate: la lingua sorgente viene riscritta per prima, poi è il testo migliorato a essere tradotto, così ogni store view eredita i contenuti migliori invece di tradurre il vecchio testo. Il raggruppamento ti permette di applicare passi diversi ad attributi diversi ed eseguirli come un'unica operazione.

AI — Models (il pool di credenziali)

Registra ogni AI una sola volta nella scheda AI — Models e riutilizzala ovunque. Ogni riga è una credenziale: un nome personalizzato, il provider (Anthropic, OpenAI, Google/Gemini, OpenRouter o DeepL), la chiave API (memorizzata cifrata), il modello — digitalo o clicca Load models per scegliere solo i modelli che la tua chiave può effettivamente usare, ciascuno annotato con la sua velocità di risposta — una capacità (translate / enhancement / both), un default, un ordine di fallback e un flag di abilitazione.

Aggiungine quante vuoi: se una chiave si esaurisce (senza credito, in rate limit, un errore di autenticazione) il modulo la marca in cooldown e passa alla credenziale successiva nella catena, tra provider diversi, così un'esecuzione lunga sopravvive a una chiave morta. Il modello e il prompt vengono poi scelti per passo nel profilo — arricchisci con un modello di alto livello e traduci i titoli di scarso valore con uno economico e veloce, in un'unica pipeline.

Max tokens (per credenziale) è il limite sui token che un modello può generare — un limite, non un obiettivo, quindi paghi solo ciò che viene prodotto. Troppo basso e il testo si tronca; con i modelli di ragionamento può persino non restituire nulla. Il default di 4000 copre descrizione + descrizione breve + titolo + meta. Extended thinking è disattivato di default (non migliora i testi di vendita) e puoi impostare un prezzo opzionale per-AI per alimentare la stima dei costi.

AI Compare

Apri la scheda AI Compare di un profilo, seleziona i modelli da confrontare e scegli alcuni prodotti campione. Run comparison arricchisce ogni campione con ogni modello (un dry-run — non viene scritto nulla) in una matrice: una colonna per modello, una riga per prodotto, ogni cella mostra il titolo generato con un riferimento, il tempo di generazione, un costo € indicativo (dai conteggi reali dei token dell'API) e un Preview che apre il risultato completamente renderizzato.

Un giudice — il modello che scegli nel menu a tendina, idealmente il più capace — valuta ogni output per qualità linguistica, formattazione, misure contestualizzate, registro premium, validità del JSON e SEO, e sceglie un vincitore; il verdetto aggiunge tempo medio e costo medio per modello. Scegli All models judge e ogni modello restituisce il proprio verdetto, una tabella ciascuno. Un timer dal vivo e uno skeleton mostrano il giudice al lavoro, un pulsante Stop interrompe e l'ultimo confronto viene salvato sul profilo così ricompare — con un timestamp — senza rieseguire.

Come funzionano i token (e cosa causa una loro impostazione errata)

Ogni passo di magnify o translate è una chiamata a un modello AI. Il modello legge il prompt della tua persona, i campi sorgente del prodotto e — quando genera anche il titolo — un piccolo campione di titoli affini: questo è l'input. Poi scrive un singolo oggetto JSON con i campi riscritti: questo è l'output. Il provider ti fattura entrambi, ma i token di output costano diverse volte più di quelli di input, quindi è la lunghezza del testo generato a determinare il costo.

Max tokens limita solo l'output che un modello può produrre in una chiamata. È un limite, non un obiettivo: se il testo termina naturalmente prima paghi solo ciò che è stato scritto, quindi un limite generoso non costa mai di più — evita soltanto che un buon output venga tagliato. Il valore predefinito di 4000 copre agevolmente una descrizione ricca più short description, titolo e meta description insieme.

Cosa causa un limite troppo basso. Se l'output fosse più lungo del limite, la risposta viene troncata a metà frase e il JSON non si chiude mai — il modulo non riesce a interpretarlo. Alcuni modelli recenti eseguono anche un reasoning nascosto prima di scrivere: con un limite troppo stretto possono spendere l'intero budget a ragionare e restituire assolutamente nulla. In entrambi i casi Babel non mantiene silenziosamente il testo originale — segna quel prodotto come fallito con il motivo reale in coda, così puoi alzare il limite e riprovare. Se i prodotti tornano insolitamente corti o “bloccati nella lingua di partenza”, il limite dei token è la prima cosa da controllare.

Extended thinking è disattivato di default, di proposito. Per i testi di vendita del catalogo non migliora il risultato — esce lo stesso testo — mentre consuma token e tempo e rischia la trappola della risposta vuota vista sopra. Lascialo disattivato per la generazione; il giudice AI Compare lo abilita solo dove il ragionamento aiuta davvero, e ripiega con eleganza quando il modello scelto non lo supporta.

In pratica: tieni Max tokens a 4000 (o poco più per descrizioni molto lunghe), tieni d'occhio la coda per gli errori con un motivo chiaro invece di un output sbagliato silenzioso, e lascia che la stima dei costi — alimentata dai conteggi reali dei token restituiti dall'API — ti dica quanto costerà davvero ogni esecuzione prima di lanciarla.

Le caratteristiche oggettive del prodotto

Su tanti cataloghi le misure non stanno in nessun attributo: stanno dentro il nome. Carta da Parati Rotolo 10 m, Prolunga Elettrica 5 m. Per una persona si legge benissimo, per il negozio non esiste: chi chiede dieci metri si vede proporre una scheda da un pezzo, perché nessun campo dice quanto è lungo un pezzo.

Mentre lavora un articolo, Babel ne annota i dati misurabili nell’attributo Product characteristics (Babel) della scheda prodotto, che tu leggi e correggi.

unita_vendita: confezione
copertura_pezzo: 2.22 m2
pezzi_confezione: 8
spessore: 8 mm
materiale: laminato
tipologia: pavimento flottante (dedotto)

unita_vendita non si deduce mai. È un termine commerciale: dice a che cosa si riferisce il prezzo. Una riga diversa da pezzo si scrive solo se valgono tutte e tre — non è dedotta, c’è il numero che rende possibile il conto (pezzi_confezione per la confezione, copertura_pezzo per i metri) e la prova sta nei dati del prodotto, cercata dal modulo e non data per buona perché lo dice l’AI. Se niente lo dice, la riga semplicemente non c’è, e vuol dire che il prezzo è del pezzo: il lato sicuro.

Il conto lo fa copertura_pezzo — quanto copre UN pezzo — che è una misura e si ricava dal prodotto. Una confezione di laminato che copre 2,22 m² porta unita_vendita: confezione e copertura_pezzo: 2.22 m2, e una richiesta di trenta metri quadri diventa quattordici confezioni. Senza la coppia diventava trenta confezioni, cioè più del doppio della spesa.

Il marcatore (dedotto) è il confine. Una riga che finisce così non l’ha scritta nessuno: l’AI l’ha dedotta. Serve a capire e a cercare, ma da lì non si ricava mai una quantità. Per confermare un dato si cancella quella parola; quello che è sbagliato si corregge, quello che non c’entra si cancella. Il catalogo è tuo.

Su un prodotto con varianti ognuno porta la sua parte: sul padre quello che vale per tutte le varianti (l’unità di vendita, il materiale, il tipo), su ogni variante quello che la distingue (la sua misura, la sua taglia). Le varianti si lavorano solo quando a cambiare è una misura: se cambia soltanto il colore, la variante non avrebbe niente di suo da dire. Un raggruppato o un bundle non hanno misure proprie — sono un elenco di articoli, ognuno con le sue — e su virtuali e scaricabili non si scrive niente: un corso non si misura.

Non riscrive i testi: è una chiamata a parte, piccola, con la sua memoria. Per gli articoli già elaborati c’è il bottone Annota le caratteristiche nella pagina del profilo, oppure bin/magento babel:params --profile=3. Su un catalogo vero: 38 articoli padre e 116 varianti passati, l’unità di vendita su 34 dei 38 padri — è del padre e mai della variante, perché come si vende una cosa non cambia fra l’80 e il 100.

Su una variante il campo è spesso vuoto, ed è l’esito giusto: quello che la distingue sta già in un attributo Magento (il suo peso, la misura su cui varia), e riscriverlo anche qui farebbe due copie destinate a divergere — con la variante che vince sul padre. Su quel catalogo 97 varianti su 116 portano una riga propria, le altre 19 non avevano niente da aggiungere. E le regole valgono anche su quello che è già scritto: una riga lasciata da una versione precedente che viola il formato di oggi viene tolta al giro successivo, mentre una riga che hai corretto a mano non si tocca.

Tipi di prodotto e gestione differenziata

Un prodotto configurabile non è un articolo singolo, un raggruppato non è un pacco, un prodotto virtuale o scaricabile non si spedisce. Il modulo riconosce il tipo da sé e passa all'AI una descrizione della struttura, che cambia ciò che il testo dice e ciò che non deve dire.

Dove si accende. Scheda Mapping del profilo, sul singolo passo: Contesto struttura prodotto. È spento di default: accenderlo cambia ciò che l'AI riceve e quindi fa rigenerare le schede di quel profilo al giro successivo. Accendilo prima di una lavorazione nuova, non a metà di una in corso.

• Configurabile — riceve l'asse di scelta con la sua etichetta nella lingua della vetrina (per esempio misura: 80, 100), le opzioni e gli attributi che differiscono davvero fra i figli, ricavati confrontandoli. Non c'è nulla da configurare a mano: gli attributi dei configurabili il modulo li intercetta da solo. Prezzi, prezzi speciali, costi e fasce restano fuori di proposito, perché cambiano e un testo che li cita invecchia male. Il testo risultante racconta la gamma; un'intestazione non deve mai riportare il valore di una sola opzione (per esempio Tubo 1m 100 quando 100 è una delle misure).
• Bundle — riceve i titoli delle opzioni, quali sono obbligatorie e gli articoli selezionabili in ciascuna, così il testo può spiegare come si compone il prodotto.
• Raggruppato — riceve l'elenco degli articoli associati, perché il testo dica che si comprano insieme e a cosa serve ciascuno.
• Virtuale — riceve solo il tipo, che basta: all'AI viene vietato di parlare di spedizione, consegna, imballo e peso. Senza questa regola il modello scrive spedizione rapida anche per una garanzia estesa.
• Scaricabile — riceve il numero di file e se esiste un campione: il testo spiega la consegna digitale, e la spedizione resta vietata.

Le varianti non si lavorano. Accanto c'è Salta le varianti, acceso di default a livello di gruppo: un prodotto che compare come figlio di un configurabile viene escluso dalla coda. Non ha una pagina che il cliente possa aprire, quindi arricchirla è spesa senza ritorno; su un catalogo costruito sulle varianti sono la maggior parte della coda. Chi vende le varianti come articoli a sé stanti lo spegne.

Limitare i bersagli. Sullo stesso passo, Tipi di prodotto e Visibilità restringono la coda a ciò che vuoi davvero lavorare — per esempio solo i configurabili, o solo i prodotti visibili in catalogo e ricerca.

Cross-sell, correlati e up-sell (relazioni AI)

Tre interruttori indipendenti permettono a un profilo di proporre prodotti cross-sell, correlati e up-sell usando l'AI. Il modello suggerisce sempre e solo SKU reali del tuo catalogo — non può inventare un prodotto inesistente — e i suggerimenti vengono scritti nei collegamenti nativi cross-sell/correlati/up-sell di Magento, così compaiono nei blocchi standard dello storefront. Attiva solo i tipi di relazione che vuoi far gestire al modulo.

Anteprima in dry-run (e renderizzata)

Prima che venga scritto qualcosa, esegui un profilo in dry-run: il modulo genera i contenuti proposti per un campione di prodotti e li mostra affiancati al testo attuale, inclusa un'anteprima renderizzata così vedi come apparirà davvero la descrizione migliorata sulla pagina — non solo il testo grezzo. In dry-run non viene salvato nulla; serve a validare il persona prompt e la pipeline prima di impegnarti in un'esecuzione completa.

La griglia "Enrichments & Translations"

La scheda "Enrichments & Translations" è la griglia operativa: ogni campo generato per ogni prodotto e lingua, paginata e filtrabile. Puoi modificare inline qualsiasi valore generato prima o dopo che viene applicato — l'output dell'AI è un punto di partenza, non un vincolo — e ogni riga mantiene un collegamento al testo originale, così puoi ripristinare l'originale per quel campo con un'azione se il risultato non ti piace. È il livello human-in-the-loop sopra la pipeline automatizzata.

I testi che dichiari definitivi

Prima o poi arriva il prodotto la cui descrizione la scrivi tu: l'articolo di punta, quello a cui tiene il titolare, quello in cui il testo dell'AI era buono ma non giusto. Lo sistemi a mano e da quel momento vuoi una sola garanzia — che nessuno lo riscriva mai più. Quella garanzia è la casella Final, novità della v3.4.0.

Apri Enrichments & Translations, apri un prodotto: sotto ogni campo c'è una casella “Final — never regenerate this text”. Spuntala e quel campo è dichiarato tuo.

Che cosa significa “definitivo”, in concreto. Per quel campo, su quel prodotto, in quello store view:

• l'AI non viene mai più chiamata per quel campo — né alla prossima esecuzione, né dopo che hai cambiato il prompt della persona, né dopo un cambio di modello, né dopo uno svuotamento della cache, né quando premi Apply to already processed. Non costa nulla, per sempre. E se tutti i campi di un prodotto sono dichiarati definitivi, la chiamata AI per quel prodotto non viene proprio fatta;
• se il valore sparisce dal prodotto — un importatore lo ha sovrascritto, qualcuno ha ripristinato l'originale, una migrazione lo ha cancellato — il controllo in background rimette al suo posto il testo che hai dichiarato, di nuovo a costo zero;
• vince sulle regole automatiche del modulo stesso. Il meta title, per esempio, normalmente è forzato a seguire il nome del prodotto, sempre; dichiara definitivo il meta title e vince il tuo testo anche su quella regola;
• vale solo per quel campo. Gli altri campi dello stesso prodotto continuano a essere generati normalmente. Dichiarare definitiva la descrizione non congela il meta title e non toglie il prodotto dal profilo.

Modificare nella griglia spunta la casella al posto tuo. Appena scrivi in un campo della griglia, la sua casella Final si spunta da sola. È il comportamento che l'interfaccia lascia intendere — sei entrato e hai corretto quel testo, quindi la correzione è tutto il punto — e prima della v3.4.0 non era così: un testo corretto a mano sopravviveva fino al successivo cambio di prompt e veniva poi rigenerato sopra, in silenzio. Se vuoi che un testo corretto venga rigenerato più avanti, togli la spunta prima di salvare.

L'unica cosa da ricordare: un campo definitivo è l'unica cosa nel modulo che sopravvive a un cambio di prompt della persona o di modello. Tutto il resto viene ricostruito dal risultato salvato, e il risultato salvato è archiviato sotto una chiave che comprende l'intero prompt — cambia il prompt e nessuno dei risultati salvati è più riutilizzabile.

I testi che tornano al loro posto da soli

Ecco un guasto che fino a ieri passava inosservato. Un prodotto già elaborato non rientra mai in coda da solo — è voluto, ed è ciò che rende rieseguire un profilo un'operazione economica e sicura. L'effetto collaterale: se qualcosa sovrascrive un testo generato dopo che il prodotto è stato elaborato, quel prodotto non viene più guardato. Il front-end continua a mostrare il testo sovrascritto, la coda dice done, lo storico conserva ancora il testo generato e da nessuna parte viene segnalato un errore. L'abbiamo scoperto su un catalogo vero: 318 prodotti con titoli e descrizioni in inglese su uno shop italiano, per settimane, con il testo italiano ancora fermo nello storico del modulo.

La v3.4.0 chiude la falla. Un controllo in background gira ogni ora e fa una sola domanda per ogni risultato salvato, leggendo solo il database e senza mai chiamare un'AI per chiederlo: il testo che ho scritto è ancora sul prodotto? Quando la risposta è no, il prodotto torna in coda con il trattamento più economico possibile:

Lavora a fette, e questo conta. Ogni esecuzione esamina 500 risultati salvati e si ricorda dove si è fermata, riprendendo da lì un'ora dopo. Il confronto costa due query per riga, quindi spazzolare un catalogo grande ogni singola ora sarebbe un peso che nessuno ha chiesto. Il catalogo viene comunque coperto tutto — solo distribuito nel tempo. Su un catalogo grande questo significa che un testo sparito può aspettare ore, e su uno molto grande un paio di giorni, prima che il controllo ci arrivi. Non è bloccato: non ci è ancora arrivato. Se ti serve una risposta adesso, bin/magento babel:reapply guarda subito quello che gli indichi.

Lo governi da Stores → Configuration → Codingrow → AI Babel Enchanter → Keeping the texts in place:

• Put back texts that disappeared — Yes per impostazione predefinita. Mettilo su No e non viene rimesso a posto più nulla in automatico; ti resta il comando babel:reapply per le passate manuali.
• At most, per check — 200 per impostazione predefinita. Quello che eccede il tetto viene ripreso dalle esecuzioni successive. Mettilo a 0 per spegnere del tutto il controllo in background.

Perché il tetto conta i prodotti e non le chiamate AI. “Questo non costa nulla” è una previsione basata sul risultato salvato. Se nel frattempo hai cambiato il prompt o il modello, quel risultato salvato non è più riutilizzabile e un ripristino che sembrava gratuito diventa a pagamento. Mettere un tetto ai prodotti tiene il conto sotto controllo anche quando la previsione sbaglia. I ripristini gratuiti vengono elaborati per primi, così il lavoro che non costa nulla viene comunque sempre fatto prima che il tetto venga raggiunto.

Che cosa non fa, e che cosa fa. Non tocca mai prezzi, giacenze, immagini o qualunque attributo fuori da quelli gestiti dal profilo, e non arruola mai un prodotto che non è mai stato elaborato. Ma sulla parte che sorprende bisogna essere chiari: rimette in coda il prodotto, e l'esecuzione riscrive poi tutti i campi gestiti da quel profilo. Quindi se avevi corretto uno di quei campi sulla pagina prodotto, quella correzione viene sostituita. Non è un bug, è la regola dei due canali: una correzione che vuoi conservare va nella griglia, oppure prende la spunta Final.

Da riga di comando, bin/magento babel:reapply si limita a riportare e non scrive nulla a meno che non passi --confirm — il modo sicuro per vedere lo stato di un catalogo prima di decidere. Aggiungi --only-free per i soli ripristini a costo zero, --profile e --limit per restringere la passata.

Applicare un nuovo prompt ai prodotti già fatti

I profili sono deliberatamente anti-ripasso: un prodotto già elaborato non viene rielaborato, ed è proprio questo a rendere sicuro ed economico rieseguire un profilo. Il rovescio della medaglia è che quando migliori il prompt della persona, il miglioramento arriva solo ai prodotti elaborati da quel momento in poi — tutto ciò che è già stato fatto si tiene il vecchio testo. Fino alla v3.4.0 l'unico modo per includerli era babel:run --force da riga di comando.

Adesso la pagina del profilo ha un pulsante apposta.

Apply to already processed rimette in coda per quel profilo i prodotti marcati done, partial e skipped. La conferma dichiara il costo in parole chiare prima che succeda qualsiasi cosa: “I prodotti il cui testo di origine non è cambiato vengono riutilizzati a costo zero. Gli altri vengono riscritti dall'AI, e il tuo provider te li fattura: quindi dopo aver cambiato la persona o le istruzioni aspettati che l'intero profilo venga riscritto.”

Quell'ultima frase non è un formalismo. Ogni risultato di arricchimento è archiviato sotto una chiave che comprende il provider, il modello e l'intero system prompt. Cambia la persona, cambia il template, cambia il modello, e non un solo risultato di arricchimento nel catalogo è riutilizzabile — e le traduzioni seguono, perché quello che traducono è appena cambiato. Quindi premere questo pulsante dopo un cambio di prompt significa “rigenera tutto questo profilo, e pagalo”. Prima di un cambio di prompt, su un catalogo non toccato, lo stesso pulsante è quasi gratuito.

Usalo quando hai migliorato il prompt e vuoi portare i vecchi prodotti al nuovo standard; quando hai aggiunto un attributo a un gruppo e lo vuoi riempito ovunque; quando hai corretto un errore di mappatura. Non usarlo quando vuoi soltanto riparare testi spariti — per quello c'è il controllo in background di cui sopra, ed è molto più economico.

I campi dichiarati Final non vengono rigenerati nemmeno da questo pulsante.

Se il catalogo è importato

Se i prodotti arrivano in Magento da un feed fornitore, da un ERP, da un PIM o da un qualsiasi import schedulato, quell'importatore e Babel scrivono sugli stessi campi. Che i due convivano in pace dipende da come è configurato l'importatore e da quanti store view hai — e quando non convivono, il sintomo non è un messaggio d'errore: è il testo che hai pagato che sparisce in silenzio mentre ogni schermata continua a dire che è andato tutto bene.

Il test di accettazione richiede un minuto: arricchisci un prodotto, lancia l'import senza cambiare nulla nel feed, ricarica il prodotto. Se il testo di Babel è ancora lì, quell'importatore è compatibile. Se è tornato il testo del fornitore, non lo è — e non c'è impostazione di Babel che lo risolva.

Rollback

Ogni valore scritto dal modulo è reversibile. Oltre al ripristino dell'originale per singola riga nella griglia, il comando CLI babel:rollback ripristina i contenuti in blocco — per profilo, per prodotto o dell'intera esecuzione — riportandoli al testo presente prima che il modulo intervenisse. Poiché l'originale è sempre conservato, un'esecuzione sull'intero catalogo non è mai una porta a senso unico.

Queue e circuit breaker sui crediti

Le esecuzioni lunghe vengono elaborate tramite una coda che puoi osservare, mettere in pausa e riprendere. Il circuit breaker integrato (configurato in Resilience) protegge l'esecuzione: in caso di errori ripetuti del provider — più spesso il provider senza credito o in rate limit — si mette in pausa dopo N errori, attende il cooldown configurato e può ritentare automaticamente gli errori transitori invece di far fallire l'intero batch. Quando ricarichi il credito o il limite si azzera, riprendi la coda e continua da dove si era fermata.

Schede commerciante: resi e spedizione

Google legge dalla scheda prodotto le condizioni di reso e di spedizione per mostrarle nelle sue schede commerciante gratuite, e Search Console le segnala come mancanti quando non ci sono. Non si possono dedurre dal catalogo — sono condizioni commerciali — quindi si dichiarano in configurazione, sotto Merchant listings (returns and shipping). Entrambi i blocchi sono spenti di default e richiedono i dati strutturati del prodotto attivi.

• Condizioni di reso → hasMerchantReturnPolicy: paesi (scelti dall'elenco di Magento), finestra di reso, giorni, come torna la merce, chi paga e l'eventuale costo.
• Condizioni di spedizione → shippingDetails: paesi serviti, costo (0 per la spedizione gratuita), tempi di preparazione e di consegna in giorni lavorativi.

Due regole sono volute. Un blocco con i campi obbligatori incompleti viene scartato intero invece che pubblicato a metà: Google confronta quanto dichiari con quello che il cliente trova sul tuo sito, quindi una dichiarazione sbagliata vale meno di una assente. E con "reso non accettato" non si pubblicano né il metodo né chi paga: non c'è reso da descrivere.

L'offerta porta anche validFrom, la data da cui vale il prezzo pubblicato: l'inizio del prezzo speciale quando c'è, altrimenti la data di creazione del prodotto. Quella non richiede alcuna configurazione.

Quasi mai queste condizioni sono uguali per tutto il catalogo: i tempi di preparazione e consegna cambiano fra magazzino proprio e dropshipping, la spedizione dipende dall'ingombro, la finestra di reso da cosa si vende. E il numero di solito esiste già sul prodotto, in un attributo che compila il tuo importatore o il tuo team. Ognuno di quei campi può quindi puntare a un attributo del prodotto — l'elenco comprende quelli personalizzati — con una casella per scrivere un codice che l'elenco non offre. Dove il prodotto ha un valore vince lui; dove non ce l'ha resta il valore fisso; e un valore che non è un numero ricade sul fisso invece di pubblicare un'assurdità.

Ogni numero può venire da un attributo del prodotto, scelto dall'elenco del catalogo: qui i tempi di preparazione e consegna arrivano dagli attributi che compila un importatore.

Riga di comando (CLI)

Tutto può essere pilotato dalla CLI per la schedulazione e le esecuzioni di grandi dimensioni.