Localizing a marketplace search for 12 markets: the assumptions that cost me

I run OneFindMe, an AI product-search front end for
AliExpress in 12 languages. Translating the UI was the easy part. The hard part
was everything I assumed about what each market wants — and kept getting wrong
until I measured instead.

This is three of those assumptions, what the data actually said, and the code
that changed. If you're localizing anything commerce-shaped past the string
table, you'll recognize the pattern: the bug is never the translation, it's the
belief underneath it.

Assumption 1: "same homepage, translated, is localized"

The first version showed every market the same "today's deals" row — the same
eight products, just translated. A shopper in Saudi Arabia and a shopper in
Brazil saw identical items in different words.

That isn't localization, it's translation wearing a localization costume. The
Gulf shopper doesn't want the same products as the Brazilian one; they want
things that sell there — an abaya, an oud diffuser, an Arabic coffee pot.
Showing them a translated version of someone else's shortlist is worse than
showing nothing, because it signals the site doesn't actually know their market.

The fix was per-market seed lists, chosen by audience before geography. A
single dispatch, checked in this order:

function dealsTerms() {
  if (lang === "ar" || ARAB_COUNTRIES.has(country)) return DEALS_GULF;
  if (country === "IL") return DEALS_IL;
  if (EU_COUNTRIES.has(country)) return DEALS_EU;
  return DEALS_INTL;
}

Language is checked before country on purpose: an Arabic speaker who happens
to be browsing from Germany should still get the Gulf row, not the EU one. The
person's language is a stronger signal of what they're shopping for than the IP
they happen to be behind.

Lesson: a translated shortlist is not a localized shortlist. Localize the
selection, not just the labels — and let the audience signal win over the geo
signal when they disagree.

Assumption 2: I knew what a market considered acceptable

Here's the one I'm least proud of, and the most useful.

A women's-clothing search on the Arabic surface returned some items I looked at
and thought: I should filter these out for a conservative market. I started
writing a modesty filter — block anything that looked immodest on the Arabic
side. It felt responsible.

Then I did the thing I should have done first: I opened the actual AliExpress
Saudi storefront, as a Saudi user, and ran the same query. AliExpress itself
puts "sexy"-labelled and form-fitting clothing on the first page of a plain
dress search there. Immodest clothing is the market norm, not an edge case.

My filter would have made my engine stricter than the store the shopper was
walking into anyway — blocking a sports bra from someone who searched for
women's clothing, while the destination site shows it on page one. That's not
protecting anyone; it's just lost results.

So I threw the modesty filter away. What I kept was much narrower: a filter for
things that were a relevance failure in any market — a fetish costume
surfacing on a search for "dress" is wrong for a shopper in Riyadh and one in
Tel Aviv. That list is short and explicit, and deliberately excludes words with
innocent uses (a "nightclub dress" is an ordinary party dress; "Lolita" is a
real fully-covering fashion style; "sexy" is 42% of AliExpress's own first
page).

Lesson: don't encode your assumption about a market into a filter. Go
observe the market — the real benchmark for what to show is the store the user
is heading to. I almost shipped a paternalistic filter built on a guess; four
minutes of looking inverted the whole decision.

Assumption 3: more traffic in a language means demand in that language

I'd built full localized pages for three Gulf markets, confident all three had
Arabic shopping demand. Then I pulled the search-console data per country, and
two of the three had almost no Arabic queries at all — the "traffic" was
my own users mis-geolocated through carrier routing and VPNs, searching in other
languages entirely.

I'd spent weeks building for demand that a five-minute export would have shown
me wasn't there. Worse: content I'd written as filler in one language quietly
out-performed the pages I'd carefully localized, because that's where the real
demand was.

Lesson: "traffic from country X" and "demand in language X" are different
measurements, and you can't tell them apart without looking at the actual
queries. Export the per-market data before you build the per-market page, not
after.

The pattern under all three

Every one of these was the same shape: a reasonable-sounding assumption about a
market I wasn't in, encoded into code, that a small measurement would have
corrected before I wrote a line. Translating strings is a solved problem.
Localizing judgment — what to show, what to filter, what to build — is where
the real work is, and it's all measurement, not intuition.

• Localize the selection, not just the strings. A translated shortlist isn't local.
• Let the audience signal beat the geo signal when they conflict.
• Observe the market before you filter it. The benchmark is the store the user is going to, not your idea of that market.
• Per-market demand data before per-market pages. Traffic ≠ demand.

If you're building commerce in markets you don't personally live in, the
uncomfortable truth is that your instincts about those markets are a liability
until they're checked. Mine were wrong three times in a row. Curious whether
anyone's found a faster way to catch these than shipping and measuring — the
comments are open.

---

I build OneFindMe — AI product search for
AliExpress by text or image, in 12 languages. It's free; it runs on affiliate
commission at no extra cost to the buyer.