An English course can look finished and still be difficult to localize. The published module may work perfectly, while issues such as a missing editable project, narration that differs from the script, and important instructions remaining embedded in screenshots. Sending only the visible slide text to a translation provider leaves those problems unresolved. They usually emerge when translated content must fit back into a working learning experience.
For teams commissioning course translation, the useful starting question is: what does a localization provider need to reproduce this course accurately in another language? Terralíngua’s desktop publishing services include adapting learning content created in Articulate and Adobe Captivate. Preparing the source materials helps define the translation, authoring-tool adaptation and multilingual layout work required before production begins.
This guide focuses on project preparation. The goal is a source package that identifies what learners see, hear and do, along with whom can approve changes. A complete package supports a realistic quotation and gives reviewers something more precise to approve than a folder called “final course.”
Identify the Product, Version, and Required Output
“An Articulate course” does not identify a single production environment. Record whether the material was created in Storyline 360, Rise 360 or another product. For Adobe Captivate, specify the exact version and whether the source is a Captivate Classic project. Include the installed build where applicable and identify any third-party components or custom code the course depends on.
Articulate’s current Storyline documentation describes both its integrated localization workflow and text export/import using Word or XLIFF. XLIFF is a structured file format for exchanging translatable content. The appropriate route depends on the project and available features; a file-based handoff should not be assumed as the only option. Agree on the project workflow before preparing exports.
Articulate’s guidance on translating Storyline 360 courses
Adobe publishes separate localization instructions for Captivate Classic, including exporting captions, and importing translated content the project’s copy. Those instructions should not be treated as a universal procedure for every Captivate edition. Determine the course material owner to verify maintenance and update protocols.
Adobe’s localization guidance for Captivate Classic
Define the expected needs for all editable localized projects, published modules, translation files, caption files, and audio assets. If a learning management system, or LMS, will deliver the course, provide its required publishing specification. Share the compiled required tool compatibility, account access, and delivery formats with Terralíngua at the quotation stage, rather than assuming every version or output is interchangeable.
Establish One Approved Source Version
Ensure the content owner will confirm the supplied project is the final version for translation. Include a playable reference so the localization team can compare the editable material with the approved learner experience. A published package is valuable as a reference, but it should not be assumed to replace the authoring source needed for efficient editing.
Record the course title, internal identifier, source language, revision date and approval status. Specify the target language variants and intended learners, including their technical background. “Portuguese” should become a defined audience decision, such as Brazilian Portuguese for employees in Brazil. Supply approved product names, abbreviations, and terminology, together with any terms that must remain unchanged.
Make unresolved items visible. If a product screenshot is awaiting replacement or a policy paragraph is still under review, list it with the owner and a decision date. Translation can sometimes proceed around a clearly isolated pending item, but it should be determined as to when resolution should be final. Otherwise, a late source correction can affect text, audio, layout, and testing in every language.
Assemble the Editable Course and Its Dependencies
For desktop projects, supply the native authoring files and the assets needed to open and edit them. For an online authoring environment, agree on an appropriate course-sharing or transfer arrangement. Confirm that the recipient has the permission and access needed for the scope of work. Do not rely on a public review link as an editable source with the access needed.
Check the package from the recipient’s perspective. Does it open without missing fonts or media? Are externally linked documents accessible? Are licensed assets permitted to be shared and adapted? Include editable graphics where available and identify any assets that require replacement by the original designer. Keep credentials out of the source folder and arrange access through an approved method.
Use a short inventory to make the handoff navigable. Each asset should have a filename or location, its purpose, its language status and the person responsible for decisions about it. This is especially helpful when a course pulls together materials from training, product marketing, and technical teams. It prevents an unapproved attachment from being mistaken for the authoritative source.
- Editable course source and a playable approved reference
- Product, version, build, and required publishing settings
- Linked documents, downloadable resources, and editable visual assets
- Narration scripts, audio files, videos, and caption files
- Terminology guidance, audience information, and language variants
- Open issues, asset permissions, and named review owners
Locate All Relevant Text
A slide-by-slide reading does not expose every learner-facing string. Check layers, object states, feedback messages, question banks, branching paths, menus, and completion messages. Review player controls, resource titles and accessibility text as well. An inventory should identify where these elements live and how they will be translated, even if some are managed separately from the main text export.
Ask a course author to demonstrate paths that a reviewer might otherwise miss: an incorrect answer, a retry, a skipped prerequisite or a branch intended for a particular job role. Supply a simple route map or walkthrough notes. These references give translators the context needed to distinguish an instruction from feedback or a button label from a sentence fragment.
Treat exported text as working input, not automatic evidence of completeness. Compare a representative export with the playable course before translating the full package. Investigate anything missing or duplicated, and preserve the identifiers required for re-import. This small preparation exercise can reveal separate assets that would otherwise remain in English after the core translation work is complete.
Prepare Visuals for Localization
Identify text in screenshots, illustrations, and animations. Provide editable originals where possible, and decide whether each visual needs translation, replacement, or retention with an explanation. A software screenshot that remains in English may need to stay visually faithful to that interface while the surrounding instructions explain what the learner must select.
Document these decisions rather than leaving ambiguous references for translators. For example, a fictional course might instruct learners to select a button labeled “Submit” in an English-only application. Translating the button name without preserving its relationship to the visible interface could make the instruction harder to follow. The product owner should confirm the intended treatment before localization.
Especially review layouts with short wording layouts: narrow tabs, tightly packed comparison tables, fixed-size buttons, and text placed inside illustrations. Allow room for language differences without assigning a universal expansion percentage. Provide approved fonts and style guidance and identify which objects may be resized or rearranged. Readability should guide adaptation rather than shrinking every translated sentence to fit.
Reconcile Narration, Captions, and Screen Content
Translate and approve the script first before finalizing the recording. Ensure the recording is using the approved, final script and not an earlier version. Organize the script by a stable slide (or scene identifier) and distinguish translatable content such as the spoken words or production notes. Include pronunciation guidance for product names, acronyms, and specialized terminology. Synthetic voice narration is populated from the final script, so do not localize the spoken before the written materials.
Identify the relationship between audio and activity. Does a highlight appear when a term is spoken? Does a demonstration pause for an instruction? Does the next screen depend on timing completion? These details affect how translated narration is placed. Provide separate voice, music, and special effects tracks when available. Flag media that is supplied only as a finished composite, which cannot be edited.
Decide whether the project needs translated narration, subtitles, captions or several services for completion. Captions may also communicate meaningful non-speech audio, so their preparation should account for more than dialogue alone. If synthetic narration is being considered, include voice preferences in the brief and allow time for pronunciation review, pacing, and synchronization. Is there flexibility with the end time? If so, the source timing should be treated as a reference, not a locked target.
Define Interaction Logic and Assessment Intent
Translation teams need to understand what an interaction is intended to teach. Provide the learning objective for assessments, the correct answer logic, and any feedback that may change according to the response. Flag wording when it is designed to be deliberately similar. A linguistic adjustment that could make one answer longer or more specific may change how a question functions.
Separate learner-facing text from technical values. A visible label may be translatable while a variable name, tracking identifier or custom-code value must remain unchanged. Have the source content author identify protected content boundaries. Where a trigger or condition depends on an exact text value, the technical owner should assess the effect of localization before it is changed.
Include the same accessibility features already implemented, such as alternative text, reading order, and keyboard navigation. Specify which checks must be repeated in the localized course. Translation on its own will not validate accessibility or instructional effectiveness. The learning team should retain responsibility for the educational objective, and qualified reviewers should approve any technical, safety-sensitive, or policy-related wording within the course.
Assign Review Decisions Before Localization Begins
Assign individual roles to consolidate language feedback, even if several specialists contribute. Language reviewers can assess terminology and naturalness; course authors can assess behavior and layout; subject owners can confirm technical meaning. Establish who resolves disagreements, and who has final release authority. Without those decisions, successive reviewers may repeatedly reverse approved wording.
Give reviewers the same reference package and a clear brief. Ask them to identify the affected screen or asset, explain the issue, and propose a correction where possible. Distinguish an inaccurate translation from a preference and a source-content change. All can be valid feedback, but they have different implications for related assets and approved material. Determine when the review feedback is approved and should be implemented in the translated material with the translation memory revisions. Do not immediately implement review feedback until all has been collected and evaluated.
Plan when each decision must happen. Terminology and script approval should be prioritized before audio production and final layout. A later change may still be necessary, but its consequences should be visible. For instance, replacing a product term could require updates to narration, subtitles, screenshots and assessment feedback, not just a search-and-replace in slide text.
Determine Return Requirements Before Requesting a Quote
Outline the final format expectations and acceptance requirements as a brief with the quote request. The brief should describe the final deliverable course in observable terms. All agreed content is localized; translated text remains readable; audio matches the intended scene; and required interactions behave as approved. Specify which devices, browsers, and LMS (Learning Management System) environment are in scope, so the quotation reflects the intended delivery conditions.
Include all source files or a sufficient representative sample with the quotation request. With a sample choose a complex interaction, a text-heavy screen, and a narrated section rather than just the opening slide. These examples help expose the work that a simple word count assumption misses. It will also allow the translation team to identify whether source cleanup or asset reconstruction should precede translation. The translation team will evaluate many considerations to ensure smooth delivery.
- Open the returned editable project to check for any missing dependencies.
- Compare all inventoried learner-facing content with the approved language scope.
- Check text fit, character display, captions and visual references in context.
- Test branching, incorrect answers, feedback, and completion behavior.
- Verify the agreed publishing and tracking behavior in the target LMS.
- Tracking expectations for approvals and addressing any unresolved issues.
Effort depends on more than course duration. Missing source files, text-heavy graphics, custom interactions, audio replacement, and the number of language versions can all affect preparation and production. Explain whether reviewers will be available together or sequentially and identify needs such as launch dates. These inputs support a grounded schedule without assuming that translation is the only task on the critical path.
Keep the Source Material Relevant
Before handing over a large course collection, group modules by shared dependencies. Several courses may reuse the same introduction, glossary, player configuration, or downloadable guide. Identify the authoritative version of each shared item and explain where it appears. This helps the project team assess reuse without assuming passages that look similar are approved to be identical.
Also distinguish required content changes from optional improvements. The source content may contain a dated illustration that the owner would like to replace, while an incorrect instruction must be corrected before translation. Marking those priorities allows the team to scope the preparation deliberately. Otherwise, localization can become a more complex redesign project without an agreed budget or decision process.
Retain the approved source and localized deliverables with a clear relationship between their versions. When an update arrives, identify changed screens and dependent assets instead of sending a newly assembled folder without explanation. Include previously approved terminology and decisions so the team does not have to reconstruct why a label or screenshot was treated in a particular way.
Decide who maintains the editable localized courses after delivery. If an internal author will make later edits, include those handoff needs in the original scope and ensure revision updates are communicated with the translation team. A delivery record which lists project versions, published outputs, and outstanding issues to address in the next version makes the next update easier to assess. It also reduces uncertainty when the original course designer is not available.
Preserve a record of local exceptions. One language version may use a different screenshot because the software interface differs in that market, or a narration segment may require a longer pause. Those are production decisions should be carried and communicated forward. Treating every future update as a fresh copy of the English course could unintentionally remove an adaptation that reviewers already approved.
Frequently Asked Questions
Can a Published Course Replace the Editable Project Files?
The published course is not the same as the editable source files. A published course is useful as a reference, but it may not provide the access needed to efficiently edit text, interactions, and media. Identify the authoring product and version, supply the available files, and explain any missing elements. Agree on any reconstruction needs or the preferred alternative approach before production starts.
Does Translation Export Include Every Piece of Learner-Facing Text?
It is best to check rather than assume. Compare a representative export with the playable course, including feedback, branching paths, player controls, downloads, and text embedded in visuals. Identify content managed outside the main export function and assign a translation route for it. Preserve the identifiers needed to insert translated text into the course.
When Should Narration Be Produced?
Approve the relevant translated script and terminology before producing the final audio. Confirm pronunciation and timing with a native speaker of the language. If the source or terminology changes afterward, identify the affected audio, captions, and screen content together. A listening review should take place in the assembled course, not on isolated recordings.
What Should Be Retained for Future Course Updates?
Keep the approved source, editable localized projects, published outputs and associated scripts, media and caption files within the agreed handoff scope. Keep a record of the required tool versions, terminology decisions, and language-specific exceptions. For the next update, provide a required update list with the affected assets so approved adaptations are not lost when a new source version is introduced.
Discuss the Prepared Package with Terralíngua
Terralíngua’s services include adaptation of Articulate and Adobe Captivate content, multilingual formatting, and the correct language support for fonts and characters. Our multimedia services include supporting learning content with audio and interactive elements. Experience with these requirements is essential when translated text must be integrated into a usable course, rather than delivered as a separate document. Confirm the experience not only with the localization services but the capabilities with the tools, required versions, and the production scope for the final project.
Explore Terralíngua’s learning-content adaptation and desktop publishing services
To request an assessment, send the course inventory, a representative editable sample, a playable reference, target languages, audience information, and deadline for the return formats. Inform if you require assistance with identifying who will review language specific content, technical content, and course behavior. If an element is missing, describe what is needed. A clear account of the gaps is more useful than a package that appears complete but will not produce the desired outcome.