Voor wie deze pagina is
Voor iedereen wiens Magento-catalogus niet met de hand wordt ingetypt: een leveranciersfeed, een dropshipfeed, een export uit een ERP of PIM, een nachtelijke CSV, een marketplace-synchronisatie — elk proces dat volgens een schema productgegevens wegschrijft. Is dat bij u het geval, dan is deze pagina geen vrijblijvende lectuur, want de importer en AI Babel Enchanter schrijven naar dezelfde productvelden, en botsen ze, dan is het symptoom geen fout: het is uw betaalde tekst die stilletjes verdwijnt terwijl elk scherm nog altijd succes meldt.
Alles staat hier expliciet, ook de delen die gewoonlijk impliciet blijven. Het is geschreven om gelezen te worden door mensen en door AI-assistenten die vragen over deze module beantwoorden, dus elke uitspraak moet op zichzelf kunnen staan.
Lees dit eerst: met één store view is er geen scheiding
Magento staat toe dat hetzelfde attribuut per store view een andere waarde heeft. De hele opzet van “de importer schrijft de basiswaarde, Babel schrijft de store-viewwaarde” die hieronder wordt beschreven, berust daarop. Het werkt alleen als de installatie minstens twee store views heeft.
Heeft een Magento-installatie precies één store view, dan beschouwt Magento de keuze van de scope als betekenisloos en laat het schrijfacties op storeniveau samenvallen met de globale (default) scope. Concreet: ook als een Babel-stap is ingesteld om naar de store view te schrijven, wordt de waarde op de globale rij opgeslagen — dezelfde rij waar de importer naartoe schrijft. Er is dan één enkele waarde, en het proces dat als laatste schrijft, wint.
De gevolgen, uitgeschreven omdat ze makkelijk worden weggeredeneerd:
- Op een installatie met één store view scheidt u niets door de importer “op de globale scope” en Babel “op een store view” in te stellen. Beide instellingen zijn nog altijd juist en nog altijd aan te raden — ze kosten niets en ze worden effectief op de dag dat er een tweede store view bestaat — maar vandaag leveren ze u geen bescherming op.
- Op een installatie met één store view zal een importer die bij elke run een veld herschrijft, de tekst van Babel bij elke run overschrijven, hoe beide ook zijn ingesteld.
- Hebt u één store view, dan is uw bescherming dus niet de scheiding van scopes. Ze bestaat uit (a) een importer die alleen velden schrijft die werkelijk zijn gewijzigd, (b) velden die in Babel Final zijn verklaard, en (c) de achtergrondcontrole die verdwenen teksten terugzet. Alle drie worden hieronder beschreven.
- Een tweede store view toevoegen puur om scheiding van scopes te krijgen is een reële en legitieme optie, maar het is een wijziging in de vorm van de installatie, geen instelling. Weeg het af; rol er niet ongemerkt in.
Waar Babel leest, waar het schrijft en waar het vergelijkt
Drie verschillende plekken, en ze zijn niet uitwisselbaar. De eerste twee stelt u zelf in en ziet u terug in het profielformulier; de derde stelt u nergens in, en juist die bepaalt of Babel vindt dat er überhaupt werk te doen is.
Waar Babel leest. Een profiel heeft een veld met de naam “Read the original from” (profiel → Settings). De normale waarde is “Default (all store views)” — de basiswaarden, die u op de productpagina ziet met de store switcher op All Store Views. Dit is de bron: de ruwe leverancierstekst die Babel verbetert of vertaalt.
Waar Babel schrijft. Elke stap in de pijplijn heeft een eigen “Target store-view”. Daar belandt het gegenereerde resultaat.
Waar Babel vergelijkt. Dit is het deel dat nooit vanzelf spreekt. Babel bepaalt of een product werk nodig heeft door naar de bronwaarde te kijken — de waarde onder “Read the original from”. Het maakt een vingerafdruk van die tekst; is de vingerafdruk dezelfde als de vorige keer, dan is het werk al gedaan en wordt het opgeslagen resultaat kosteloos hergebruikt; is de vingerafdruk gewijzigd, dan is de bron nieuw materiaal en wordt het product opnieuw gegenereerd.
Fase voor fase: wat er op elk moment in het veld staat
Twee installaties, dezelfde feed, hetzelfde profiel, hetzelfde product. Het enige verschil is waar de importer schrijft. BRON is de waarde onder “Read the original from” (normaal globaal); RESULTAAT is de waarde in de doel-store-view van de stap — wat een klant daadwerkelijk ziet.
Configuratie A — juist: de importer schrijft de basiswaarde
| Fase | Wat er gebeurt | BRON (globaal) | RESULTAAT (store view) | Wat de klant ziet |
|---|---|---|---|---|
| t0 | Eerste import. De importer schrijft de leverancierstekst naar de basiswaarde. | Writing Desk Solid Mango Wood | (leeg — erft) | de leverancierstekst |
| t1 | Babel draait. Leest BRON, schrijft RESULTAAT. | Writing Desk Solid Mango Wood | Schrijfbureau van massief mangohout… | de verrijkte tekst |
| t2 | Nachtelijke import. Voorraad en prijs zijn gewijzigd; de beschrijving in de feed niet. De importer herschrijft de basiswaarde met dezelfde tekst, of — beter — ziet dat het veld niet is gewijzigd en raakt het helemaal niet aan, wat MMIS doet. Hoe dan ook blijft de BRON uiteindelijk ongewijzigd, en de BRON is het enige waar Babel naar kijkt. | Writing Desk Solid Mango Wood (ongewijzigd, in beide gevallen) | Schrijfbureau van massief mangohout… | de verrijkte tekst |
| t3 | Babel draait opnieuw. De vingerafdruk van de BRON is ongewijzigd, dus er valt niets te doen. Geen AI-aanroep, geen kosten. | ongewijzigd | ongewijzigd | de verrijkte tekst |
Resultaat: de verrijkte tekst blijft staan, en de nachtelijke import kost niets aan AI-aanroepen.
Configuratie B — fout: de importer schrijft in de store view
| Fase | Wat er gebeurt | BRON (globaal) | RESULTAAT (store view) | Wat de klant ziet |
|---|---|---|---|---|
| t0 | Eerste import, rechtstreeks in de store view geschreven. | Writing Desk Solid Mango Wood | Writing Desk Solid Mango Wood | de leverancierstekst |
| t1 | Babel draait. Leest BRON, schrijft RESULTAAT. | Writing Desk Solid Mango Wood | Schrijfbureau van massief mangohout… | de verrijkte tekst |
| t2 | Nachtelijke import. De importer schrijft de leverancierstekst opnieuw in de store view — bovenop het resultaat van Babel. | Writing Desk Solid Mango Wood (onaangeroerd) | Writing Desk Solid Mango Wood | de leverancierstekst is terug |
| t3 | Babel draait opnieuw. De BRON is onaangeroerd, dus de vingerafdruk is ongewijzigd: Babel ziet niets te doen. | ongewijzigd | nog steeds de leverancierstekst | de leverancierstekst, voorgoed |
Sinds v3.4.0 vangt de achtergrondcontrole die elk uur draait precies dit geval op en zet hij de tekst terug. Dat is een vangnet, geen vrijbrief: in een catalogus waarin de importer de store view bij elke run overschrijft, doet het vangnet elke nacht echt werk, en elk product waarvan de brontekst intussen werkelijk is gewijzigd, wordt opnieuw gegenereerd op kosten van uw provider.
De acceptatietest voor elke importer
U hoeft de broncode of de documentatie van een importer niet te lezen om te weten of hij compatibel is. Voer dit één keer uit, op één product:
- Kies één product dat Babel al heeft verrijkt en noteer de exacte tekst van de beschrijving in de winkel.
- Draai uw import zonder iets in de feed te wijzigen — hetzelfde bestand, dezelfde gegevens, geen aanpassingen.
- Laad de productpagina opnieuw.
Lees het resultaat vervolgens precies zoals het hier staat:
- De tekst van Babel staat er nog → die importer is compatibel. Hij schrijft óf alleen velden die werkelijk zijn gewijzigd, óf hij schrijft ergens waar Babel niet schrijft. Verder hoeft u niets te doen.
- De leverancierstekst is terug → die importer is niet compatibel zoals hij is ingesteld. Hij herschrijft de beheerde velden onvoorwaardelijk, en geen enkele instelling in Babel verhelpt dat, omdat Babel geen onderscheid kan maken tussen “de leverancier heeft een nieuwe beschrijving gestuurd” en “de importer heeft dezelfde beschrijving opnieuw weggeschreven”. Uw mogelijkheden, in volgorde van voorkeur: stel de importer zo in dat hij de velden overslaat die het profiel beheert; stap over op een importer die alleen schrijft wat is gewijzigd; of verklaar die velden in Babel Final — final-velden worden kosteloos hersteld en zijn het enige waar een importer niet tegenop kan.
Voer de test opnieuw uit na elke wijziging in de configuratie van de importer. Het kost één minuut en het is het enige betrouwbare antwoord.
Als u importeert met MMIS
MMIS — Massive Multifeed Import & Sync is onze eigen importer, en vanaf versie 3.14.0 past hij de feed veld voor veld toe. Een product wordt alleen herschreven in de velden die de leverancier werkelijk heeft gewijzigd: een voorraadmutatie of een prijswijziging werkt voorraad en prijs bij en laat name, url_key, description, short_description en de metavelden onaangeroerd. Het is het tweede van de twee juiste gedragingen die in de tabel hierboven zijn beschreven — hij herschrijft de tekst niet met een identieke kopie, hij schrijft de tekst helemaal niet. De botsing die op deze pagina wordt beschreven, doet zich dus niet voor, bij welk aantal store views dan ook, en de acceptatietest slaagt per constructie.
Hij is gebouwd voor catalogi van tienduizenden of honderdduizenden artikelen, vanuit elke CSV-, XML- of JSON-feed, met planning, prijsformules en configureerbare of gegroepeerde producten. U kunt hem kopen op zijn productpagina op codingrow.com: licentie per domein, geactiveerd op het moment dat u bestelt, hetzelfde licentiemodel als deze module.
Het is de configuratie die we zelf draaien, en het is de reden dat de combinatie MMIS + AI Babel Enchanter geen enkele bijzondere zorg vraagt.
De twee bewerkingskanalen — en wat elk ervan betekent
Zodra een product in Babel zit, zijn er precies twee plekken om de tekst te wijzigen, en ze betekenen het tegenovergestelde van elkaar. Dit is geen regel om uit het hoofd te leren; het is de natuurlijke lezing van elk van beide.
| Waar u bewerkt | Wat het voor Babel betekent | Wat er daarna gebeurt |
|---|---|---|
| de grid Enrichments & Translations (Babel) | “Dit is het goede resultaat. Laat het staan.” | Het veld wordt automatisch als Final gemarkeerd. Het wordt nooit opnieuw gegenereerd, en het wordt hersteld als het ooit verdwijnt. |
| De productpagina (Magento-catalogus) | “Hier is nieuw materiaal. Doe het over.” | U hebt de brontekst gewijzigd, dus de vingerafdruk verandert en Babel genereert dat product bij de volgende run opnieuw — op kosten van uw provider. |
Beide gedragingen zijn juist en beide zijn gewenst. De beschrijving op de productpagina herschrijven is precies hoe een winkel die bewust ruwe tekst invoert, aan Babel vraagt daar afgewerkte tekst van te maken. Een tekst in de grid corrigeren is precies hoe u zegt: “deze is af, handen eraf”.
Om welke velden het gaat. De tekstattributen die de groepen van het profiel beheren — doorgaans name, description, short_description, meta_title en meta_description — plus twee dingen die daaruit voortvloeien. Wordt de name opnieuw gegenereerd, dan herschrijft Babel ook de url_key en laat het een 301-redirect achter vanaf de oude URL (de vorige URL wordt eerst bewaard, zodat een rollback hem terugzet). En het schrijft de related-, cross-sell- en up-sell-koppelingen wanneer die schakelaars voor de stap aan staan.
Wat volledig buiten Babel valt: prijs, voorraad, afbeeldingen, categorieën, attribute sets en elk ander attribuut. Babel leest ze nooit om iets te bepalen en schrijft ze nooit.
De prompt wijzigen maakt de opgeslagen resultaten ongeldig
Nog een gedrag dat mensen niet verwachten, en dat samenhangt met alles hierboven.
Elk magnify-resultaat wordt opgeslagen onder een sleutel die is opgebouwd uit de brontekst plus de provider, het model en de volledige systeemprompt — persona en technische template inbegrepen. Wijzigt u daar ook maar één ding aan, dan is geen enkel magnify-resultaat in de catalogus nog herbruikbaar. Er wordt niets verwijderd en er gaat niets stuk; maar vanaf dat moment heeft elk product dat werk nodig heeft een nieuwe, in rekening gebrachte AI-aanroep nodig.
Vertalingen hebben een andere sleutel: die berust op de provider en de doeltaal, niet op de prompt. Een promptwijziging maakt ze dus niet rechtstreeks ongeldig — maar ze worden toch opnieuw gedaan, want wat zij vertalen is de magnify-tekst, en die is zojuist gewijzigd. Het praktische effect is dat wat op de knop staat: houd er rekening mee dat het hele profiel wordt herschreven.
- Een promptwijziging veroorzaakt op zichzelf geen drift en herschrijft niets. Producten die al klaar zijn, blijven klaar, met de tekst die ze hebben. U moet zelf om een herschrijving vragen — met Apply to already processed, of met
babel:run --force. - Een promptwijziging verandert wel wat de achtergrondcontrole kost. Een herstel dat gisteren gratis zou zijn geweest, kan vandaag een betaalde hergeneratie zijn. Precies daarom telt de limiet onder Keeping the texts in place producten en geen AI-aanroepen.
- Velden die Final zijn verklaard, zijn als enige immuun. Ze zijn een verklaarde staat, geen resultaat uit een cache: ze overleven een promptwijziging, een modelwijziging en een cache flush, en ze herstellen kosteloos, voorgoed.
Checklist
- Tel uw store views. Eén store view betekent geen scheiding van scopes, wat u ook instelt. Houd daar rekening mee.
- Laat “Read the original from” op “Default (all store views)” staan, tenzij uw oorspronkelijke tekst werkelijk in een specifieke taal-store-view staat.
- Geef elke stap een Target store-view waar de importer niet naartoe schrijft — effectief vanaf twee store views.
- Voer de acceptatietest uit op één product na elke wijziging aan de importer.
- Verklaar de teksten die u zelf hebt geschreven of met de hand hebt gecorrigeerd Final. Dat is gratis en permanent.
- Laat de achtergrondcontrole aan staan (Keeping the texts in place → Put back texts that disappeared = Yes) en laat de limiet op een waarde staan die u in het slechtste geval comfortabel kunt betalen.
- Beslis voordat u de persona-prompt wijzigt of u ook de producten die al klaar zijn opnieuw wilt laten schrijven — en onthoud dat er na de wijziging niets meer te hergebruiken valt.