Twine story translation becomes much faster when the translator can change what the reader sees without changing where the story goes. If you are searching for how to translate a Twine game, localize a Harlowe story, adapt SugarCube passages, or preserve branching links while translating interactive fiction, the central problem is not a dictionary lookup. It is protecting the passage graph, state conditions and player choices while making every displayed line read naturally in the target language.
In an ordinary short story, a sentence can be revised and checked against the paragraphs around it. In Twine, a sentence may also contain a link, a condition, a macro or a value that changes what happens next. The visible text “Open the door” may be safely translated, while the passage identifier behind it should remain the exact string the runtime expects. A translator who changes both as though they were the same kind of wording may produce a beautiful sentence that leads to a missing passage.
This guide provides a Twine-specific method for treating interactive fiction as connected language and behavior. It distinguishes Harlowe, SugarCube, Chapbook and other story formats rather than pretending that every Twine macro is interchangeable. It explains the structural boundary, works through a miniature branching story, identifies dangerous editing patterns, and gives writers and testers concrete checks before release. Its one dominant reader job is to deliver a translated playable story whose choices, conditions and endings still work.
A Twine story is a graph readers traverse
A Twine story is organized into passages linked by routes. A reader enters one passage, reads text, makes a choice, perhaps changes story state, and moves to another passage. The resulting experience is not simply a sequence of pages fixed in advance. Two people may encounter different scenes, different lines and different endings depending on earlier actions. That makes translation quality partly a graph-preservation problem: every intended route must remain reachable after the words change.
Think of a passage as having two layers. The author-facing layer includes its identifier, tags, code and connections. The reader-facing layer includes narration, dialogue, visible choice labels and accessible cues. Sometimes these layers appear in the same markup expression. For example, the familiar link syntax [[Read the letter->letter_room]] displays one phrase while routing to a passage named letter_room. The visible phrase may be translated; the destination identifier should stay consistent with the actual passage title.
This boundary is the foundation of efficient review. The translator needs enough context to understand what “Read the letter” means and what its choice implies. The developer needs confidence that letter_room still exists and is the destination after translation. The tester needs to click the translated link and confirm that the correct scene opens. These are separate questions, and one clear asset inventory can answer all three.
When a project has many passages, build a graph or export of passage connections before beginning. Record the start node, reachable branches, conditional paths and all endings. A translation that accidentally creates a new passage title or changes a macro can alter this graph without making the HTML visibly malformed. The more branches a story has, the more valuable this baseline becomes.
Story formats determine which syntax is meaningful
Twine is a framework for making nonlinear stories, but it does not impose one universal authoring language for every project. Story formats implement different macros and rendering behavior. The official Twine Cookbook lists Harlowe, SugarCube, Chapbook and Snowman as formats with distinct conventions. Harlowe uses forms such as (if: $hasKey)[...]; SugarCube uses structures such as <<if $hasKey>> ... <</if>>. Chapbook and Snowman follow other conventions. A method that is valid in one format can be meaningless or damaging in another.
Before translating, document the selected story format and its version, the Twine application or source workflow used, and how the build is tested. If the story has custom JavaScript, CSS, macros or third-party extensions, record those dependencies as well. A translator does not need to become an engine developer, but must know which characters delimit control syntax and which text is safe to edit. The project should not ask translators to infer this from hundreds of raw passages.
Some stories can be localized with separate language-specific story builds. Others use custom lookup tables to choose language at runtime. Both can work, but neither should be confused with a built-in universal Twine translation command. The implementation will depend on story format and project architecture. Choose the smallest method that can be verified for the target story, then make it explicit in the localization brief.
This is also why copying Ren’Py or game-engine localization instructions into Twine is risky. Similar narrative concepts do not imply the same markup, passage names, state variables, save behavior or test runner. Transfer the discipline of preserving identifiers and contextual choices, not syntax from another engine.
Separate visible link text from passage destinations
Links are the highest-leverage editing rule in Twine localization because they look like ordinary prose but can carry route instructions. The Twine Cookbook documents forms such as [[Visible words->Destination]] and [[Visible words|Destination]]. A shorter form [[Destination]] can also serve as both the link label and the passage target. That shorter form is convenient when authoring in one language but creates a translation trap: changing the visible words also changes what passage name the syntax points to.
Suppose the English story uses [[Forest]] to link to a passage also named Forest. A translator replaces the word with Bosque but does not rename the passage. The target story now points somewhere else, potentially a missing destination. A safer source authoring pattern separates presentation from identity before translation: [[Go to the forest->forest_entry]]. The Spanish label can become [[Ir al bosque->forest_entry]] while the destination remains stable.
The same principle applies to passage titles referenced by special macros, conditional navigation, startup settings or save-related logic. Do not rename passage identifiers casually. Even a harmless-looking capitalization change can matter depending on the system that resolves it. Build a table of source passage names, link targets and target-language display labels. The table lets QA compare structure independently of style.
A useful structural test extracts all destinations from the original story and the translated story and compares them against the defined passage identifiers. The test must understand the selected story format because not every navigation action is written with the same plain link syntax. A basic text search can catch obvious mistakes, but format-aware validation is safer when the story uses dynamic routes and macros.
Protect variables, conditions and story state
A Twine passage can contain values that track inventory, relationships, evidence, time or other story conditions. The exact language depends on the story format, but the general rule is stable: variable names and control expressions are part of program behavior, not prose. A translator should preserve the relevant syntax unless a developer has requested a deliberate code change. Translating $hasKey as though it were dialogue can make a condition stop working.
Consider a gate scene. One branch is shown only if the reader found a brass key; another explains that the gate remains locked. The English text may use the same word “key” in narration, a choice label and a variable name. The visible word should be translated naturally, perhaps using a specific term for the kind of key involved. The variable identifier should remain unchanged. Conflating the layers can cause both a linguistic mistake and an unreachable route.
Provide translator notes that identify syntax to preserve. Instead of saying only “Do not touch code,” mark the boundaries of editable text and give examples from the actual story format. It is especially helpful to show paired source and target passages with working markup. A translator can then edit sentences, reorder visible clauses if the format allows it, and preserve the identifiers and delimiters that the runtime needs.
Testing should intentionally cover state-dependent passages. A happy-path run from Start to a common ending may miss the branch reached only when a player has no key, chooses a particular item or returns to an earlier scene. Compare pre-translation and post-translation behavior under the same state. If the story offers a debug route for setting variables, maintain one for localization QA without exposing it in the public build.
Build a passage inventory that explains meaning
A bilingual spreadsheet containing only lines of text is rarely enough for interactive fiction. The translator needs the passage identifier, visible source text, preceding passage or situation, character or narrative voice, possible outgoing choices, relevant state, whether the line is optional, and any special formatting. A line such as “Not yet” may be a refusal to leave, a statement about a delayed event or a hint that an action remains locked. The surrounding branch makes the difference.
Create a context pack for each cluster of passages. Include a simple route map, selected screenshots, a summary of what the player already knows, and the immediate consequence of each choice. For a conversation, show who speaks and whether a choice is sincere, deceptive, sarcastic or forced. When a target language requires more explicit pronouns or formality distinctions than English, this context prevents the translator from guessing inconsistently across branches.
Distinguish the player’s knowledge from the protagonist’s knowledge. A story may deliberately let readers suspect a betrayal before the protagonist does. A translation that resolves an ambiguity too early can spoil a narrative turn. Similarly, the source may avoid revealing a character’s gender, social rank or identity until a later passage. If the target grammar requires a choice the source avoids, flag it for an author-approved strategy rather than treating the issue as a routine vocabulary decision.
For repeated terms, keep a compact glossary. A “seal” could be an animal, a wax impression, a magical barrier or an official mark. Interactive stories often reuse motifs, and a reader’s recognition of a repeated term can be crucial to solving a puzzle. The glossary should connect terms to their story meaning and note exceptions when a deliberately misleading label is part of the design.
Choose a translation architecture that matches the story
There are several valid ways to ship a translated Twine story. Separate localized builds can preserve one passage graph per language and allow straightforward source comparisons. A single multilingual build can use a project-defined message lookup or language-variable mechanism, but the specific code is story-format-dependent. The best choice depends on whether players need in-story language switching, how much branching text exists, whether downloadable versions are distributed, and how updates will be maintained.
A separate-build strategy may be simplest for a short educational story. The author freezes a baseline story, creates a target-language copy, protects identifiers, and compares passage connections. The risk is drift: an English bug fix may be applied to one version and forgotten in another. The maintenance plan therefore needs a change log and a method to identify source passage updates. A bilingual review table can show which target scenes require revision after a story edit.
A shared multilingual build can reduce duplicate logic but has its own risks. Every visible line may need to be wrapped in a lookup mechanism; conditional text may be harder to maintain; and language switching mid-passage may require rebuilding displayed content without inadvertently resetting story state. Do not promise runtime switching until that precise behavior has been implemented and tested. For many authors, simply giving users a clear language choice before starting is sufficient.
Whichever architecture you choose, define the source of truth. Is the canonical narrative in Twee files, the Twine application’s passage editor, or a version-controlled external text workflow? Who can edit identifiers and macros? How are source changes marked for translators? A clear answer prevents an editor from translating the wrong build or overwriting a later author revision.
A small linked-story example, before and after translation
Imagine a five-passage educational story called The Lantern at the Gate. It begins in start, branches to gate, garden and watchtower, and ends at ending_safe or ending_lost. The player can inspect a clue, choose whether to trust a stranger, and reach different outcomes. The author separates visible link labels from stable destination names before translation.
A deliberately simplified source passage might look like this:
:: start
The lantern flickers. A stranger points towards the gate.
[[Follow the stranger->gate]]
[[Search the garden->garden]]
A Spanish translation of the visible material can preserve the same graph:
:: start
La linterna parpadea. Una persona desconocida señala la puerta.
[[Seguir a esa persona->gate]]
[[Buscar en el jardín->garden]]
Here :: start is a common Twee-style passage header in text-source workflows, not a macro to paste blindly into any editor field. The significant detail is that the visible sentences and link labels change while start, gate and garden remain the same passage identities. The example leaves narrative choices open for translator review; a different tone might call for a less formal or more suspenseful Spanish phrase.
Next, imagine that the gate passage contains a condition checking whether the player collected a key. The translator should edit the narration and choice captions inside each branch while preserving the condition and destination. QA must run the branch twice: once with the key and once without it. If the Spanish version reaches ending_safe with the key and the same authored consequences, the structural route is preserved. Then a language reviewer checks whether the choice actually tells the reader what decision they are making.
A good miniature example is worth running end to end before localizing a long novel. It reveals whether the chosen source format, export process and protected-markup rules are practical for the full story.
Harlowe-specific hazards in editing passages
Harlowe uses its own macro syntax and hooks. For example, the Twine Cookbook illustrates conditional forms such as (if: $hasKey)[It looks like the key will open the door.]. The text within the hook can be translated, but the structure of (if: ...) and its delimiters should not be altered accidentally. A missing bracket or a changed variable name may cause a rendering or logic error even when the target prose is grammatical.
Harlowe links and styling can also be expressed through macros and named hooks rather than only plain [[...]] links. A search-and-replace operation that targets a visible phrase might hit a macro argument, CSS selector or other control token with a very different purpose. Before bulk editing, find out which elements the author uses for navigation and for state changes. Do not assume that every string in quotation marks is a sentence meant for readers.
A translator working in Harlowe should have a small reference sheet showing editable narration, editable visible choice labels and protected syntax patterns from the actual game. If a literary revision requires changing the placement of a link within a sentence, preserve its destination and test the click. If a target script changes line-breaking behavior, check the full passage for hook styling and any interactive text that appears only after a previous click.
Harlowe story styles may also be affected by layout and CSS rules. A visually attractive English passage can become difficult to read when the target text expands or uses a different script. Keep styling concerns separate from grammar. First verify correct narrative meaning and route, then adjust presentation without weakening readability or changing story state.
SugarCube-specific hazards in editing passages
SugarCube has different macros, conventions and special passages. The Cookbook’s example uses <<if $hasKey>> and corresponding closing markup. The SugarCube reference documents many features for variables, navigation, widgets and state management. A translator who treats double-angle macro markup as decorative punctuation can change the program. Likewise, names of special passages such as StoryInit can carry behavior rather than serve as ordinary chapter headings.
SugarCube’s extended link features can be more expressive than basic passage links, which is valuable for authors but increases the need for format-aware extraction. The translator should receive clear boundaries around code, link destinations, variable expressions and displayed strings. A bulk replacement that changes a variable name in one macro while leaving the rest of the story untouched may make the issue difficult to find during a superficial reading pass.
Consider a link whose visible label depends on a variable or whose click changes a variable before navigation. The target label may be translated; the state-changing expression must be preserved unless an authorized code edit is required. Verify the actual after-click state in a test story. Do not evaluate only whether a clickable phrase appears. A link that looks right but fails to set a flag can change the ending many passages later.
When a project relies on SugarCube saves or history, multilingual variants need deliberate compatibility testing. A translated build might preserve identifiers and therefore retain some state assumptions, but compatibility is not guaranteed merely because passage names match. The exact save/version behavior depends on how the story was authored and distributed. Test representative saves rather than promising universal interchangeability.
Choices carry consequences, not just labels
A Twine choice may appear as a short phrase but represent a major decision. “Tell the truth,” “Keep silent” and “Lie for her” establish a moral structure that the reader expects the story to honor. A translation should preserve the intended action and degree of agency. If the reader chooses an option translated as “Tell the truth” and the next passage treats it as a lie, the localization fails its fundamental purpose even when both sentences sound fluent.
This is why every choice needs context about its outcome. Record whether the action is reversible, whether it changes a variable, whether it merely explores information, and whether it commits the player to an ending. Two choices might be deliberately deceptive; the wording should preserve that authorial design rather than make the story easier by explaining a twist too openly. The translator’s job is to recreate the intended experience, not to remove all ambiguity.
Review parallel choices as a set. If three options in English have matching rhythm or escalating urgency, the target should consider how to preserve their relationship. One unusually long choice may dominate the screen visually and suggest importance that the source did not intend. An adaptation may need different sentence length or syntax to balance the alternatives. Test them in the actual passage rather than evaluating each label alone.
A useful QA exercise reads the target choices aloud without showing the source, asks a reviewer what each action appears to do, and compares those interpretations with the game’s actual routes. This catches errors that a literal source-target check might miss. It is particularly helpful in educational interactive stories where the learner’s decision is itself the teaching mechanism.
Narrative voice across branches and repeated scenes
An interactive narrator may speak in second person, a character may change register after learning a secret, and two routes may revisit the same location with different emotional meaning. Translation needs continuity across those paths. If a protagonist addresses a mentor formally in one branch and casually in another without narrative cause, the inconsistency can expose the seams of the localization. English may not mark that distinction overtly, but many target languages require decisions about address and politeness.
Create a voice sheet for recurring speakers and the narrator. Include relationship, age or status when relevant, characteristic vocabulary, level of formality and whether a phrase is deliberately ironic. Do not overdetermine details the source intends to hide. When the target language forces grammatical choices, escalate the question and preserve the author’s intended uncertainty as far as practical.
Track repeated motifs. A lantern that signifies safety early in the story may represent betrayal later. If it is translated under several unrelated terms, readers can miss the connection. Conversely, a single English word may represent two different objects in different branches and should not be forced into one target term merely to satisfy a mechanical consistency checker. Meaningful consistency requires narrative analysis, not blind sameness.
Review complete arcs rather than isolated passages. Read the target from start to an ending, take another route, and compare how key terms, promises and character revelations accumulate. A translation can sound natural line by line yet feel incoherent when a later payoff depends on an earlier phrase that was paraphrased too freely. Preserve the story’s causal and emotional structure alongside its clickable graph.
Conditional text and hidden branches need coverage
The hardest scenes to review are often the ones that do not appear in an ordinary read-through. Conditional passages may depend on inventory, relationship scores, visited locations, random outcomes or a combination of flags. If translation QA follows only the most common branch, these passages can remain untranslated or broken for months. A simple manual walkthrough may be insufficient for a story with many state combinations.
Build a route matrix that names each meaningful condition and its expected visible result. For the lantern story, the key state may be hasKey, the trust state may be trustedStranger, and the available endings may depend on both. Rather than testing every possible arbitrary combination, identify the combinations that change displayed wording or navigation. Use an author-approved debug mode or test harness to reach them quickly. Keep the test harness outside the public story unless it is meant for readers.
Coverage can be measured in several ways: passages reached, outgoing links exercised, meaningful conditional branches triggered, and endings observed. No single measure proves full quality. A passage may have been visited but only one of its three conditional lines displayed. Similarly, reaching all endings does not prove that every choice label describes its consequence correctly. Report coverage honestly and prioritize high-risk paths, especially those containing irreversible actions or educationally important feedback.
If the target-language editor discovers an unreachable or contradictory route in the source, treat it as an authoring issue. Do not quietly change control syntax as part of translation. The developer or author should decide the fix, and then all language versions should receive the coordinated change.
Layout, accessibility and reading rhythm
Twine is often used because writing and reader choice can carry the experience without complex graphics. That makes typography and navigation unusually important. Target-language text may expand, use longer words, require different line breaks, or include scripts with different shaping and direction. A translated passage can become a wall of text that pushes the available choices far below the viewport. That may alter pacing or make navigation tiring, especially on mobile devices.
Test paragraph spacing, heading hierarchy, link contrast, keyboard focus, screen-reader access and comfortable line length. Do not rely on color alone to distinguish a choice from surrounding narration. Ensure translated labels identify actions clearly when read out of visual context. An icon or emphasized word that seems obvious to the author may be ambiguous in another cultural or linguistic setting. Accessibility is part of preserving the reader’s ability to make the intended choices.
Pay attention to the story’s rhythm. A one-line hesitation before a revelation may become three lines because of translation and viewport width. That can be fine, but sometimes a deliberate break or delayed reveal should be reconsidered. If the game uses timed text, animated word reveals or click-to-continue effects, test reading speed and the treatment of user-perceived characters. Do not cut a complex script into raw units simply because the source was English.
Keep mobile and desktop testing separate where needed. A browser-based story may work beautifully on a laptop and show clipped buttons on a phone. The target text must be evaluated in the experience the reader actually receives, not only in the translator’s editor window.
Glossaries, transcreation and cultural references
Interactive fiction may rely on riddles, names, historical references, jokes or local customs. Translating these elements can require more than replacing words. A clue built around the spelling of an English term may be unsolvable if that term is translated normally. A pun that is optional flavor can be adapted creatively, while a pun that encodes an essential puzzle answer requires agreement between translation, puzzle design and test logic.
Mark these segments early. A “puzzle-critical” note should explain what the player must infer, what evidence exists, and what solution the game expects. The translator can then propose a target-language clue that preserves the reasoning task, or the author can approve a redesigned puzzle. Changing only the surface wording while leaving a language-dependent answer checker unchanged may trap players in an unwinnable passage. That is not an editorial nuance; it is a functional defect.
Names and cultural references need a policy. A fictional place name may remain unchanged, be transliterated, or receive a translated descriptive form, depending on style and plot. A real-world reference may need a short contextual cue if the target audience would otherwise miss its role. The goal is not to make every reference familiar, but to keep the reader’s understanding and the author’s intended effect aligned.
Record decisions as reusable notes. If the team agrees how to treat the “Moon Gate” and its related symbol, apply that choice to narration, choices and endings. When there is a deliberate exception, document why. These notes make later source updates quicker and prevent inconsistent revisions from appearing across branches.
Worked failure analysis: one translation, three broken routes
Suppose The Lantern at the Gate receives a first Spanish draft. The story reads fluently, but the QA tester notices that a choice disappears after opening the garden passage. The source had a Harlowe conditional hook; the target edit accidentally removed a closing bracket while rearranging the sentence. The defect is mechanical. The reviewer restores the protected syntax and rechecks both outcomes of the condition rather than changing the Spanish prose unnecessarily.
A second error sends readers to a nonexistent passage. The original markup was [[Tower]], with Tower serving as both visible text and destination. The translator made it [[Torre]], but the passage title remained Tower. The author repairs the source architecture by separating label and destination, then applies the same stable destination in both languages. The immediate Spanish route works, and future translations become safer. This is a systemic fix rather than a one-off redirect.
The third error is harder to catch. The Spanish label for a choice suggests the reader will protect a stranger, while the actual branch accuses the stranger of theft. A structural checker finds nothing wrong: the destination exists, the conditions execute, and the HTML renders. A human reviewer who reads the whole branch identifies the contradiction. The translator revises the label to express the intended action, and the author confirms that the ambiguity is not a deliberate plot device.
The three defects illustrate why this job needs separate tests for syntax, navigation and meaning. A translated story can pass two layers and still fail the third. The quickest reliable workflow applies each check deliberately rather than expecting a spellchecker or a single playthrough to catch everything.
A format-aware QA pipeline for a translated build
Begin with a clean export or source snapshot of the original story. Record passage identifiers, expected start passage, special passages, link destinations and branching conditions. Create an editable text inventory with protected markup and reviewer context. Translate the visible text in controlled batches. After each import, run a structural comparison: the number and identity of passages, destinations, required macro patterns and critical variable names should match expectations unless the author approved a change.
Next, test the story in its actual story format. A generic parser that understands [[...]] links may not understand SugarCube’s extra navigation macros or Harlowe’s conditional hooks. Use the relevant format’s own test environment and any project-specific test harness. Watch for broken passage references, visible raw macro text, missing variables, empty choices, and unexpected state changes. Check whether special passage names were kept intact.
Then run linguistic review by route. Provide the reviewer a path through a sequence of passages, the narrative aim of the scene and the expected choice outcomes. Do not simply send a flat alphabetical list. An issue record should include passage ID, branch conditions, screenshot, source line, target line and proposed fix. An editor can then determine whether the change affects one sentence, several linked passages or a critical puzzle.
Finally, validate the published HTML build or download file on its intended browsers and devices. Test the same target artifact that will be distributed. A working Twine editor preview is useful but not a substitute for checking a bundled website, embedded story or hosted version with its real scripts and assets.
Publishing and updates without splitting the story apart
A story may continue to evolve after translation. The author adds a passage, changes the condition for an ending, fixes a typo, or changes a character’s motivation. A localization workflow must distinguish simple source-copy edits from structural changes. A short English spelling correction may require only one target review. A new choice that changes the route graph requires translation and navigation regression across affected paths.
Keep source and target versions traceable. If the story is maintained in Twee files under version control, use passage-aware diffs where possible. If it is maintained in the Twine application, export approved snapshots and record what changed before asking translators to update their versions. The key requirement is a stable baseline against which passage identifiers and links can be compared. A new target build should not quietly import yesterday’s code and last month’s prose.
Use a clear release note identifying story format, supported languages, tested route coverage, known limitations and where feedback should go. A player reporting “the gate choice did nothing” has given a useful symptom; the maintainer should be able to connect it to a passage and link without asking the player to understand Twine markup. A good maintenance structure turns those reports into focused fixes.
If several target-language builds are shipped, test each one independently even when the same original graph was copied. One translator may accidentally change a destination or delimiter in their version. Structural similarity reduces risk but cannot replace an executable acceptance test for each delivered artifact.
Transfer: the graph idea matters in many learning experiences
The underlying lesson travels beyond interactive fiction. Educational branching scenarios, choose-your-path reading activities, onboarding flows and interactive assessments all contain visible instructions connected to state and outcomes. Translation must preserve both what the learner understands and which action the system performs. A reader clicking a translated choice should receive the intended consequence, not merely a page that happens to load.
Twine is a particularly useful teaching example because the boundary between prose and control markup is exposed to the author. In a conventional mobile app, the same boundary may live in separate source files or localization tables. In a narrative engine, it may live in scripts and dialogue resource IDs. The platform-specific syntax changes, but the need for stable identity, contextual translation and route testing remains.
For adjoining ideas, see the published stable localization keys guide, inline-tag placement guidance, and translation QA error taxonomy. Those pages explain transferable principles. This article owns the narrower job of keeping a Twine passage graph and its reader-facing language aligned, which is not the same as translating a general document or a fixed linear script.
Frequently asked questions
Can I translate a Twine story without breaking its links?
Yes, if you distinguish visible labels from the passage destinations they reference. Prefer markup that makes that separation explicit, protect identifiers, and compare link destinations before and after translation. Test the resulting story, not merely the translated text export.
Are Harlowe and SugarCube translation instructions interchangeable?
No. Twine story formats have different macro syntax and runtime conventions. Harlowe uses forms such as (if: ...)[...], while SugarCube uses forms such as <<if ...>>. Identify the format and version before setting protected-text rules.
Should I translate the names of passages?
Usually preserve passage identifiers when they are part of links or control logic. If an author wants localized display headings, translate those separately from the technical identifiers. Renaming a passage should be a coordinated engineering change with a full navigation check.
Is [[Next scene]] safe to translate directly?
It may not be, because that text can serve as both visible label and destination. A safer pattern is to separate the label from a stable target, such as [[Enter the courtyard->courtyard_entry]], then translate only the visible label.
Can one Twine file switch between languages at runtime?
It is possible for a project to implement multilingual behavior, but Twine does not have one universal cross-format language-switch command. Runtime design depends on story format, custom code and whether switching must preserve current state. Test that exact requirement before promising it.
Why do some translated branches never appear?
Check whether state conditions still evaluate as intended, whether identifiers and delimiters were preserved, and whether those branches are reachable under the tested state. Build a matrix of meaningful conditions rather than reviewing only the most common route.
How should translators handle variables inside text?
Preserve variable names and control syntax unless the author explicitly changes them. Supply notes explaining what the variables mean, how values will appear to readers, and any gender, number or politeness constraints the target language needs to resolve.
How do I translate riddles and language-dependent puzzles?
Document what the puzzle tests and what answer logic expects. The translator may need an adapted clue or an author-approved change to the puzzle itself. A literal translation that makes the clue unsolvable is not a successful localization.
Does a complete passage list prove the story is translated?
No. Conditional text can hide within visited passages, and accessible link labels can still describe the wrong consequence. Review branch conditions, choices, endings and actual runtime behavior as well as passage counts.
What should be included in a Twine localization handoff?
Provide the story format and version, canonical source snapshot, passage IDs, link graph, context notes, voice and terminology guidance, protected markup rules, test routes and target build process. This lets translators focus on meaning and helps QA find structural faults quickly.
Summary: preserve the path while translating the experience
A Twine story is a network of passages, choices and stateful consequences expressed partly through text. Localization succeeds when a reader can follow the same intended routes, understand the same choices and experience the same narrative effects in another language. Protect destination identifiers, variables and story-format syntax; translate visible labels with contextual freedom; test conditional branches; and inspect readability on real devices. That is how a branching story can be translated quickly without sacrificing the thing that makes it interactive.
Continue with the How People Translate Quickly series index or the Master Art of Translation overview for broader context.
Source documents and technical references
The authoritative starting points are the Twine Cookbook story-formats guide, the Twine Cookbook link guide, the Harlowe manual and the SugarCube 2 documentation. Verify exact syntax against the version used by the source story, especially when it contains custom macros, scripts or a separate Twee compilation workflow.