Why can you not just edit the zip?
To translate a SCORM course, translate the source project, not the published zip. A SCORM package is compiled output: text is spread across generated HTML, JavaScript and data files, often in formats no translator should touch. Export the text from the authoring source, translate it, re-import it, then publish a new package per language.
It is tempting to unzip the package, search for the English strings and replace them. Sometimes that even appears to work. But generated files are not designed to be edited by hand. Text can be split across several files, encoded inside JavaScript, rendered into images, or referenced by length or position somewhere else. One missed quote mark in a data file and a page stops loading. Worse, the next time anyone republishes from the source project, every hand edit is lost.
The rule that saves the most time: the source project is the master for every language, and the published zip is always regenerated from it.
Exporting text for translation
Most authoring tools can export a course's text for translation and import the translated version back into a copy of the project. The common formats are XLIFF, the standard interchange format that professional translation tools read, and a document table with the source text in one column and space for the translation in the next.
A workable process looks like this:
- Freeze the source. Finish editing the original language first. Every change after export means a second translation round.
- Duplicate the project for each target language, so each has its own master.
- Export the text and send it to translators with screenshots or a review link, so they see context, not isolated strings.
- Import the translation into that language's project copy.
- Review in context with a native speaker clicking through the course, not just reading the file.
- Publish a SCORM package from each language project.
If the course was made from a PowerPoint, PDF or Word file rather than in an authoring tool, the source document is the master instead. Translate the document, then convert it again. It is the same principle: change the source and regenerate, never patch the output.
One package per language or one for all?
There are two ways to deliver a translated course, and the choice affects tracking.
| One package per language | One multi-language package | |
|---|---|---|
| How it works | A separate zip per language, each uploaded as its own course | One zip with a language picker at the start |
| Tracking | A separate completion record per language | One completion record whatever the language |
| Build effort | Low; each is a normal course | Higher; the picker and every language share one runtime |
| Updates | Republish each language that changed | Republish one package, retest every language |
| Package size | Normal | Grows with every language's media |
One package per language is the default for good reason. Each version is simple to build, test and replace. Its weakness is reporting: if compliance needs one record per learner regardless of language, you either assign each learner only one language version or merge reports afterwards. Choose the multi-language package only when a single completion record is a hard requirement, and accept the extra testing. A large multi-language package can also strain size limits; see how to reduce SCORM package size.
What usually gets missed
Translation exports catch the obvious on-screen text. These are what reviewers find later:
- Alternative text on images, which screen reader users hear.
- Quiz feedback for correct and incorrect answers, and any hint text.
- Interface labels such as Next, Submit, Menu and Resume, which some tools manage separately from course text.
- Audio and captions, which need voice-over or subtitle files, not just text.
- Text inside images, diagrams and screenshots, which no text export can reach.
- The course title in the manifest, which is what learners see in the LMS catalogue.
Also give each language package its own manifest identifier and title. Two packages with the same identifier can confuse an LMS that uses it to match uploads to existing courses. The relevant manifest fields are covered in imsmanifest.xml explained.
Layout: text expansion and right-to-left
Translated text is rarely the same length as the original. Many languages run noticeably longer than English, and a button or caption sized for English text can overflow, wrap or be cut off. Short labels are the worst affected, because a one-word English label may need several words elsewhere.
Right-to-left languages such as Arabic and Hebrew need more than translated text: the reading order, alignment and often the layout direction must flip. Check that your authoring tool supports right-to-left output before promising those languages, because retrofitting it is much harder than planning for it.
Testing each language version
Treat every language package as a separate release and test each one, not just the original:
- Launch it in the target LMS and click through every page for overflow and untranslated strings.
- Complete it, close it, relaunch, and confirm completion and score were recorded.
- Exit half way and resume, to confirm the bookmark survives.
Tracking behaviour should be identical across languages. If one version reports differently, something changed in the build, not just the text. The full routine is in how to test a SCORM package before the LMS does.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.