One customer types "o'zbekcha", another "ozbekcha", a third types the same word in Uzbek Cyrillic with the letter ў, and a fourth, whose phone only has a Russian keyboard, types it in Cyrillic with a plain "u" instead of ў. To a person that is one word. To a chatbot it is four different strings, and if any part of the system compares text literally, the customer gets "product not found" or ends up in the CRM twice. If you run a business in Uzbekistan, or serve Uzbek-speaking customers from the Gulf or the UK, this article shows where the two-script reality breaks automation, how to build a text normalisation layer, which script to reply in, and how to test it all before launch.
The model understands; the system around it does not
Uzbek has two scripts in everyday use. Latin is the official alphabet, but Cyrillic is still familiar to many adult customers and common in older documents and signage. Modern language models read both, and even "Latin without apostrophes". If your bot is nothing but a model answering questions, script will rarely cause trouble. For a broader view of where models are strong and weak in Uzbek, see AI in the Uzbek language: strengths and limits.
A production bot, however, is more than a model. Around it sit deterministic components that compare text character by character:
- catalogue and knowledge-base search, by keyword or by embeddings;
- triggers and menus, such as "if the message contains 'narx' (price), show the price list";
- the CRM, which looks for duplicates by name, address or company;
- analytics, which counts topics and requests.
This is where "Toshkent", "Tashkent" and Toshkent typed in Cyrillic become three cities, and "g'isht", "gʻisht" and "g`isht" (brick) become three products. The failure is silent: nobody sees that search returned nothing; the bot just asks the customer to clarify.
The spellings you will actually see
| Variant | Example | Where it comes from |
|---|---|---|
| Standard Latin | oʻzbek, gʻisht | Uzbek keyboard layouts, official texts |
| Latin with a plain apostrophe | o'zbek | The most common form in messengers |
| Latin with other marks | o`zbek, o’zbek | Different keyboards, phone autocorrect |
| Latin with no apostrophe | ozbek, gisht | Typing fast, not switching layouts |
| Full Uzbek Cyrillic | o'zbek, g'isht, qovun written with ў, ғ, қ | Uzbek Cyrillic keyboard |
| "Russian" Cyrillic | the same words with plain u, g, k | No ў, қ, ғ, ҳ on the keyboard, so the nearest Russian letters stand in |
Add Russian words inside Uzbek sentences ("zakaz qilmoqchiman" — I'd like to order), Russian written in Latin letters ("dostavka bormi?" — is there delivery?), and the nasty case of a Cyrillic "o" or "a" slipped into a Latin word. They look identical on screen and are different characters to a search index.
A normalisation layer: what happens before search
Don't teach every component every variant. Convert incoming text to one canonical form before it reaches search, triggers and the CRM, and keep the original message untouched next to it — the model and your staff should see what the customer actually wrote.
- Unify apostrophes. Straight ', backtick `, curly ’, and the standard Uzbek marks ʻ and ʼ all map to one character. Which one doesn't matter; using the same one in the catalogue, the knowledge base and incoming messages does.
- Convert Cyrillic to Latin. This direction is far more reliable than the reverse. Most letters map one to one: ў → o', қ → q, ғ → g', ҳ → h, the Cyrillic kha → x, and the single letters for sh, ch, yo, yu and ya become those two-letter pairs. The tricky spots: the Cyrillic "e" becomes "ye" at the start of a word and after a vowel; the "ts" letter in Russian loanwords is written sometimes as "s", sometimes as "ts", so you need an exceptions list built from your own vocabulary; the hard sign maps to the ʼ mark.
- Build a "rough key" for search. Strip apostrophes, fold o' → o, g' → g, қ → k, lowercase everything. Now "Oʻzbekiston", "ozbekiston" and the same word typed in Cyrillic all match. The key occasionally merges different words, so use it to fetch candidates and let the model or an exact comparison make the final pick.
- Replace look-alike characters. Cyrillic letters that look like Latin a, e, o, p, c and x inside a Latin word are swapped for their Latin twins. A word mixing two alphabets is almost always a keyboard slip.
Why not store everything in Cyrillic instead? Because Latin-to-Cyrillic guesses wrong more often: "yo'l" (road) is written in Cyrillic as y + ў + l, not with the single "yo" letter, and the "sh" in the name "Is'hoq" is not the Cyrillic "sh" letter but "s" plus ҳ. Keep search in Latin and use Cyrillic only for replies.
Process → what AI or code does → what stays with a person
| Process | What AI or code does | What stays with a person |
|---|---|---|
| Understanding the message | The model reads the original in any script | Reviewing edge cases from the logs |
| Finding a product or answer | Code normalises the query and fetches candidates; the model chooses | Maintaining the synonym and product-name dictionary |
| Writing a lead to the CRM | Stores original and normalised name and address, dedupes on the normalised form | Deciding whether to merge doubtful duplicates |
| Replying to the customer | Replies in the customer's script from templates and the knowledge base | Approving templates in both scripts |
| Reporting | Groups topics by normalised text | Drawing conclusions and changing scenarios |
Our AI consultant that turns inbound messages into structured leads follows the same split: the model reads free text, the CRM receives fields in one consistent form.
Which script to reply in
The rule that rarely fails: reply in the script the customer used. If the message is too short to tell ("ok", "rahmat"), look at earlier messages in the thread. With no history, use the default script you chose for the business.
Customer (in "Russian" Cyrillic, transliterated here): gisht bormi? 500 dona kerak, Chilonzorga (any bricks? need 500, delivered to Chilanzar)
Bot (in Uzbek Cyrillic, transliterated here): Assalomu alaykum! Ha, g'isht omborda bor. 500 dona uchun narxni va Chilonzorga yetkazib berishni menejerimiz aniqlashtiradi. Qaysi turdagi g'isht kerak — pishgan g'ishtmi yoki blokmi? (Yes, bricks are in stock. Our manager will confirm the price for 500 and delivery to Chilanzar. Which type do you need — fired brick or block?)
The customer wrote in "Russian" Cyrillic without ў and ғ. Normalisation turned "gisht" into the search key, search found the product "G'isht pishgan" (fired brick), and the bot answered in Cyrillic like the customer — but in correct Uzbek Cyrillic. It did not quote a price, because that depends on volume and delivery, and handed that question to a manager while asking which type of brick is needed.
Write two rules into the model's instructions explicitly: never mix scripts within one reply, and never correct or comment on the customer's spelling.
Pre-launch checklist
- Catalogue and knowledge base use one Latin form with one apostrophe; every product has alternative names (colloquial, Russian, abbreviations).
- Normalisation runs before search, triggers and the CRM; the original message is stored alongside.
- An exceptions list covers brands, districts, streets and words with the Cyrillic "ts" and "e" letters.
- A test set exists: 20–30 queries, each written in 4–6 of the variants above. The bot must find the same thing for every variant.
- Queries where search found nothing are flagged in the logs, reviewed weekly and added to the dictionary.
If you process names, phone numbers and addresses, also check the data-storage rules — see Uzbekistan's personal data law and AI automation.
FAQ
Can the model transliterate Cyrillic to Latin by itself?
Yes, and for a one-off translation it is convenient. For search and CRM, simple predictable code is better: it behaves identically on every message, instantly and at no cost. Keep the model for understanding meaning, not swapping letters.
Which script should the catalogue use?
One script, and Latin is the practical choice because reverse transliteration errs more often. Keep human-checked Cyrillic names in a separate field for replies.
What about voice messages?
Speech recognition picks the transcript script on its own, and not always the one you expect. Run transcripts through the same normalisation layer as typed text.
Should the bot ask customers which script they prefer?
Usually not; it is an unnecessary step. Mirror the customer. For broadcasts and notifications, remember the script from their first messages and store it on the customer record.
More on how automation handles local specifics is in the Uzbekistan section. If you want a bot that understands customers equally well in any script, see how we build AI agents or get in touch. The cost depends on scope and data; the first conversation is there to work it out.