Building eLearning in Hindi, Tamil or Telugu is not the same job as translating it into German. The translation is the easy part. What breaks is typography and layout: Indic scripts form conjunct characters that browsers split when you apply letter-spacing or wrap a line, vowel signs that detach from the syllable they belong to when markup lands mid-conjunct, and a danda that orphans to the next line like a stray comma. On top of that, short interface strings can double or triple in length, and the same course can render correctly in Chrome and wrongly in Firefox and Safari. Plan for typesetting QA per script, not just a translation review.
Key takeaways
- The translation is not the hard part. Typesetting, rendering and QA per script are, and they are the line items most vendors leave out of a quote.
- Indic conjuncts are single typographic units that browsers still treat as separate clusters in some operations — letter-spacing and justification visibly splinter them.
- A vowel sign can end up attached to the wrong consonant if a styling span lands in the middle of a conjunct. It looks like a typo to a reviewer and is actually a markup problem.
- The same published course can render correctly in Chrome and incorrectly in Firefox and Safari, with the correct font installed. Test per browser, not just per language.
- Budget a native-speaker typographic review that is separate from the translation review. A translator checks meaning; almost nobody checks whether the glyphs assembled correctly.
Why this is not just translation with different words
Most localisation advice on the internet is written about European languages, where the work is genuinely mostly translation plus some layout tolerance. German runs about a fifth longer than English, French a little less, and your buttons need room. That advice transfers badly to Indian languages, because Devanagari, Tamil and Telugu are not alphabets in the way Latin is.
They are abugidas. A consonant carries an inherent vowel; other vowels attach as marks that sit above, below, before or after the consonant they modify — sometimes visually before a letter they logically follow. Consonant clusters fuse into conjunct forms that are single shapes, not sequences. The result is that the relationship between what is stored in the file and what should appear on screen is far less direct than in Latin script, and every layer of the stack that assumes otherwise introduces a defect.
India has 22 languages in the Eighth Schedule of the Constitution, and mandated frontline training — safety, compliance, POSH, sector-specific certification — increasingly has to be delivered in the language a worker actually thinks in. The demand is real and growing. The delivery is harder than the sales conversation usually admits.
What actually breaks, specifically
These are not folklore. The W3C maintains a Devanagari gap analysis documenting exactly where web rendering still falls short, and the same classes of defect appear in eLearning output because eLearning output is a web page.
Conjuncts splinter under letter-spacing and justification
A conjunct is two or more consonants fused into one shape. Browsers have historically treated the components as separate grapheme clusters, so any operation that inserts space between clusters — letter-spacing, justified alignment — pulls the conjunct apart and adds gaps that should not exist. A designer who applies tracking to a heading in a Latin-script template has just broken every conjunct on the Hindi version of that slide.
Unicode 15.1 improved the grapheme-cluster rules for Devanagari, Bengali and Gujarati, and the Gecko, Blink and WebKit engines support the newer rules. This is genuinely better than it was. It is not finished.
Vowel signs detach from their syllable
The one that produces the most baffling bug reports. If a styling span — a bold, a colour, a highlight from an authoring tool — lands inside a partial conjunct, the vowel sign can visually separate and appear to modify the following character instead. The W3C describes exactly this: an i vowel-sign that no longer appears at the start of the word and instead looks like it belongs to the next character.
To a reviewer this reads as a spelling mistake. The translator will insist the text is correct, because it is. The defect is in the markup, and no amount of retranslation fixes it.
The danda wraps like an orphan
The danda (।) ends a sentence in Devanagari. It should behave like a full stop and stay with the text before it. Instead it can wrap alone onto the start of the next line, which looks to a native reader roughly like a line beginning with a stray full stop.
Baselines do not agree across scripts
Indic scripts that have a joining headline use that line as the baseline. Mix Devanagari and Latin in one heading — a product name inside a Hindi sentence, which happens constantly in corporate training — and the two scripts sit at visibly different heights unless the fonts were chosen to work together and the line height was set for both.
| Symptom a reviewer reports | What it usually actually is |
|---|---|
| “There is a spelling mistake in this word” | A vowel sign detached by a styling span inside a conjunct |
| “The letters have gaps in them” | Letter-spacing or justification splitting a conjunct |
| “The heading looks crooked” | Baseline mismatch between the Indic and Latin fonts |
| “It is fine on my machine” | Browser engine difference, or a font that failed to embed |
| “Text is cut off / overlapping the button” | Expansion against a layout fixed to English string lengths |
Expansion, and why your buttons break first
Translated text changes length, and the shorter the string the worse it gets. Published figures across languages show short interface strings expanding hardest: a label of ten characters or fewer commonly grows 100–200%, eleven to twenty characters by 80–100%, twenty-one to thirty by 60–80%, and full paragraphs settle around 30%.
That ordering is the important part, because it is the opposite of most people's intuition. Teams review the body copy for overflow and never check the buttons, the menu, the progress labels or the quiz feedback — which are exactly the strings that double.
An honest caveat on the numbers. Reliable per-language expansion figures for Hindi, Tamil and Telugu are hard to find; the widely circulated cheat-sheets cover European languages, CJK, Arabic and Hebrew and simply omit Indic. Anyone quoting you a precise percentage for Tamil is likely extrapolating. Treat the string-length pattern as the reliable guidance and measure your own content rather than trusting a table.
The practical consequence: design the layout to be length-agnostic before translation starts. Buttons that size to content, no text baked into images, no two-line assumptions, and generous line height. Retrofitting this after the Hindi build is where localisation projects lose their margin.
The authoring-tool reality
This is where theory meets the thing you actually publish.
The same course renders differently per browser
A documented case on Articulate's own community: Hindi matras not rendering correctly in Firefox and Safari while the identical course displayed correctly in Chrome — with Noto Sans Devanagari, the recommended font, already in use, published to SCORM 1.2 and tested in SCORM Cloud. The lesson is not that one tool is bad. It is that correct output in your browser proves nothing. Indic QA has to run across engines.
Fonts must be embedded, and chosen as a pair
Pick an Indic font and a Latin font that were designed to sit together, set the line height for the taller of the two, and confirm the font is actually embedded in the published package rather than being resolved from the learner's machine. A frontline worker on a shared Windows terminal may not have your font installed, and the fallback will not form conjuncts the way you tested.
Do not put translated text into images
Obvious, routinely ignored. Every diagram label, every screenshot annotation, every certificate template with text baked in becomes a separate design job per language, and none of it is searchable, accessible or fixable without going back to the source file. Keep text in text layers, always.
Package per locale, and decide the enrolment model early
One SCORM package per language, or one package with a language selector? Separate packages give clean completion reporting per locale and let you ship Hindi before Tamil is ready. A single multi-locale package is tidier for the learner and harder to report on. Pick before you build; converting later means rebuilding the manifest and, usually, the tracking. Our SCORM packaging guide covers the mechanics.
Voice-over, and the mistake everyone makes once
The mistake is treating the English audio timing as fixed and asking the Hindi voice artist to fit it. Speaking rates and sentence structure differ; forcing a translated script into the original timing produces narration that is either rushed to the point of being hard to follow or padded with unnatural pauses. Both read as low quality to a native listener even when every word is correct.
Re-time the slide to the language, rather than compressing the language to the slide. That means on-screen animation cues need to be adjustable per locale, which is a build decision made at the start, not a fix applied at the end.
Two other things worth deciding early. Dialect and register: Hindi for a Delhi office and Hindi for a factory floor in a Hindi-belt district are not the same register, and Tamil has a marked gap between formal written and spoken forms — pick deliberately and brief the artist. Synthetic versus human voice: synthetic Indic voices have improved considerably and are reasonable for high-volume, low-stakes content where the script changes often. For anything a worker's safety depends on, or anything carrying the brand, human narration still wins clearly.
- 1Decide the language list before the English build, not after
Knowing you will ship Tamil changes how you build the English version — layout tolerance, no baked-in text, adjustable animation timing. Retrofitting those decisions is the single largest avoidable cost in a localisation project.
- 2Build the English master to be length-agnostic
Buttons that size to their content, generous line height, no two-line assumptions, and absolutely no text inside images. Test it by pasting placeholder text at double length before you translate anything.
- 3Choose the Indic and Latin font pair together, and embed both
Set line height for the taller script. Confirm the fonts are embedded in the published package rather than resolved from the learner's device — frontline learners on shared terminals will not have your font.
- 4Extract strings, translate, and glossary the terms that must not vary
Product names, safety terms, regulatory language and anything appearing in an assessment. A term that shifts between modules will surface as a learner complaint about the quiz being unfair.
- 5Run typographic QA as a separate pass from translation review
Different person, different question. The translator checks meaning; this pass checks whether the glyphs assembled — conjuncts intact, vowel signs attached to the right consonant, no orphaned danda, no clipped text. A native speaker who has never seen the English version is ideal.
- 6Test across Chrome, Firefox and Safari, on the devices learners actually use
Rendering differs by engine. Add a low-end Android handset to the matrix if that is what the audience has — it usually is, and font fallback behaves differently there.
- 7Re-time audio and animation per language, then package per locale
Do not compress narration to fit English timing. Decide separate packages versus one multi-locale package before building, because switching later means rebuilding the manifest and the tracking.
Translate an existing finished course
- Faster to start, and sometimes the only option when the English course already exists
- Every layout constraint is already baked in, so expansion problems surface as rework
- Text inside images has to be rebuilt per language, one design job at a time
- Animation and audio timing are fixed to English, so narration gets compressed
- Realistic when the course is short, mostly text, and the language list is one or two
Build multilingual from the start
- Layout is length-agnostic from day one, so expansion is absorbed rather than fixed
- All text lives in text layers and string files, so a new language is a translation, not a redesign
- Animation cues and audio timing are adjustable per locale by design
- Adding the fourth language costs a fraction of what adding the second did
- Worth it whenever more than two languages are in scope, or more are likely later
Need something custom-built?
Indian-language delivery is a production capability rather than a feature you switch on: layout that survives expansion, a font pair that renders correctly across engines, a typographic QA pass staffed by native readers, and packaging that reports cleanly per locale. We build courses this way from the start, and we will tell you honestly when translating your existing course is the cheaper right answer.
Add one Hindi slide to your English course before you commit to anything.
Take a real slide — one with a heading, a button, a bulleted list and a product name in the middle of a sentence — translate it, publish it, and open it in Chrome, Firefox and Safari on a mid-range Android phone. Half an hour of work, and it will tell you more about your actual readiness than any vendor conversation.
Frequently asked questions
Why does our Hindi course look correct in Chrome but wrong in Firefox?
Browser engines differ in how they handle Indic grapheme clusters and vowel signs. Unicode 15.1 improved the clustering rules and Gecko, Blink and WebKit all support the newer rules, but vowel-sign handling still varies. This is why cross-browser testing has to be part of Indic QA — correct output on the machine that built the course proves very little.
A reviewer says there is a spelling mistake but the translator insists the text is right. Who is correct?
Usually both. The text is correct and the rendering is not. When a styling span lands inside a partial conjunct, a vowel sign can visually detach and appear to modify the following character — it reads exactly like a typo. Look at the markup around the word before sending it back for retranslation.
How much longer does Hindi or Tamil text get?
Nobody publishes trustworthy per-language figures for Indic scripts — the widely shared expansion tables cover European languages, CJK, Arabic and Hebrew and skip Indic entirely. What holds across languages is that short strings expand hardest: labels under ten characters commonly grow 100–200%, while full paragraphs settle nearer 30%. Measure your own content rather than trusting a percentage.
Can we just use machine translation?
For a first pass on high-volume, low-stakes content, increasingly yes, with native review afterwards. For anything assessed, regulated or safety-critical, no — not because the grammar will be wrong but because register and domain terminology will be, and a mistranslated safety instruction is a different category of error from an awkward sentence.
Should each language be a separate SCORM package?
Separate packages give clean completion reporting per language and let you ship one language before the others are ready, which usually matters more than it sounds. A single multi-locale package with a language selector is neater for the learner but harder to report on. Decide before building — converting afterwards means rebuilding the manifest and normally the tracking too.
Are synthetic Indic voices good enough yet?
For high-volume content that changes often, they have become reasonable. For safety-critical training or anything carrying the brand, human narration is still clearly better — and either way, re-time the slide to the language rather than compressing the narration to fit the English timing.
What is the single biggest avoidable cost?
Deciding to localise after the English course is finished. Length-agnostic layout, text kept out of images and per-locale animation timing are cheap decisions at the start and expensive rework at the end. If a second language is even plausible, build for it from the first slide.
Where to start
If you are scoping a multilingual rollout, the useful first move is the half-hour test in the tip above — one real slide, one language, three browsers, on the hardware your learners have. It converts an abstract project into a concrete list of things to fix.
Related reading:
- Course development services — how we build courses intended for more than one language
- SCORM packaging and publishing to Moodle — the per-locale packaging mechanics
- eLearning development cost in India — market benchmarks, including where localisation sits
- Training video production cost in India — relevant once voice-over and subtitles enter scope
Or write to marketing@edzlms.com.