A customer in Osaka types "防水のハイキングブーツ" into your search bar. Your catalog has exactly what they want, listed as "Waterproof Hiking Boots." Your search returns nothing.
Nothing is broken. Keyword search did what it was built to do: it looked for those characters in your product titles and found none. The product exists, the intent is clear, and the customer leaves anyway.
This is the multilingual search problem, and most teams solve it the expensive way. This post covers why the usual fixes don't hold up, how multilingual semantic search works, and how to set it up with a single index.
Why Keyword Search Fails Across Languages
Keyword search matches strings. Two words in different languages that mean the same thing share no characters, so they share no match. "Zapatos," "chaussures," "Schuhe," and "shoes" are four unrelated tokens as far as BM25 is concerned.
Even inside a single language, keyword search needs help that is language-specific:
- Tokenization. English splits on spaces. Japanese, Chinese, and Thai don't use spaces between words, so they need dedicated tokenizers.
- Stemming. "Running" and "ran" reduce to the same root with English rules. German compounds, Arabic roots, and Turkish suffixes each need their own.
- Stop words and synonyms. Every list is per language, and someone has to maintain it.
So a keyword engine that supports ten languages is really ten configurations sharing a product name.
The Usual Fixes (And What They Cost)
Translate the catalog. You run every product through machine translation and store a copy per language. Storage and indexing multiply by the number of languages, every catalog update has to be re-translated, and translation errors in short product titles are common. "Light jacket" can come back as a jacket that glows.
Translate the query. You detect the query language, translate it to English, then search. This adds a network hop and latency to every search, and it fails on the queries that matter most: short, ambiguous ones with no context to translate from. Language detection on a two-word query is a coin flip between related languages.
One index per language. You route each user to the index for their locale. Now a Spanish speaker in Germany gets the German index, mixed-language queries ("nike zapatillas running") fall between two indexes, and a product only listed in English is invisible to everyone else.
All three treat language as a routing problem. It's a representation problem.
How Multilingual Semantic Search Works
Semantic search converts text into a vector, a list of numbers that represents its meaning. Texts with similar meaning land close together in vector space. Search becomes a nearest-neighbor lookup instead of a string match. (If this is new, start with Keyword vs Semantic Search.)
A multilingual embedding model is trained on text from many languages at once, including pairs of sentences that mean the same thing in different languages. The result is a single shared vector space where meaning decides position and language doesn't. "Waterproof hiking boots," "防水のハイキングブーツ," and "botas de senderismo impermeables" all land in roughly the same place.
That has two practical consequences:
- Same-language search works everywhere. Korean queries match Korean content, with no Korean-specific tokenizer or stemmer.
- Cross-language search works too. A Japanese query matches an English listing, because the comparison happens on meaning, after both have been turned into vectors.
No translation step runs at index time or at query time. There's nothing to detect and nothing to route.
Setting It Up
With Vecstore, multilingual support isn't a setting. Every text database handles 100+ languages by default, and queries and documents can be in different languages.
Insert your catalog as it is, in whatever language each listing was written in:
const BASE_URL = 'https://api.vecstore.app/api';
const products = [
{ sku: 'BOOT-01', text: 'Waterproof hiking boots with ankle support' },
{ sku: 'JKT-14', text: 'Veste coupe-vent légère pour la course à pied' },
{ sku: 'BAG-60', text: 'Mochila impermeable de 60 litros para senderismo' },
];
for (const product of products) {
await fetch(`${BASE_URL}/databases/${DB_ID}/documents`, {
method: 'POST',
headers: {
'X-API-Key': API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({
text: product.text,
metadata: { sku: product.sku },
}),
});
}
Three products, three languages, one database. Now search it in a fourth:
async function search(query) {
const res = await fetch(`${BASE_URL}/databases/${DB_ID}/search`, {
method: 'POST',
headers: {
'X-API-Key': API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ query, top_k: 5 }),
});
const { results } = await res.json();
return results;
}
await search('防水のハイキングブーツ');
await search('wasserdichter Rucksack zum Wandern');
await search('light jacket for running');
The Japanese query returns the English boots. The German query returns the Spanish backpack. The English query returns the French jacket. The search function has no language parameter because it doesn't need one.
Where It Still Needs Care
Multilingual semantic search removes most of the work, but a few things are still yours to decide.
Exact identifiers. SKUs, model numbers, and brand names aren't language. "XPS-15-9530" should match exactly, in any locale. This is the case for hybrid search, which combines keyword matching for exact terms with semantic matching for everything else.
What you show after the match. Search finds the English listing for the Japanese shopper. Whether you display it in English or translate the title at render time is a product decision. Finding and presenting are separate problems, and only the first one needs to happen on every query.
Per-market availability. A product that matches semantically may not ship to the user's country. Store region, currency, and stock in metadata and filter on it, so relevance and availability stay independent.
Testing with real queries. Pull actual searches from each market and check the results. Shoppers mix scripts, drop diacritics, and blend languages in ways a test set written by one team in one language won't cover.
When You Need It
If your content and your users share one language, multilingual search won't change much. It starts to matter when:
- You sell or publish across borders and maintain one catalog
- Your content is user-generated and arrives in whatever language people write in (marketplaces, forums, reviews, support tickets)
- You're entering a new market and don't want search to be the thing that blocks launch
- Your "zero results" report is full of queries in languages you never configured
That last one is worth checking today. Queries in unsupported languages rarely show up as complaints. They show up as sessions that end at the search bar.
The Bottom Line
Keyword search ties relevance to spelling, so every new language is a new configuration. Semantic search ties relevance to meaning, and meaning doesn't change when the language does. One index, one API call, and a query in any language finds the right result in any other.
Try Vecstore for free. 100 credits on signup, no credit card. Index a few listings and search them in a language you didn't write them in.
