Bot type
Three languages, one support queue, no separate teams
A multilingual Telegram support bot answers routine questions in Arabic, English and Russian, and hands anything else to a human with the conversation translated for them. It removes the need for a per-language rota. It does not replace agents, and machine translation will occasionally be wrong.
Multilingual support bots: price, timeline and limits
- Fixed price
- $4,600 USD
- Delivery
- 21 calendar days from kickoff
- Message length
- 4096 characters, or 1024 for a media caption
- language_code
- Reflects the app's interface language, not reading preference
- RTL buttons
- Render correctly but do not reflow — truncated at a fixed width
- Gulf Arabic MT
- Materially worse than Modern Standard Arabic
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
A Dubai business serving Emirati, expatriate and Russian-speaking customers has a staffing problem before it has a technology problem. Cover three languages across business hours and you need at least six people, most of whom are idle most of the time. Cover them badly and one language group consistently waits longer, notices, and says so publicly.
The tempting shortcut is to answer everything in English and expect customers to cope. Many will. The ones who do not are disproportionately the high-value ones — an Arabic-speaking customer dealing with a medical or legal matter is not going to accept a second language for a conversation that matters, and is right not to.
The realistic split is that a large share of inbound support is a small set of repeated questions: opening hours, prices, where you are, is this in stock, how do I cancel. Those answers can be authored once per language and served instantly with no translation risk at all. Everything else goes to a human, with the thread translated so the agent can work without speaking the customer's language. The bot is not doing the hard conversations. It is clearing the space for people to have them.
How the build runs
Language is detected once and then respected
The first message decides, and the choice sticks for the conversation with a visible way to change it. Re-detecting per message produces a bot that switches language mid-thread on a short reply, which reads as broken.
commandsCommon questions are answered from authored text, not translation
Each frequent answer is written by a native speaker in each language. This is the difference between a support bot people trust and one that is technically correct and subtly wrong in the language that matters most to the reader.
inline-keyboardAnything unmatched goes to a human immediately
No loop of rephrasing, no third attempt at understanding. A support bot that will not let you reach a person is worse than no bot, and every escalation is logged as a candidate for a new authored answer.
forum-topicsThe agent sees the thread in their own language
Inbound messages are translated for the agent and their replies translated back, with the original always visible alongside. The agent can see when a translation looks wrong, which is the only practical safeguard.
forum-topicsOut of hours, the bot says so plainly
With the actual next opening time in the customer's language, and the option to leave the question for the morning. Pretending an agent is available and then not replying for eleven hours is worse than the honest version.
commandsUnanswered questions become next month's authored answers
Every escalation is grouped by topic and language. The list is short, it is real, and it turns support volume into a maintenance backlog rather than a permanent staffing cost.
webhook
What Telegram will and will not let you do
Telegram renders right-to-left text correctly, but button labels do not reflow and are truncated at a fixed width.
Arabic labels must be tested at real length. A label that fits in English routinely overflows in Arabic, and the result is a button whose meaning is cut off mid-word.
Telegram supplies a `language_code` on the user object, but it reflects the app's interface language.
It is a hint, not an answer. An Emirati customer with an English phone interface who writes in Arabic must get Arabic, so detection runs on the message text with `language_code` as a tiebreak.
A message caption is limited to 1024 characters while a plain message allows 4096.
Long answers accompanying an image have to be split. Arabic renderings of the same answer are frequently longer than the English, so a caption that fits in one language may not in another.
Machine translation quality for Gulf Arabic dialect is materially worse than for Modern Standard Arabic.
Customers write in dialect. This is why the common path uses authored answers and only the escalation path uses translation, and why the agent always sees the original text.
Telegram usernames and display names can contain mixed scripts and directional control characters.
Names are rendered with explicit isolation so a crafted display name cannot reverse the layout of the message around it — a small detail that otherwise produces convincing spoofed messages.
When not to build this
- Your support volume is under about thirty conversations a day. Authoring and maintaining three language sets costs more than the agent time it saves.
- Your questions are genuinely varied with no repeated core. The economics of this build depend on a concentrated head of common questions; without it the bot escalates nearly everything.
- You expect it to replace agents. It clears routine volume so agents handle the rest; a business that cuts headcount to match will discover the difference during its first bad week.
- You cannot get native-speaker review for the authored answers. Machine-translated canned responses are worse than answering only in English, because they look official and read wrong.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with per-conversation language state. |
| Cloudflare Workers | current | Runtime for the bot and the agent-side translation calls. |
| Cloudflare D1 | current | Answer sets per language, conversation state and escalation logs. |
| Cloudflare Workers AI | current | Translation on the escalation path only, never on the authored path. |
| TypeScript | 5.9 | Strict mode, with language keys typed so a missing translation fails the build. |
Questions people ask before committing
Why not translate everything automatically?
Because the common answers are the ones customers judge you on, and Gulf Arabic dialect is exactly where machine translation is weakest. Authoring the top twenty answers per language is a bounded amount of work and removes the risk entirely from the path most customers take.
How does the agent handle a language they do not speak?
They see the customer's message translated with the original beneath it, and type in their own language. It is not perfect, and the agent can tell when a translation is odd because the original is right there — which is the practical safeguard against confident nonsense.
What share of conversations does the bot typically resolve?
It depends entirely on how concentrated your question distribution is, and anyone quoting a figure before seeing your history is guessing. The useful early step is exporting three months of support threads and counting; that number decides whether this build is worth it.
Does Arabic display correctly in Telegram?
Message text does, reliably. Inline button labels are the weak point because they are truncated at a fixed width rather than reflowed, so every label is tested at real Arabic length rather than at the English placeholder.
Can we add a fourth language later?
Yes. Language keys are typed, so adding one produces compile errors listing every answer that still needs writing. That is deliberate — a half-translated language set shipping silently is the failure this design prevents.
Can it connect to our existing helpdesk?
Yes. Escalations can open a ticket in Zendesk or Freshdesk with the translated thread attached, so your existing SLA reporting keeps working rather than being split across two systems.