How do you build an AI workflow for English, Arabic, Hindi or Malayalam? Treat language as an end-to-end routing requirement, not a final translation step. Detect locale and script, preserve the original, apply an approved glossary, test code-switching and regional formats, evaluate each language separately, and route low-confidence or consequential cases to a fluent human.
Translation alone is not a workflow
A customer may type Malayalam in Latin characters, mix Hindi and English, use Gulf Arabic terms, attach an English invoice and expect an Arabic explanation. The workflow must preserve meaning across detection, retrieval, business rules, tool actions and the final message. Translating only the visible response leaves failures elsewhere.
Write a language requirement for every stage
- Input: channel, expected languages, scripts, speech quality, documents and code-switching.
- Detection: confidence, user override and treatment of very short text.
- Understanding: entities, dates, currencies, names and domain terms.
- Knowledge: authoritative source language, translated copies and freshness owner.
- Action: canonical field values and deterministic business rules.
- Response: locale, script, tone, right-to-left layout and disclosure.
- Fallback: fluent reviewer, original context and response-time expectation.
Build a regional test-case matrix
| Dimension | Cases | Pass evidence |
|---|---|---|
| Locale and script | Arabic, Hindi, Malayalam, English; native and romanised input | Correct detection and readable output |
| Code-switching | One sentence or thread mixes languages | Meaning and entities survive switching |
| Domain terms | Products, ERP labels, names and local expressions | Approved glossary is followed |
| Numbers and dates | Indian/UAE formats, currencies and right-to-left context | Values remain exact and unambiguous |
| Tone | Formal, conversational and service-recovery messages | Respectful local phrasing without invention |
| Fallback | Unsupported dialect, low confidence or poor audio | Human route keeps original text/audio |
Download the multilingual test-case matrix and add real, consented or safely reconstructed cases from each channel.
Use one canonical operating language carefully
Many SMEs keep ERP fields and internal processes in English while serving customers in several languages. That can work if translation boundaries are explicit. Store the original message, detected locale, translated working text and final response separately. Never overwrite the original with a model translation.
Use deterministic normalisation for account numbers, dates, currency and product IDs. Let AI interpret free text, but validate its extracted values against the system of record before any write.
Own a terminology glossary
List product names, department labels, policy terms, abbreviations, honorifics and phrases that must not be translated. Include approved Arabic and Indian-language equivalents plus context. Assign an owner and version. Google Cloud documents glossary support and broad language availability, but provider support does not prove fitness for your domain or dialect.
Store term type, source, target, definition, example, prohibited alternatives, locale and reviewer. Separate a customer-friendly term from the ERP field when necessary. Version the glossary with evaluations so a later language change can be traced to its source.
Handle script, romanisation and direction explicitly
Hindi or Malayalam may arrive in Latin characters; Arabic may include English product names, numerals and codes. Preserve the input script and avoid silently converting customer names or identifiers. Transliteration can support search or typing assistance, but it is not equivalent to translation and may be a preview feature in a provider's service.
Test right-to-left layouts with embedded numbers, currency, phone numbers and Latin product codes. Check message order, punctuation, tables, forms and copy-paste behaviour on real devices. An accurate Arabic sentence can still become unusable in a broken interface.
Design retrieval for multilingual evidence
Decide whether the knowledge base stores one authoritative language, professionally maintained parallel versions, or both. If a query is translated before retrieval, retain the original and working query and test whether specialised terms survive. If documents are embedded across languages, evaluate cross-language retrieval with known relevant passages.
The response should not present a translated policy as more authoritative than its source. Keep source title, owner, effective date and language. For contractual, financial, medical or legal content, route to approved wording and human review rather than improvised translation.
Separate language uncertainty from business uncertainty
A system may understand the words but lack the data to answer, or it may have the record but misunderstand the language. Record detection confidence, extraction confidence, source availability and business-rule result separately. This lets the workflow ask the right repair question: choose a language, clarify a field, provide a document, or wait for a human.
Never average these signals into one opaque confidence number. High model confidence does not authorise a refund or an ERP write. Consequence and permissions still determine the action boundary.
Evaluate each language as its own product surface
Do not average all languages into one accuracy number. Report task success, entity preservation, policy compliance, unsupported claims, tone, escalation and user correction by language, script, channel and consequence. Include native or professionally fluent reviewers. Machine back-translation can help triage differences; it is not ground truth.
Design speech and chat separately
Speech introduces accents, background noise, turn timing and pronunciation. Microsoft's current support tables show that capabilities differ across speech recognition, text-to-speech and speech translation, so verify the exact locale and feature. Chat introduces romanisation, emojis and message fragments. A platform listing a language does not guarantee reliable performance in either channel.
For voice, build cases with local names, place names, account numbers, dates and code-switching. Measure recognition and task completion, not only a general transcript score. For chat, test fragmented messages, copied documents, voice-note transcripts and changes of language midway through the case.
Protect regional customer data
Document what personal data crosses translation, speech, model and storage services, where it is processed, how long it remains and who can access it. Review India's DPDP framework, the UAE federal PDPL and any sector or free-zone requirements for the real deployment. Minimise sensitive content before external processing and retain only the evidence the workflow genuinely needs.
Language routing can reveal nationality, ethnicity or other sensitive inferences. Use it to deliver service, not to profile people beyond the approved purpose. Restrict who can access transcripts and reviewer notes. When using real cases for evaluation, obtain an approved basis and de-identify where possible.
A safe routing pattern
Detect language with confidence and allow the customer to choose. Route to a language-specific prompt, glossary and knowledge set. Convert business fields into a canonical schema. Apply deterministic checks. Generate the response in the requested locale. If confidence, policy or consequence crosses a threshold, hand the original and structured context to a fluent human.
This architecture makes multilingual capability observable. You can see whether the problem came from detection, translation, retrieval, business rules or response generation—and improve the right layer.
Build the evaluation set from regional reality
Start with consented or safely reconstructed examples from sales, support, finance and operations. Balance languages by business importance and risk, not population alone. Include common requests, rare high-impact cases, code-switching, romanised text, typos, dialect, poor audio, conflicting documents and requests that must be refused or escalated.
Have fluent reviewers score intent, entities, factual support, terminology, tone, action and escalation. Track disagreements between reviewers. For each release, keep a fixed regression set and a rotating set from recent corrections. Publish known limitations to the operating team.
Use a staged rollout
- Stage 1: classify and route messages while humans answer.
- Stage 2: draft answers with source links for fluent review.
- Stage 3: send low-risk approved answers with sampled QA.
- Stage 4: add one validated tool action with explicit confirmation.
Compare results by language at every stage. Do not let strong English performance justify autonomous Arabic, Hindi or Malayalam handling without its own evidence.
Regional example: service enquiry to ERP draft
An inbound Malayalam-English WhatsApp enquiry can be preserved in its original form, classified, translated into a controlled working representation and matched to an approved service catalogue. Product and location terms come from the glossary. The workflow collects missing fields in the customer's chosen language, then creates a draft service request using canonical codes. A person reviews uncertain scope or price; the final response records the source and system ID.
The same architecture serves Arabic-English enquiries in the UAE. The language layer changes; the control boundary does not. Identity, consent, price, tax, entitlement and ERP posting remain deterministic business responsibilities.
Release criteria by language
- Minimum number of representative cases and critical scenarios reviewed
- Intent and entity thresholds met without masking severe failures
- Approved glossary terms used consistently
- Unsupported or ambiguous cases escalate correctly
- Native-script and romanised inputs both tested where relevant
- Right-to-left layout and mixed identifiers verified on target devices
- Fluent human capacity available for the promised service hours
- Privacy, retention and reviewer access approved
Record a separate release decision for every supported language-channel pair. “Arabic supported” is too broad when chat, voice, documents and outbound templates behave differently.
Primary sources
- Google Cloud — Translation language support
- Google Cloud — Translation API overview
- Microsoft — Azure Speech language and voice support
- MeitY — Digital Personal Data Protection Rules, 2025
- UAE Government — Cyber and personal-data protection laws
Continue the implementation path
Test the language people actually use
Plan a multilingual workflow around real cases
I help India- and UAE-facing teams define language routes, terminology, evaluation and human fallback for customer and operational workflows.
Plan a multilingual AI pilot