Adventure Game Studio Translation: TRS, TRA and QA

How do you translate and localize Adventure Game Studio projects professionally without breaking the experience? This complete Adventure Game Studio localization guide explains the actual text and language mechanisms, how to make the interface understandable across countries, and how to test the final release. It is written for independent adventure-game creators, volunteer translation teams, educators and publishers preparing a story-driven title for players across different countries. You can follow the decisions in order and use the troubleshooting section when a real game behaves differently from its translated source files.

The essential platform distinction is this: AGS provides a built-in translation workflow: create a translation in the editor, fill a source/target TRS file, compile it as a TRA resource and select it for a running game. Text embedded in graphics and some dynamically assembled strings need separate attention. A working language file is only one part of a usable product. A player has to see the correct message, understand the available action, and receive the intended result. Before committing to several languages, confirm the toolchain and release format for the version of Adventure Game Studio your project actually uses.

This guide follows a point-and-click coastal observatory mystery in which players read museum labels, question a harbour keeper, examine a lighthouse diagram and decide how to repair a radio. It covers translation scope, text identities, interface wording, language selection, content revisions, real-player testing and delivery checks. The practical objective is a translated sentence must never change inventory state, hotspot identifiers, puzzle solutions, dialogue branching, code comparisons or a player’s saved progress. You will also find a four-week rollout, a symptom-first fault finder and frequently asked questions for teams preparing their first multilingual edition.

Quick answer: the reliable localization route

Identify the player-visible content and all non-translatable program identifiers in Adventure Game Studio.
Create stable source references and give translators scene, speaker and decision context.
Translate complete meanings, not disconnected words; protect variables, logic, format markers and resource keys.
Test each choice and message in the actual running product in a supported target language.
Package the complete release and keep evidence of source version, language coverage, fallback and player outcomes.

Contents and how to use this guide

What a translated game must preserve
A worked story and the language-versus-logic boundary
Twenty-five practical decisions from source preparation to distribution
A symptom-first troubleshooting reference
Three complete player journeys and a testing matrix
A four-week plan, reader questions and primary documentation

Adventure Game Studio: what language changes and what must remain the same

In our running example, a point-and-click coastal observatory mystery in which players read museum labels, question a harbour keeper, examine a lighthouse diagram and decide how to repair a radio. A translator is not merely replacing captions. The words must give the player enough information to decide what to do next, but not more information than the original game intended. A menu term, a puzzle clue and a conditional response may all need different review methods, even if they share a word in English.

Consider this specific source moment: In the English game the harbour keeper says, ‘The west lamp is dim.’ The translator can change the displayed sentence, but the script must still test the same west-lamp puzzle flag and must not silently swap east with west. This demonstrates the core boundary: language communicates a decision while program state controls its consequences. If you preserve only the visible words, readers may receive natural prose that leads to a wrong outcome. If you preserve only code, they may receive an accurate branch with an incomprehensible choice. Both must agree.

A useful small-scale trial is one route through the game: first launch, language selection, an instruction, a decision, a state change, a surprising result, recovery and a saved-session return. Choose one target language with a competent human reviewer. Keep the source-language journey beside it. A successful comparison is not identical sentence length; it is equivalent information, choice and outcome.

Adventure Game Studio localization: twenty-five implementation decisions

1. Define one authoritative source language

AGS replacement pairs depend on recognizing original source strings. A clear source version and string inventory let translators distinguish a changed sentence from an unchanged display label.

For a practical first pass, Make an inventory with filename, location, screenshot, speaker, player action and expected outcome. Record whether the original appears in a dialog, GUI property, description or script literal. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

If the original is quietly edited after the translation is prepared, a replacement can stop matching. Update the translation source and review the affected pair before approving a new build. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

2. Create translations using the editor

The Translations tree in Adventure Game Studio is the normal place to add a language. The editor generates a .TRS text file populated from available game text.

On a small project, Create one new language, allow the editor to populate its source, then inspect a few dialog turns, button captions and object descriptions before delegating translation. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Generating a file is not translating a game. Check exactly which visible strings were extracted and which signs or art assets remain outside the editor workflow. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

3. Respect original-and-target line pairing

