On this page
- Why WhatsApp templates in Hindi and regional languages are a commercial decision, not a translation project
- How WhatsApp template localisation actually works
- Indian languages, locale codes and script notes
- The operational traps that break localised templates
- Worked example: one utility template, three languages
- What most teams get wrong about multilingual WhatsApp templates
- The native-speaker review loop, in eight steps
- Language detection and routing inside the inbox
- Template caps, language multiplication and the arithmetic that surprises people
- Get started with InfiQ
There is a pattern we see in almost every account that grows past its first city. The English template set performs well for a few months, the brand expands its ad spend into tier-2 and tier-3 districts, and the numbers stop moving. Nothing broke. The messages are still delivered, still read. They are simply arriving in a language the recipient can decode but does not think in.
Then somebody suggests translating everything, an intern runs the library through a machine translator, and half the submissions come back rejected while the half that get approved read like a scam. That is the actual failure mode. Not the absence of Hindi, but the presence of bad Hindi.
This post is the operational version of that problem: how WhatsApp template localisation works mechanically, what the language codes are, which grammatical properties of Indian languages break templates written by English speakers, and how to run a review loop that produces copy a native speaker would send to their own family. If you want the categorisation and cost side of templates, InfiQ's guide to WhatsApp template categories covers that separately; language does not change your per-message rate, and this post explains why that matters.
Key points
- A localised WhatsApp template is a distinct language version registered under a shared template name, and Meta reviews each language version on its own merits within the standard 24-hour template review window.
- Adding a language does not change your per-message cost, because Meta's rate cards are priced per market and per message category, not per language.
- Every language version counts separately against the template cap of 250 per WhatsApp Business Account when the parent business portfolio is unverified, rising to 6,000 once that portfolio is verified with an approved display name.
- Machine-translated template copy fails review and underperforms for the same underlying reason: it produces the wrong formality register and misplaces variables in verb-final languages such as Hindi, Tamil and Bengali.
- India is WhatsApp's largest market, with over 500 million users, and Meta launched AI-powered customer support for Indian small businesses in May 2026 — both of which push language coverage from a nice-to-have to an operating requirement.
- Sending in a language your inbox cannot reply in damages quality rating faster than not sending in it at all.
Why WhatsApp templates in Hindi and regional languages are a commercial decision, not a translation project
India is WhatsApp's largest market by user base, and the growth in that base has for years come from outside the metros. That is the whole commercial argument, and it does not need a fabricated conversion percentage to hold. The Constitution's Eighth Schedule lists the languages Indian institutions are expected to operate in, and a business that reaches a customer in Nashik, Coimbatore or Cuttack in English is asking that customer to do translation work in the two seconds they spend on a notification.
We are deliberately not quoting an uplift figure here. Vendor blogs circulate regional-language conversion lifts with no primary source behind them, and you should treat any number you see without a named methodology as marketing. The honest case is structural rather than statistical.
Three structural reasons language coverage pays. First, WhatsApp messages arrive on the notification surface next to messages from family, so register mismatches are noticed in a way an email subject line never is — an English utility message reads institutional, a Marathi one reads personal. Second, comprehension failures on transactional messages generate support load: a customer who does not fully parse "your shipment has been rescheduled to 21 Aug" calls the helpline, and that call costs more than the message did. Third, trust in a payment or KYC instruction is language-dependent, which is why BFSI and healthcare teams localise before D2C brands do.
There is also a platform reason. Meta launched AI-powered customer support for Indian small businesses in May 2026, with UPI payments described as coming soon. As automated conversation becomes the default on the platform, the businesses with a clean multilingual template library are the ones whose automation can actually answer.
How WhatsApp template localisation actually works
A localised WhatsApp template is a separate language version of a message template, created under the same template name but registered against a different language code, with its own body text, its own variables and its own review outcome. That definition contains the three facts most teams get wrong.
One name, many versions. You do not create order_dispatched_hindi and order_dispatched_tamil. You create order_dispatched and add language versions to it. At send time your API call names the template and the language, and Meta selects the matching version. Keeping one name is what lets you swap a contact's language without changing application code.
Each version is reviewed independently. Meta's template review documentation puts approvals and rejections at up to 24 hours, with appeals also reviewed within 24 hours and requiring a sample. That SLA applies per language version. Six languages means six review outcomes, and in practice they do not all land at once — you will regularly have an approved Hindi version and a rejected Telugu version of the same message, which your send logic must handle rather than crash on.
Each version carries its own quality history. Template quality and template pausing run on user feedback, and feedback is collected against what people actually received. A badly worded Bengali version can be paused while the English one stays healthy. That is a feature: it isolates damage. It is also a monitoring obligation, because a paused language version is a silent delivery gap for one segment of your list.
One more mechanical point, and it is the reassuring one. Meta's pricing documentation prices messages per market and per category — marketing, utility, authentication, service — on the per-message model that replaced conversation pricing on 1 July 2025. Language is not a pricing dimension. A utility template delivered in Malayalam to an Indian number costs the same as the English version to the same number — the current India rates are marketing ₹0.94, utility ₹0.19 and authentication ₹0.14 per delivered message (ex-GST), identical whatever the language.
Indian languages, locale codes and script notes
The table below covers the twelve Indian languages most Indian businesses ask about, with the language code commonly used in template creation and the script properties that change how you write copy. Treat the codes as a starting point and verify each one before you build a mapping table in production, because Meta maintains its own supported-language list and it is the only authority on which codes are accepted.
| Language | Commonly used code | Script | What changes in your copy |
|---|---|---|---|
| Hindi | hi |
Devanagari | Verb-final word order; verbs agree with gender and number, so avoid past-tense constructions built around a variable noun |
| Bengali | bn |
Bengali-Assamese | Verb-final; strong formality split (আপনি vs তুমি); conjunct-heavy rendering expands line height |
| Marathi | mr |
Devanagari | Same script as Hindi, different vocabulary and inflection — never reuse Hindi copy for Marathi |
| Telugu | te |
Telugu | Agglutinative; single words get long, which pushes header and button labels past their limits |
| Tamil | ta |
Tamil | Highly agglutinative and diglossic — written Tamil differs sharply from spoken, and formal written register is correct for business messaging |
| Gujarati | gu |
Gujarati | Devanagari-adjacent structure without the headline stroke; number formatting conventions follow Indian grouping |
| Kannada | kn |
Kannada | Long compound forms; polite imperatives are the safe register for CTAs |
| Malayalam | ml |
Malayalam | The longest average string expansion of the set; budget aggressively for truncation |
| Punjabi | pa |
Gurmukhi | Gurmukhi, not Devanagari; check your rendering pipeline actually ships the font |
| Odia | or |
Odia | Less commonly supported in vendor tooling than in Meta's list; verify end to end before promising it |
| Assamese | as |
Bengali-Assamese | Shares a script with Bengali but is a distinct language; audience segmentation errors are common here |
| Urdu | ur |
Perso-Arabic (Nastaliq) | Right-to-left. Latin-script variables such as order IDs and URLs create bidirectional rendering problems — see the traps table |
Two practical notes on that table. Marathi and Hindi share Devanagari, and Bengali and Assamese share a script, which means a script-detection routine cannot identify the language — it can only identify the writing system. If you are inferring language from an inbound message, script detection narrows the field, it does not decide.
And your CRM needs one canonical language field holding one of these codes, set at opt-in wherever possible. Teams that store language as free text end up with "hindi", "Hindi", "HI" and "hin" in the same column, which is how a Tamil-speaking customer receives a Gujarati fee reminder.
Native script or Roman transliteration
Roman-script Hindi — "Aapka order bhej diya gaya hai" — is the format most Indian internet users type in, which makes it tempting for templates. It is a real option, and it wins in specific places rather than generally.
Native script wins for utility and authentication messages, for older audiences, for anything about money, and anywhere the message needs institutional credibility. A payment reminder in Devanagari reads like a bank. The same reminder in Roman Hindi reads like a person, which is exactly wrong for that job.
Transliteration wins in conversational contexts: replies inside an open Customer Service Window, chatbot dialogue, and marketing copy aimed at 18–30 urban audiences who read Roman faster than Devanagari despite speaking Hindi at home. It also wins as a hedge when you genuinely do not know whether a segment reads the script.
The trap is submission. Roman-script Hindi is Hindi content in Latin characters, and if you submit it under the English language code you are describing the template inaccurately to a reviewer and risking a collision with the duplicate-content rule — Meta rejects a template whose body plus footer matches an existing template, and that rule does not apply only to obviously identical copy. Decide the code deliberately and document the decision.
The operational traps that break localised templates
This is the table to keep open while you write. Every row is a failure we see repeatedly, and none of them are visible if you only review copy in a spreadsheet rather than rendered on a phone.
| Trap | What goes wrong | What to do instead |
|---|---|---|
| Grammar forces a different variable order | Hindi and Tamil are verb-final, so the natural sentence puts the date before the verb where English puts it after. Reusing one fixed parameter array across languages delivers the right values in the wrong slots | Keep the meaning of each index fixed ({{1}} is always the name), and build a per-language parameter map at send time rather than resequencing indices |
| A body that ends on a variable | In verb-final languages a trailing {{4}} sits where the verb belongs. If the value arrives empty or short, the sentence has no ending |
Never end a localised body on a variable. Close with a verb or a full stop after fixed text |
| String expansion and truncation | Devanagari, Tamil, Telugu and Malayalam render longer than the English source. Headers and button labels breach their character limits before the body does | Budget roughly 1.3–1.5× the English length, and test button labels first because they have the tightest ceiling |
| Wrong formality register | Machine translation and junior translators produce आप/तुम/तू inconsistently, or informal Tamil (நீ) instead of நீங்கள் | Lock the polite-plural register in a written style guide per language, and enforce it at review, not at draft |
| Gender agreement in Hindi, Marathi and Gujarati | Verbs and adjectives agree with gender, so a sentence built around a variable noun or a customer's name cannot agree correctly for every value | Rewrite into gender-neutral constructions — present-passive and nominal forms rather than gendered past tense |
| Currency and number formatting | ₹482000 rendered with Western grouping (₹482,000) instead of Indian grouping (₹4,82,000), or the ₹ symbol dropped by a font fallback | Format the value in your backend for the Indian locale before it enters the parameter, and confirm ₹ renders in every target script |
| Date formats | "19/08" is ambiguous, and a Latin month abbreviation inside a Devanagari sentence looks machine-made | Pass a fully localised date string per language ("19 अगस्त", "19 ஆகஸ்ட்") rather than one shared string, and keep Latin digits for legibility |
| Mixed-script and RTL payloads | A Latin-script order ID or URL inside an Urdu body reverses visually and becomes unreadable | For RTL languages, isolate Latin runs on their own line, and render-test on a real device before submission |
| Duplicate content across versions | Two languages whose bodies are near-identical after transliteration, or a Roman-script variant submitted under the same code as the English one | Verify each version against the duplicate rule; note the rule does not apply to authentication templates, which is why OTP copy can be near-identical across your set |
| Missing language version | Send logic requests ta, no approved Tamil version exists, and the message fails or silently drops |
Define an explicit fallback chain — regional language, then Hindi, then English — and alert on every fallback so gaps surface |
The per-language parameter map deserves a concrete shape, because it is the fix that saves the most engineering time. Same template name, same send path, one lookup:
order_dispatched / hi → [name, order_id, date_hi, tracking_url]
order_dispatched / ta → [name, order_id, date_ta, tracking_url]
order_dispatched / bn → [name, order_id, date_bn, tracking_url]
The values differ per language because the date is localised, not because the indices moved. If you are wiring this through a platform rather than raw API calls, a template library that shows every language version of a template together is the difference between catching a mismatch at review and catching it in production.
Worked example: one utility template, three languages
Take a hypothetical D2C home-textiles brand in Jaipur shipping across India. Volumes and copy here are illustrative. It runs a dispatch notification as a utility template, sends it around 40,000 times a month, and wants Hindi, Tamil and Bengali versions.
The English source, which is the specification and not the copy to translate:
Hi {{1}}, your order {{2}} has been dispatched and will arrive by {{3}}. Track it here: {{4}}
Four variables: customer first name, order ID, expected delivery date, tracking URL. Category is utility, because it follows up on a transaction the customer already completed and carries no offer.
Hindi (hi, Devanagari):
नमस्ते {{1}}, आपका ऑर्डर {{2}} भेज दिया गया है और {{3}} तक पहुँच जाएगा। ट्रैक करें: {{4}}
What changed and why. The greeting is नमस्ते rather than a transliterated "Hi", because the whole point is that this does not read as an English message wearing Devanagari. आपका is the polite-plural possessive — तेरा or तुम्हारा would be grammatically fine and commercially fatal. The verb construction भेज दिया गया है is passive, which sidesteps gender agreement entirely: no form of this sentence needs to know whether {{1}} is Priya or Pranav. The date variable {{3}} now sits before the verb पहुँच जाएगा rather than at the end, which is why the sentence cannot be produced by substituting words into the English order. And the tracking URL moved to its own line after a full stop, so the body does not end on a variable inside a clause.
Tamil (ta):
வணக்கம் {{1}}, உங்கள் ஆர்டர் {{2}} அனுப்பப்பட்டுவிட்டது. {{3}} அன்று உங்களை வந்தடையும். கண்காணிக்க: {{4}}
What changed and why. One English sentence became two Tamil ones. A single Tamil sentence carrying dispatch and arrival would run long enough to wrap awkwardly on a mid-range Android screen, and Tamil's agglutination means அனுப்பப்பட்டுவிட்டது is one word doing what English needs four for — dense but long. உங்கள் is the polite form. The register is formal written Tamil, not the spoken form, which matters because a business message in spoken Tamil reads either overfamiliar or fake. Note that {{3}} is followed by அன்று, a postposition — so the date string passed for Tamil must be a bare date with no preposition baked in, or the sentence doubles up.
Bengali (bn):
নমস্কার {{1}}, আপনার অর্ডার {{2}} পাঠানো হয়েছে এবং {{3}} তারিখের মধ্যে পৌঁছে যাবে। ট্র্যাক করুন: {{4}}
What changed and why. আপনার is the honorific second person; তোমার would be the intimate form. পাঠানো হয়েছে is again passive, avoiding gender agreement. তারিখের মধ্যে ("by the date of") is added because a bare date before পৌঁছে যাবে reads clipped in Bengali — which means the Bengali body has fixed text the other two do not, and a word-count comparison across versions will look wrong even though every version is correct.
Three things fall out of this exercise. The three localised bodies are all longer than the English source, so a header or button that fits in English needs re-checking in all three. The date parameter must be built three different ways, which is a backend change and not a copy change. And no version is a translation of the English — each is written to the same specification, which is the only method that survives review. If you run this on an abandoned-cart sequence rather than a dispatch notice, be careful that a localised "complete your order" does not acquire promotional framing in translation and push the template into the marketing category, a trap the abandoned cart recovery playbook works through in detail.
What most teams get wrong about multilingual WhatsApp templates
They translate the campaign instead of resourcing the conversation. This is the big one. A broadcast in eight languages generates replies in eight languages, and a three-agent inbox cannot answer them. The customer who receives a fluent Kannada message and gets an English reply — or no reply — is worse off than the one who received English throughout, and they express that by blocking or reporting, which is what actually drives quality rating down. Send only in languages you can hold a conversation in. If you can support two, launch two well.
They use machine translation and are surprised by rejections. Machine translation produces text that is grammatically defensible and registerially wrong, and a reviewer reading a formally correct message in the intimate register with a transliterated brand name and a literally-rendered "shop now" is looking at something that pattern-matches to spam. The specific failure modes are consistent: wrong honorific, gender agreement errors around variable nouns, imperatives that read as commands rather than invitations, and calques of English marketing idiom that have no equivalent. Machine translation is acceptable as a first draft for a native speaker to rewrite. It is not acceptable as submitted copy, and it is never acceptable in a template containing variables.
They assume shared script means shared copy. Hindi copy pasted into a Marathi template will be understood by most Marathi speakers and resented by many of them. Bengali copy served to an Assamese audience is the same error. Script is not language.
They forget the fallback path. Every multilingual send needs an answer to "what happens when this contact's language version is rejected, paused, or was never created". Silent failure is the default, and silent failure in a utility message means a customer who never learned their order shipped.
They localise the message and not the flow. A template that lands in Tamil leading to an English WhatsApp Flow or an English landing page loses the customer at the handoff. Flow screens, button labels, and the automated first reply all need the same language treatment as the template — and Flows are supported on Android 6.0+ and iOS 12+, with support on WhatsApp Web rolling out from December 2025, so the rendering surface matters too.
The native-speaker review loop, in eight steps
This is the process that produces approvable copy. It takes longer than translation and less time than recovering from a paused template.
- Write the English source as a specification, not as copy. State the intent, the category, each variable's meaning, and three realistic sample values per variable including the longest one you would ever pass.
- Brief a native speaker to write, not to translate. Give them the specification and the register rule ("polite-plural, institutional but warm, no exclamation"). Ask for the message they would send to their own parent.
- Have a second native speaker review it aloud. Reading aloud catches register errors that silent reading misses, and it catches the gender-agreement problems that only appear when a specific name is substituted.
- Render it with worst-case variable values on a real device. Longest name, longest product title, longest localised date, a full tracking URL. Check the body, the header, and every button label against its limit. Screenshot it.
- Check it against the traps table — variable order, trailing variables, currency grouping, date construction, RTL isolation, duplicate content.
- Submit one language first and learn from the outcome. Do not submit six versions simultaneously on day one. Send Hindi, see what review says, apply the lesson to the other five. Review runs up to 24 hours, so this costs you a day and can save five rejections.
- Log every rejection with the language and the reason, and fold it into a per-language style guide. Rejection reasons repeat, and the pattern is usually parameter formatting or a policy issue rather than the language itself — InfiQ's breakdown of why WhatsApp templates get rejected maps the common causes.
- Re-review after any edit. An edit re-exposes a template to review and to categorisation, per Meta's template categorization documentation. A one-word change in Tamil is a new submission.
Language detection and routing inside the inbox
Getting the right language onto the send is a data problem before it is a copy problem. Rank your signals by reliability rather than convenience.
The strongest signal is a declared preference captured at opt-in — a language question on the sign-up form, the checkout, or the first Flow screen. Declared language is the only signal that reflects what the customer wants to read rather than what someone inferred about them, and capturing it belongs in the same consent step as everything else in InfiQ's opt-in and DPDP guide. The second-strongest is observed behaviour: the script and language of the customer's own inbound messages, which tells you what they type in even if it does not tell you which script they prefer to read. Third, and weakest, is geographic inference from PIN code, city or state. It is a reasonable default for a first send and a poor basis for a permanent record, because a Bengaluru address says very little about whether the household speaks Kannada, Tamil, Telugu or Hindi.
Store one canonical code per contact, timestamp it, and record which signal set it. Then define the fallback chain explicitly: declared regional language, then Hindi, then English, with an alert whenever a send falls back so gaps in your library surface as data rather than as churn.
On the inbox side, route by language before routing by topic. Tag agents with the languages they can genuinely write, not the ones they can read, and set the queue to prefer a language match. Where you cannot staff a language, be honest in the template: give a phone line and an IST support window rather than implying a chat channel that will answer in a language you do not have. Coaching institutes and schools hit this hardest, because parent communication is the least English-tolerant category in Indian business messaging — the WhatsApp for education playbook goes through that buyer in detail.
Template caps, language multiplication and the arithmetic that surprises people
Every language version consumes a slot. A WhatsApp Business Account holds 250 approved templates if its parent business portfolio is unverified, and 6,000 if that portfolio is verified with an approved display name. Multiply your library by your languages before you commit to a language roadmap.
Take a hypothetical coaching institute in Kota with an unverified business portfolio. It runs 26 distinct utility message types across the student lifecycle — enquiry acknowledgement, counselling slot confirmation, fee due, fee receipt, batch change, test schedule, result published, attendance alert, parent meeting, transport update, holiday notice and so on. It runs 4 authentication templates for portal login. And it runs 12 seasonal marketing templates for admissions cycles.
That is 42 message types. In English alone, 42 of 250 slots, comfortable. Add Hindi, Marathi, Gujarati and Bengali for its out-of-state cohorts and it becomes 42 × 5 = 210 of 250 slots, or 84% of the cap consumed with 40 slots left for the next academic year's experiments. Add a sixth language and it is 252 — over the cap, before a single new message type is created.
| Message types | Languages | Slots used | Against the 250 cap | Against the 6,000 cap |
|---|---|---|---|---|
| 42 | 1 (English) | 42 | 17% | 0.7% |
| 42 | 3 | 126 | 50% | 2.1% |
| 42 | 5 | 210 | 84% | 3.5% |
| 42 | 6 | 252 | Over cap | 4.2% |
| 42 | 12 | 504 | Over cap | 8.4% |
The lesson is not "use fewer languages". It is that business verification is the prerequisite for a serious multilingual strategy, because the jump from 250 to 6,000 is what makes twelve languages arithmetically possible at all. Verification is worth doing anyway — it is also one of the three routes to the 2,000 messaging-limit tier under Meta's messaging limits documentation, where limits now sit at business-portfolio level rather than per phone number.
The cost picture is the counterweight, and it is genuinely good news. Localisation adds no per-message cost. Rate cards are per market and per category, so 40,000 Hindi utility messages cost exactly what 40,000 English utility messages cost, and volume tiers on utility and authentication rates aggregate across the portfolio per market–category pair regardless of language. What localisation costs you is template slots, review cycles, and inbox capacity. Budget those three and check current rates on Meta's downloadable INR rate card or InfiQ's cost breakdown.
One timing note for anyone planning a Q4 rollout. From 1 October 2026 Meta resumes charging for service messages and for utility templates sent inside an open Customer Service Window, both of which are free in August 2026, per Meta's documentation on non-template messages. That makes the free-form multilingual conversation a billable line rather than a free one, and it raises the value of getting the template right first time instead of clarifying in chat afterwards. The full picture is in InfiQ's post on the October 2026 pricing change.
Get started with InfiQ
Multilingual template libraries fail on operations, not ambition. The teams that make it work keep every language version of a template in one view, catch the button-label overflow before submission, and staff an inbox that can answer in the languages they broadcast in. InfiQ onboards you through official Meta Business Solution Provider channels, with a template library, a shared team inbox, broadcast campaigns and InfiQ Flows for in-chat journeys.
Ready to run WhatsApp templates in Hindi and your other priority languages without losing track of versions? Start your 7-day free trial — InfiQ gets you live on the official WhatsApp Business API in about 2 hours, with a template library and a shared team inbox that can be routed by language. Or book a walkthrough to map your existing template set against the languages you actually need first.

