A set of standardized guidelines for making eLearning courses interoperable across various platforms. How does it work with translated content?

SCORM, Shareable Content Object Reference Model, was developed by the US Department of Defense as a set of standards for eLearning and training content production. The goal was to make the final courses easily transferable across systems and platforms by standardizing file formatting. Given the enormous amount of training used by the military across many branches and millions of users, SCORM also helped eliminate redundancy and the need to reproduce complex work that had already been done, but could not be reproduced and distributed because of file incompatibility.

The model evolved from its initial iteration in 2003 to keep up with improvements in technology. Eventually an Application Programming Interface (API) known as Experience API or xAPI was developed to help make the data completely portable. By this stage SCORM had been adopted in the private sector as well and was administered by an agency, the Advanced Distributed Learning (ADL) Initiative dedicated to the task. The reg and its subsequent versions were published and are openly available for use by anyone creating eLearning and Training content.

Translated eLearning can lose its SCORM context

These days, courses are complex things involving multiple media types including text, animations, slide decks, audio and video, quizzes, and more, all designed to provide a complete learning experience. Translation of this content into multiple languages with different word lengths, character sets, and considering cultural factors, is a specialized challenge. Maintaining a standard that is portable as the content is adapted to those factors requires the translator, translation project managers, and others involved in the translation project to apply SCORM standards or connect the xAPI to the newly translated content.

SCORM is a mixed bag and xAPI is a step forward

Originally developed in 2003 as SCORM 1.0, which was primitive and buggy; the next iteration, 1.2, was much more solid. The current version, 4, has not seen widespread acceptance, in part because the underlying technology is outdated and predates much of today’s cloud capabilities.

The answer to this is the Experience API (xAPI), formerly known as the Tin Can API. It has the ability to connect more data types to more systems. Most major learning management systems (LMSs) claim SCORM and xAPI compatibility but in many cases the implementation has been customized and doesn’t always work across systems. xAPI is the more reliable solution because it only requires the LMS developer to build a connector for it.

How these protocols fit into eLearning translation workflows

When SCORM or xAPI is required, we have to test compatibility and apply changes to translated content to ensure conformance. Our eLearning customers who deal with the government or highly regulated subjects like pharma and life sciences, are those most likely to require the application of these standards and capabilities. Because of this we have developed internal resources to apply and test for these requirements. Unfortunately, many learning management systems, while claiming SCORM and xAPI capabilities, don’t always deliver, limiting our ability in some cases to bring our customers into compliance.

Interoperability between systems, if implemented well, promises to change the eLearning landscape

The Internet developed because it was built on a set of standard protocols and developer languages that were universally accepted and utilized. Prior to that we had closed systems like AOL, that were privately held and that did not adhere to the same standards. In eLearning development, lessons can be learned from these examples. Proprietary formats limit the ability for more learners to use learning content. Standard XML usage and more versatile APIs can help create an eLearning universe across platforms and across multiple languages. SCORM represents the earliest iteration of that vision.