You own the training catalog. Maybe you run L&D for a company that just opened a plant in Monterrey, maybe you manage compliance training for a health system whose workforce speaks six languages, maybe you are the instructional technologist at a district that needs its staff onboarding modules in Spanish and Vietnamese before the next hiring wave. The course is built. It works. Someone opened the authoring tool, found the translation export, and said: “Great — we’ll send this file out and import it back.”
Here is what that plan gets wrong. The translation export is not the course. In Articulate Storyline 360, for example, File › Translation › Export produces a Word or XLIFF file of the text the tool can see: slide text, buttons, quiz questions. It cannot see words that are part of a graphic, a screenshot, or a video frame. It does not contain your narration audio. It knows nothing about the animation timeline that was built around English sentence lengths. Translate the export, import it back, publish — and you get a course that is partly in the target language, partly in English, and timed for a language nobody on the receiving end is listening to.
The five layers of a course, and which ones the export sees
A published course is a stack. Each layer needs its own decision, and the export touches only one of them.
| Layer | What it contains | In the text export? |
|---|---|---|
| On-screen text | Slide copy, buttons, labels, quiz questions, feedback | Mostly yes |
| Embedded text | Words inside images, screenshots, infographics, video frames | No — source files needed |
| Audio | Narration, scenario dialogue, video soundtracks | No — script and recording needed |
| Timing and interaction | Animation cues, synced highlights, timed navigation, branching | No — must be re-synced after translation |
| Package and tracking | SCORM/xAPI manifest, completion rules, scoring, LMS metadata | No — must be re-published and tested |
The villain in most failed eLearning localization projects is not bad translation. It is scope that was drawn around the export file, because the export file is what the authoring tool made easy.
On-screen text: plan for expansion, and find the text you cannot select
English is compact. Most European target languages run longer, and short strings grow the most: W3C’s internationalization guidance, citing IBM’s design guidelines, shows strings of ten characters or fewer commonly running two to three times their English length. Button labels, menu items, and callouts are exactly those strings. A “Next” button that fit perfectly becomes a truncated or overflowing one.
Three decisions keep this from turning into a slide-by-slide repair job:
- Get the source files for every graphic with words in it. Layered design files let a designer swap text; a flattened PNG means rebuilding the graphic. Screenshots of software need to be re-captured in the localized interface where one exists, or annotated where it does not.
- Leave room. Fixed-size text boxes and tight button shapes are where expansion breaks layouts. Auto-fit settings help but can shrink text below legibility.
- Decide right-to-left early. Arabic, Hebrew, Farsi, and Urdu need mirrored layouts, not just translated strings — the same issue we covered for websites in website localization vs. translation.
Audio: voiceover, subtitles, or both
This is the biggest scope and budget decision in the project, and it should be made deliberately, per course, not by default.
Re-recorded voiceover
Best for learner experience and for content where learners need their eyes on the screen — software simulations, equipment procedures, safety demonstrations. It is also the option that most disturbs timing: a translated script almost never lands at the same length as the English, so every animation cue, synced highlight, and timed slide transition built against the English audio has to be re-synced. Scripts should be translated and adapted for speech before recording, not read cold from on-screen text.
Subtitles
Faster to produce and easier to update, and they leave the original audio in place. The trade-off is reading load: a learner reading subtitles over a busy animated screen with its own on-screen text is splitting attention. Subtitles work well for talking-head video and interviews; they work poorly for dense procedural slides.
Both
For many organizations the answer is voiceover plus same-language captions — and for accessibility, that is often not optional. Which brings us to the layer most localization scopes forget.
Not sure which of your courses need voiceover and which can run on subtitles? Send us the course list with a short description of each. We will recommend an audio approach per course and flag which ones have text baked into graphics before anyone starts translating.
Accessibility does not carry over between languages
If your English course was built to WCAG 2.1 Level AA — the standard DOJ adopted for ADA Title II web content and mobile apps, with the first compliance date April 26, 2027 for larger public entities — the localized version has to meet it too. Conformance is a property of each published version, not of the project. In practice that means:
- Captions per language (WCAG 1.2.2). Prerecorded audio in a video needs synchronized captions. New Spanish narration needs Spanish captions; the English caption file does not satisfy it. Our captioning services produce human-reviewed caption files in the target language.
- Transcripts for audio-only content (WCAG 1.2.1). Podcast-style modules and audio scenarios need a text alternative in the language of the audio. A transcription of the localized recording, not a translation of the English script, is what matches what the learner actually hears.
- Language of page and parts (WCAG 3.1.1 and 3.1.2). The player and content must declare the correct language so screen readers pronounce it properly. A Spanish course still tagged as English is read aloud with English pronunciation rules — unusable for the learner it was built for.
- Alt text for every localized image. Alternative text is text. It has to be translated, and it has to describe the localized graphic, not the original.
An accessible English course plus a translation is not an accessible translated course. The accessibility work is redone, or at least re-verified, in every language.
Assessments: equivalent, not just translated
Quizzes are where literal translation quietly does the most damage, because a bad assessment does not look broken — it just measures the wrong thing.
- Clues that appear or disappear. In English, the correct answer might be the only option that agrees grammatically with the stem. In a gendered language, a careless translation can create that tell or remove it, changing difficulty.
- Distractors that stop being plausible. A wrong answer built on an English idiom or a U.S.-specific reference may be obviously wrong, or confusingly right, in another market.
- Interaction logic. Drag-and-drop targets, fill-in-the-blank fields with an exact-match answer key, and text-entry questions all need their accepted answers localized — including accents, alternate spellings, and word order.
- Regulated content. For compliance training that has to be defensible — safety, harassment prevention, clinical procedures — the assessment is part of the record that a worker was trained and understood. That is a reason to use qualified human translators with subject-matter review, not raw machine output.
SCORM and xAPI: re-publish, then test in your LMS
Every localized version is typically published as its own package — a separate SCORM zip (with its own imsmanifest.xml) or a separate xAPI/cmi5 package — and uploaded to the LMS as a new course or a language variant. Three things go wrong here more often than anywhere else:
- Things that should not be translated get translated. Interaction identifiers, variable names, and xAPI activity IDs are machine keys, not copy. Translate them and completion or scoring stops reporting, frequently without any visible error.
- Reporting splits. If you need to compare completion or scores across languages, the tracking scheme has to be consistent across versions from the start. Decide what a completion means, and how the language variants roll up, before the first package is built.
- Nobody tests in the real LMS. A package that previews correctly in the authoring tool can still fail to launch, resume, or report in production. Each language version should be launched, completed, and failed deliberately in the actual LMS before learners see it.
A three-step plan that gets it right the first time
- Inventory the course, not the export. List every layer from the table above for each course: text, embedded text, audio, timing, package. Collect source files for graphics and the final narration scripts.
- Decide per course. Voiceover or subtitles, which languages, which assessments need subject-matter review, and what accessibility deliverables each version requires.
- Localize, rebuild, and test end to end. Human translation with independent review, audio production, re-sync, per-language accessibility, re-publishing, and a documented test pass in your LMS.
Get this wrong and the costs are concrete: learners in the new market tuning out a half-English course, completions that never reach the LMS, an assessment record that would not survive scrutiny, and a second project to fix the first. Get it right and a single master course serves every workforce you have, with records you can stand behind.
Why a language access provider, not just a translation shop
Language Access Hub, powered by Taika Translations, is a veteran-owned (VOSB), SAM-registered, GSA- and NASPO ValuePoint-contracted language services provider working with ATA-certified linguists. eLearning localization sits where three of our service lines meet: human translation, captioning and transcription, and Section 508 and WCAG accessibility. That matters because the failures above happen in the handoffs between those disciplines — and a single provider accountable for all of them has no handoff to hide behind.