पाठशाला Pathshala · ग्राहक Grāhak, The customer · Lesson 29 · Scale

Localisation for India: more than translating the app

A translated menu is the smallest part of localising for India. Script, input, numbers, payment habits and support decide whether a user who prefers Tamil or Marathi stays. Choose the order of languages from your own usage data.

Pathshala, The Founder Library · 11 October 2026 · 7 min read

Most Indian products are localised the same way: a translation agency turns the interface into Hindi in a fortnight, a language switch appears in settings and almost nobody uses it. The users who needed it were lost at the keyboard, the payment screen or the help article, none of which was translated.

This lesson sets out what localisation for India actually includes, how to pick the order of languages from your own usage data rather than from a map, the engineering that breaks in Indic scripts, why payment habits belong in the locale, and the quarterly review that decides whether to add the next language. A figure ranks languages by what they recover.

Translation is the smallest part

The size of the opportunity has been clear for a decade. The KPMG and Google report Indian Languages: Defining India’s Internet, published in April 2017, counted 234 million Indian-language internet users against 175 million English users in 2016. Its survey findings are the more useful part for a product team: about 70 per cent of Indian-language users said they struggled with English keyboards, about 88 per cent were more likely to respond to a digital advertisement in their own language, and about 60 per cent named limited language support as the largest barrier to using online services. The figures are nearly a decade old; the direction has not reversed.

Read those numbers again and only one of them is about translated text. The rest are about input, trust and whether the whole service works in the language, not just the menu. Localisation has six layers, roughly in order of difficulty. Language of the interface. Script, including users who write Hindi in Roman letters. Input: keyboards, voice and transliteration. Formats: lakh and crore, dates, names and addresses that do not fit Western forms. Payment methods and the language of payment messages. Support and help content in the same language as the product.

Read your usage data before choosing a language

The census tells you how many people speak a language. It does not tell you how many of your users struggle in English or what that costs you. Four signals in your own data do. Device language: the share of new users whose phone is set to an Indian language. Location: state from pincode or IP, which is a rough proxy and no more. Transliterated search and chat: users typing “kaise kare” into a search box or a support chat are telling you their language and that they will not switch script. Support tickets by language, including voice notes.

Use those signals to define cohorts, then measure each cohort’s onboarding completion against users who chose English. The gap, multiplied by the size of the cohort, is the number of users each month whom the English product is losing. That is the case for localising, and it is a case a finance head can check. A language cohort that completes onboarding as well as English users does not need a translated product first; it may need nothing at all.

Order the languages by what they recover

Localisation has a cost: translation of the interface, help articles, messages and notifications with a native reviewer, then a monthly cost for support, content and every new string from every release. Set the recovered activations against that cost and a payback period falls out for each language. Launch the shortest first.

At fifty thousand new users a month, half the gap closed and ₹300 of contribution per activated user, only Hindi pays back within a year on this data, in under seven months. Tamil, with a smaller cohort but the widest gap, comes second at about twenty months. Double the new users and Tamil, Telugu, Marathi and Bengali all fall inside a year, while Kannada takes nearly two years and Gujarati and Malayalam nearly five. The order is not the order of speakers in the country; it is the order of the gap in your funnel, and it changes as you grow. The one number nobody knows in advance is the share of the gap localisation closes. Launch one language, measure it for a quarter and use that measured figure for the rest.

Choose languages by the gap in your own funnel, not by the number of speakers on a map. Measure the first before you build the second.

Scripts and the engineering that breaks

Indic scripts break interfaces built for English in predictable places. Conjunct consonants and vowel signs above and below the line need taller line heights, so buttons and table rows sized for Latin text clip them. Text often runs longer, so labels overflow. Line breaking has its own rules: the W3C’s draft Indic Layout Requirements says breaks should fall at word boundaries and should not be allowed inside numerical values such as currency amounts or years. Use fonts with full Indic coverage, test every screen in the longest language rather than the shortest, and never put text in images.

Input matters more than display. Support transliteration so users can type in Roman letters and see their own script, and accept both scripts in search. Offer voice input where the task allows it; many users who struggle to type will speak. Machine translation has become usable for first drafts: the government’s Bhashini platform, as a PIB backgrounder of October 2025 describes it, enables real-time translation for the 22 Scheduled Languages and several tribal languages. Every string a customer will read still needs a native reviewer who knows the product; machine output gets the words right and the register wrong.

Formats are the cheapest win. Show money in lakh and crore with the Indian digit grouping, accept names with one word, and accept addresses that describe a landmark. These changes help every Indian user, including the ones who chose English.

Payment habits are part of the locale

A user who completes onboarding in Marathi and meets a card form in English has not been localised. Map how each cohort pays: UPI apps, cards, net banking, cash on delivery or a family member who pays on their behalf. Make the payment screen, the OTP message and the receipt match the product’s language.

For users on feature phones or poor connections, NPCI’s UPI 123PAY lets people pay without internet through an IVR number, a missed call, a feature-phone app or a sound-based tap at a merchant, and offers multiple language options on the IVR. If any part of your service reaches those users, through an agent, a shop or a collection flow, test whether it can take a 123PAY payment before you translate a single screen. The lesson on [building for low-end Android and patchy networks](/library/building-for-low-end-android-patchy-networks) covers the rest of that stack.

Support in the language you sell in

A product in Tamil with support in English sends the user back to English at the moment of most frustration. Before launching a language, have at least one person who can answer support in it during working hours, a set of help articles for the ten most common questions, and the ability to receive voice notes. Keep a glossary of the product’s terms in each language, agreed once and used everywhere, so the same feature is not called three different things in three screens. Decide early whether a term stays in English: many users know “OTP”, “EMI” and “KYC” better than any translation, and a purist rendering of them helps nobody. Test the glossary with ten users from the cohort before launch, not with the translator.

Watch the support data for the first quarter. A rise in tickets in the new language is usually good news: users who were silently dropping out are now asking for help. A fall in onboarding completion is not; it usually means a translated term confused people, and the glossary needs a change.

The quarterly localisation review

Every quarter, an hour with product, growth and support. Refresh the cohorts: device language, location and transliterated search, by month. Measure the gap for each launched language against its pre-launch baseline, and for each candidate against the English cohort. Recompute the payback with the measured share of the gap closed, not the assumed one. Check the cost of keeping up: strings released untranslated, help articles out of date, support response times by language. Decide one thing: add a language, fix one, or hold.

A language that has not narrowed its gap after two quarters needs a fix in input, payment or support before it needs more translation. A language that has narrowed it is the evidence for the next one.

The data in the figure is illustrative. Survey figures are from the KPMG and Google report of April 2017; payment and platform details were checked in October 2026.

Sources

1. KPMG in India and Google, Indian Languages: Defining India’s Internet (April 2017) — 234 million Indian-language users against 175 million English users in 2016; ~70% struggle with English keyboards; ~88% more likely to respond to local-language ads; ~60% cite limited language support as the largest barrier.
2. W3C, Indic Layout Requirements (Working Draft, 29 May 2020) — Line breaks at word boundaries; no breaks inside numerical values such as currency amounts or years.
3. Press Information Bureau, 22 Languages, Digitally Reimagined (25 October 2025) — Bhashini enables real-time translation for the 22 Scheduled Languages and tribal languages.
4. NPCI, UPI 123PAY product overview — UPI without internet via IVR, missed call, feature-phone app and proximity sound; multiple language options on the IVR. Checked October 2026.