AI will write 5,000 Romanian listings in a weekend. On Monday the problems start

Just a few years ago, localizing a few thousand products for a new market meant weeks of work, a big team and a fairly serious budget.

Today?

Load the data into AI, prepare a prompt and, in theory, you can have your whole Romanian catalog ready before Monday.

Sounds great. And it actually is great.

As long as we don’t confuse two completely different things: a quickly generated catalog and a well-localized catalog.

AI has changed what’s possible in e-commerce expansion. It lets us work faster, cheaper and, above all, at a scale that until recently needed whole teams.

But with that scale came a new problem.

Today we don’t only have to worry about whether AI makes a mistake. We have to worry that we can automatically copy the same mistake 5,000 times.

One mistake times 5,000

With 20 products, mistakes can still be caught by hand. On one fairly important condition, of course: you have someone who knows the language well enough to notice that something is wrong at all.

Because if the reviewer doesn’t speak Romanian, they can look at a grammatically correct sentence and have no reason whatsoever to question it.

And AI sounds very convincing. Even when it’s wrong.

With a catalog of several thousand SKUs, the problem gets even bigger.

The model can add a parameter the product never had. Mix up a material. Misread a variant. Change what’s in a set. Use a term that is linguistically correct but completely unnatural for the local market.

It can also create a bolder claim that wasn’t in the source data, or keep “optimizing for SEO” until the text reads more like a bag of keywords than a listing written for a shopper.

And then there’s one of my favourite problems with large catalogs: different names for the same type of product.

Because AI loves synonyms. E-commerce, not so much.

One brush head, two names and a lot of listings

Let’s take an example completely unrelated to the industries I work with every day.

We sell replacement heads for electric toothbrushes.

The model may translate the term into Romanian as:

“vârf pentru periuță electrică”

instead of the term we had checked and agreed on earlier:

“capăt pentru periuță electrică”.

With one product, that’s simply one bad translation. You fix it. End of story.

But imagine the company has dozens of models, several brands, packs of 2, 4 and 8, different bristle types, compatibilities and variants.

For one product AI uses “vârf”. For another, “capăt”. For a third, it may find yet another term.

One name appears in the category, another in the filter, a third in the product title, and we send a fourth version to Google Merchant Center or the marketplace.

Each of these terms may even look linguistically correct.

The problem is that the store stops being consistent.

And if the wrong decision gets saved into an automation, the same term can end up in hundreds of product titles, descriptions, filters, product feeds, marketplace listings, ads, metadata and sometimes even product images.

Suddenly we’re not fixing one product page anymore.

We’re fixing the whole sales ecosystem.

Translation shouldn’t start with translating

It sounds a bit absurd, but on large localization projects one of the first things worth doing is exactly this: not translating the whole catalog.

First, decisions have to be made.

What is this product really called in the Romanian market? What name do shoppers use? What name do competitors use?

What shows up on eMAG? What shows up on Google? What term do specialist stores and distributors use?

And even more important: is the term that’s popular in search results actually correct?

Is there a difference between consumer language and technical language? Do we want the same form in the title as in the category? Is the term the marketplace uses the one we should use on our own store?

Only after that research do we make a decision.

But we don’t leave it in the head of the person who did the research. We don’t leave it in a single ChatGPT chat either, hoping that in three weeks the model “will remember what we agreed last time”.

Because this isn’t about memory.

We need a system.

The glossary, where language democracy ends

We create a glossary.

In it we record the key language decisions for a specific market.

If we decide to use “capăt pentru periuță electrică”, that decision goes into the glossary.

If another term is unwanted, we record that too.

In the glossary we can set the preferred product name, accepted synonyms, the form used in titles, the form used in categories, filter terms, parameter names, words we don’t use, context notes and exceptions for specific categories.

Only once the glossary has been reviewed do we approve it as the source of truth for that market.

That’s an important moment.

From then on, AI shouldn’t decide all over again how to translate the same product each time.

The decision was made earlier. AI just has to follow it.

Research first. Then the language decision. Then recording and approval. Only then scaling.

And only then do we feed the glossary to AI for further translation and localization.

It’s a small change in the process that makes a huge difference across a few thousand products.

Correct Romanian isn’t always good Romanian e-commerce

Localization doesn’t mean checking whether a sentence is grammatically correct.

You can write a text without a single grammar mistake and still create a listing that sounds odd to a Romanian shopper. Or artificial. Or too technical. Or simply like a translation.

That’s why, in expansion, I’m not only interested in the question:

“Is this correct Romanian?”

I’m also interested in:

“Is this really what Romanians call the product?”

“Is this how they search for it?”

“Is this the term they expect on a product page?”

“Does this read like local e-commerce, or like a foreign store run through a translator?”

Those are two completely different things.

And this is exactly where knowing an AI tool isn’t enough. You also need knowledge of the language, the market and local shopper behaviour.

My preferred AI localization workflow

On larger projects I increasingly work with a very simple flow:

ChatGPT → glossary → QA → Codex → native check

Each stage has a different role.

And separating those roles is what makes the biggest difference.

ChatGPT: research, context and a first draft

ChatGPT works very well in the preparation stage.

It can help analyze a product, organize data, write a first draft, compare terminology or point out where more research is needed.