A TRS source uses alternating original and translated lines. Blank target lines can indicate untranslated entries, but the file’s structural line positions must remain valid.

To make this operational, Have translators work from a protected copy, preserve source lines and structural blank lines, and use a diff or small validation script to detect unexpected extra or missing lines. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Moving a target sentence onto another source line can show a fluent but incorrect clue at the wrong moment. Reject any TRS with unexplained pair-count differences. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

4. Compile translations to TRA resources

The game’s runtime consumes compiled translation data rather than a raw spreadsheet created for reviewers. AGS offers a compile action for a selected translation.

In the working story, Compile each completed TRS, archive the resulting .TRA alongside its source revision and include it in the same release test as the executable. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A good .TRS left uncompiled does not make a localized release. Launch the installed artifact, not merely the editor preview, and confirm that target text appears. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

5. Choose language before story choices

A player should be able to identify the language menu without understanding the current language. Language selection is a usability problem as well as a technical setting.

For a practical first pass, Use recognizable language names, keep a reversible path to the default language and test selection at first launch and after a saved session is resumed. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

If switching language requires navigating an unreadable menu, the feature is theoretically present but practically inaccessible. Test with a reviewer who cannot read the default language. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

6. Use Game.ChangeTranslation deliberately

AGS exposes a runtime API for changing an available translation; its return value can indicate success or failure. An empty translation name can revert to the default language.

On a small project, Wire the menu to a known translation filename stem, check the return result, and refresh affected screens in the test project before shipping. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Do not display a success confirmation when a file was missing. Verify both the active language and the screen the player sees immediately after the switch. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

7. Distinguish source language from locale formatting

Replacing a sentence does not automatically establish local preferences for dates, measurements, decimal punctuation or idioms. Players may understand words but misread values.

To make this operational, Keep game-state numbers authoritative and specify which visual presentation rules belong to each supported language or region. Review clocks and numeric puzzle cues separately. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Never change a puzzle’s numeric answer merely to imitate a translated phrase. Confirm that a formatted quantity still denotes the same amount. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

8. Write translator context for puzzle clues

Adventure-game words can be actions, locations and inventory clues. Terms such as light, key, charge or port have several plausible meanings in isolation.

In the working story, Give translators a screenshot, a description of the puzzle and the exact referent. Ask a second reviewer to replay the clue before the answer is known. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

An elegant translation that points to the wrong object is a gameplay defect. Compare what players infer with the designer’s intended step. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

9. Protect dialogue speakers and turn order

Dialogue conveys relationships, timing and information release. A translation that merges lines or changes implied speakers can make a scene difficult to follow.

For a practical first pass, Audit character names and dialogue turns in the live game. Preserve who knows each fact at each point, particularly when a revelation is conditional. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A player must not learn a secret from a sentence that originally concealed it. Test the conversation before and after every branch-triggering answer. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

10. Translate GUI labels as actions

Buttons such as Look, Use, Talk, Save and Quit are part of the interaction grammar. A label must match the action that follows it.

On a small project, Build a compact interface glossary with verb forms and room for expansion. Test whether a newcomer chooses the correct button without English hints. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A single misleading action verb can make a working control feel broken. Review hover text and button behavior together rather than assessing wording alone. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

11. Handle dynamic strings with GetTranslation

Not every string assembled by code is automatically replaced in the same way as an ordinary literal. The manual documents GetTranslation for cases needing explicit lookup.

To make this operational, Identify concatenated instructions and strings used in comparisons, then choose full, translatable messages or carefully reviewed explicit translation lookup. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Joining translated word fragments can produce ungrammatical language, especially where agreement and word order change. Prefer a complete message for each meaningfully distinct state. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

12. Preserve formatted-string placeholders

AGS warns that translated formatted strings need matching placeholders in the original order. A percent-s or percent-d token is executable formatting, not decorative punctuation.

In the working story, Freeze a placeholder manifest per source string; inspect translations for token type, count and sequence; then test with actual in-game values. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A missing, reordered or changed placeholder can display the wrong clue or cause an error. Do not sign off from prose review alone. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

13. Check object names and hotspot descriptions

