· updated

Language Is Product, Not Localization

Building for India's languages at ShareChat, Lokal, and a multilingual newsroom taught me that language changes the product, not just its strings.

Consumer IndiaContent Systems

Most products treat language as the last step: build the product, then translate the strings. I’ve spent years building for India’s language users, at a vernacular social platform, at a Tier 2/3 local-news app, and across a newsroom publishing in eight languages. I’ve come to a blunter view: language is a product decision that touches everything upstream of the strings. Treat it as a checkbox and the checkbox will quietly cap your growth.

If you’re the PM deciding whether the next language is a translation project or a product launch, this essay argues for the second, and for staffing and measuring it that way: field research in the new market, a cost-per-language number you work to bring down, and a native reviewer at the point where trust is decided.

Language users are not English users minus English

At Lokal, I owned onboarding and sharing for Tier 2/3 users, and the roadmap wasn’t written in a Bangalore office. It was corrected by field usability sessions, watching real users in their own context. What we saw wasn’t a translation problem. It was different mental models: different trust barriers at signup, different expectations about what an app may ask for, and sharing behavior organized almost entirely around WhatsApp.

So the fixes weren’t translations either. We redesigned onboarding around the confusion and trust barriers we actually observed, and completion rose 9%. We rebuilt share formats around how WhatsApp forwarding really works in those communities, and organic installs rose 10%. Neither win came from better strings. Both came from treating the language user’s context as the spec.

The invisible product: language operations

If languages are your growth surface, launching a language is a product flow, with users (your internal teams), latency, and failure modes. At Lokal, expansion was bottlenecked not by demand but by how long each new language took to stand up. We automated the launch process, cut launch time by 30%, and expanded into two more languages.

That reframe matters for any multilingual roadmap. Alongside “which language next?”, ask what your cost per language looks like and what would halve it. Teams that never ask this ship one flagship language experience and n−1 degraded copies.

In the newsroom: translation is editorial, not mechanical

At Asianet News I rebuilt the editorial CMS for a network spanning eight languages, and AI made cross-language publishing far cheaper. A story in one language could become grounded drafts in the others, with AI-suggested titles, tags, and metadata per language.

But the decision that made editors adopt it, rather than resist it, was refusing to treat translation as mechanical. Every AI-assisted draft was approved by that language’s editor before publishing. A Kannada headline isn’t a Malayalam headline passed through a model; register, idiom, and news judgment are language-local. The system’s job was to take the mechanical bulk off the desk and hand a native editorial mind the part that actually decides trust. Editorial output tripled, not because humans were removed, but because they were repositioned to the only place they were irreplaceable.

The AI era raises the stakes

Generative AI makes multilingual output nearly free, which means the floor is now trivially reachable, and indistinguishable from the trap. A model will happily produce fluent-looking text in dozens of languages. Whether it reads as native, lands the right register, or handles the code-switching real Indian users actually type is exactly the kind of quality that fails silently in a language your team doesn’t read.

So multilingual AI products inherit the rule the newsroom taught me: your evaluation has to be language-native even when your team isn’t. Language-local review, language-local quality gates, language-local golden examples. If you only evaluate the English surface, you’re shipping n−1 products you’ve never actually seen.

What this means if you’re the PM

  • Audit your second language as hard as your first. Put the flagship experience next to the same flow in your next-biggest language. The gap between them is your real localization debt, and it belongs on the roadmap.
  • Watch users in their context at least once per market. The trust barriers you’ll find are not in your analytics.
  • Track cost per language launch as a product metric. If nobody owns that number, expansion speed is set by whichever team is slowest.
  • Keep a native human at the decision point that carries trust, and design the AI to make that person fast, not optional.

The teams that win language markets aren’t the ones that translate the most strings. They’re the ones that noticed language was the product all along.


The numbers here are from my work at Lokal (2021–22) and Asianet News (2022–25); more on how I think about AI-assisted content systems in the motomotar case study.