22 scheduled languages, one app: what Indic localization actually costs to ship in 2026
Summary. India's Constitution lists 22 languages in the Eighth Schedule, and the 2011 Census recorded 121 languages and 270 mother tongues with 10,000 or more speakers. India had 958 million active internet users as of the IAMAI and Kantar Internet in India Report published 29 January 2026, with roughly 548 million of them rural, over 57% of the total, and rural growth running at nearly four times the urban pace. Against that, machine translation has become the cheapest line in the build: AWS Translate lists $15.00 per million characters and Google Cloud Translation lists $20.00 per million characters for standard neural translation, both with free tiers. AI4Bharat's IndicTrans2 and IndicConformer models are MIT licensed and free to self-host, covering 22 official Indian languages for speech recognition. So the translation bill for a mid-sized app is measured in hundreds of dollars, not thousands. The cost lands elsewhere: in text shaping, font selection, string handling and layout, where a naive implementation produces broken glyph clusters that no amount of translation quality can fix. This article covers what to budget, what to build, and the specific engineering traps.
The demand side, with real numbers
The IAMAI and Kantar ICUBE 2025 study, launched 29 January 2026 at the India Digital Summit in Bengaluru, gives the current picture from a sample of roughly 87,000 to 100,000 respondents across more than 400 towns and 1,000 villages:
- 958 million active internet users, growing around 8% year over year.
- Approximately 548 million rural users, over 57% of the total, with rural growth at nearly four times the urban rate.
- 588 million, or 61%, consuming short-video content.
- 44% engaging with AI-enabled features such as voice search, image search and chatbots, rising to 57% among 15 to 24 year olds.
- 193 million multi-device users, 20% of the base, up from 165 million in 2024.
- 18% going online via someone else's device, around 80% of them rural.
- 38% of the population, roughly 579 million people, still not active online.
One caution on a figure you will see quoted everywhere. The line about 870 million users accessing the internet in Indic languages comes from the 2024 edition of the same report series, not the 2026 release, and we could not verify it from a primary document, so it is not repeated here as current. The 2026 press release does not carry an Indic-language usage figure at all. Build the business case on the rural and next-user numbers above, which are current and sourced, rather than on a language-share statistic that circulates without provenance.
The census picture matters for scoping. The 2011 Census, still the latest language data published by the Office of the Registrar General, recorded 121 languages and 270 mother tongues at the 10,000-speaker threshold, split into the 22 Eighth Schedule languages in Part A and 99 others in Part B. Of the 22 scheduled languages, 21 exceed one million speakers; Sanskrit is the only exception at 24,821. Hindi leads at roughly 528 million, followed by Bengali at about 97 million, Marathi at 83 million, Telugu at 81 million and Tamil at 69 million.
No product ships 22 languages at once. The scoping conversation is which five or six earn their maintenance cost, and the answer is almost always driven by where your users already are rather than by speaker counts.
Translation is now the cheap part
Here is what the three routes cost as of August 2026.
| Route | Price | Free tier |
|---|---|---|
| AWS Translate, standard text | $15.00 per million characters | 2 million characters per month for 12 months |
| Google Cloud Translation, NMT | $20.00 per million characters | 500,000 characters per month, as a recurring $10 credit |
| Google Translation LLM | $10.00 per million input plus $10.00 per million output | Shared with the NMT credit |
| AWS Active Custom Translation | $60.00 per million characters | 500,000 characters per month for 2 months |
| Google custom AutoML NMT | $80.00 per million, tiering down to $30.00 above 4 billion | 500,000 characters as a $40 credit |
| Self-hosted AI4Bharat IndicTrans2 | Infrastructure only, MIT licence | Not applicable |
Azure AI Translator is deliberately absent from the price column. Its public pricing page is JavaScript-rendered and returns the literal placeholder $- in place of every per-character rate, so we could not verify the figures. What does render as static text on that page: the F0 free tier is 2 million characters per month covering standard translation and custom training combined, the D3 instance is $40 per million for custom translation and document translation with training data at $10 per million and training capped at $300 per job, and the older S2, S3 and S4 instances are deprecated in favour of commitment tiers at 250 million, 1 billion and 4,000 million characters per month.
Two comparison traps are worth flagging, because they are how procurement gets the wrong answer. AWS's 2 million free characters run for 12 months only, while Azure's F0 2 million is monthly with no stated expiry but is shared with custom model training. They are not the same offer. And Google bills per code point including whitespace and untranslated markup, so <p> tags and attributes inside your strings are billed characters; an empty request still bills one character.
To put it in build terms: a consumer app with 4,000 UI strings averaging 40 characters is 160,000 characters per language. Six languages is under a million characters, which sits inside a single month's AWS free tier and costs under $15 at list once the free tier lapses. Translation is not the budget line anyone should be arguing about.
Bhashini: excellent, government-backed, and not priced for production
Bhashini is the Indian government's language platform, built on the ULCA architecture, where models carry a Model ID and developers call pipelines identified by a Pipeline ID. It is genuinely capable, and the developer documentation is good.
The service catalogue is broader than translation alone. Pipelines support ASR, NMT, TTS and combinations including ASR plus NMT plus TTS. The exposed task types include translation, transliteration, text-to-speech, audio and text language detection, named entity recognition, OCR for scene text, handwritten and printed sources, speaker enrolment and verification, speaker diarization, language diarization, voice cloning and lip sync. Notable service identifiers include a multilingual conformer ASR covering 22 languages, IndicTrans v3 covering 15 languages, and a transliteration service listing 24 languages.
The integration pattern is three calls: an optional pipeline search, then a mandatory pipeline config call, then a mandatory pipeline compute call. Onboarding runs through the ULCA portal with email authentication, and keys are generated under the profile page. Each integrator is limited to 5 keys, app names must be lower case with shows, and the config call needs a user ID alongside the API key.
The commercial position is the thing to understand before you architect around it. Bhashini's own documentation states that usage of the APIs is for proof of concept purposes only, and that anyone wanting to use them on production systems, or charging end users, should contact the Bhashini team for the paid version and pricing plans. There is no published rate card, no per-character price and no published production quota.
That is not a criticism. It is a design constraint. Prototype on Bhashini, validate the language quality, then negotiate a production agreement or fall back to a commercial API or self-hosted models before launch. Building a production dependency on an endpoint whose terms say proof of concept is how a launch slips.
One trap worth naming: bhashini.ai and bhashiniservices.com are a separate private vendor with their own subscription pricing. They are not the government platform, and their rates should never be presented as Bhashini's.
Self-hosting AI4Bharat: what is actually available and licensed
AI4Bharat, the research lab at IIT Madras, publishes the models most Indic pipelines are built on, and the licensing is unusually friendly.
| Model | Coverage | Licence |
|---|---|---|
| IndicTrans2, 1B parameters | Tagged 26 languages, paper covers all 22 scheduled languages | MIT |
| IndicTrans3-beta | 15 primary languages plus preliminary support for 7 low-resource | CC BY 4.0, gated |
| IndicConformer-600M-Multi | 22 official Indian languages, hybrid CTC and RNNT speech recognition | MIT |
| IndicF5 text-to-speech | 11 Indian languages, 0.4B parameters, 24 kHz output | MIT |
| IndicBERTv2-MLM-only | 23 Indic languages plus English, 278M parameters | MIT |
IndicTrans2 remains the pragmatic choice for most production deployments because it is MIT licensed and ungated, with RoPE long-context variants handling up to 2,048 tokens. IndicTrans3-beta is built on Gemma-3 and fine-tuned for document-level translation, which makes it the better fit for long-form content, but it is a gated repository under CC BY 4.0 and you must accept terms to pull it.
IndicF5 is worth a design note. It is voice-prompted rather than zero-configuration: it requires reference prompt audio and a reference transcript alongside the text, so an application using it needs a curated set of reference voices per language rather than a single API call. Budget that as a content task, not an engineering one.
The build-versus-buy line falls in a predictable place. Below roughly 50 million characters a month, a commercial API at $15 to $20 per million is cheaper than the GPU hours and the operational burden. Above that, or where data residency rules out sending text off-premises, self-hosting IndicTrans2 becomes the sensible route, and the MIT licence removes the legal friction that usually kills the idea.
Where the money actually goes: shaping, fonts and strings
This is the section that separates a working Indic launch from one that ships broken text to a million users.
Indic scripts require complex text layout. The Noto documentation puts it plainly: many scripts need several glyphs to represent the same character in different positions within a word, and the shaping rules that enable complex text layout live in the font's advanced typographic features. Browsers and most word processors support shaping fully, but many applications, especially older graphic design tools, do not support shaping for all scripts. The symptom is unmistakable once you know it: letters appear disjoined or in reverse order.
Critically, the reordering happens in the shaping engine, not in the font. Microsoft's Devanagari script development documentation states that OpenType lookups in an Indic font must be written to match glyph sequences after reordering has occurred, and that fonts should not have substitutions that attempt to perform the reordering themselves. The engine divides text into syllable clusters, finds the base consonant by scanning backwards, decomposes two- and three-part matras before repositioning them, and reorders reph and matras into pre-base, below-base, above-base and post-base positions. Only one pre-base reordering Ra is allowed per syllable.
The practical consequence is the single most useful thing in this article. Naive string operations break Indic text. Substring, reverse, character count and truncation with an ellipsis all operate on code points, and a Devanagari or Tamil syllable cluster spans several code points that must stay together. A character-count validator that works fine in English will reject valid Hindi input. A "show first 40 characters" truncation will chop a cluster in half and render a broken glyph. Audit every string utility in the codebase before the first Indic string reaches it.
The font trap almost every Indic build gets wrong
Noto ships two families for most Indic scripts, and choosing the wrong one produces cramped, clipped text in exactly the places users notice.
From the Noto documentation: letters in Arabic, Indic and Southeast Asian scripts often connect both vertically and horizontally, so text for continuous reading in those scripts needs a more generous line height. For those scripts, Noto includes an additional family with the UI suffix, which is more compact vertically and has the same line height as the basic Noto Sans fonts.
Noto's own guidance prescribes the UI variant for Bengali, Devanagari, Gujarati, Gurmukhi, Kannada, Malayalam, Oriya, Sinhala, Tamil and Telugu, plus Khmer, Lao, Myanmar and Thai, wherever vertical space is limited. That means buttons, tab bars, list rows, form labels and navigation. The non-UI family belongs in document and article body text where line height can breathe.
Latin, Cyrillic and Greek share a single Noto font, but Devanagari, Arabic, Chinese, Hebrew and emoji each have dedicated fonts, so a multi-script app needs an explicit font stack rather than one file. The pattern from the Noto documentation looks like this:
font-family: 'Noto Sans Devanagari', 'Noto Sans Tamil', 'Noto Sans',
'Noto Sans Symbols 2', sans-serif;
Variable Noto fonts only work in newer applications and systems, so ship static Noto if the target platform range is wide.
Vertical space, not horizontal expansion
The commonly quoted translation expansion percentages, such as 200% to 300% growth for strings of 10 characters or fewer, come from IBM's guidelines for European languages as quoted by the W3C. They are not Indic data, and we could not verify an Indic-specific horizontal expansion rate from any primary source.
The documented Indic risk is vertical. The W3C states that numerous scripts require much more height than Latin text, including Devanagari as used for Hindi, partly because of taller glyphs and partly because of larger inter-line spacing. Design implication: fixed-height rows, single-line buttons and vertically centred labels are where Indic layouts break, not fixed-width containers. Test with Devanagari and Tamil in every component with a constrained height before writing the localization off as done.
The platform mechanics, Android and iOS
Both platforms now support per-app language selection, which changes the design of the settings screen and removes the need to build a custom language picker that fights the system.
Android. The centralised per-app language setting arrived in Android 13, API level 33, and requires compileSdkVersion 33 or higher. The framework APIs are LocaleManager.setApplicationLocales() and getApplicationLocales(), and the app must declare android:localeConfig on the <application> element pointing at an XML locale configuration. Omit that attribute and users simply cannot set your app's language independently of the device.
One documentation discrepancy to be aware of: Google's own pages disagree on the filename, with the localization guide showing res/xml/locale_config.xml and the Android Gradle Plugin 8.1.0 release notes showing res/xml/locales_config.xml. Check which one your build actually resolves rather than trusting either page.
AGP 8.1.0 and Android Studio Giraffe added automatic generation. Set generateLocaleConfig = true under androidResources and add a res/resources.properties file with unqualifiedResLocale=en-US. It is off by default, and the build fails if you also hand-write a locale configuration file.
For anything below API 33, the AppCompat backport does the work through AppCompatDelegate.setApplicationLocales(LocaleListCompat), available from AppCompat 1.6.0, which shipped stable on 11 January 2023. Four caveats cost real debugging time:
- On Android 12, API 32, and lower the backport works with the
AppCompatActivitycontext, not the application context. - With Compose, the activity must extend
AppCompatActivityor the locale silently fails to apply. - Persistence below API 33 requires the
AppLocalesMetadataHolderServiceentry withautoStoreLocales=true, which performs a blocking main-thread read and trips StrictMode disk-read and disk-write violations. - Calling
setApplicationLocalesrecreates the activity unless you handle locale configuration changes explicitly.
iOS. String Catalogs, the .xcstrings format, arrived in Xcode 15 and supersede both .strings and .stringsdict files. They compile down to the older formats at build time, so adopting them requires no change to the deployment target. Apple's guidance from WWDC 2024 is that for apps supporting multiple localizations, when a user has more than one language in Language and Region settings, the app-specific language setting appears automatically. To force it to appear regardless, set UIPrefersShowingLanguageSettings to YES in Info.plist, and deep-link to it with UIApplication.openSettingsURLString.
Store metadata is a separate track from the app UI. App Store Connect now supports 50 localizations, with recently added languages including Bangla, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Tamil, Telugu and Urdu. Localised store listings are cheap and drive install conversion, and they are frequently forgotten in projects that localise the app itself thoroughly.
What a realistic Indic localization engagement looks like
| Phase | Work | Typical duration |
|---|---|---|
| Language selection | Analytics on current regional traffic, support-ticket language mix, market priority; pick 4 to 6, not 22 | 1 to 2 weeks |
| String audit and extraction | Externalise hard-coded strings, adopt String Catalogs or locale config, fix string utilities that break clusters | 2 to 4 weeks |
| Translation pipeline | Commercial API or self-hosted IndicTrans2, glossary for product terms, review workflow with native speakers | 2 to 3 weeks |
| Typography and layout | Noto UI variants in constrained components, vertical space fixes, per-script font stack, device testing | 2 to 4 weeks |
| Voice and speech, if needed | IndicConformer for ASR, IndicF5 with curated reference voices for TTS | 3 to 5 weeks |
| Store and support | Localised App Store and Play listings, in-app help, support routing by language | 1 to 2 weeks |
Two honest observations from doing this work. The translation review with native speakers is the step teams try to skip, and it is the step that determines whether the app reads as native or as machine output; product terminology, honorifics and register are where machine translation is weakest and where users notice fastest. And the typography phase consistently takes longer than planned, because the failures only appear on real devices with real content, not in design mockups rendered with a Latin fallback font.
How eCorpIT can help
eCorpIT builds Indic-language support into mobile and web products as a scoped engagement: string audit and extraction, a translation pipeline on either a commercial API or self-hosted IndicTrans2, typography and layout work using the correct Noto UI variants, and native-speaker review of the strings that carry your product terminology. Our senior engineering teams work across Android with Kotlin, iOS with Swift and Flutter, and we design data handling aligned with Digital Personal Data Protection Act requirements where user content passes through a translation service. eCorpIT is CMMI Level 5 appraised, ISO 27001:2022 certified and MSME registered, based in Gurugram since 2021, and works with AWS, Microsoft and Google as technology partners. If you are planning a regional launch and want the string and typography audit done before translation starts, talk to our team.
Related reading: our enterprise mobile app development guide, Android and Kotlin app development, iOS and Swift app development, Flutter app development, and our accessibility audit and remediation service, which shares most of its testing surface with localization work.
FAQ
How many languages does an Indian app need to support?
Almost never 22. India's Eighth Schedule lists 22 scheduled languages and the 2011 Census recorded 121 languages at the 10,000-speaker threshold, but four to six languages chosen from your own regional traffic and support-ticket mix covers most demand. Each additional language carries permanent translation review and testing cost.
What does machine translation cost for Indian languages in 2026?
AWS Translate lists $15.00 per million characters for standard text and Google Cloud Translation lists $20.00 per million for neural machine translation. AWS includes 2 million characters monthly free for 12 months; Google gives 500,000 characters monthly as a recurring $10 credit. Google bills whitespace and markup as characters.
Can I use Bhashini in production?
Not on the public APIs as documented. Bhashini's developer documentation states that usage is for proof of concept purposes only, and directs anyone deploying to production or charging end users to contact the Bhashini team for the paid version and pricing plans. No public rate card exists. Prototype on it, then negotiate before launch.
Which AI4Bharat models can I self-host commercially?
IndicTrans2 for translation, IndicConformer-600M-Multi for speech recognition across 22 official Indian languages, IndicF5 for text-to-speech in 11 languages, and IndicBERTv2 for language understanding are all MIT licensed, so they carry no commercial restriction. IndicTrans3-beta is CC BY 4.0 and gated, requiring you to accept terms before download, and it is built on Gemma-3 for document-level translation.
Why does my Hindi or Tamil text render as broken glyphs?
The shaping engine, not the font, reorders Indic syllable clusters. Microsoft's Devanagari documentation states that font lookups must match glyph sequences after reordering has occurred. If your rendering path lacks complex text layout support, letters appear disjoined or reversed. Naive substring and truncation operations produce the same symptom.
Which Noto font variant should I use for Indic scripts?
Use the UI-suffixed family in constrained vertical space. Noto's guidance prescribes Noto Sans UI variants for Bengali, Devanagari, Gujarati, Gurmukhi, Kannada, Malayalam, Oriya, Sinhala, Tamil and Telugu where space is limited, because they are more compact vertically. Use the standard family for document and article body text.
How do per-app language settings work on Android and iOS?
Android 13, API level 33, added the centralised per-app language setting, requiring android:localeConfig on the application element; AppCompat 1.6.0 backports it below API 33. On iOS, the app-specific language option appears automatically when a user has multiple languages set, and UIPrefersShowingLanguageSettings forces it to show.
How many internet users does India have, and how many are rural?
The IAMAI and Kantar Internet in India Report published 29 January 2026 puts active internet users at 958 million, growing around 8% year over year, with approximately 548 million rural users representing over 57% of the total. Rural adoption is growing at nearly four times the urban rate.
References
- Languages included in the Eighth Schedule of the Indian Constitution, Department of Official Language
- Abstract of Speakers' Strength of Languages and Mother Tongues 2011, Office of the Registrar General, India
- Internet in India Report 2025 press release, IAMAI and Kantar, 29 January 2026
- Bhashini APIs developer documentation
- Bhashini available models and service identifiers
- Bhashini prerequisites and onboarding
- AI4Bharat IndicTrans2 1B English to Indic model card
- AI4Bharat IndicTrans3-beta model card
- AI4Bharat IndicConformer 600M multilingual model card
- AI4Bharat IndicF5 text-to-speech model card
- AI4Bharat IndicBERTv2 model card
- AWS Translate pricing
- Google Cloud Translation pricing
- Azure Translator pricing details
- Using Noto fonts, Noto documentation
- Developing OpenType fonts for Devanagari script, Microsoft Learn
- Text size in translation, W3C internationalization
- Per-app language preferences, Android developers, updated 11 May 2026
- Android Gradle Plugin 8.1.0 release notes, updated 16 July 2026
- Discover String Catalogs, WWDC 2023 session 10155, Apple
- Build multilingual-ready apps, WWDC 2024 session 10185, Apple
- Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology
Last updated: 3 August 2026.
Top comments (0)