India has 22 scheduled languages and hundreds of dialects. Nigeria has more than 500. Indonesia has over 700 living languages, with Bahasa Indonesia as the unifying official language and dozens of regional languages in active daily use. Across the Global South, most of the populations that social sector technology is meant to serve do not primarily operate in English, and often not in the national official language either.
Most social sector tech products are built in one language and localized later, if at all. The ones that reach multilingual populations at scale are built with localization as a first-class architectural concern from the start. The difference isn't just in the timeline; it's in what becomes possible.
Three localization models
Translators receive a content export, translate offline, and hand it back. High quality from qualified translators with domain expertise, but timelines run in months. Every source content change triggers a new translation cycle. Doesn't scale with content volume: the cost per language stays constant regardless of how many languages you've already done.
Right for: low-volume content in sensitive domains where quality is non-negotiable and timelines are long.
Machine translation applied directly to content strings, no human review. Fast and cheap. Quality is uneven for domain-specific vocabulary, poor for content requiring cultural adaptation, and often inadequate for voice content where accent and register matter as much as word choice.
Right for: internal documentation, low-stakes content, early prototyping. Not right for content in health, legal, financial, or education contexts where errors carry real consequences.
AI translation generates a first draft, domain experts review and correct, corrected output feeds back into the model. Collapses translation cycles from months to weeks without sacrificing quality on domain-specific content. Each iteration builds a domain-specific translation corpus, so quality improves over time as the model learns from expert corrections.
Right for: most social sector products targeting multilingual deployment. The emerging standard for organizations that need both quality and scale.
Infrastructure choices in the Global South
India's open-source multilingual stack (Bhashini, IndicTrans2, and the AI4Bharat language models developed at IIT Madras) provides a foundation for HITL localization across Indian languages without building translation infrastructure from scratch. Kisan-eMitra, the AI grievance redress system serving over 110 million PM Kisan farmers, deployed across 11 Indian languages using this stack. What would have been a multi-year manual translation effort became a rapid deployment, with the stack handling initial translation and domain experts from agriculture and social protection handling review.
Sarvam AI's 22-language voice platform extends this further into speech: recognition, synthesis, and two-way conversation across Indian languages, built on open-source foundations so the linguistic assets remain with the deploying organization rather than locked to a vendor.
Organizations that build localization on open or standards-based infrastructure own their linguistic assets: the translation corpus, the domain-specific corrections, the voice models. Organizations that build on proprietary APIs own nothing. When the vendor changes pricing or discontinues a language, the work done to that point has no residual value.
For contexts outside India, the infrastructure choices are different but the principle holds. The localization pipeline should be built on open or standards-based infrastructure wherever available, both to reduce cost and to ensure that the organization retains what it builds.
What needs to be true upstream
A HITL localization pipeline only works if the content architecture supports it. This is the connection between the previous post in this series and this one: atomic content is localizable content.
If content is stored as discrete objects (individual strings, individual audio scripts, individual feedback messages), a localization pipeline can operate on each object independently. Review cycles are shorter because each unit is small. Version control is simpler because each object updates without affecting others. Incremental deployment is possible because translated objects can be released as they complete review, rather than waiting for the entire library.
If content is packaged in monolithic files, none of this is possible. The localization pipeline hits the same structural problem as the content update pipeline: everything is coupled, so every change requires touching everything. Organizations that try to add multilingual capability to a monolithic content architecture typically end up maintaining separate full copies of the entire content library per language, with all the maintenance overhead that implies.
Designing for voice from the start
Text translation is only part of the localization problem in low-resource contexts. A significant share of users in these contexts have low literacy in any written language. Products that reach them need voice interfaces: spoken prompts, spoken responses, spoken feedback.
Voice localization has different requirements than text localization. Accent matters in ways written language doesn't. Regional dialect variation may not be captured in a standard language model. The reference audio used to train speech recognition may not reflect the acoustic environment of rural deployment: ambient noise, low-quality device microphones, speaker variability across age and gender.
Building for voice from the start means making audio a first-class content type in the architecture: stored as data, localizable at the component level, testable in the target deployment environment before launch. Retrofitting voice into a text-first product is structurally similar to retrofitting localization into a monolingual product: technically possible, but expensive, incomplete, and often worse than starting again.
Three questions for product builders and funders
1. What is your current localization cycle time for a single-language content update? At that speed, how many languages could you realistically maintain without the localization effort becoming the dominant constraint on content quality?
2. Are your content objects small enough that a translator can review a single unit independently? If understanding one object requires reading surrounding content for context, your content isn't atomic enough to support efficient localization review.
3. Who owns the translation assets your localization pipeline produces? The corpus of domain-specific corrections built up through HITL review has real value: it encodes expertise that took years to develop. That asset should belong to the organization or to the commons, not to a vendor.