Shoppers type in Latin.
Your catalog is in Armenian.
Product names in Armenian e-commerce are written in Armenian script. Plenty of shoppers still type in Latin letters — on a phone, without an Armenian keyboard, out of habit. Their query describes a product your catalog contains, in a script your search never sees. The result page is empty, and the sale goes to whoever shows up next.
- 1The problemLatin-letter queries return zero results against an Armenian-script catalog.
- 2The requestConvert the query with one API call as the shopper searches.
- 3The responseArmenian text for your search engine. Numbers pass through.
- 4The resultThe full catalog becomes searchable — with no catalog changes.
A search box that speaks one script
The shopper below typed a perfectly good product name. It just isn’t in the script your search index understands.
What the shopper sees today
No products found for “karmir gorg”.0 results — the catalog lists կարմիր գորգ, not “karmir gorg”.
Why it keeps happening
- Zero-result searches. A real product query dies at the script boundary. You see it in analytics as “no results”, not as lost revenue.
- Every shopper spells differently.
karmiris only one of the spellings people use for the same word. Adding Latin keywords to every product doesn’t scale. - Can’t fix it in the catalog. You would have to predict every Latin variant of every product name, in both directions, forever.
One call, before the search runs
When the search box receives a query, transliterate it first, then search with the Armenian text.
Send use_llm: false on this path: for a keyword search you want the instant result —
deterministic, with no extra latency.
curl -X POST https://armtranslit.com/api/v1/transliterate \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"text": "karmir gorg araqum Yerevanum", "use_llm": false}'{
"id": "019b6a41-3e0f-7c92-b1d5-8f2a6047d3c1",
"input": "karmir gorg araqum Yerevanum",
"raw_transliteration": "կարմիր գորգ առաքում Երևանում",
"refined_text": null,
"tone": "casual",
"used_llm": false,
"matched_words": 2,
"total_words": 4
}def search(query: str):
r = httpx.post(
"https://armtranslit.com/api/v1/transliterate",
headers={"X-API-Key": "YOUR_API_KEY"},
json={"text": query, "use_llm": False},
)
q = r.json()["raw_transliteration"]
return catalog.search(q) # կարմիր գորգ առաքում ԵրևանումWhat came back
raw_transliteration- The query in Armenian script, ready for your search engine — Elasticsearch, Meilisearch, Postgres full-text search, anything that receives text.
use_llm: false- The instant path: no grammar polish, no AI call. The same query always converts to the same text, so results are cacheable.
matched_words/total_words- A confidence count per query. Log it next to your search analytics to see how well queries convert.
id- Keep it if you want to send a correction later — for example when a product nickname comes out wrong.
Real conversions from the engine
| Query typed by the shopper | Sent to the search engine | Why it matters |
|---|---|---|
karmir gorg | կարմիր գորգ | “red carpet” — colour and product in one query |
ezhan gorg | էժան գորգ | “cheap carpet” — price-sensitive shoppers find the same listings |
sev koshik 42 | սև կոշիկ 42 | numbers pass through untouched |
araqum Yerevanum | առաքում Երևանում | “delivery in Yerevan” — service queries work too |
The same search, after one call
The query the shopper typed still leads. The engine just receives it in the script the catalog is written in.
What the shopper sees now
Converted to կարմիր գորգ before searching
- Zero-result searches stop coming from the script gap. Latin-letter queries meet the real catalog — you don’t maintain a parallel list of Latin keywords.
- Nothing about the catalog changes. Conversion happens at query time, so it works with the listings you already have.
- Numbers survive.
42stays42; only the words around it are converted. - Search analytics become comparable. Log the converted query and spelling variants stop fragmenting your top-searches report. More on normalising logs and corpora
Does this work with Elasticsearch, Meilisearch or Postgres full-text search?
Yes. The API is engine-independent: you convert the query string to Armenian script first, then hand it to your search engine exactly as you do today. No plugin or indexer change is required.
What happens to numbers, brand names and product codes in the query?
Numbers pass through unchanged: sev koshik 42 becomes սև կոշիկ 42. Latin letters are always converted, so a brand name or a code with letters in it (nike, A12) comes back in Armenian letters too. If your catalog keeps those in Latin, search with both the original query and the converted one.
Should I use the polished version for search?
No — for keyword search, send use_llm: false. The instant result is deterministic and skips the AI step entirely. The polished version is for text a human will read, like product reviews you display.
See it in another context
Make every query count
One call between the search box and your engine. Get a key, convert your first query, and watch the zero-result page disappear.