On this page
Quick answer
Start with the exact menu path documented by Articulate: File, Localization, XLIFF/Word Translation. Choose a supported XLIFF version that matches your translation tool, or export Word with useful context such as slide thumbnails. In a Word file, only the Translation column is intended for editing. Preserve variable references and technical structures; do not expect the manual file to translate closed captions, trigger conditions or player labels automatically.
After import, a green check on a translated spreadsheet is not your acceptance test. Play the target course as a fresh learner and as a returning learner. Fail a quiz, pass it, enter text, reveal hidden layers and complete a tracked LMS attempt. If the instructions are translated but the wrong branch opens or the completion score is not recorded, the job is not done.
The mechanism: slide text and executable learning behavior travel on different tracks
Storyline authors think in scenes, slides, layers, states and triggers. Translators often receive a structured list of text segments. Those are different views of the same lesson. A segment that reads Try again can belong to a wrong-answer feedback layer, while the state deciding when that layer appears is determined by a separate condition. Translating the sentence correctly cannot confirm that the condition still fires for the right answer.
The manual interchange file is best understood as a map back to the original project’s text-bearing objects. It helps move approved target wording in and out; it does not rebuild the instructional design in the target language. Variable names, results calculations, player chrome, closed captions and audio may be outside that handoff. The correct division of work is to let translators review meaning and let Storyline specialists preserve the object and state relationships.
Consider a quiz result that says You scored 80 percent. In many projects the figure is not literal prose but a runtime variable reference. If the translator replaces the reference with a phrase, the learner may see a static string rather than the actual score. That is not a grammar error; it is a broken link between presentation and program state. Similar problems occur when feedback depends on stored answer values rather than just what the choice label says.
There is also a release boundary. The source project may be updated after translation export; the published SCORM package may be generated from a different revision; the LMS may preserve an earlier attempt. The team should record the exact source copy, target copy, imported file and publish settings. Speed improves when every defect can be attributed to one boundary instead of restarting an entire translation.
Understand the mechanism
Identify what the manual Storyline translation mechanism controls before writing a single target sentence. Export format, source revision, project copy, text column and slide state each impose constraints. These six cases establish how to keep the original experience intact while producing a language-specific version.
Protect the original project
Here is a situation that can fool a busy reviewer. A training team opens its only Storyline project and imports a German text file straight into that master. A translation change now contaminates the source baseline, and the team cannot easily compare what learners saw in English. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
What makes the result possible is the mechanism underneath the wording: Manual Storyline translation is a round trip from an authored project through an export file and back into a project copy. The project file contains behavior, layout and media beyond the exported text, so changing the sole master destroys a useful control. The safest audit names the source of truth before anybody edits a translation. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
A safe way forward is to inspect first and change later. Duplicate the approved source project and label the target-language copy with language, source revision and intended release. Keep the original read-only during the translation cycle, and establish where both files and review evidence will be stored. Hold the reader’s task constant while you change one suspected input. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
The result should be falsifiable, not a feeling of completion. Launch both copies side by side at the same learning state. Reviewers must be able to identify which source produced the translated build and restore the untouched original without reverse-engineering changed slides. Then change one adjacent condition and see whether the rule continues to hold. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Choose the actual manual translation route
The problem first appears as a harmless-looking detail. An instructional designer assumes the current Articulate Localization product and Storyline’s manual XLIFF or Word workflow behave identically. They budget for one-click multilingual delivery when their project uses separate manually translated files. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The crucial distinction is not grammatical. Articulate offers a contemporary localization workflow and a documented manual route under File, Localization, XLIFF/Word Translation. Capabilities and entitlements differ, so the manual import process should be documented on its own terms rather than described as if it were the newer integrated service. Two different owners may have to sign off: one for the words, another for the behavior. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The repair should be small enough to reverse. Decide which workflow the project actually uses and verify the product build and license. For manual translation, make a copy of the source and follow the supported export, translate, import and player-label steps without borrowing assumptions from another workflow. A change log should say what was edited and which observation justified it. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Here is the acceptance evidence to collect. A teammate should be able to locate the same menu commands and explain whether the deliverable is a separate language-specific Storyline project or a multi-language package created by a different supported feature. Save the route or learner path so a later reviewer can run it again. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Consider the journey from the reader’s point of view. A language vendor expects XLIFF 2.0 but receives 1.2 and reports that the package cannot be parsed. The designer blames accented characters and starts rewriting the course text unnecessarily. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
To diagnose it, trace the decision that selected this output. Storyline’s documented manual export can produce XLIFF 1.2 or 2.0 and asks for the source language. The interchange format defines how translation tools identify source and target segments; a format mismatch occurs before anyone evaluates wording. A correction made at the wrong layer can disguise the problem without resolving it. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Rather than translating the visible symptom again, test its source. Agree on the vendor’s supported XLIFF version and source-target language pair before exporting. Inspect a small sample in the actual translation environment, and keep the exported file unchanged until its compatibility is confirmed. Keep an untouched source or staging copy so the comparison remains meaningful. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
A final comparison must focus on the user’s outcome. The vendor can import and re-export the sample without losing segment relationships; the target file can then be imported into a disposable Storyline project copy for a visible rendering test. Keep known exceptions visible; silence is not evidence that they were tested. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Word export is a structured handoff
A common temptation is to fix whatever English text is visible. The reviewer receives a DOCX with slide thumbnails and edits all the text in the table, including reference columns, to make the document look consistently German. Storyline later imports incomplete or misassigned text. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
Here the internal structure matters more than a polished title. The enhanced Word export uses a designated Translation column for editable target copy. Other columns carry source context and structural information; they are not free-form fields for prose polishing. Optional thumbnails and single-table format can help translators understand slide relationships. That is why the file on disk and the experience in the product both need evidence. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Make one hypothesis and put it against the running system. Instruct the vendor to edit only the Translation column and preserve the remaining Word structure. Decide whether slide thumbnails are needed for layers and tricky buttons, and handle side comments outside import-sensitive cells. If the fix affects many places, sample a second location before calling it general. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Close the loop with a target-language test and an original-language control. Compare a handful of translated segments with their slides after import. The text must appear on the correct object, not merely somewhere in the project, and the imported Word file should remain traceable to the source export. Verify that the solution did not damage the source-language journey. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
A text export is not a course export
For a controlled trial, begin with this concrete mismatch. A manager sees every target sentence in an exported file and concludes that the full experience is translated. In the actual learner journey, the player controls, captions and some trigger text remain in English. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The causal chain runs through a non-obvious dependency. The manual export captures text the supported feature can round-trip; it does not make every Storyline property a translatable segment. Articulate explicitly distinguishes certain player labels, trigger conditions and closed captions from this process. Only a recorded source revision can settle a dispute about which wording was approved. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
This is a good place for a focused staging exercise. Create a translation inventory with separate rows for exported slide text, player text, captions, audio, assets and behavior-dependent strings. Assign each to the correct Storyline interface or production workflow rather than forcing it into the XLIFF file. Ask a product owner to approve changes that may affect measurement or correctness. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Do not settle for a screenshot of a successful first page. Review each category in a target-language published preview and record its completion status. A fully translated XLIFF file does not pass if the learner still encounters unreviewed messages at a quiz or navigation boundary. Where two people disagree, the documented observation should settle the claim. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Slide state is part of meaning
It is worth looking at the event that exposed the defect. An interactive safety lesson changes a button from Begin to Retry after a wrong answer. The normal state is translated, but the Retry state was never shown during translator review and remains English. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
A successful translation file can coexist with this failure because Storyline objects can expose different states and slide layers based on learner interaction. A single screenshot of the opening slide does not reveal all text the learner can encounter, and the translation export alone does not prove state coverage. The visible output is evidence of rendering, not proof that the intended source was selected. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Keep the handoff narrow: decide whether the fix belongs to words, structure or release configuration. Inventory required object states and conditional layers before export. Give translators context for each state-specific message, then run the interactions that reveal it in the imported copy rather than reviewing only the first screen. If a test is not reproducible, record the missing condition instead of guessing. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
A reviewer unfamiliar with the implementation should still be able to check it. Test the normal, hover or selected, disabled and feedback states that matter to the lesson. The displayed words must correspond to the current learner action; a translated default state paired with wrong-state feedback fails. Record a pass or fail with the object identity and tested version. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Prepare the translation without damaging structure
The most serious failures arise when visible text and behavior are mistaken for one thing. Variables, conditions, player labels and assessment states require different expertise. Treat the translation document as a bounded handoff, not as permission to edit every English-looking identifier.
Keep variable references intact
The next case separates an editorial concern from a system concern. An English result slide says Your score is %Results.ScorePercent%. A translator renders the token as a German phrase because it looks strange in the sentence, and the translated result becomes a literal string rather than a learner’s calculated score. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The user sees one result, but the application combines several inputs. Project variable names and references are program identifiers. In the manual translation workflow, Articulate warns not to translate result slide variable references or variable names through the exported file; changing one side breaks the relationship unless deliberately updated inside Storyline. Do not confuse a valid format with a valid message or a valid user journey. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The practical sequence is easier than it first looks. Mark variable references as protected tokens in the translation brief. Translate the natural sentence around them, use a read-only placeholder legend for context and let a Storyline specialist handle an intentional variable rename if ever required. Keep operational IDs out of prose review unless their meaning is explicitly in scope. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
To prove the fix, repeat the original failure in the corrected version. Complete the quiz in the imported language version and confirm that the learner’s actual numeric result appears in the sentence. Repeat with two distinct scores to ensure the display is not hard-coded or accidentally frozen. A second tester is useful because they have not learned to avoid the broken route. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Variable values are not variable names
An apparently small change can cross several ownership boundaries. A text variable stores a default message like Not started. The translator correctly wants it localized but assumes the project’s identifier should also become German, leaving triggers referencing the former name. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
This behavior has a precise explanation. The human-readable default value of a variable and the reference used by triggers are different objects. Storyline allows translation of values through certain built-in processes, while names and references require deliberate coordination. When the outcome is surprising, control the other variables before blaming the language. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Before opening a new translation request, identify the controlling reference. Identify whether a token is a displayable value, a stable variable name or a reference in slide text. Localize only values within the supported export, and leave names unchanged unless a Storyline maintainer performs a controlled project-level update. Avoid a bulk replacement that might modify unrelated examples. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
An effective sign-off records what happened, not merely who clicked Approve. Trigger the variable change, then visit each slide that displays it. The correct localized value must appear and the dependent navigation or feedback behavior must still fire under the original intended conditions. An automated check may confirm structure, but a person still needs to judge meaning. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Trigger conditions need separate review
This failure is especially easy to miss in a quick visual review. A learner chooses an answer that should open a remediation slide but the imported German course sends them to the end. The translator changed no visible question, so everyone initially assumes the test design itself must be wrong. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
Notice which part of the experience is outside the sentence itself. Trigger conditions drive object behavior and may compare variables, states or values. Articulate’s manual text export does not translate trigger conditions, so any language-dependent values referenced in conditions must be reviewed in Storyline rather than treated as ordinary exported copy. The fastest useful escalation identifies the exact object, setting and owner involved. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The corrective action needs an owner and a baseline. List triggers that depend on string values or answer identities and compare their operands with the translated project’s actual runtime values. Change only the intended condition or stored value, never the visible labels as a workaround for misfiring logic. Verify the control paths, not just the main line of text. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Evidence from the released surface is stronger than editor-state confidence. Exercise each affected trigger with both a matching and nonmatching state. The correct destination should open in the translated course, with the same completion or remediation policy as the source. If a critical action remains impossible, the translation should not be released. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Player labels are a separate task
One practical way to spot the hidden assumption is through a test persona. After importing the German slide text, learners press an English Next button and receive an English Resume prompt. The design team asks translators to find these phrases in the XLIFF file, where they are absent. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The failure is reproducible because the system follows a rule. Storyline’s player has its own configurable text labels. The manual slide-text export does not cover them, and a polished slide translation can therefore coexist with English navigation chrome. The test should distinguish an intentional difference from an accidental mismatch. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Start by reproducing the same state in the original language. Open player text labels in Storyline and adapt the relevant controls for the target language, using supported configurations. Include menu, search, accessibility and resume-related wording where it is exposed by the chosen player. Review changes with the person who owns the downstream consequence. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Treat this as a regression test that can be rerun next month. Start, resume, navigate and exit a target-language course. At each boundary, player actions must be understandable and lead to the same interaction outcome as in the source course. Compare the saved evidence with the original definition of the reader job. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Quiz feedback and score meaning
Do not assume that two similar screenshots represent the same state. The translated question says choose all correct answers, but a feedback layer still congratulates a learner who chose only one. The content editor wants to improve the congratulatory wording without checking the scoring condition. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
There is an important boundary between display and control. Assessment items combine question instructions, answer identities, scoring behavior, feedback layers and result variables. Translation must preserve which choice is correct and what counts as passing; attractive feedback language cannot repair an incorrect evaluation. Without that distinction, new translations may create fresh regressions elsewhere. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Do not alter the public version merely to prove a theory. Compare the question’s source rule and translated instruction, then test correct, partly correct and incorrect inputs. Inspect feedback layers and score outputs while keeping answer logic unchanged unless the assessment designer approves an alteration. A well-named defect ticket is often faster than an unbounded rewrite request. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Success has to be visible at the point of use. Record expected and observed feedback for each test choice. The correct answers, scores and remediation behavior should match the source assessment under semantically equivalent learner decisions. Test both the ordinary path and the path that previously failed. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Slide masters and reusable elements
Before judging the target sentence, examine how it reached the screen. A footer with a legal disclaimer is part of a master layout and appears in twelve scenes. Translators correctly translate slide bodies but overlook the footer because it is visually detached from their main text review. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
What looks like translation drift may instead be a selection error. Master layouts, repeated elements and shared resources can display language-bearing text across many slides. Fixing each visible occurrence independently encourages drift, and a sample that omits master content may understate the number of untranslated strings. A reviewer should be able to explain the rule in ordinary language. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Translate the content only after verifying its destination. Identify shared labels, master placeholders and reusable templates before the handoff. Determine where the wording is actually owned, translate at the correct level and recheck all affected slides for clipping or inconsistent overrides. Do not merge a workaround that hides an error state from the user. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
The most persuasive outcome is a controlled comparison. Visit several slides using each relevant layout and verify the same approved disclaimer appears. If one slide intentionally overrides the master, document why its exception is valid rather than treating the mismatch as a mere typo. The aim is a reusable proof, not a one-off demonstration. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Test the failure paths and make safe repairs
Now test the learner’s full experience instead of just the exported text. Caption files, spoken narration, button sizes, assistive technology and right-to-left script rendering can produce defects invisible to a bilingual text reviewer. Each case asks for evidence from the published interaction.
Closed captions do not follow the text import
Here is a situation that can fool a busy reviewer. A translated lesson has German narration but the learner turns captions on and sees the English transcript. The team had assumed all text visible in Storyline would be included in the Word export. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
What makes the result possible is the mechanism underneath the wording: Articulate states that closed captions are not translated through this manual XLIFF or Word process. Caption files and caption timing require separate handling, and narration language must agree with the captions actually selected during playback. The safest audit names the source of truth before anybody edits a translation. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
A safe way forward is to inspect first and change later. Export or produce an approved target-language caption track using the appropriate caption workflow. Retain timing and speaker context; verify that any new audio pacing has not made cues appear too early or late. Hold the reader’s task constant while you change one suspected input. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
The result should be falsifiable, not a feeling of completion. Watch the complete clip with sound off and captions enabled in the target language. Every consequential instruction must be readable, correctly timed and consistent with the localized narration and action shown. Then change one adjacent condition and see whether the rule continues to hold. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Audio narration and text-to-speech
The problem first appears as a harmless-looking detail. A translator changes a safety instruction on screen but the recorded English narration says the older number of minutes. Some learners follow the voice, others read the subtitle, and the training message conflicts. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The crucial distinction is not grammatical. Spoken language is media content rather than merely a slide-text field. Translated copy may require new recording, text-to-speech generation and synchronization, and audio timing can affect transitions and on-screen reveals. Two different owners may have to sign off: one for the words, another for the behavior. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The repair should be small enough to reverse. Inventory every audio clip with its source script, revision and target narration requirement. Produce target-language audio with technical terms checked, then align its timing with interactions and any separately managed captions. A change log should say what was edited and which observation justified it. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Here is the acceptance evidence to collect. Play each narrated slide without relying on the text panel. A listener should hear the same condition, action and amount as a reader sees, and the slide must not advance before the crucial instruction is spoken. Save the route or learner path so a later reviewer can run it again. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Text expansion affects interaction targets
Consider the journey from the reader’s point of view. A German Continue to the next step button becomes longer than the original design allows, so the label wraps over an adjacent icon. The team proposes a shorter translation that accidentally changes a mandatory action into an optional suggestion. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
To diagnose it, trace the decision that selected this output. Translation expansion is a layout constraint with semantic consequences. Buttons, hotspots, text boxes and speech bubbles have sizes and click regions, while a shorter synonym may change what learners believe will happen. A correction made at the wrong layer can disguise the problem without resolving it. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Rather than translating the visible symptom again, test its source. Prefer resizing, responsive layout adjustments or a vetted concise label over casually weakening the meaning. Inspect font metrics, line breaks and click areas in the actual published target version, not only in Storyline editing view. Keep an untouched source or staging copy so the comparison remains meaningful. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
A final comparison must focus on the user’s outcome. The learner can read the complete instruction and activate the intended control on a common laptop and a smaller screen. A visual fit that obscures an obligation is not acceptable. Keep known exceptions visible; silence is not evidence that they were tested. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Accessibility labels and focus order
A common temptation is to fix whatever English text is visible. A learner using a screen reader encounters an English alternative label on a German diagram. Nearby buttons have translated captions but their focus sequence follows visual assumptions that no longer match the new copy. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
Here the internal structure matters more than a polished title. Accessibility text, focus order and states are part of the functional lesson. Their quality is assessed by the experience offered to the user, not solely by whether the object displays translated visible words. That is why the file on disk and the experience in the product both need evidence. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Make one hypothesis and put it against the running system. Audit alternative text, instructional labels, feedback announcements and keyboard focus behavior in the target project. Ask reviewers who understand accessibility to inspect dynamic layers and changes triggered by learner answers. If the fix affects many places, sample a second location before calling it general. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Close the loop with a target-language test and an original-language control. Navigate a critical slide using keyboard and assistive technology. Every actionable object needs a meaningful target-language name and a sequence that lets the learner understand its role before activating it. Verify that the solution did not damage the source-language journey. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Right-to-left and font coverage
For a controlled trial, begin with this concrete mismatch. An Arabic translation reads correctly in a document but appears with broken glyph shaping and awkward button order in the published player. The language reviewer is fluent but cannot fix font rendering by rewriting sentences. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The causal chain runs through a non-obvious dependency. Writing direction, glyph coverage and interface ordering are presentation issues. Language selection does not guarantee that every font, component and player design choice supports the intended script and reading progression. Only a recorded source revision can settle a dispute about which wording was approved. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
This is a good place for a focused staging exercise. Test the chosen font and text objects with the actual target script, including numerals and mixed English technical terms. Review layout direction and cursor or focus behavior before shortening the translation to conceal clipping. Ask a product owner to approve changes that may affect measurement or correctness. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Do not settle for a screenshot of a successful first page. A native reader should be able to follow the slide and controls naturally, while a technical tester confirms no symbol or token disappeared. Keep the original technical strings where required and use deliberate bidirectional handling where needed. Where two people disagree, the documented observation should settle the claim. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Prove the release and transfer the method
Finish by checking navigation dependencies, retakes, LMS reporting, import reproducibility and review ownership. A language variant should be publishable and supportable like any other course release, not merely readable in a project editor.
Navigation and locked progression
It is worth looking at the event that exposed the defect. The localized player shows a correct Next label, but the button is disabled until the learner views every interactive layer. A translator calls it a broken translation because the English test was conducted after the prerequisite interaction. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
A successful translation file can coexist with this failure because Navigation rules can depend on visited states or timing. A translated label may be visible while the action it describes is intentionally unavailable; comparing different learner histories can create a false localization defect. The visible output is evidence of rendering, not proof that the intended source was selected. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Keep the handoff narrow: decide whether the fix belongs to words, structure or release configuration. Reset both language versions to the same learner state and record the prerequisites for unlocking. Translate the instruction that explains those prerequisites, and inspect triggers only if equivalent states produce different behavior. If a test is not reproducible, record the missing condition instead of guessing. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
A reviewer unfamiliar with the implementation should still be able to check it. A fresh learner should understand what remains to be done, then see the button unlock at the expected moment. The source and target versions must implement the same progression requirement. Record a pass or fail with the object identity and tested version. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Completion and LMS reporting
The next case separates an editorial concern from a system concern. A translated SCORM package loads inside the learning platform, but the learner finishes all slides without receiving completion credit. The translated feedback is fine; the reporting behavior is not. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The user sees one result, but the application combines several inputs. LMS completion and quiz reporting are outputs of Storyline course configuration and learner interaction. Translation may touch visible assessment instructions or navigation that influence whether an end state is reached, even though the export file itself does not redefine SCORM rules. Do not confuse a valid format with a valid message or a valid user journey. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The practical sequence is easier than it first looks. Compare the source and target publish settings, tracking method and completion conditions. Complete the target package in a staging LMS as a synthetic learner and inspect the recorded status rather than relying on the final congratulations slide. Keep operational IDs out of prose review unless their meaning is explicitly in scope. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
To prove the fix, repeat the original failure in the corrected version. The target-language attempt must produce the expected completion or passed status and score under the same learner actions as the source. Capture LMS evidence without disclosing a real learner’s record. A second tester is useful because they have not learned to avoid the broken route. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Retakes and resume paths
An apparently small change can cross several ownership boundaries. A target-language course passes its first attempt but displays a wrong-language hint after the learner fails and chooses Retry. A suspended session can also resume on a slide whose old label was never checked. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
This behavior has a precise explanation. Retake, review and resume paths reuse states that differ from the initial learner experience. A test that visits each slide once without changing attempt history cannot expose language defects in those conditional states. When the outcome is surprising, control the other variables before blaming the language. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Before opening a new translation request, identify the controlling reference. Test a failed first attempt, a successful retake, a paused session and a resumed session in the target language. Check dynamic score text, feedback states, player controls and any saved choices across those journeys. Avoid a bulk replacement that might modify unrelated examples. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
An effective sign-off records what happened, not merely who clicked Approve. Verify that all learner-facing messages are appropriate to the actual attempt number and state. A translation is not finished if returning learners receive wrong instructions or lose the intended progress behavior. An automated check may confirm structure, but a person still needs to judge meaning. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Import in a disposable copy first
This failure is especially easy to miss in a quick visual review. A vendor returns a Word document with one broken table row. An editor imports it into the primary German course file and spends hours isolating the faulty segment while undoing unrelated local formatting. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
Notice which part of the experience is outside the sentence itself. The import step maps translated content back onto existing Storyline objects. A failed or partial mapping can create widespread review work even if most target phrases are valid; direct editing of the only language file removes a useful baseline. The fastest useful escalation identifies the exact object, setting and owner involved. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
The corrective action needs an owner and a baseline. Import into a duplicated project file and retain the incoming export, the pre-import copy and an issue log. Review a representative slide set before accepting the full project and do not overwrite the previous approved language build until tests pass. Verify the control paths, not just the main line of text. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Evidence from the released surface is stronger than editor-state confidence. Re-open the project and compare object text, styles and key interactions with the baseline. A second teammate should be able to repeat the import and reproduce any reported problem from the preserved files. If a critical action remains impossible, the translation should not be released. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Sign off the course, not the export
One practical way to spot the hidden assumption is through a test persona. Everyone approves the translated XLIFF file, but no one plays the course end to end after publishing. A hidden quiz layer contains a mistranslated safety warning and the LMS records an incorrect score. That example is deliberately specific: it gives a tester a situation to recreate, not a universal claim about every Storyline 360 project.
The failure is reproducible because the system follows a rule. A translation file is only one intermediate artifact in an interactive product. Storyline learners experience media, states, player labels, accessibility, assessments and tracking behavior; those require a functional published-build test. The test should distinguish an intentional difference from an accidental mismatch. When you investigate, distinguish which part is owned by content authors, which part by the product, and which part by the release process.
Start by reproducing the same state in the original language. Use a release matrix with language, course revision, reviewer, target package, assessment paths and LMS status. Separate linguistic review from instructional-design review and technical package validation, and record any known unlocalized components explicitly. Review changes with the person who owns the downstream consequence. Record the input that changed and the expected result before you retest, so an unrelated improvement cannot be mistaken for the actual repair.
Treat this as a regression test that can be rerun next month. Sign-off should include a completed target-language learner journey and a failing-path regression test. A new reviewer must be able to reproduce the course version and understand why the content is safe to release. Compare the saved evidence with the original definition of the reader job. Try a neighboring language, version, answer path or user state; only then decide whether the same check can be reused elsewhere.
Worked example from start to finish
Storyline 360 manual round-trip ownership map Surface Manual Word/XLIFF handoff Separate verification Slide prose Translate designated text segments Read text on imported slide Variable references Protect reference identifiers Exercise live value substitutions Trigger conditions Not localized by the manual text import Test branch behavior in Storyline Player labels Configure in player settings Test navigation and resume Closed captions Manage separately Review timed target-language playback
A fictional safety course contains five slides, a branching hazard scenario, one embedded video and a results slide. Learners must select the safe response and earn at least 80 percent to complete. The training team needs a German version. Before export, the course owner freezes the English source revision, copies the .story project, records relevant variable references and lists all user-visible feedback layers.
The team exports a supported XLIFF file and asks translators to preserve segment identifiers and variable tokens. Alternatively, it uses enhanced Word export with thumbnails and instructs reviewers to change only the Translation column. The language reviewer checks commands, hazard terminology and conditions; the Storyline owner separately handles player buttons, closed captions, new narration and any trigger condition that relies on a value translated elsewhere.
The translated file is imported into the German project copy. The owner first previews the opening sequence, then deliberately selects the wrong hazard option, selects the correct one, fails the score threshold and tries again. A result variable should display the actual score in German context. The video captions should match the German narration. An accessibility tester checks the keyboard order and the meaning of feedback layers.
Finally the team publishes a staging package using the same tracking settings as the English course. Two synthetic learners take different quiz paths and the LMS must report the expected completion and score. The acceptance matrix links the source .story revision, translated file, imported project, published package, reviewer observations and release decision. A successful XLIFF import alone is recorded as a milestone, not the end state.
Practical release checks
For a manual XLIFF or Word handoff, check content, behavior and reporting as separate streams. The most valuable test is one that a course author and a bilingual reviewer can reproduce together in a language-specific project copy.
Save a source revision and language-specific .story copy before exporting any text.
Confirm the chosen manual workflow and the vendor-supported XLIFF version or enhanced Word format.
In Word, edit only the Translation column; preserve segment structures in XLIFF.
Keep variable names, result references and protected runtime identifiers intact unless deliberately updated inside Storyline.
List manual exceptions: player labels, trigger conditions, caption files, audio and image text.
Test conditional layers, normal and incorrect feedback, quiz thresholds and dynamic scores.
Inspect expanded text, button hit targets, target-script font shaping and accessibility descriptions.
Exercise resume, retake, locked navigation and final course completion journeys.
Publish to a staging LMS and verify score or completion is actually reported.
Archive the imported language copy and reviewer matrix; preserve a reversible previous release.
Practice and transfer
Try scenario A. Your German translation spreadsheet looks complete, yet the learner sees an English Next button and an English video caption. Identify which surface is managed by Storyline player labels and which requires separate caption work. Explain why re-exporting the same Word document does not inherently solve either problem.
Try scenario B. An imported translated result slide shows the characters %Results.ScorePercent% instead of a score. Compare the source and target references, inspect the real variable in Storyline and run two different results. Decide what evidence would justify editing a variable name, rather than hiding the problem with a literal score.
Try scenario C. A trainer reports that the German course is complete because every slide was visited. Ask what happened on a failed attempt, a resumed session and the LMS results screen. Write a minimal three-person review protocol assigning each test to a language reviewer, an instructional designer and an LMS administrator.
The lesson transfers to many interactive learning tools: text files are not executable learning experiences. Translate words in context, preserve the behavior that gives them meaning, and validate the released path a learner actually takes.
Summary
Manual Storyline 360 translation succeeds when the XLIFF or Word round trip preserves object identity and is followed by explicit review of elements the export does not cover. Test variables, triggers, captions, player labels, quizzes, accessibility and LMS outcomes before publishing a new language package.
Frequently asked questions
Can Storyline 360 export XLIFF and Word for manual translation?
Yes. Articulate documents manual export to XLIFF 1.2 or 2.0 and an enhanced Word translation document, followed by import into a project copy.
Should I translate variable names in the exported file?
Normally no. Names and references are control identifiers and may break if only one side changes. Translate values where supported and coordinate intentional renames inside Storyline.
Does the Word or XLIFF import translate captions and player controls?
Not as part of the documented manual text round trip. Articulate instructs authors to handle closed captions, trigger conditions and player labels separately.
Why is the German course not marked complete by my LMS?
The cause might involve course tracking, learner actions or quiz conditions. Compare source and target publish settings and test the actual package in staging instead of assuming a language-text defect.
What is the minimum useful acceptance test?
A complete target-language learner path that includes a correct answer, a wrong answer, result-variable output, player controls and the expected LMS completion record.
The following official Storyline 360 references were checked on 25 October 2026. Product capabilities and account entitlements can change; verify the exact version and permissions in your own environment before adopting a release step.
Related eduKateSG reading opportunities: Why Translate | E-Learning and Online Training · Top Ways to Translate Correctly | Localize E-Learning Courses . These links support adjacent concepts rather than repeating this article’s platform-specific job.
Editorial release state for Storyline 360: prepared as an offline candidate; no post has been created and no existing permalink has been modified.
