Retour au blog
translatelocalizationscormairtl

How to Translate a SCORM Course into 100+ Languages Without the Source File

par The ScormEdit Team·24 février 2026·9 min de lecture

A request that sounds simple and almost never is: "We need this course in Spanish, French, and Arabic by next month." The course is a published SCORM package, the original authoring project is long gone, and suddenly translating ten slides of text feels like rebuilding the course three times over. Here is how localization of a published SCORM course actually works, and where the real friction is.

Why this is harder than translating a document

A Word document is one continuous flow of text. A published SCORM course is the opposite: the words are scattered across many machine-generated data files, interleaved with layout, timing, and player metadata you must not touch. Translating the course means finding every piece of on-slide text — headings, paragraphs, button labels, menu titles, quiz questions and answer choices, feedback messages — without disturbing the structure that makes it play and report completion.

And some text is not text at all. If the original author flattened a stylized title or a diagram into an image at publish time, those words are pixels. No translation tool can reach them; the only option is to replace the whole image with a localized version. Knowing which words are editable text and which are baked into graphics is the first real task of any localization job.

On-slide text in modern Storyline output is stored as structured data separate from the player engine, so it can be extracted and replaced. Text rendered into images at publish time cannot — it has to be swapped at the image level.

Three ways to translate, and what each costs you

1. Manual translation by a human in the data files

Highest quality, slowest, and brutal to do by hand in minified JavaScript. A linguist editing escaped JSON strings directly is one stray quote away from breaking the file. This is the right level of quality but the wrong level of access — it asks a translator to also be a careful engineer.

2. CAT tools (computer-assisted translation)

Tools like memoQ, Trados, Smartcat, and Crowdin are built for serious localization: translation memory, glossaries, and reuse across versions. They shine when you have many languages, frequent updates, and a need for consistency. The catch is the round trip — you have to extract the translatable text into a format the tool accepts, translate it there, and merge it back in without corrupting the package. With the source file, that export exists; with only the published zip, you need something that can pull text out of the published output and put it back.

3. AI translation

Modern machine translation has gone from "obviously wrong" to "good enough to review and fix" for a great deal of e-learning copy. For getting a course into ten languages quickly, AI is dramatically faster and cheaper than commissioning ten human translations from scratch. The honest framing: AI gets you a strong first draft at scale, and a human review pass turns that draft into something you would put in front of learners. We compare CAT tools and AI in depth in a separate article.

The caveats that wreck translations after the fact

Text expansion and contraction

Translated text rarely matches the length of the original. German and Finnish often run noticeably longer than English; some languages run shorter. A button that fit perfectly in English may overflow its box in French, and a heading sized for one line may wrap to three. SCORM slides have fixed layouts, so length changes are a layout problem, not just a wording one — always preview, do not assume it fits.

Right-to-left languages

Arabic, Hebrew, Urdu, and Farsi read right to left, which affects far more than the text itself — alignment, reading order, and the direction of layouts and arrows can all need attention. Published courses were usually authored left-to-right, so RTL output deserves extra scrutiny in preview. Treat RTL as its own QA pass, not an afterthought.

Two languages that look fine in a spreadsheet can look broken in the player: text overflowing buttons, headings wrapping awkwardly, RTL content misaligned. Translation is not done until you have seen it in the actual course.

Fonts and special characters

A course built for one alphabet may not ship fonts that cover another. Accented characters, non-Latin scripts, and right-to-left glyphs can render as boxes or fall back to a substitute font if the package does not include coverage for them. This is exactly the kind of thing that looks fine in the data and wrong on screen.

Verify every language in preview

  1. Play each translated version end to end and read it on the actual slides, not just in a text export.
  2. Watch for overflow, awkward wrapping, and RTL alignment problems.
  3. Confirm any text that lived in images has been localized or consciously left as-is.
  4. Check quiz questions, answer choices, and feedback — these are easy to miss and the most important to get right.
  5. Upload one translated package to a test LMS and confirm it still reports completion exactly like the original.
Localization is not finished when the words are translated. It is finished when each language plays cleanly, fits its layout, and reports completion like the original.

Translating from the published package, in the browser

ScormEdit translates published SCORM courses directly, no source file required. It extracts the editable on-slide text from the package, runs AI translation into the languages you need — well over a hundred of them — and writes the translated text back into a valid SCORM zip, leaving the player structure and completion logic untouched. You review each language in the built-in preview, catch the overflow and RTL issues before you ship, and download a working localized course. It turns "rebuild this three times" into reviewing three drafts.