It can create the structure for descriptions, FAQs, short descriptions, titles or the data a marketplace needs.

It can also help line up several possible product names and analyze how they’re used.

But it shouldn’t get complete freedom over every terminology decision in the catalog.

Especially if we’re later going to copy those decisions automatically across thousands of products.

Glossary: decide once, then reuse

The next stage is the glossary.

Here we record every decision we want to apply across the whole project.

For me, it’s one of the key elements of quality.

I don’t want AI to translate the same type of product from scratch every time.

I want it to know:

• this is the preferred term,
• this is the term we use in titles,
• we don’t use this name,
• this variant can only be used in a specific context.

Once the glossary is approved, we feed it to AI in the next stages.

Then the model doesn’t “guess”.

It works to a standard agreed in advance.

And what if a new term appears that isn’t in the glossary yet? We don’t let AI quietly decide for us. The term goes into analysis, gets checked and approved, and only then becomes part of the source of truth.

That way the glossary grows together with the catalog.

QA: checking whether AI got too creative

Then comes QA.

It’s a very easy stage to skip, because “the text is already there”.

But we’re not only checking the language.

We verify parameters, materials, numbers, dimensions, variants, set contents, compatibility, consistency with the source material, terminology, claims, and technical and safety information.

We also check whether one type of product has suddenly started appearing under several different names.

Whether the names in titles match what we set in the glossary.

Whether AI decided to “liven up” the text with an extra synonym.

Whether information appeared that wasn’t in the source.

In other words: we check that AI didn’t add, lose or “improve” anything on its own.

Because in marketing, creativity is an asset.

In a product’s technical parameter, a bit less so.

Codex: automating only an orderly process

Only then do I move on to working at scale.

And this is where Codex comes in.

You can use it to check large data sets, spot inconsistencies, work across hundreds or thousands of products and automate repetitive changes.

We can look for products where a banned term has appeared.

Check whether all products in a category use the approved glossary.

Spot missing parameters.

Compare source data with the final version.

Find source-language fragments accidentally left in Romanian descriptions.

Control title length.

Check content structure.

Find products where the same parameter has been named in several different ways.

We automate a process we’ve already put in order. Not chaos.

Because automating chaos doesn’t make it stop being chaos.

It just means we get more of it, faster.

Native check, in the right place

At the end comes the native check.

And here there’s an important “but”.

AI doesn’t remove the need to know the language.

It changes where we need that knowledge most.

We don’t always need a native speaker to read 5,000 nearly identical product pages by hand.

Far more value can come from a native speaker who checks a new category, new terminology, bestsellers, key landing pages, important glossary decisions, difficult cases, higher-risk content and texts that will become templates for hundreds of other products.

That’s a fundamental difference.

A person is no longer the manual translator of every single SKU.

They become part of the quality control system.

AI doesn’t replace specialists. It lets you use their knowledge differently

This is probably where the change AI brings to expansion is easiest to see.

A few years ago, a large catalog could need a whole team writing descriptions by hand.

Today we can automate a large part of that work.

But we still need people who can make the right decisions.

Someone who knows the language. Someone who understands local e-commerce. Someone who knows when a translation is technically correct but sounds wrong locally. Someone who can notice that the term AI used may not match what users are actually searching for.

So AI doesn’t take people out of the process.

It just moves them from production to control, research and decision-making.

And in my view, this is one of the biggest benefits of using AI in expansion.

It isn’t about replacing knowledge.

It’s about not wasting that knowledge on tasks that can be safely automated.

So where do SEO, GEO and zero-click come in?

Only here.

And deliberately only here.

Because before we optimize content for Google, marketplaces, AI search or generative answers, we need correct data and correct terminology.

There’s little point in perfectly optimizing a product name for SEO if it’s wrong locally.

There’s no point building an FAQ for a product AI gave a feature it doesn’t have.

And there’s little point creating content “for AI” if we haven’t set our own source of truth.

Data quality first.

Then terminology.

Then consistency.

Only then SEO, GEO, zero-click and scaling visibility.

The order matters.

A good prompt won’t fix bad data

And one more thing we often forget.

We can write the best prompt in the world.

We can define the model’s role, tone of voice, SEO, target audience, heading structure, CTA and every rule imaginable.

But if, in the input data, the company itself doesn’t know what material the product is made of, AI won’t solve that problem.

If the source says in one place that the set has four parts and in another that it has five, the model shouldn’t pick whichever version seems more likely.

A good AI should say:

“I have a conflict in the data. Let’s check it.”

That is far more valuable than a beautifully written description with wrong information.

And we’re back at the same point: localization quality starts long before the text is generated.

The most expensive mistake? The one we can scale

AI can speed up expansion enormously.

It gives smaller companies access to possibilities that until recently were reserved for large teams.

We can analyze markets faster, prepare content, localize catalogs, update listings and enter new marketplaces.

That’s exactly why I’m less and less interested in the question:

“How fast can AI translate the whole catalog?”

I’m much more interested in:

“How do we build a process that lets us safely localize 5,000 or 10,000 products?”

Because the biggest risk of AI in expansion isn’t that it makes one mistake.

Mistakes always happen.

The problem starts when we can now publish the same mistake automatically 5,000 times.