Players often inspect hotspots to learn whether a room object is interactive. Some values may be translated through AGS properties while others are assembled in scripts.

For a practical first pass, Walk through every room with interaction markers enabled. For each object, check visible names, descriptions and feedback for both solved and unsolved states. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

If a hotspot stays in English while the surrounding room is translated, the player may miss a clue. Record whether the source comes from an editor property or a custom text system. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

14. Localize text inside rendered art separately

A poster, door sign, photograph or map may contain lettering baked into an image. Translating catalog strings cannot replace those pixels.

On a small project, Inventory visual assets with language-bearing text; create localized images when possible, or a readable caption alternative when changing the art is inappropriate. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Do not promise that the .TRA file covers graphical text. Inspect the actual artwork in each released language and include screen-reader or transcript alternatives when suitable. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

15. Choose fonts for real scripts

Text decoding and font rendering are different requirements. A target language may need glyphs, shaping or punctuation support the default game font lacks.

To make this operational, Use an approved font strategy for each script, then check menus, dialog windows, accented names and long place labels in a packaged build. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A string can be perfectly translated yet render as boxes or missing marks. Test sample characters and complete sentences, not just the language selection screen. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

16. Protect right-to-left layout claims

An AGS game designed around left-to-right layout might not have complete bidirectional shaping or mirrored navigation for every target script.

In the working story, Prototype real Arabic or Hebrew sentences early, test mixed digits and object names, and state limitations rather than treating right-to-left support as automatic. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Flipping a panel is not the same as correct text shaping. If a script cannot be shown reliably, postpone advertising full support until it works. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

17. Keep speech and subtitles synchronized

Voice files, subtitles and dialogue timing can form one player experience. Translating text without considering audio can create unreadable or contradictory scenes.

For a practical first pass, Decide whether each locale has localized voice acting, original voice with translated subtitles, or text-only play. Document the choices and check timing. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Never label a language edition fully voiced unless the relevant clips exist. Verify skipped dialogue and fast-click behavior as well as normal playback. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

18. Use an explicit fallback policy

An incomplete translation should not turn a critical puzzle instruction into blank text. At the same time, silent fallback can overstate translation coverage.

On a small project, List missing entries, select a readable default fallback, and inform release reviewers which game chapters remain mixed-language. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A menu that renders is not proof the narrative is fully localized. Run through the final chapter rather than extrapolating from a translated introduction. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

19. Avoid rewriting puzzle truth

A translated clue may need a different pun or idiom to preserve playability. Such adaptation needs both linguistic and design approval.

To make this operational, For wordplay, document the answer, player evidence and allowable rewrite; test the clue and expected action in the new language with fresh readers. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A literal clue may become insoluble, while a freer rewrite may reveal the answer prematurely. Neither should be accepted without gameplay validation. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

20. Version the translation after story changes

Adventure games evolve: new dialogue, changed inventory notes and corrected captions create translation drift. The AGS update-translation operation can help append new source entries.

In the working story, After changing source content, update each language file, review additions and altered meanings, and log which locales are ready for the next build. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Do not assume that old translation pairs remain suitable after a plot revision. Mark every changed clue for semantic review, even when the original wording looks similar. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

21. Check save files around language changes

A saved game should restore meaningful gameplay state. Language selection may be an application preference, but it must not reset quests or invalidate stored scripts.

For a practical first pass, Save before opening a puzzle, switch language, restore, and compare inventory, dialogue flags and room position to the original run. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Text translation should never become a migration of gameplay data. If a saved scene fails only in one language, reproduce the language transition independently of the story bug. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

22. Test reading speed and text windows

English dialogue boxes may be sized for short sentences. Translated text can be longer or use different wrapping conventions.

On a small project, Capture long and short lines at target resolution, including large-text settings if offered. Review pauses, scrolling, overflow and the player’s ability to dismiss text. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Clipping the last word of a direction can change what a player does. Treat readability as part of functional correctness, not visual polish. Check the full path from source data through language selection to the running interface. A file may contain the right phrase while a cache, scene property or compiled artifact continues to display an older version. Name the exact location and build when reporting a discrepancy.

23. Validate installation and translation discovery

