To localise e-learning content successfully, translate and adapt the entire learning experience—not just the text on each slide. A complete project may include written lessons, interactive choices, assessment feedback, captions, audio narration, accessibility features and the way course progress is reported to a learning management system (LMS).
This practical guide explains how to localise e-learning content step by step, from the initial course audit to linguistic review, LMS testing and launch. It covers common workflows involving Storyline, Rise and Captivate, includes a clearly hypothetical English-to-French-and-Arabic example, and finishes with a delivery checklist.
If you first need the distinction between translation and localisation, read what e-learning localisation means. If you are commissioning rather than building the course, see TranscribeLingo’s e-learning language services for course text, subtitles, audio, supporting resources and multilingual delivery requirements.
What does e-learning localisation actually include?
E-learning translation converts learning text or spoken language into another language. Localisation adapts the course so the learner can navigate it, understand examples and complete its intended tasks in an appropriate linguistic and cultural context. A source course can be accurate when translated sentence by sentence and still fail learners because of clipped buttons, untranslated feedback or an assessment that does not launch.
| Course component | What needs localising | How to verify |
|---|---|---|
| On-screen lessons and navigation | Titles, instructions, buttons, tooltips, hints and progress messages | Inspect every state and layout in the target language |
| Quizzes and assessments | Questions, answer options, scoring explanations and feedback | Test correct/incorrect branches, retries and passing conditions |
| Audio and video | Narration, scripts, visual labels, captions and subtitles | Check pronunciation, timing, line breaks and visual synchronisation |
| Illustrations and examples | Text embedded in graphics, units, names and culturally specific references | Review relevance without changing the learning objective |
| Course player and LMS | Language settings, menu labels, launch paths, completion and reporting | Publish and finish a real test attempt in the target-language package |
| Accessibility | Captions, alternatives, keyboard access, reading order and language identification | Test with representative users and assistive technologies |
The goal is an instructionally equivalent experience, not mechanical word-for-word similarity. In mandatory training, especially compliance or safety topics, changes to examples, instructions or assessed meaning should be agreed with the relevant subject-matter owner.
Step 1: audit the source course before translation
Make an inventory of everything the learner sees and hears. Include the published course, editable authoring source, media files, question banks, downloadable PDFs, narrated scripts, glossary and any separate LMS configuration. Run through the entire English course as a learner and capture its existing behaviour before work starts.
- Audience and locale: Is the target French for France or Canada? Is Arabic for a particular region? Identify languages and locales precisely.
- Learning objectives: Determine which concepts, outcomes and safety instructions must remain consistent.
- Source assets: Collect editable Storyline/Rise/Captivate projects, PowerPoint, video source files, fonts, illustrations and accessible alternatives.
- Interactions: List branches, slide layers, hotspots, question banks, success/failure feedback and navigation controls.
- Systems: Confirm the LMS, its supported package format and whether a learner can switch languages within one package.
- Approvals: Assign subject-matter reviewers, language reviewers, developers, accessibility testers and the final sign-off owner.
Freeze a version of the source course for the initial translation round. Uncontrolled source changes are a common cause of missing or mismatched text during import. If updates are likely, agree a change log and a process for assessing which target languages require rework.
Step 2: prepare translation-ready files, scripts and terminology
Avoid copying text manually from screenshots when editable project files exist. Where the tool supports it, export the text in the native or interchange format required by the translation workflow; preserve IDs, variables, markup and placeholders. Give translators screenshots or previews so short phrases such as “Next”, “Continue” and “Complete” can be interpreted in context.
Build a terminology list covering product names, role titles, course outcomes and legally or technically defined concepts. A translation memory can help with repeated training modules, but every reused match must still fit the current context. For source-content preparation, refer to how to write translation-ready text.
Separate variables from language content. For example, in a quiz message such as You scored {score}%, the target-language wording may change but the functional {score} token must remain intact. Check variables, links, alt text and error states instead of only the visible lesson paragraphs.
Step 3: translate course text and interactive assessments
Translate learning objectives, lesson explanations, navigational labels, quiz stems, answer options, hints and every branch of the learner journey. A professional translation review should confirm not just grammar but whether the wording prompts the intended decision or action. The assessment must test the same skill after localisation.
Give special care to multiple-choice questions. A distractor that was clearly wrong in the source language may become ambiguous after translation. A mnemonic or joke may no longer be meaningful. The linguist and instructional designer should agree an equivalent target-language example rather than silently changing a key technical concept.
Preserve placeholders and identifiers and avoid moving question IDs or result variables inadvertently. After import, rerun every quiz choice, including incorrect paths, retries, pass/fail states and explanations; errors can occur outside the first or default branch.
Step 4: localise videos, narration, subtitles and supporting audio
Create a media inventory with filenames, spoken language, duration, whether the original narration is retained, and which text is embedded in each shot. Decide whether each language needs translated subtitles, a new voiceover, dubbing, re-recorded screen captures or a combination.
- Subtitles: Work from a verified script or transcript, translate the speech faithfully, then retime and line-break the captions for the actual target language.
- Captions: Include meaningful non-speech audio and speaker information when needed, not just dialogue. Maintain accessibility in each target language.
- Voiceover: Match pronunciation and agreed terminology; allow for a longer translated script by adjusting timings or visual sequences without losing learning content.
- On-screen video text: Translate callouts and demonstrations through editable overlays or appropriate localised media assets.
- Downloads and supplemental resources: Check linked PDFs, worksheets, transcripts and filenames so the learner is not sent back to an untranslated source document.
Audio, video and captions often form separate deliverables. Read our e-learning audio localisation guide and e-learning transcription and captioning accessibility guide for related topics. The W3C’s WCAG guidance on prerecorded captions explains that captions convey meaningful sound information as well as dialogue.
Step 5: work with Storyline, Rise and Captivate carefully
Articulate Storyline 360
A common external-language workflow in Storyline is to export translation-ready text from an editable project, translate the supported file format and reimport it into a suitable copy of the source course. Depending on the project and tool version, workflows may involve XLIFF or Word and require manual attention to slides, layers, feedback states and masters. After import, visually review layouts and triggers—not just the translated strings.
Articulate also offers built-in multilingual management and AI localisation for Rise and Storyline. These features have their own limitations: Articulate staff explain that a project already translated through Articulate Localization may not support later external XLIFF export. If an external CAT-tool review or client-owned TMX/XLIFF workflow is essential, establish the export method before using built-in localisation. Confirm feature behaviour in the version actually deployed.
Articulate Rise 360
Rise can offer an export-and-translate workflow using supported XLIFF, or built-in Articulate Localization for supported setups. Articulate’s official localisation overview describes translating and validating multilingual training within Articulate 360. Before committing to a particular workflow, test whether the format, language, review process and output packaging meet your needs; not every new Articulate content type exposes the same external export options.
Adobe Captivate
Adobe Captivate supports exporting text for localisation and importing translated content, but authoring and language support is version-specific. Adobe’s Captivate 13.0 FAQ states that right-to-left languages such as Arabic and Hebrew are not supported in that version. For an Arabic project, do not assume that translating the text will give a functioning RTL interface; verify product compatibility and select a suitable alternative approach before production.
The authoring tool, translation management system, CAT tool and LMS perform different jobs. A TMS may coordinate language tasks, but it does not automatically fix authoring layouts or certify that a published SCORM package reports completion correctly.
Step 6: rebuild layouts for text expansion and right-to-left needs
Translated phrases can be longer or shorter than the original. Allow space in buttons, scrolling panels, quiz feedback and responsive layouts instead of shrinking text until it is hard to read. Check every breakpoint and interaction state, including mobile landscape and narrow portrait screens.
For right-to-left content, evaluate text direction, alignment, interface order, numbers, punctuation, mixed Latin names, embedded terms and whether the authoring/player system supports RTL. Mirroring all visual elements is not necessarily appropriate: timelines, diagrams and brand assets may need case-by-case treatment.
Use fonts that contain the required character sets and correctly shape Arabic or other scripts. Test actual learner devices and platform combinations; successful rendering in an exported Word file does not prove the final course player supports the language.
Step 7: publish and test SCORM, xAPI and LMS functionality
The original source course may work perfectly and the translated one may not. Build the target-language package using the LMS-approved delivery method, then upload it to a staging course. Keep the source package and translated package version numbers traceable.
- Launch: Sign in as a learner and start the translated course from the actual LMS, not only the authoring preview.
- Navigation: Finish every required lesson; check external files, backwards/forwards movement and resume/bookmark behaviour.
- Assessments: Test passing, failing, retrying and answer feedback, including branching scenarios.
- Reporting: Verify completion status, score and other required learning records are received correctly by the LMS.
- Alternative paths: Test mobile devices, multiple browsers and language-specific settings as relevant.
- Re-entry: Close the course and return; verify that saved progress and completion behave as intended.
SCORM and xAPI are distinct tracking approaches; use the specifications supported by your LMS. The ADL SCORM best-practices guide describes content packages and the value of inspecting actual behaviour rather than assuming package validity. When testing an xAPI workflow, inspect statements and reporting in the configured learning record store (LRS) as appropriate. Do not claim compatibility solely because a ZIP file imported successfully.
Step 8: test e-learning accessibility in every language
Accessibility is not completed simply by adding translated subtitles. Test the course against the relevant requirements of WCAG 2.2 and any applicable organisational standard. The content and the surrounding course player may require separate assessment. Review language identification, focus order, keyboard operation, accessible labels, heading structure, contrast and text alternatives.
- Can learners complete all required interactive questions with a keyboard?
- Does the translated course have an understandable focus order and labelled controls?
- Do captions and transcripts match the target-language audio and meaningful sounds?
- Do screen readers announce target-language content appropriately, including mixed-language terms where relevant?
- Do larger text sizes, zoom and mobile layouts expose every instruction and answer choice?
- Are important diagrams and embedded text available through suitable accessible alternatives?
Check accessibility with real assistive technology where practical and document failures by language, screen, control and severity. Compliance conclusions require testing to the applicable standard; publishing a course in multiple languages does not itself demonstrate accessibility conformance.
Step 9: review language, functionality and learner acceptance
Use separate sign-offs for linguistic quality, functional QA and learner acceptance. A language reviewer can approve terminology without discovering a broken quiz, while a developer can verify completion tracking without recognising a mistranslated instruction. Bring these checks together before release.
| Review | Owner or specialist | Typical issues |
|---|---|---|
| Linguistic QA | Qualified translator/reviewer | Missing strings, wrong terminology, inappropriate tone, mistranslated questions |
| Functional QA | Course developer or tester | Clipped text, broken triggers, layout overflow, failed quiz scoring |
| Accessibility QA | Accessibility specialist/tester | Captions, keyboard barriers, screen-reader language, focus order |
| Subject-matter approval | Training or regulatory content owner | Changed technical meaning, safety instructions or learning outcomes |
| Learner acceptance | Representative target-language learners | Confusing examples, navigation uncertainty and unclear assessment wording |
For broader software and content QA techniques, see our localisation testing process and checklist. Log each defect with the screen, source language, target language, expected result, actual result and screenshot or recording when appropriate.
Worked example: English safety training adapted into French and Arabic
This is a fictional planning example, not a customer project or proof of a measured business outcome. Assume a company has a 20-minute English course containing five short modules, two instructional videos, one branching scenario and a ten-question assessment. It wants French (France) and Arabic versions.
| Course element | French localisation checks | Arabic localisation checks |
|---|---|---|
| Navigation buttons | Allow for French text length; check mobile button widths | Verify Arabic shaping, RTL reading order and whether player supports it |
| Safety terminology | Confirm approved French technical glossary | Agree Arabic terminology and any English brand or equipment terms |
| Video and audio | Prepare French captions and chosen voiceover approach | Review subtitles, timing, voiceover pronunciation and mixed-script displays |
| Scenario and quiz | Retest every option, feedback message and passing score | Retest content plus RTL focus sequence and option ordering |
| LMS package | Launch, complete and check reporting for French build | Validate tool compatibility first, then test LMS and learner view |
Before ordering all the audio recordings, the team pilots one module in both languages. If its chosen authoring tool does not support Arabic RTL, it revises the technical plan instead of continuing to translate content that cannot be displayed correctly. It then completes linguistic review, learner acceptance and LMS testing for each language independently.
How long does e-learning localisation take and what affects the cost?
Turnaround and fees cannot be estimated reliably from the number of slides alone. A 30-slide module with buttons, branching logic, captions and interactive video may require more work than a longer static lesson. A useful project brief separates the costs of translating text, adapting layouts, creating subtitles or voiceover, preparing LMS packages and quality assurance.
- Content volume: Count translatable words across slides, notes, questions, feedback, files and video scripts.
- Source editability: Editable projects may be less expensive than courses requiring rebuilding from published assets.
- Media requirements: Narration, dubbing, re-editing, caption timing and on-screen video text add production stages.
- Languages and directionality: Locale-specific differences, fonts and RTL compatibility can change scope.
- Assessment complexity: Branching, randomised quizzes, detailed feedback and external integrations need functional testing.
- Approvals and revisions: Terminology sign-off, SME review, accessibility testing and source-course changes affect schedules.
Ask for a scoped quotation based on a course inventory and a sample module rather than a fixed per-slide promise. Retain a version-control plan for later course updates so new source material can be translated without losing prior review work.
Final e-learning localisation checklist
- Record target locales, audience, learning objectives and course owner.
- Collect all editable source files, scripts, media and current published packages.
- Audit navigation, quiz states, downloadable files and hidden course text.
- Choose supported authoring/export workflows before translation begins.
- Approve terminology, style guidance and the handling of placeholders.
- Translate and review all text, audio, captions and assessment feedback.
- Adapt cultural examples without changing the intended learning result.
- Check layout expansion, fonts, RTL capability and mobile presentation.
- Test captions, keyboard navigation and screen-reader requirements.
- Publish and complete each target-language package in the actual LMS.
- Verify scores, attempts, bookmarks and completion reporting.
- Obtain linguistic, functional, accessibility and owner approval before launch.
Frequently asked questions about e-learning localisation
What is the difference between e-learning translation and localisation?
Translation converts the language of course content; localisation also adapts media, examples, navigation, assessments, layouts and functional behaviour for the target audience.
Can Storyline and Rise courses be translated using XLIFF?
Some conventional Storyline and Rise workflows support external XLIFF translation, but export/import support differs by tool, content type, version and whether built-in Articulate Localization has already been used. Test the exact workflow before committing the project.
Does course localisation require translating videos and quizzes?
Often, yes. If narration, videos, question feedback or interactive scenarios contain language that learners need to complete the objectives, those elements need translation or an equivalent approved alternative.
Will a translated SCORM course automatically work in my LMS?
No. File import alone does not establish that launch, bookmarking, scoring, completion or learner navigation works. Test the actual target-language package in the intended LMS.
Can Adobe Captivate localise a course into Arabic?
Adobe’s published Captivate 13.0 FAQ states that right-to-left languages are not supported in that version. Check compatibility for the exact product/version and use an alternative implementation if needed rather than relying on text translation alone.
How can I measure success after localisation?
Track completion, assessment performance, learner issues and support requests by language, while controlling for differences in cohorts, training requirements and rollout conditions. Localisation itself does not guarantee higher completion rates.
Do translated courses automatically meet WCAG accessibility standards?
No. Accessibility requires testing the content and relevant player features, such as captions, keyboard support, labels, reading order, language identification and alternatives. Assess against the applicable standard and document the results.
Official resources and further reading
- Articulate: localisation capabilities in Articulate 360
- Articulate community: external XLIFF export caveat after AI localisation
- Adobe: current Captivate version 13.0 FAQ, including RTL limitations
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- ADL: SCORM best practices for instructional designers
Need multilingual e-learning content or course localisation?
TranscribeLingo’s e-learning language services cover course text, narration, captions, transcripts and supporting learning resources. To scope a project, share the source authoring format, existing package, target languages, number of modules, scripts, interaction types, accessibility requirements and delivery deadline using an approved enquiry route. Request a localisation quote; the team can then confirm the work and technical responsibilities for your specific course.
