AI Babel Enchanter documentatie

Installatie

Vereisten

Magento 2.4.x — getest op 2.4.9, compatibel met eerdere 2.4.*-releases. PHP 8.1–8.5. Werkt met zowel het standaardthema Luma als het Hyvä-thema — de module draait volledig in de admin en schrijft standaard catalogusattributen, zodat je storefront de verbeterde content toont zonder themawijzigingen. Is afhankelijk van de gratis module codingrow/module-core, die automatisch wordt geïnstalleerd. Vereist een API-sleutel van minstens één AI-provider voor de stap verbeteren/herschrijven (Anthropic, OpenAI, Google of OpenRouter) en, voor vertaling, een sleutel voor machinevertaling (DeepL) of een LLM dat als vertaler wordt gebruikt. Al het AI- en vertaalgebruik wordt je rechtstreeks door de provider gefactureerd — Codingrow rekent nooit een opslag.

Installatiestappen

1. Voeg de inloggegevens die je per e-mail ontvangt toe aan het bestand auth.json in de root van je Magento-project: { "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 is vereist bij een productie-deployment; op een developer-setup kun je het overslaan)
6. Plak je licentiesleutel in Admin → Stores → Configuration → Codingrow → AI Babel Enchanter → License → License Key, sla op en leeg vervolgens de cache.

Configuratie

Stores → Configuration → Codingrow → AI Babel Enchanter.

Verwijderen

Zet Enable op No en sla op om alle verwerking meteen te stoppen — de content van je catalogus blijft precies zoals die is. Wil je eerst terug naar de originele tekst, voer dan een rollback uit (zie de Gebruikershandleiding). Om de module volledig te verwijderen: bin/magento module:disable Codingrow_BabelEnchanter daarna composer remove codingrow/module-ai-babel-enchanter.

Providers & kosten

Providers kiezen

AI Babel Enchanter heeft twee onafhankelijke providerslots: één voor de stap verbeteren/herschrijven (een LLM) en één voor vertaling (een LLM of een aparte machinevertaaldienst zoals DeepL). Je neemt je eigen sleutels mee en al het gebruik wordt je rechtstreeks door de gekozen provider gefactureerd — Codingrow rekent nooit een opslag. Kies het verbetermodel op kwaliteit en vertaal met hetzelfde LLM of met een goedkopere MT-sleutel per teken.

Anthropic (Claude-modellen)

1. Log in op console.anthropic.com.
2. Ga naar console.anthropic.com/settings/keys.
3. Klik op Create Key, geef hem een naam (bijv. "AI Babel Enchanter") en kopieer de waarde.
4. Plak hem in het providerslot met Provider op Anthropic en gebruik daarna Load models.

OpenAI (GPT-modellen)

1. Log in op platform.openai.com.
2. Ga naar platform.openai.com/api-keys.
3. Klik op Create new secret key, geef hem een naam en kopieer hem meteen — hij wordt maar één keer getoond.
4. Plak hem in het providerslot met Provider op OpenAI en gebruik daarna Load models.

Google (Gemini-modellen)

1. Log in op aistudio.google.com met een Google-account.
2. Ga naar aistudio.google.com/app/apikey.
3. Klik op Create API key, kies of maak een Google Cloud-project en kopieer de sleutel.
4. Plak hem in het providerslot met Provider op Google en gebruik daarna Load models.

OpenRouter (één sleutel, de modellen van veel providers)

1. Log in op openrouter.ai.
2. Ga naar openrouter.ai/keys.
3. Klik op Create Key, geef hem een naam en kopieer de waarde.
4. Plak hem in het providerslot met Provider op OpenRouter en gebruik daarna Load models.

DeepL (machinevertaling)

1. Log in op deepl.com/pro-api.
2. Open Account → API keys en kopieer je Authentication Key.
3. Plak hem in het slot Translation provider met de vertaler op DeepL.

DeepL wordt per teken afgerekend (ongeveer € 20 per 1M tekens), meestal goedkoper dan een LLM voor zuivere vertaling. Je kunt DeepL ook helemaal overslaan en vertalen met hetzelfde LLM als de verbeterstap.

Load models — geen model-id om in te typen

Zodra de API-sleutel is ingevuld, sla je de sectie op en klik je op Load models onder het veld Model: de module roept met jouw sleutel het model-lijst-endpoint van de provider aan en vult een dropdown met elk model dat je sleutel daadwerkelijk kan gebruiken — kies uit de lijst in plaats van een id te typen. Er blijft een handmatig tekstveld als fallback voor een model-id dat nog niet in de lijst staat. Een link direct onder het veld wijst altijd naar de juiste sleutelpagina van de momenteel geselecteerde provider.

De kosten van een run over de hele catalogus inschatten

Een volledige doorloop kent twee kostenfactoren die per product optellen: verbeteren (LLM-tokens, prijs per miljoen) en vertalen (tekens, prijs per miljoen, maal het aantal doeltalen). Gebruik de calculator hieronder om een run in te schatten voordat je hem start — het is een louter indicatieve schatting; je werkelijke cijfers hangen af van de lengte van de content en de gekozen modellen.

Gebruikershandleiding

Profielen en persona prompt

Alles wat de module doet is georganiseerd in profielen. Een profiel is een herbruikbare configuratie die je op een deel van de catalogus uitvoert: welke attributen het mag aanraken, de pipeline van toe te passen stappen, een optionele exclusieve categorie zodat het profiel alleen op producten in die categorie werkt, en een persona prompt — vrije-tekstinstructies die de tone of voice en de regels van de herschrijving bepalen. Profielen zijn anti-revert: een product dat al door een profiel is verwerkt, wordt bij de volgende run overgeslagen tenzij je het reset, dus opnieuw draaien is veilig.

Groepen en stappen (de pipeline)

Binnen een profiel definieer je groepen van stappen die op volgorde draaien. De twee kernstaptypes zijn improve (de brontekst herschrijven/verrijken met de verbeteringsprovider) en translate (de doeltaalversies produceren). De normale pipeline is improve → translate: eerst wordt de brontaal herschreven, daarna wordt de verbeterde tekst vertaald, zodat elke store view de betere versie erft in plaats van de oude tekst te vertalen. Groeperen laat je verschillende stappen op verschillende attributen toepassen en als één bewerking uitvoeren.

AI — Models (de pool met inloggegevens)

Registreer elke AI één keer op het tabblad AI — Models en gebruik hem overal opnieuw. Elke rij is één set inloggegevens: een eigen naam, de provider (Anthropic, OpenAI, Google/Gemini, OpenRouter of DeepL), de API-sleutel (versleuteld opgeslagen), het model — typ het of klik op Load models om alleen de modellen te kiezen die je sleutel echt kan gebruiken, elk geannoteerd met zijn responssnelheid — een capaciteit (translate / enhancement / both), een standaard, een fallback-volgorde en een ingeschakeld-vlag.

Voeg er zoveel toe als je wilt: als een sleutel uitvalt (zonder tegoed, rate limit, een auth-fout) markeert de module hem met cooldown en schakelt over naar de volgende set inloggegevens in de keten, over providers heen, zodat een lange run een dode sleutel overleeft. Model en prompt worden vervolgens per stap in het profiel gekozen — verrijk met een topmodel en vertaal titels van lage waarde met een goedkoop, snel model, in één pipeline.

Max tokens (per set inloggegevens) is het maximum aan tokens dat een model mag genereren — een limiet, geen doel, dus je betaalt alleen voor wat wordt geproduceerd. Te laag en de tekst wordt afgekapt; bij redeneermodellen kan er zelfs niets terugkomen. De standaard van 4000 dekt beschrijving + korte beschrijving + titel + meta. Extended thinking staat standaard uit (het verbetert verkoopteksten niet) en je kunt een optionele prijs per AI instellen die in de kostenraming wordt meegenomen.

AI Compare

Open het tabblad AI Compare van een profiel, vink de te vergelijken modellen aan en kies een paar voorbeeldproducten. Run comparison verrijkt elk voorbeeld met elk model (een dry-run — er wordt niets weggeschreven) tot een matrix: één kolom per model, één rij per product, elke cel toont de gegenereerde titel met een referentie, de generatietijd, indicatieve €-kosten (uit de echte API-tokentellingen) en een Preview die het volledig gerenderde resultaat opent.

Een jury — het model dat je in de dropdown kiest, idealiter je meest capabele — beoordeelt elke uitvoer op taalkwaliteit, opmaak, gecontextualiseerde maten, premium register, JSON-geldigheid en SEO, en kiest een winnaar; het oordeel voegt de gemiddelde tijd en gemiddelde kosten per model toe. Kies All models judge en elk model geeft zijn eigen oordeel terug, één tabel per stuk. Een live timer en een skeleton tonen de jury aan het werk, een Stop-knop onderbreekt, en de laatste vergelijking wordt opgeslagen op het profiel zodat die — met een tijdstempel — weer verschijnt zonder opnieuw te draaien.

Hoe tokens werken (en wat een verkeerde instelling ervan veroorzaakt)

Elke magnify- of translate-stap is één aanroep naar een AI-model. Het model leest je persona-prompt, de bronvelden van het product en — wanneer het ook de titel genereert — een kleine steekproef van verwante titels: dat is de input. Vervolgens schrijft het één JSON-object met de herschreven velden: dat is de output. De provider rekent je beide aan, maar output-tokens kosten enkele keren meer dan input-tokens, dus de lengte van de gegenereerde tekst bepaalt de kosten.

Max tokens begrenst alleen de output die een model in één aanroep mag produceren. Het is een limiet, geen doel: eindigt de tekst vanzelf eerder, dan betaal je alleen voor wat geschreven is, dus een royale limiet kost nooit meer — het voorkomt alleen dat goede output wordt afgekapt. De standaardwaarde van 4000 dekt ruimschoots een rijke beschrijving plus short description, titel en meta description samen.

Wat een te lage limiet veroorzaakt. Als de output langer zou zijn dan de limiet, wordt het antwoord midden in een zin afgekapt en sluit de JSON nooit — de module kan het niet parsen. Sommige recente modellen doen vóór het schrijven ook verborgen reasoning: met een krappe limiet kunnen ze het hele budget aan nadenken besteden en helemaal niets teruggeven. In beide gevallen behoudt Babel niet stilzwijgend de oorspronkelijke tekst — het markeert dat product als mislukt met de echte reden in de wachtrij, zodat je de limiet kunt verhogen en opnieuw kunt proberen. Komen producten ooit ongewoon kort of “vastgelopen in de brontaal” terug, dan is de tokenlimiet het eerste om te controleren.

Extended thinking staat standaard uit, met opzet. Voor verkoopteksten in de catalogus verbetert het het resultaat niet — dezelfde tekst komt eruit — terwijl het tokens en tijd verbruikt en de valkuil van het lege antwoord hierboven riskeert. Laat het uit bij het genereren; de AI Compare-jury schakelt het alleen in waar reasoning echt helpt, en valt netjes terug wanneer het gekozen model het niet ondersteunt.

In de praktijk: houd Max tokens op 4000 (of iets hoger voor zeer lange beschrijvingen), houd de wachtrij in de gaten op fouten met een duidelijke reden in plaats van stille slechte output, en laat de kostenraming — gevoed door de echte tokenaantallen die de API teruggeeft — je vertellen wat elke run daadwerkelijk kost voordat je hem start.

De objectieve producteigenschappen

In veel catalogi staan de maten in geen enkel attribuut: ze zitten in de naam. Behangrol 10 m, Verlengsnoer 5 m. Een mens leest dat moeiteloos, de winkel niet: wie tien meter vraagt krijgt een pagina met één stuk, want geen veld zegt hoe lang één stuk is.

Terwijl Babel aan een product werkt, noteert het de meetbare feiten in het attribuut Product characteristics (Babel) op de productpagina, dat jij leest en corrigeert.

unita_vendita: confezione
copertura_pezzo: 2.22 m2
pezzi_confezione: 8
spessore: 8 mm
materiale: laminaat
tipologia: kliklaminaat (dedotto)

unita_vendita wordt nooit afgeleid. Het is een commerciële term: hij zegt waar de prijs op doelt. Een regel anders dan pezzo wordt alleen geschreven als alle drie gelden — hij is niet afgeleid, het getal dat de rekensom mogelijk maakt is er (pezzi_confezione voor het pak, copertura_pezzo voor meters), en het bewijs staat in de gegevens van het product, door de module nagekeken en niet op het woord van de AI aangenomen. Zegt niets het, dan ontbreekt de regel simpelweg, en dat betekent dat de prijs voor één stuk is: de veilige kant.

Het rekenwerk doet copertura_pezzo — hoeveel ÉÉN stuk dekt — een maat die uit het product te bepalen is. Een pak laminaat dat 2,22 m² dekt draagt unita_vendita: confezione en copertura_pezzo: 2.22 m2, en een vraag om dertig vierkante meter wordt veertien pakken. Zonder het paar werden het dertig pakken: meer dan het dubbele.

De markering (dedotto) is de grens. Een regel die zo eindigt heeft niemand geschreven: de AI heeft hem afgeleid. Hij helpt begrijpen en zoeken, maar er wordt nooit een aantal uit berekend. Om iets te bevestigen verwijder je dat woord; wat fout is corrigeer je, wat er niet hoort haal je weg. Het is jouw catalogus.

Bij een product met varianten draagt ieder zijn deel: de ouder wat voor alle varianten geldt (verkoopeenheid, materiaal, type), elke variant wat hem onderscheidt (zijn maat, zijn diameter). Varianten worden alleen verwerkt als er een maat verandert: verandert alleen de kleur, dan heeft de variant niets eigens te zeggen. Een gegroepeerd product of een bundel heeft geen eigen maten — het is een lijst artikelen, elk met de zijne — en op virtuele en downloadbare producten wordt niets geschreven: een cursus heeft geen maat.

Het herschrijft je teksten niet: het is een aparte, kleine aanroep met een eigen geheugen. Voor al verwerkte artikelen is er de knop Eigenschappen noteren op de profielpagina, of bin/magento babel:params --profile=3. In een echte catalogus: 38 ouderartikelen en 116 varianten doorlopen, de verkoopeenheid bij 34 van de 38 ouders — die hoort bij de ouder en nooit bij de variant, want hoe iets verkocht wordt verandert niet tussen de 80 en de 100.

Bij een variant is het veld vaak leeg, en dat is de juiste uitkomst: wat hem onderscheidt staat al in een Magento-attribuut (zijn gewicht, de maat waarin hij varieert), en het hier ook schrijven levert twee kopieën op die uiteen gaan lopen — waarbij de variant het van de ouder wint. In die catalogus dragen 97 van de 116 varianten een eigen regel, de andere 19 hadden niets toe te voegen. En de regels gelden ook voor wat er al staat: een regel die een oudere versie heeft achtergelaten en die het formaat van vandaag schendt, wordt bij de volgende ronde verwijderd, terwijl een regel die jij met de hand hebt gecorrigeerd nooit wordt aangeraakt.

Producttypen en hun verschillende behandeling

Een configureerbaar product is geen los artikel, een gegroepeerd product geen pakket, en een virtueel of downloadbaar product wordt niet verzonden. De module herkent het type zelf en geeft de AI een beschrijving van de structuur, die verandert wat de tekst zegt en wat hij niet mag zeggen.

Waar je het aanzet. Tabblad Mapping van het profiel, bij de afzonderlijke stap: Productstructuurcontext. Standaard uit: aanzetten verandert wat de AI krijgt en laat de pagina's van dat profiel bij de volgende ronde opnieuw genereren. Zet het aan vóór een nieuwe ronde, niet halverwege een lopende.

• In winkelwagen — een aantalkiezer op de kaart bevestigt voor het toevoegen. Sinds 2.2.0 worden ook producten met maten, kleuren of meerdere artikelen in de chat gekocht: de assistent vraagt één keuze per keer en de juiste variant komt in het winkelwagentje. De productpagina wordt alleen nog aangeboden voor opties die de chat niet aankan, zoals een gravure of een bestand dat geüpload moet worden.
• Bundel — krijgt de titels van de opties, welke verplicht zijn en welke artikelen in elke optie te kiezen zijn, zodat de tekst kan uitleggen hoe het product is samengesteld.
• Gegroepeerd — krijgt de lijst van gekoppelde artikelen, zodat de tekst kan zeggen dat ze samen worden gekocht en waar elk voor dient.
• Virtueel — krijgt alleen het type, en dat volstaat: de AI mag verzending, levering, verpakking en gewicht niet noemen. Zonder die regel schrijft het model snelle verzending ook bij een verlengde garantie.
• Downloadbaar — krijgt het aantal bestanden en of er een voorbeeld bestaat: de tekst legt de digitale levering uit, en verzending blijft verboden.

Varianten worden niet verwerkt. Ernaast staat Varianten overslaan, standaard aan op groepsniveau: een product dat als kind van een configureerbaar product voorkomt, blijft buiten de wachtrij. Het heeft geen pagina die een klant kan openen, dus verrijken is uitgeven zonder opbrengst; in een catalogus die op varianten is gebouwd vormen ze het grootste deel van de wachtrij. Wie varianten als zelfstandige artikelen verkoopt, zet het uit.

Doelen beperken. Op dezelfde stap beperken Producttypen en Zichtbaarheid de wachtrij tot wat je werkelijk wilt bewerken — bijvoorbeeld alleen configureerbare producten, of alleen producten die zichtbaar zijn in catalogus en zoekresultaten.

Cross-sell, gerelateerde en up-sell (AI-relaties)

Drie onafhankelijke schakelaars laten een profiel met behulp van de AI cross-sell-, gerelateerde en up-sell-producten voorstellen. Het model stelt uitsluitend echte SKU's uit je catalogus voor — het kan geen niet-bestaand product verzinnen — en de suggesties worden geschreven in Magento's native cross-sell-/gerelateerde/up-sell-koppelingen, zodat ze in de standaard storefront-blokken verschijnen. Zet alleen de relatietypes aan die je door de module wilt laten beheren.

Dry-run-voorbeeld (en gerenderd)

Voordat er iets wordt weggeschreven, voer je een profiel in dry-run uit: de module genereert de voorgestelde content voor een steekproef van producten en toont die naast de huidige tekst, inclusief een gerenderd voorbeeld zodat je ziet hoe de verbeterde beschrijving er echt uit zal zien op de pagina — niet alleen de ruwe tekst. In dry-run wordt niets opgeslagen; het dient om de persona prompt en de pipeline te valideren voordat je je vastlegt op een volledige run.

Het "Enrichments & Translations"-raster

Het tabblad "Enrichments & Translations" is het werkraster: elk gegenereerd veld voor elk product en elke taal, gepagineerd en filterbaar. Je kunt elke gegenereerde waarde inline bewerken voor of nadat die is toegepast — de AI-uitvoer is een startpunt, geen slot — en elke rij houdt een link naar de originele tekst, zodat je met één actie het origineel kunt herstellen voor dat veld als het resultaat je niet bevalt. Dit is de human-in-the-loop-laag boven de geautomatiseerde pipeline.

Teksten die u definitief verklaart

Vroeg of laat is er een product waarvan u de beschrijving zelf schrijft: het paradepaardje, het artikel waar de eigenaar aan hecht, het artikel waarvoor de AI-tekst goed was maar niet juist. U corrigeert hem met de hand, en vanaf dat moment wilt u één garantie — niemand herschrijft dit ooit nog. Die garantie is het selectievakje Final, nieuw in v3.4.0.

Open Enrichments & Translations, open een product, en onder elk veld staat een selectievakje met het label “Final — never regenerate this text”. Vink het aan en dat ene veld is van u.

Wat “final” precies betekent. Voor dat veld, op dat product, in die store view:

• de AI wordt er nooit meer voor aangeroepen — niet bij de volgende run, niet nadat u de persona-prompt wijzigt, niet nadat u van model wisselt, niet na een cache flush, niet wanneer u op Apply to already processed drukt. Het kost niets, voorgoed. En als elk veld van een product definitief is verklaard, wordt de AI-aanroep voor dat product helemaal niet gedaan;
• verdwijnt de waarde van het product — een importer heeft hem overschreven, iemand heeft het origineel hersteld, een migratie heeft hem gewist — dan zet de achtergrondcontrole uw definitief verklaarde tekst terug, opnieuw zonder kosten;
• het wint van de automatische regels van de module zelf. De meta title wordt bijvoorbeeld normaal gesproken altijd gedwongen de productnaam te volgen; verklaar de meta title final en uw tekst wint zelfs daarvan;
• het geldt uitsluitend voor dat ene veld. De overige velden van hetzelfde product worden gewoon gegenereerd. De beschrijving definitief verklaren bevriest niet de meta title, en haalt het product niet uit het profiel.

Bewerken in de grid vinkt het vakje voor u aan. Zodra u in de grid in een veld typt, vinkt het bijbehorende Final-vakje zichzelf aan. Het is het gedrag dat de interface impliceert — u bent erin gegaan en hebt die tekst gecorrigeerd, dus die correctie is precies waar het om gaat — en vóór v3.4.0 gebeurde het niet: een met de hand gecorrigeerde tekst overleefde tot de volgende promptwijziging en werd daarna stilzwijgend overschreven door een nieuwe generatie. Wilt u wel dat een gecorrigeerde tekst later opnieuw wordt gegenereerd, haal het vinkje dan weg voordat u opslaat.

Het enige om te onthouden: een final-veld is het enige in de module dat een wijziging van persona-prompt of model overleeft. Al het andere wordt opgebouwd uit het opgeslagen resultaat, en dat opgeslagen resultaat ligt opgeborgen onder een sleutel die de volledige prompt bevat — wijzigt u de prompt, dan is geen enkel opgeslagen resultaat nog herbruikbaar.

Teksten die vanzelf terugkomen

Hier is een storing die vroeger onopgemerkt bleef. Een product dat verwerkt is, komt nooit uit zichzelf opnieuw in de wachtrij — met opzet, zodat het opnieuw draaien van een profiel goedkoop en veilig is. Het neveneffect: overschrijft iets een gegenereerde tekst nadat het product is verwerkt, dan wordt dat product nooit meer bekeken. De winkel blijft de overschreven tekst tonen, de wachtrij zegt done, de historie bevat nog altijd de gegenereerde tekst, en nergens wordt een fout gemeld. We troffen het aan in een echte catalogus: 318 producten met Engelse titels en beschrijvingen in een Italiaanse winkel, wekenlang, terwijl de Italiaanse tekst gewoon in de historie van de module stond.

v3.4.0 maakt hier een einde aan. Een achtergrondcontrole draait elk uur en stelt per opgeslagen resultaat één vraag, waarbij alleen de database wordt gelezen en er nooit een AI voor wordt aangeroepen: staat de tekst die ik heb geschreven nog op het product? Is het antwoord nee, dan gaat het product terug in de wachtrij met de goedkoopste behandeling die past:

Hij werkt in plakjes, en dat is belangrijk. Elke run bekijkt 500 opgeslagen resultaten en onthoudt waar hij is gestopt, om een uur later vanaf daar verder te gaan. De vergelijking kost twee query's per rij, dus een grote catalogus elk uur helemaal doorlopen zou een belasting zijn waar niemand om heeft gevraagd. De hele catalogus komt nog steeds aan de beurt — alleen gespreid in de tijd. Op een grote catalogus betekent dat dat een tekst die is verdwenen uren kan wachten, en op een zeer grote catalogus een paar dagen, voordat de controle erbij is. Het hangt niet, het is er alleen nog niet. Hebt u nu een antwoord nodig, dan kijkt bin/magento babel:reapply onmiddellijk naar wat u hem aanwijst.

U regelt dit onder Stores → Configuration → Codingrow → AI Babel Enchanter → Keeping the texts in place:

• Put back texts that disappeared — standaard Yes. Zet u hem op No, dan wordt er nooit iets automatisch teruggezet; het commando babel:reapply blijft beschikbaar voor handmatige rondes.
• At most, per check — standaard 200. Alles boven de limiet wordt door de volgende runs opgepakt. Zet hem op 0 om de achtergrondcontrole uit te schakelen.

Waarom de limiet producten telt en geen AI-aanroepen. “Deze kost niets” is een voorspelling op basis van het opgeslagen resultaat. Hebt u intussen de prompt of het model gewijzigd, dan is dat opgeslagen resultaat niet meer bruikbaar en verandert een herstel dat gratis leek in een betaald herstel. Door producten te begrenzen blijft de rekening ook begrensd wanneer de voorspelling ernaast zit. Gratis herstelacties worden als eerste verwerkt, zodat het goedkope werk altijd gedaan is voordat de limiet wordt bereikt.

Wat hij niet doet, en wat hij wel doet. Hij raakt nooit prijzen, voorraad, afbeeldingen of welk attribuut dan ook aan buiten de attributen die het profiel beheert, en hij neemt nooit een product op dat nooit is verwerkt. Maar wees duidelijk over het deel dat mensen verrast: hij zet het product terug in de wachtrij, en de run herschrijft vervolgens elk veld dat dat profiel beheert. Hebt u een van die velden op de productpagina gecorrigeerd, dan wordt die correctie dus vervangen. Dat is geen bug, het is de regel van de twee kanalen: een correctie die u wilt behouden hoort thuis in de grid, of krijgt het vinkje Final.

Op de commandoregel bin/magento babel:reapply rapporteert alleen en schrijft niets tenzij u --confirm meegeeft — de veilige manier om de staat van een catalogus te bekijken voordat u beslist. Voeg --only-free toe voor de herstelacties die niets kosten, en --profile en --limit om de ronde te beperken.

Een nieuwe prompt toepassen op de producten die al klaar zijn

Profielen zijn bewust anti-revert: een product dat al verwerkt is, wordt niet opnieuw verwerkt, en juist daardoor is het opnieuw draaien van een profiel veilig en goedkoop. De keerzijde is dat een verbeterde persona-prompt alleen de producten bereikt die vanaf dat moment worden verwerkt — alles wat al klaar is, houdt de oude tekst. Tot v3.4.0 was babel:run --force op de commandoregel de enige manier om ze alsnog mee te nemen.

Nu heeft de profielpagina er een knop voor.

Apply to already processed zet de producten met de status done, partial en skipped terug in de wachtrij van dat profiel. De bevestiging benoemt de kosten in gewone taal voordat er iets gebeurt: “Producten waarvan de brontekst niet is gewijzigd, worden kosteloos hergebruikt. De rest wordt door de AI herschreven, wat uw provider bij u in rekening brengt; houd er na een wijziging van de persona of de instructies dus rekening mee dat het hele profiel wordt herschreven.”

Die laatste zin is geen standaardtekst. Elk magnify-resultaat ligt opgeborgen onder een sleutel die de provider, het model en de volledige systeemprompt bevat. Wijzigt u de persona, wijzigt u de template, wisselt u van model, dan is geen enkel magnify-resultaat in de catalogus nog herbruikbaar — en de vertalingen volgen, want wat zij vertalen is zojuist gewijzigd. Op deze knop drukken na een promptwijziging betekent dus “genereer dit hele profiel opnieuw, en betaal ervoor”. Vóór een promptwijziging, op een onaangeroerde catalogus, is dezelfde knop vrijwel gratis.

Gebruik hem wanneer u de prompt hebt verbeterd en de oude producten op het nieuwe niveau wilt brengen; wanneer u een attribuut aan een groep hebt toegevoegd en het overal ingevuld wilt zien; wanneer u een fout in een mapping hebt hersteld. Gebruik hem niet wanneer u alleen teksten wilt repareren die zijn verdwenen — daarvoor is de achtergrondcontrole hierboven, en die is veel goedkoper.

Velden die Final zijn verklaard, worden ook door deze knop niet opnieuw gegenereerd.

Als uw catalogus wordt geïmporteerd

Komen producten in Magento binnen via een leveranciersfeed, een ERP, een PIM of welke geplande import dan ook, dan schrijven die importer en Babel naar dezelfde velden. Of die twee vreedzaam samengaan, hangt af van hoe de importer is ingesteld en van hoeveel store views u hebt — en gaan ze niet samen, dan is het symptoom geen foutmelding: het is uw betaalde tekst die stilletjes verdwijnt terwijl elk scherm nog altijd succes meldt.

De acceptatietest kost één minuut: verrijk één product, draai de import zonder iets in de feed te wijzigen en laad het product opnieuw. Staat de tekst van Babel er nog, dan is die importer compatibel. Is de leverancierstekst terug, dan is hij dat niet — en geen enkele instelling in Babel verhelpt dat.

Rollback

Elke waarde die de module schrijft is omkeerbaar. Naast het per rij origineel herstellen in het raster draait het CLI-commando babel:rollback content in bulk terug — per profiel, per product of voor de hele run — naar de tekst die er stond voordat de module ingreep. Omdat het origineel altijd bewaard blijft, is een run over de hele catalogus nooit een eenrichtingsdeur.

Queue en circuit breaker op tegoed

Lange runs worden verwerkt via een wachtrij die je kunt bekijken, pauzeren en hervatten. De ingebouwde circuit breaker (geconfigureerd onder Resilience) beschermt de run: bij herhaalde providerfouten — meestal een provider zonder tegoed of met een rate limit — pauzeert die na N fouten, wacht de ingestelde cooldown af en kan tijdelijke fouten automatisch opnieuw proberen in plaats van de hele batch te laten mislukken. Wanneer je tegoed bijvult of de limiet reset, hervat je de wachtrij en gaat die verder waar hij gebleven was.

Verkopersvermeldingen: retour en verzending

Google leest retour- en verzendvoorwaarden van de productpagina om ze in zijn gratis verkopersvermeldingen te tonen, en Search Console meldt ze als ontbrekend wanneer ze er niet zijn. Ze zijn niet uit de catalogus af te leiden — het zijn commerciële voorwaarden — dus worden ze opgegeven in de configuratie, onder Merchant listings (returns and shipping). Beide blokken staan standaard uit en vereisen dat de gestructureerde productgegevens aan staan.

• Retourvoorwaarden → hasMerchantReturnPolicy: landen (uit de lijst van Magento), retourtermijn, dagen, hoe de goederen terugkomen, wie betaalt en eventuele kosten.
• Verzendvoorwaarden → shippingDetails: landen waarnaar je verzendt, kosten (0 voor gratis verzending), verwerkings- en levertijd in werkdagen.

Twee regels zijn bewust. Een blok met onvolledige verplichte velden wordt in zijn geheel weggelaten in plaats van half waar gepubliceerd: Google vergelijkt wat je opgeeft met wat de klant op je site aantreft, dus een verkeerde opgave is minder waard dan geen. En bij "retouren niet geaccepteerd" worden noch de methode noch de betaler gepubliceerd: er is geen retour te beschrijven.

Het aanbod bevat ook validFrom, de datum vanaf wanneer de gepubliceerde prijs geldt: de start van de speciale prijs als die er is, anders de aanmaakdatum van het product. Daarvoor is geen configuratie nodig.

Deze voorwaarden gelden zelden voor de hele catalogus: verwerkings- en levertijden verschillen tussen eigen magazijn en dropshipping, verzending hangt af van het volume, de retourtermijn van wat je verkoopt. En het getal staat meestal al op het product, in een attribuut dat je importeur of je team invult. Elk van die velden kan daarom naar een productattribuut wijzen — de lijst bevat ook je eigen attributen — met een vakje om een code te typen die de lijst niet aanbiedt. Waar het product een waarde heeft, wint het product; waar niet, blijft de vaste waarde staan; en een waarde die geen getal is valt terug op de vaste in plaats van onzin te publiceren.

Elk getal kan uit een productattribuut komen, gekozen uit de lijst van de catalogus: hier komen verwerkings- en levertijd uit de attributen die een importeur invult.

Opdrachtregel (CLI)

Alles kan vanaf de CLI worden aangestuurd voor planning en grote runs.