Localising eLearning into six Indian languages

At Learning Owl I managed localisation into Hindi, Tamil, Kannada, Punjabi, Gujarati, and Telugu. At Kidvento I've used HeyGen and ElevenLabs to produce localised video content in Hindi and French without re-recording.

Most of what I now believe about localising eLearning, I learned by getting one of those wrong first.

Treat the translation file as code, not as content

If your translators send back a Word doc, you've lost. The handoff has to be a strict structured file — JSON, XLIFF, CSV with locked keys — that nobody can re-flow accidentally. Once we accepted a Word doc full of "translated columns," we shipped a module that mixed two languages on the same slide because a row got skipped during paste. After that, the file format was non-negotiable.

Length is the variable nobody warns you about

Devanagari Hindi runs roughly 1.2× to 1.4× the character count of English. Tamil runs longer still. Buttons that fit "Continue" in English will overflow with "தொடரவும்". Buttons that fit "जारी रखें" will look anaemic with "OK."

You can't tweak each slide's layout per language unless you want N Storyline files. Design the layout for the longest target language first, leave generous space everywhere, and accept that the English version will look slightly too airy. It will land fine in Tamil.

Audio is a separate project from text

When a client asks for "Hindi localisation" they almost always mean text plus audio. Treat them as separate work streams. Text changes are mechanical. Audio re-records depend on voice talent availability, studio time, and a re-QA pass for every slide where narration timing changed. Estimate them separately or you will be late.

Hindi is more than one register

There is formal, Sanskrit-leaning Hindi — the variety used in government communication — and there is the spoken Hindi most learners actually use. Pick a register consciously, write it into the style guide, apply it ruthlessly. The most common reviewer complaint is not "this is wrong" but "this is the wrong register," and the only defence against that is having committed to one in writing before the first slide is translated.

RTL is a redesign, not a translation

Hindi to Punjabi is a copy-paste away. Hindi to Urdu is not. RTL is a layout problem — mirrored navigation, reversed timeline arrows, audio progress that grows leftward — and a Punjabi-shaped build won't carry over. "We already do Hindi, Urdu should be easy" is the assumption you'll be asked to defend most often. It's wrong.

Numbers, dates, units are content

A learner survey we shipped once asked "How many years have you been at this company?" The Hindi translation was clean. The number input next to it accepted only ASCII digits. A non-trivial number of learners typed "तीन" (three, in Devanagari) and were rejected by validation. Numbers are content. So are dates, currencies, and measurement units. If you haven't checked whether the form accepts the localised form, you have a bug.

Cultural context is the part you can't outsource

A compliance module that opens with a Diwali office-party scenario lands oddly in Tamil Nadu, where Pongal is the regionally celebrated festival. The Tamil reviewer caught it. We changed the opening for the Tamil version. Then we noticed the Punjabi version had a similar issue, and the Kannada one, and the Telugu one was actually fine, and the rule turned out to be: open with a regional festival the learner's office would actually mark.

That isn't translation. That's a per-region rewrite. There is no AI tool that will tell you to do it. The reviewer who lives in the region is the most valuable role in the localisation stack.

Build the master as if the localised versions exist

The strongest single habit: when authoring the English master, write it as if you already know it will become five other languages.

• Avoid puns and idioms
• Avoid scenarios where a specific cultural backdrop is doing load-bearing work
• Keep sentences short
• Avoid sub-clauses that translate to four words in one language and a single word in another — that's how audio timing diverges across locales

The constraints that come from "this has to translate" tend to push you toward writing that is shorter, more direct, and more universally readable — including in the source language.

On voice talent

Regional voice talent matters more than the budget conversation suggests. A voice that sounds like the learner's own raises completion rates in a way generic pan-Indian narration does not. If you can only invest in one thing per localisation, invest in the voice. Text can be tightened by reviewers. Voice has to be cast right the first time.

On AI-assisted localisation in 2026

I use HeyGen and ElevenLabs in the Kidvento pipeline for Hindi and French — generally for prototype passes and for languages where regional voice talent is hard to schedule. The current state of the tools:

• Strong for: time-pressed prototype passes, languages where a regional human is scheduled but you need a draft now, lip-synced video where re-shooting is impractical
• Weak for: register nuance, cultural rewrites, idiom, the kind of small voice-acting choices that distinguish a usable narration from a memorable one

The right pattern is human-in-the-loop. AI drafts the variant, a regional reviewer revises, a regional voice records the version that ships. Skipping the reviewer step is the failure mode I see most often.

Closing

Localisation is the part of eLearning where the gap between "technically correct" and "actually works for the learner" is widest. Hire a reviewer in the region. Build the pipeline so their changes apply at the file level rather than the design level. Assume the first version of any localised module will be wrong in a way you don't yet know.