Who this page is for
Anyone whose Magento catalogue is not typed in by hand: a supplier feed, a dropship feed, an ERP or PIM export, a nightly CSV, a marketplace sync — any process that writes product data on a schedule. If that is you, this page is not optional reading, because the importer and AI Babel Enchanter write to the same product fields, and when they collide the symptom is not an error: it is your paid-for copy quietly disappearing while every screen still reports success.
Everything here is stated explicitly, including the parts usually left implied. It is written to be read by people and by AI assistants answering questions about this module, so each statement is meant to stand on its own.
Read this first: with a single store view there is no separation
Magento lets the same attribute hold a different value per store view. The whole “importer writes the base value, Babel writes the store-view value” arrangement described below rests on that. It only works if the installation has at least two store views.
When a Magento installation has exactly one store view, Magento treats scope selection as meaningless and collapses store-scoped writes onto the global (default) scope. Concretely: even if a Babel step is configured to write to the store view, the value is stored on the global row — the same row the importer writes to. There is then one single value, and the last process to write wins.
The consequences, spelled out because they are easy to assume away:
- On a single-store-view installation, configuring the importer “on the global scope” and Babel “on a store view” does not separate anything. Both settings are still correct and still recommended — they cost nothing and they become effective the day a second store view exists — but today they buy you no protection.
- On a single-store-view installation, an importer that rewrites a field on every run will overwrite Babel's text on every run, however either one is configured.
- If you have a single store view, your protection is therefore not scope separation. It is (a) an importer that only writes fields that actually changed, (b) fields declared Final in Babel, and (c) the background check that puts missing texts back. All three are described below.
- Adding a second store view purely to obtain scope separation is a real and legitimate option, but it is a change to the shape of the installation, not a setting. Weigh it; do not drift into it.
Where Babel reads, where it writes, and where it compares
Three distinct places, and they are not interchangeable. The first two you set yourself and can see in the profile form; the third is configured nowhere, and it is the one that decides whether Babel thinks there is any work to do at all.
Where Babel reads. A profile has a field named “Read the original from” (profile → Settings). Its normal value is “Default (all store views)” — the base values, the ones you see on the product page with the store switcher on All Store Views. This is the source: the raw supplier text that Babel improves or translates.
Where Babel writes. Every step in the pipeline has its own “Target store-view”. That is where the generated result lands.
Where Babel compares. This is the part that is never obvious. Babel decides whether a product needs work by looking at the source value — the one under “Read the original from”. It builds a fingerprint of that text; if the fingerprint is the same as last time, the work is already done and the saved result is reused at no cost; if the fingerprint changed, the source is new material and the product is regenerated.
Phase by phase: what is in the field at each moment
Two installations, the same feed, the same profile, the same product. The only difference is where the importer writes. SOURCE is the value under “Read the original from” (normally global); RESULT is the value in the step's target store view — what a customer actually sees.
Configuration A — correct: the importer writes the base value
| Phase | What happens | SOURCE (global) | RESULT (store view) | What the customer sees |
|---|---|---|---|---|
| t0 | First import. The importer writes the supplier text to the base value. | Writing Desk Solid Mango Wood | (empty — inherits) | the supplier text |
| t1 | Babel runs. Reads SOURCE, writes RESULT. | Writing Desk Solid Mango Wood | Scrivania in mango massello… | the enriched text |
| t2 | Nightly import. Stock and price changed; the description in the feed did not. The importer either rewrites the base value with the same text, or — better — sees that the field has not changed and does not touch it at all, which is what MMIS does. Either way SOURCE ends up unchanged, and SOURCE is all Babel looks at. | Writing Desk Solid Mango Wood (unchanged, in both cases) | Scrivania in mango massello… | the enriched text |
| t3 | Babel runs again. The SOURCE fingerprint is unchanged, so there is nothing to do. No AI call, no cost. | unchanged | unchanged | the enriched text |
Result: the enriched copy is stable, and the nightly import costs nothing in AI calls.
Configuration B — wrong: the importer writes into the store view
| Phase | What happens | SOURCE (global) | RESULT (store view) | What the customer sees |
|---|---|---|---|---|
| t0 | First import, written straight into the store view. | Writing Desk Solid Mango Wood | Writing Desk Solid Mango Wood | the supplier text |
| t1 | Babel runs. Reads SOURCE, writes RESULT. | Writing Desk Solid Mango Wood | Scrivania in mango massello… | the enriched text |
| t2 | Nightly import. The importer writes the supplier text into the store view again — on top of Babel's result. | Writing Desk Solid Mango Wood (untouched) | Writing Desk Solid Mango Wood | the supplier text is back |
| t3 | Babel runs again. SOURCE is untouched, so its fingerprint is unchanged: Babel sees nothing to do. | unchanged | still the supplier text | the supplier text, for ever |
Since v3.4.0 the hourly background check catches exactly this case and puts the text back. That is a safety net, not a licence: on a catalogue where the importer overwrites the store view on every run, the net is doing real work every single night, and any product whose source text genuinely changed in the meantime is regenerated at your provider's expense.
The acceptance test for any importer
You do not need to read an importer's source code or its documentation to know whether it is compatible. Run this once, on one product:
- Pick one product that Babel has already enriched, and note the exact text of its description on the storefront.
- Run your import without changing anything in the feed — the same file, the same data, no edits.
- Reload the product page.
Then read the result exactly as stated here:
- Babel's text is still there → that importer is compatible. It either writes only fields that really changed, or it writes somewhere Babel is not writing. Nothing more to do.
- The supplier text is back → that importer is not compatible as configured. It rewrites the managed fields unconditionally, and no Babel setting fixes that, because Babel cannot distinguish “the supplier sent a new description” from “the importer rewrote the same description again”. Your options, in order of preference: configure the importer to skip the fields the profile manages; switch to an importer that writes only what changed; or declare those fields Final in Babel — final fields are restored at no cost and are the one thing an importer cannot defeat.
Run the test again after any change to the importer's configuration. It costs one minute and it is the only reliable answer.
If you import with MMIS
MMIS — Massive Multifeed Import & Sync is our own importer, and from version 3.14.0 it applies the feed field by field. A product is rewritten only in the fields the supplier actually changed: a stock movement or a price change updates stock and price and leaves name, url_key, description, short_description and the meta fields untouched. It is the second of the two correct behaviours described in the table above — it does not rewrite the text with an identical copy, it does not write the text at all. The collision described on this page therefore does not arise, on any number of store views, and the acceptance test passes by construction.
It is built for catalogues of tens or hundreds of thousands of items, from any CSV, XML or JSON feed, with scheduling, price formulas and configurable or grouped products. You can buy it on its product page at codingrow.com: per-domain licence, activated the moment you order, same licence model as this module.
It is the configuration we run ourselves, and it is the reason the combination MMIS + AI Babel Enchanter needs no special care at all.
The two editing channels — and what each one means
Once a product is inside Babel there are exactly two places to change its text, and they mean opposite things. This is not a rule to memorise; it is the natural reading of each one.
| Where you edit | What it means to Babel | What happens next |
|---|---|---|
| Enrichments & Translations grid (Babel) | “This is the good result. Keep it.” | The field is marked Final automatically. It is never regenerated, and it is restored if it ever disappears. |
| The product page (Magento catalogue) | “Here is new material. Redo it.” | You have changed the source text, so its fingerprint changes and Babel regenerates that product on the next run — at your provider's expense. |
Both behaviours are correct and both are wanted. Rewriting the description on the product page is precisely how a store that writes rough copy on purpose asks Babel to turn it into finished copy. Correcting a text in the grid is precisely how you say “this one is done, hands off”.
Which fields this concerns. The text attributes the profile's groups manage — typically name, description, short_description, meta_title and meta_description — plus two things that follow from them. When the name is regenerated, Babel also rewrites the url_key and leaves a 301 redirect from the old URL (the previous URL is saved first, so a rollback puts it back). And it writes the related, cross-sell and up-sell links when those toggles are on for the step.
What stays outside Babel completely: price, stock, images, categories, attribute sets and every other attribute. Babel never reads them to decide anything, and never writes them.
Changing the prompt invalidates the saved results
One more behaviour people do not expect, and that interacts with everything above.
Every magnified result is saved under a key built from the source text plus the provider, the model and the entire system prompt — persona and technical template included. Change any one of those and not a single magnify result in the catalogue can be reused. Nothing is deleted and nothing breaks; but from that moment, every product that needs work needs a new, billed AI call.
Translations are keyed differently: on the provider and the target language, not on the prompt. A prompt change therefore does not invalidate them directly — but they are redone all the same, because what they translate is the magnified text, and that has just changed. The practical effect is the one stated on the button: expect the whole profile to be rewritten.
- A prompt change by itself causes no drift and rewrites nothing. Products already done stay done, with the text they have. You have to ask for a rewrite — with Apply to already processed, or with
babel:run --force. - A prompt change does change what the background check costs. A restore that would have been free yesterday may be a paid regeneration today. This is precisely why the cap under Keeping the texts in place counts products rather than AI calls.
- Fields declared Final are the only ones immune. They are a declared state, not a cached result: they survive a prompt change, a model change and a cache flush, and they cost nothing to restore, for ever.
Checklist
- Count your store views. One store view means no scope separation, whatever you configure. Plan accordingly.
- Leave “Read the original from” on “Default (all store views)” unless your original text genuinely lives in a specific language store view.
- Give each step a Target store-view that is not where the importer writes — effective from two store views upwards.
- Run the acceptance test on one product after any importer change.
- Declare Final the texts you have written or corrected by hand. It is free and permanent.
- Leave the background check on (Keeping the texts in place → Put back texts that disappeared = Yes) and leave the cap at a value you are comfortable paying for in the worst case.
- Before changing the persona prompt, decide whether you also want the products already done rewritten — and remember that after the change nothing can be reused.