Builds, zip archives and installers may place resources in different directories than the editor expects. A language that works locally can disappear after packaging.

To make this operational, Unpack the deliverable into a clean directory, launch without developer paths, inspect file presence and switch through every advertised language. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Do not accept a screenshot from the author’s computer as deployment proof. The release package must contain the right compiled resources in the right place. Treat author intent and player behavior as separate checks. The original author should confirm the meaning, while a target-language reader should explain what action they expect to take. Agreement between those two observations is stronger evidence than a word-for-word comparison.

24. Review accessibility and tutorial cues

A player may rely on subtitles, contrast, cursor instructions or the ability to repeat a clue. These features remain important in every language.

In the working story, Ask a reviewer to complete the first room with limited audio and another to read the interface at reduced resolution. Verify that warnings and hints still make sense. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

Translation quality includes the ability to act on instructions. A beautifully localized phrase hidden by animation or low contrast does not help the player. When several languages are supported, repeat the same state and control sequence in each one. A translation should not change hidden game values or which choices are available. If the text is deliberately adapted, record why the player’s understanding remains equivalent.

25. Build traceable acceptance evidence

The final approval should connect a source revision, TRS file, TRA compilation, game executable and completed player journey.

For a practical first pass, Record one representative screenshot and outcome for each critical puzzle, supported language, platform and delivery route. Keep reviewer notes tied to the build hash. Start with one identifiable screen, scene, file or dialogue line rather than changing the entire project. Keep a short record of the input, the selected language, the expected player response and the result you actually observed. This creates a reproducible test of the decision rather than a subjective impression that the words sound good.

A general statement that language QA passed is not sufficient if a user later reports a wrong clue. A traceable record lets the team identify the precise affected release. The editorial review should ask what a reader will infer at precisely this moment. Check the surrounding scene and whether the text introduces a new fact or a new obligation. A translation that reads smoothly in isolation can still give the wrong instruction during play.

A practical review of three complete player journeys

1. The first five minutes

Open a clean build of the Adventure Game Studio project with no saved preferences. Invite someone who reads the target language but does not know the game’s source dialogue. Ask them to select a language, interpret the opening instruction, navigate the first choice and describe what they believe just happened. Observe hesitation rather than correcting it. Record the wording, the corresponding program state and whether the player reached the intended destination. If the test fails, distinguish an inaccurate sentence from an inaccessible control or missing language resource.

Pass when the reader can identify the language, perform the first meaningful task, understand the result and return to the menu without coaching. Keep the exact steps, language, expected action, screenshot or excerpt, and source revision in the review record so another tester can reproduce the journey.

2. A consequential decision

Use the central decision in a point-and-click coastal observatory mystery in which players read museum labels, question a harbour keeper, examine a lighthouse diagram and decide how to repair a radio. Create two controlled test states that differ in one relevant flag or variable. In the source and target languages, present the same available options and ask the reviewer to predict the consequences before choosing. Then execute the action and compare branch destinations, values, explanations and later references. Review whether any option sounds mandatory when it is actually tentative, or harmless when it carries a cost.

Pass when the translated choice communicates the same commitment and the same intended state transition, even where sentence structure is different. Keep the exact steps, language, expected action, screenshot or excerpt, and source revision in the review record so another tester can reproduce the journey.

3. Failure, recovery and returning later

Begin from a previously saved session shortly before an error or blocked action. Resume in the target language, read the warning, take a recovery route and complete the next scene. Where the design permits language switching, repeat the transition once during the same session and look for stale captions, audio or labels. Finally reinstall or reload the distributed build in a clean profile to verify assets do not depend on an editor-only path.

Pass when the player recovers without losing the intended state, can interpret every critical warning and sees the promised language in the actual release. Keep the exact steps, language, expected action, screenshot or excerpt, and source revision in the review record so another tester can reproduce the journey.

Adventure Game Studio troubleshooting: symptoms, causes, repairs and proof

1. Language is selectable but still English

The compiled TRA may not be present, loaded or associated with the selected name. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Inspect the release folder, call or select the expected translation and test one source line known to have a nonblank target. Confirm the visible game language in a new clean launch, not from an old cached test. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

