WhatsApp templates in Hindi and other Indian languages

A template is submitted with a language, and a version in another language is a separate submission requiring its own review. Approval of the English version tells you nothing about whether the Hindi one will pass. This is the first practical fact to plan around, because it means a three-language rollout is three review cycles, not one with translations attached.

It also means quality is tracked per language version. A poorly received Tamil template can accumulate negative feedback while the English one continues untroubled, which is diagnostically useful and easy to miss if a business thinks of them as one template.

The scheduling consequence is the one that catches people out. A business planning a campaign in several languages needs every version approved before the campaign runs, and a rejection in one language while the others pass leaves an awkward choice between delaying the whole campaign and running it for only part of the audience. Submitting all language versions together, well before the launch date, is the way to avoid discovering this with no time to fix it.

It is worth deciding early which languages you are genuinely committing to, because each one is an ongoing obligation rather than a one-off translation.

Running an approved English template through a translation tool and submitting the output is the most common approach and the least reliable. It fails for reasons that are structural rather than a matter of translation quality.

The first is register. Indian languages encode formality and social distance in ways English does not, and a translation that ignores this can be inappropriately familiar or stiffly bureaucratic. A message that reads as neutrally polite in English can land as either presumptuous or cold, and neither is what the business intended.

The second is that variables break. Word order differs, so a placeholder that sits naturally mid-sentence in English may need to move — and it cannot move to the beginning or end, since a template cannot start or end with a bare variable. Grammatical agreement is a further problem: languages with gender or case marking need the words around a placeholder to agree with a value that is not known until send time, which sometimes requires rephrasing so that no agreement is needed.

The third is that a phrase can be correct and still not be what people say. The everyday word for an appointment, a delivery or a payment in a given region may not be the formal dictionary term, and a template using the formal one reads as a translation. Recipients notice, and a message that reads as machine-translated undermines the trust the business was trying to build.

The temptation is to cover as many languages as possible. The better approach is to cover fewer, properly, because a badly written message in someone's own language is worse than a clear message in a language they read comfortably.

The test is not which languages are widely spoken in India but which ones your customers actually prefer to read. Those are different questions. A business can usually answer the real one from evidence it already has: what language customers write in when they message first, what staff use on the phone, what the shop floor uses, which regions the customer base is concentrated in.

English deserves specific thought rather than an assumption in either direction. Many Indian customers read business communication in English comfortably and find it normal in that context, while others do not. Code-mixing — Hindi vocabulary in Roman script, or English terms embedded in a regional-language sentence — is how a great many people actually write, though it makes a template harder to get right and to review consistently.

There is also an ongoing cost worth pricing before committing. Every language is a version to maintain when the message changes, a version whose quality has to be watched, and a version somebody must be able to read when a customer replies in it. A business that adds a language it cannot support in conversation has created an expectation it will fail.

The check that catches the most problems is unglamorous: give the draft to someone who speaks the language natively, is not the person who wrote it, and ideally resembles the intended recipient. Ask them what the message means and what they would do next.

That second question is the valuable one. A translation can be accurate and still leave the recipient unsure what is being asked of them, and asking for the meaning alone will not reveal that. If a reader cannot say what action the message expects, the message has failed regardless of its grammar.

Ask also whether anything reads as rude, overly familiar, or oddly formal. Register problems are invisible to a non-native speaker and obvious to a native one, and they are the errors most likely to cause offence rather than mere confusion.

Test with real values in the placeholders rather than sample text. A template that reads well with a short name and a tidy date can become ungrammatical with a long compound name, a different date format, or an item description that does not agree with the surrounding words. This is where the variable-agreement problems surface, and they surface reliably only with realistic data.

A final read on a phone is worth the minute it takes. Script rendering, line breaks and text length differ across languages, and a message that fits neatly in one may wrap awkwardly in another.

Having several approved language versions creates a new problem: knowing which one to send to whom. Sending a Tamil template to someone who reads only Hindi is worse than having no Tamil version at all, because the message was both irrelevant and unintelligible.

The most reliable signal is what the customer used themselves. Someone who messaged the business in Hindi has told you their preference more dependably than any inference from location. Recording that preference the first time it becomes apparent, and storing it against the contact rather than remembering it, is what makes it usable later.

Inference from region or name is a weak substitute and worth treating as a guess. India's linguistic geography does not map cleanly onto state boundaries, migration is ordinary, and a name says little about reading preference. Where language is genuinely unknown, asking is better than guessing, and asking once and storing the answer is better than asking repeatedly.

There is also a fallback to decide deliberately: which version goes out when preference is unknown. That should be an explicit choice, sensible for the largest part of the audience, rather than whichever version the system happens to default to.

A multilingual template set is a maintenance commitment, and this is the part underestimated most often. When the message changes — a new price, a changed process, a corrected detail — every language version needs updating and resubmitting. A business that updates the English version and forgets the others is now sending contradictory information to different segments of its customers, which is worse than the inconsistency it was trying to avoid.

Replies arrive in the language the message was sent in, which is the obvious consequence and the one businesses most often fail to plan for. Sending in Tamil invites Tamil replies, and a business with nobody who reads Tamil has created an inbound conversation it cannot service. Adding a language is a commitment to converse in it, not just to broadcast in it.

Quality signals should be read per language version, since an aggregate view can hide one version performing badly. And it is worth revisiting the language set periodically, because a customer base shifts and a language added for a region the business no longer serves is maintenance without benefit.

None of this argues against multilingual messaging, which is straightforwardly valuable in a country where most people prefer not to conduct business in English. It argues for choosing a set you can sustain, and treating each language as a channel rather than a translation.