Multilingual WhatsApp Templates Without Duplicating Everything

The first multilingual template I shipped went out to a customer in Tamil Nadu in English. Nothing was broken. The template existed, it was approved, the send returned success. It was simply the wrong language, because I had built the system around one default and never taught it to ask.

That is the whole trap with multilingual messaging: the technology works perfectly and the customer experience is still wrong.

WhatsApp does not translate anything for you

This is the fact that determines your architecture, so start here. A template is submitted per language. Meta reviews each language variant separately, and each one has its own approval status. There is no "translate" button and no automatic routing of a message to the recipient's device language.

At send time you name the language yourself, using a language code. If you do not pass one, you send the default you configured. WhatsApp renders exactly what you asked for.

So the honest summary: multilingual templates are one template name with several approved language variants, and choosing the right variant is your job, on every single send.

Structure it as one template, many variants

The mistake I see most often is treating each language as a separate template with its own name: order_update_en, order_update_hi, order_update_ar. It works, right up until you need to change one sentence, and then it is five submissions, five reviews and five chances to get a rejection.

Use one template name and different language variants. That keeps the shape of the message identical across markets, which matters more than it sounds:

• The variable count has to stay the same everywhere. Your sending code passes {{1}}, {{2}}, {{3}}; if the Hindi variant expects four placeholders and the English one expects three, the wrong send fails at runtime and only for that language.
• Section order should not drift. A customer changing language mid-conversation should recognise the message.
• Templates get re-reviewed when edited, so a single shared structure means one place to reason about.

Keep the variable values language-neutral wherever you can. A date, an order number, an amount, a link: those are the same bytes in every language. Put the language-specific wording in the template body and the data in the parameters. Then adding a language is a submission, not a re-architecture.

The part nobody budgets for: knowing which language to send

Before you can pick a variant you have to know the customer's language. There are three ways to get it, in descending order of reliability.

1. Ask once, store it on the contact. A consent step or a first conversation message that asks "English, हिन्दी, தமிழ்?" and stores the answer is the only method that is both accurate and durable. It also gives you a language the customer chose rather than one you inferred.
2. Preference collected at checkout or signup. Often correct, frequently stale, and a field many products never mark as required.
3. Geo or phone country code. The weakest option, and the one teams reach for first. A country code tells you roughly where a number was issued, not what language a person reads comfortably. India alone has more than twenty languages, and a Netherlands number can belong to someone who reads Turkish.

Treat the third as a default only, and treat it as an explicit column in your data with a flag saying "guess". When someone replies in a different language, that reply is a better signal than anything you inferred, so capture it and update the contact. This is the same discipline as consent: the customer told you something, so write it down. If your opt-in flow is not already solid, that is the prerequisite and it is worth fixing before adding languages, which is exactly what opt-in and consent on WhatsApp covers.

When a translation is missing or rejected

Two things go wrong in production and both are silent unless you plan for them.

A variant does not exist yet. You send for a customer whose language has no approved variant. The API rejects the send with a template-not-found style error for that language. If your code assumes success, you learn about it when the customer complains, or never. Make the send path ask "is this variant approved?" before it fires.

A variant gets rejected. Translation submissions get rejected for the same reasons English ones do, plus a few of their own: character encoding problems, a localised price or date format that trips a rule, a call-to-action phrase that reads as promotion in one language and not another. The process is the same as any other review and it is documented in the message template approval guide; the recurring causes are in why WhatsApp templates get rejected.

Neither of these should ever be a dead end. Decide the fallback order in advance and write it down:

1. The customer's stored language.
2. A secondary language you actually support for that market.
3. Your default, which is usually English.

A fallback is not a failure. A customer receiving a clear English message is fine. A customer receiving nothing, because your system threw an exception on a missing variant, is not. Log every fallback with the contact id and the language that was missing: that log is your backlog for which translation to add next, ranked by real demand rather than by a market sizing deck.

Arabic, RTL and the formatting details that bite

Right-to-left languages are where a template that looks fine in code renders wrong in the chat.

• Do not hand-build RTL. Put the text in the template in its natural order and let WhatsApp handle direction. Mixing direction marks into a body to force alignment breaks in other clients and in previews.
• Numbers and links inside RTL text can display in unexpected order at the edges. Test the rendered message on a real device, not in a code editor.
• Emoji and flags are usually punctuation rather than information. A flag does not mean a language.
• Do not put a translated variable through a machine translation on the fly. Parameters are data. If a customer's name or an address is in one script, keep it as it is; translating a name is how you get a message that looks automated and slightly wrong.

What to build first if you only have two languages

Do not build a translation framework. Build the smallest thing that is correct:

1. Add a language field to the contact record, defaulted but flagged as a guess.
2. Ask for the language once, in the first conversation, with buttons.
3. Create one template with two approved variants, same variable count.
4. On send, look up the contact's language, fall back to the default, log when you fall back.

That is a day of work and it covers the overwhelming majority of real traffic. Languages three through ten are then submissions and data, not new code.

If your message volumes are growing, remember that every variant you send is a billable message at the same rate as the original, and marketing-category templates outside the customer service window cost more than the free-form messages inside it. The structure of those charges is in WhatsApp Cloud API pricing in 2026, and language does not change any of it.

Where BNex fits

BNex runs your WhatsApp conversations on your own verified number, with the inbox, contacts and campaigns in one place. That matters for multilingual work because the language belongs on the contact, and the contact is where your team already works. When an agent switches a contact's language after a reply, the next template send can honour it instead of guessing again.

If you are planning a second or third language and want a second opinion on whether to submit variants or restructure the template first, message me on WhatsApp at wa.me/917358722745 with the languages and roughly what the message does. I will tell you which order I would do it in.

Related Reading