2. A clue shows the wrong translation

TRS source-target line pairing or source text matching may have drifted. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Compare the edited TRS against its source-generation version and restore any missing structural blank lines. Replay the clue before the puzzle is solved and confirm that it points at the intended object. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

3. The game fails when formatting a line

Percent placeholders were altered in translation. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Compare token types and positions with the original; restore required placeholders in the documented order. Exercise the line with several real values rather than only one sample. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

4. The game shows missing glyph boxes

The selected font lacks the required characters or script support. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Identify the exact missing Unicode characters and test a font with appropriate coverage. Read a complete accented or non-Latin sentence in the packaged release. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

5. A sign remains in English

The words are embedded in artwork rather than an extracted AGS string. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Create a localized texture or provide a clear accessible alternative. Check the rendered room from the same camera and interaction position. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

6. A button fits in English but not German

The layout assumes short labels. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Allow wrapping or adjust control dimensions while preserving clear hit targets. Test longest approved labels at small and large game windows. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

7. A language switch claims success but did not change

The requested translation stem may be unavailable or the return status ignored. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Validate Game.ChangeTranslation’s result and show an honest recovery message. Repeat from a fresh save and confirm both the menu and dialogue change. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

8. A saved game loses a puzzle state

Game-state code, not translated prose, is being altered or tested differently. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Compare inventory and flag values across the language transition; remove localized strings from state comparisons. Restore identical saves in both language settings and check state equivalence. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

9. An audio line finishes before subtitles

Localized text length changed without timing or playback review. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Review subtitle dwell duration, pause behavior and audio policy. A reviewer must read the complete line during normal play. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

10. Translation works in editor but not on another PC

A packaging or path dependency omitted compiled language resources. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Install from the actual release archive into a clean machine or profile. Check every language without relying on a developer filesystem. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

11. An update loses earlier translations

Source text changed and translation files were not updated in a controlled way. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Run the editor’s update workflow, diff changes and reacquire approval for altered puzzle clues. Revisit a previously translated scene and new scene in one regression session. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

12. A menu is unreadable to a first-time player

Language selection labels depend on knowing the default language. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Use recognisable language names and preserve an accessible route back to the default. Have a non-default-language reader set the game up without assistance. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

13. A hint becomes a spoiler

Translation increased specificity beyond the source’s intended clue. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Explain the puzzle’s evidence boundary and revise the target line with a gameplay tester. Watch an unfamiliar reader solve the puzzle at the intended stage. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

14. A localized build advertises more than it offers

Partial fallback and missing art have been treated as completed translation. Start by checking the actual user-facing state and locating the last point where the correct translation or correct branch was observed. This distinction matters because a linguistically sound target sentence may not have been selected by the runtime at all.

Publish an honest coverage matrix listing chapters, subtitles, UI, images and voice separately. Confirm that the public release description matches the installed language edition. Record the precise locale, screen or story position, build identity and whether the defect reproduces after a clean start. A correction is accepted only when the relevant player action works, not merely when an editor warning disappears.

A language-quality testing matrix that goes beyond string counts

Meaning and decision

Review a direct instruction, a tentative request, a refusal and a consequential choice in a point-and-click coastal observatory mystery in which players read museum labels, question a harbour keeper, examine a lighthouse diagram and decide how to repair a radio. Ask a native-language reader to paraphrase each action before execution. Similar words are not required, but the degree of obligation, knowledge and risk must remain accurate.

For acceptance, record the exact test state and its observed result. Separate linguistic defects from interface faults, stale data, missing assets and changed gameplay. These distinctions tell the team who should repair the issue and whether the next release must be blocked.

State and branch parity

Capture a small set of authoritative game-state values before and after important choices. Confirm that language changes the presentation, not the action’s hidden effect. Where a local adaptation intentionally changes puzzle design, treat it as a tested product variant rather than an unrecorded linguistic correction.

Typography and device behavior

Use the longest approved target-language menu label, a phrase with accented or non-Latin characters, a number embedded in prose and punctuation at the end of a line. Test actual fonts, direction, wrapping, focus and readability on supported devices.

Missing translations and fallback

Select one deliberately missing noncritical string in a test build and confirm the declared fallback. Confirm that missing critical warnings and options are reported as release blockers. A visible English fallback should never be counted as a completed translation.

Release packaging and accessibility

Install from the same artifact the public receives. Repeat the first meaningful interaction without editor data or local caches, then test keyboard and touch navigation as appropriate. Use a reader who can report confusion, not only a script that sees successful file loading.

Four-week Adventure Game Studio localization and validation plan

Week 1: source map and controlled scope

Inventory all extractable dialogue, menus, GUI properties and image text; establish a baseline English playthrough and export one TRS without modifying the published game.

The week’s exit test is an actual player journey with a named source version and target language. Capture what passed and what remains incomplete. Keep the scope small enough to review fully; adding a language name to a menu is not a substitute for tested comprehension. The plan should be adapted to the team and game’s scale, not treated as a promise that every project can finish in exactly four weeks.

Week 2: first complete target-language experience

Complete one representative language file, validate placeholders and source pairs, compile TRA and conduct a translator-led review of the first two rooms.

Week 3: coverage, variation and repair

Localize menus and remaining scenes, fix font and image-text gaps, and replay branching puzzles with newly recruited reviewers.

Week 4: release proof and maintenance

Ship only after clean-package installation, save/restore, language switching and failure recovery pass; archive the exact source, TRS, TRA and test reports.

Adventure Game Studio localization: frequently asked questions

Does AGS translate my game’s dialogue automatically?

AGS replaces recognized game text with values supplied in compiled translations, but a person still creates, checks and maintains target-language wording. Images, custom dynamic text and audio often require separate work. Treat automatic replacement as a delivery mechanism, not a translation service.

For this particular project, the best next step is to test the answer against the real scene and release configuration. Preserve the source meaning and verify what the player actually experiences rather than relying on a file existing or a setting appearing in an editor.

What is the difference between TRS and TRA?

A TRS file is the editable source-to-target translation document generated and maintained through the editor. A TRA file is the compiled translation artifact used by the game. Keep both so future changes can be reviewed and released again.

Can players switch languages without restarting?

Runtime switching is available through Game.ChangeTranslation, subject to the game’s implementation and available translation files. Make the interaction reversible and verify that already-visible interface elements update as intended.

Why do placeholders matter?

Formatting tokens are consumed by code when values are displayed. Changing their count, types or order can produce incorrect output or a runtime fault; use a placeholder manifest and test actual values.

How should translators deal with wordplay?

Ask what the clue must allow the player to infer, document the correct object or action, and seek an equivalent playable clue. Preserve the intended difficulty and do not expose undiscovered information.

Do I need a different font for every language?

Not necessarily. One typeface may cover several languages, but some writing systems need additional glyph coverage and rendering checks. Confirm the actual target sentences in the running build before making support claims.

What if only some rooms are translated?

Use a clear fallback so the game remains usable, but maintain a coverage list by room, menu, art and audio. Do not describe a partial edition as complete.

How do I update translations after new dialogue?

Use a controlled source-version workflow and the editor’s update feature, then review new entries and any old entries whose meaning changed. Compile and retest the complete deliverable.

Primary documentation and further reading

These are technical starting points rather than substitutes for version-specific testing. The workflow above combines the documented behavior of Adventure Game Studio with editorial and release practices. Always confirm features against the actual version of the game engine or library that will ship.

For the broader principles of transferring meaning across languages, see Master Art of Translation: The Complete System. For other tool-specific implementations, use the Translate Like a Pro series index. This guide focuses on Adventure Game Studio projects; it is not a substitute for general literary translation advice or unrelated language-learning articles.

Final release standard: a player can understand, decide and recover

The purpose of localization is not to increase the number of entries in a file. A successful edition lets a reader choose a language, understand a meaningful situation, make the intended decision and recognize its result. For Adventure Game Studio, that requires text, resource identities, program logic, rendering and delivery to agree. Maintain honest coverage records, preserve the author’s intentions and repeat the same player journeys after changes.

Translate Like a Pro | 7030 — Adventure Game Studio TRS/TRA Translations, Fonts, Runtime Language Switching and Build QA