A GameMaker localization workflow becomes faster when the team stops translating text inside unrelated objects and begins translating one controlled set of game strings. If you are searching for how to translate a GameMaker game, add multiple languages in GML, or test GameMaker JSON translation files, the first practical step is to separate what the player reads from the code that decides what happens. That separation changes a translation job from a risky search-and-replace exercise into a repeatable release process.
The important question is not whether a French or Japanese sentence sounds good in isolation. It is whether the correct sentence appears at the correct moment, in the correct font, with the correct variables, after a player changes language and returns to a saved game. A translation can be linguistically excellent yet be unusable because the rendering system cannot display its characters, a dialogue box clips the last word, or the game still caches English text in one room.
This guide explains a platform-specific approach for GameMaker projects using GML. It distinguishes the language of the GameMaker editor from the language of a game built in GameMaker; treats JSON as one practical storage choice rather than a magical built-in localization engine; and gives translators, developers and testers a shared method for checking results. The dominant task is to make a working multilingual game text pipeline dependable. General advice about why translation matters belongs elsewhere.
The mechanism: a player action becomes a localized string
Imagine a player opening a pause menu. The game’s state says the pause menu is open; the view says it needs to draw a label; the localization layer receives a stable key such as menu.resume; the active locale chooses the target value; the drawing layer displays that value with a suitable font. Nothing about the pause action itself needs to know whether the label reads “Resume,” “Reanudar,” or “Reprendre.” That is the useful boundary. The game logic owns actions. The localization layer owns human-readable wording.
A quick but fragile implementation puts draw_text(x, y, "Resume") in a drawing event and changes the source line for each market. A better implementation asks for tr("menu.resume"), where tr is a project-defined lookup function, not a claim about a GameMaker built-in function. This difference looks small until the game contains hundreds of UI screens, quest prompts, item descriptions and branching dialogue lines. Then a central lookup lets the translator edit target values without touching collision rules, inventory code or event order.
There are still moving parts to control. The lookup must know which language is active, which file or data structure contains the values, what happens when a key is missing, and whether the text needs arguments. The view must know how to measure and wrap the returned string. Persistence must remember the player’s setting. QA must test those mechanisms together rather than auditing the JSON file alone.
A useful responsibility map has five columns: key ownership, source meaning, translated wording, runtime lookup, and rendered result. A bug should point to one of these columns. If a menu shows a key name instead of words, suspect lookup or loading. If it shows correct words as empty rectangles, suspect the font. If clicking “Quit” opens Options, suspect the code-to-label mapping. A good pipeline helps you identify the kind of failure before you spend time changing unrelated text.
Distinguish IDE translation from translating your own game
A common search result describes changing the language of GameMaker itself. That is not the same problem. GameMaker documents how users can change the editor and manual language, and the company maintains contributions to those interface translations. Those files and preferences do not automatically localize a game you have designed. They affect the developer’s workspace, not the strings in the game’s rooms, sequences and objects.
For the game, the developer must choose an architecture or integrate a library. You can write a lightweight lookup function over parsed JSON, use a CSV-oriented community tool, or build translation resources around another workflow. Each choice has trade-offs. A simple in-house JSON table may be enough for a short puzzle game. A large story game may benefit from context notes, translation memory, dialogue identifiers and a review system. The correct test is not “Which option has the cleverest name?” It is “Can the team add a language, change a sentence, test the visible result and recover from a missing key without an unplanned code rewrite?”
This distinction also matters to translators who receive mysterious folders named Languages. Ask whether the files are editor localization files, project included files, exported translation tables, or build artifacts. Never overwrite the source game project because a generic tutorial said that a language directory exists. Identify the actual runtime resource path and the person responsible for exporting it.
Inventory every place GameMaker can show player-facing words
Begin by playing the game, not by translating a spreadsheet. Walk through the title screen, settings, pause menu, achievements, tutorial, inventory, quest log, dialogue, cutscenes, input prompts, error notifications and the end screen. Record where each visible phrase comes from. In GameMaker, text may be drawn in an object’s Draw GUI event, stored in arrays, embedded in dialogue structures, emitted by sequences, written into surfaces or assembled dynamically at runtime. A search for quote marks in GML is helpful but not complete.
A translation inventory should identify each phrase’s key, source text, screen, character or speaker, allowable length, variables, relevant screenshot, and whether the phrase is a button label or prose. Button labels need brevity and unambiguous actions. Dialogue needs voice and continuity. Tutorial text needs to match the action the player actually performs. A phrase such as “Charge” means very different things on an ability button, on a billing screen, or in a story line about running towards an enemy. A key without context can make three competent translators produce three incompatible results.
Treat text embedded in images as a separate asset task. A translated JSON entry cannot alter an English sign painted into a sprite. Similarly, subtitles baked into video or pre-rendered cutscene art require their own asset source and approval path. Record fonts and sprite-font use because some glyph sets are static. The inventory is not bureaucratic overhead: it prevents the typical late-stage discovery that every menu translated correctly but half the tutorial remained inaccessible in another language.
Before any target-language work, agree which texts are not to be translated: usernames, developer commands, save identifiers, product codes, and certain canonical item names. Do not assume “looks like a word” means “safe to translate.” The goal is to build a reliable boundary between language and game data.
Design stable keys that survive copy edits
A good key identifies what a message does, not merely what it currently says. menu.resume remains useful when English changes from “Resume” to “Continue playing.” By contrast, a key literally named Resume breaks conceptual separation. It may also tempt developers to use the English phrase itself as a lookup identifier, making normal copy edits expensive. Group keys around durable interfaces: settings.audio.title, quest.harbor.accept, dialogue.guard.warning_01. Keep names consistent and documented.
Do not make keys so generic that they erase context. Two screens can both say “Back” in English while requiring different grammatical forms in another language. One returns to the previous page, another retreats from a battle. The safest decision is to reuse a key only when the underlying meaning, action and register are intentionally shared. Repetition alone is not proof of identity. This is especially important for translators who see repeated source strings and assume the same target should be auto-propagated everywhere.
Choose whether your JSON will be nested or flat. Nested values make human browsing comfortable; flat keys may simplify some diff and export workflows. A small sample might contain a menu object with play, resume and quit values. Whichever structure you choose, preserve its types. If one language has a string at menu.quit and another accidentally has an object there, a lookup may fail even when the JSON parses successfully. Never let translators rename identifier keys without a coordinated migration.
Document the missing-key behavior before translation starts. Options include showing the source-language value with a conspicuous QA marker, logging the missing key, or stopping a test build. In a public release, a safe visible fallback may help players continue. In QA, silent fallback can conceal a whole screen of untranslated text. Use separate development and production policies rather than relying on luck.
A small JSON language table that people can read
Suppose a game has two locales and four strings. Store target values in project-controlled data files with identical keys. The following simplified tables illustrate the principle; the directory layout and loading code are decisions of the project, not a universal GameMaker convention.
{
"menu": {"play": "Play", "resume": "Resume", "quit": "Quit"},
"hud": {"lives_remaining": "Lives remaining: {count}"}
}
{
"menu": {"play": "Jugar", "resume": "Continuar", "quit": "Salir"},
"hud": {"lives_remaining": "Vidas restantes: {count}"}
}
What stays fixed? The property paths and the placeholder name {count}. What changes? The player-facing values. What still needs engineering? Loading the correct file, resolving nested property paths, substituting a count safely, and updating the view. JSON alone does not provide plural rules or define how the placeholder will be replaced. That behavior belongs to the project code or a suitable library.
In GML, json_parse can turn a JSON string into data that includes structs. The GameMaker manual explains these conversions and the difference between parsing and serializing. The sketch below is deliberately limited to an already-loaded string and a simple nested object:
var table = json_parse(raw_json_text);
var button_caption = table.menu.play;
show_debug_message(button_caption);
This is not a complete multilingual system. It demonstrates a narrow, testable piece: structured text becomes an accessible value. A production lookup needs key validation, fault handling, missing-locale behavior and perhaps variable access through variable_struct_get for dynamic property names. A good implementation earns trust by separating those concerns instead of hiding all of them behind one enormous event.
Loading files without confusing paths and platforms
Loading is where many apparently correct tables disappear. A project may work during local testing but fail after packaging because the translation file was not included, because a path resolves differently on the target platform, or because an asynchronous load completes after a screen has tried to render its labels. Treat file availability as a separate QA gate. Verify that every expected locale is present in the shipped build, not merely on the developer’s machine.
There are several legitimate approaches. A small fixed-language project can bundle data with its game. A product that updates translation content after release may use a controlled external pipeline. A mod-friendly game might read user-provided files, which creates additional validation and security responsibilities. Do not assume operating-system file access is identical in desktop, HTML5, mobile and console exports. The development environment, sandboxing, package contents and runtime permissions can differ. Consult the GameMaker file-handling documentation for the versions and platforms actually being shipped.
Create a loading contract. When a player selects es, the loader chooses the approved Spanish file, parses it, validates required top-level properties, caches a table or lookup access, and only then announces that the new locale is ready. If parsing fails, keep the last known good table and present a recoverable message. Do not replace a functioning menu with an empty screen because one target file had an extra comma. Record a diagnostic that identifies the file and line when possible; a generic “translation failed” warning is hard to act on.
A useful smoke test deliberately removes one file from a private test build. Does the game still start? Does it expose a clear failure? Can the player recover and change back to English? A reliable product makes failure visible to its team and survivable for its players.
Switching language is an event, not a replacement operation
Players often expect language changes to apply immediately in a settings screen. This expectation produces a chain of implementation tasks. The selected locale must be stored; any translation resources needed by that locale must be available; visible UI elements must refresh; and screens that cache rendered text or precompute word wrapping must invalidate their cached results. Changing a variable such as global.language is necessary in some designs but is not by itself proof that every displayed string has updated.
Consider a pause menu with three buttons, a subtitle already on screen, and a quest list generated when the room started. If only the pause menu draws its captions through a fresh lookup each frame, it may switch while the quest list remains in English. A team can avoid this by agreeing which components resolve translation at draw time and which components listen for a language-change event. The latter rebuild their displayed labels when the event fires. Both patterns can work; mixing them without documentation creates confusing partial refreshes.
Test language switching from awkward states. Switch while dialogue is open, during a tutorial step, after loading a save, and after returning from an options submenu. Confirm that controller focus and button actions do not reset inadvertently. The player chose a display language, not a new game. Do not accidentally delete quest state or restart a room merely to update strings. Save the locale separately from story variables unless the product intentionally treats language as save-specific.
When the new locale is not available or fails validation, use a fallback policy that can be explained in one sentence. A clear, recoverable result is better than a half-translated menu whose behavior is impossible to predict.
Placeholders: protect the parts that are not ordinary words
A HUD message often contains a number, player name or item title. Translators should edit the sentence around those values, not turn the values into fixed words. Consider You found {item}. A Spanish version may place the message differently and must still accept any supported item name. The project must distinguish placeholder tokens from natural language and enforce that all required tokens survive translation.
Named placeholders are easier to review than mysterious positional numbers, but they still need a substitution engine. If you choose {count}, define escaping rules for literal braces and whether the formatting function can insert arbitrary player-provided strings. If you use format specifiers supported by a chosen library, test its grammar rather than assuming one placeholder syntax works everywhere. Do not make translators guess whether %1, {0}, %s and $item are interchangeable; they usually are not.
Run a placeholder-set comparison before building: the source and target of a message should usually expose the same required tokens. But matching token sets is not enough. Their order may change, and some languages require different sentence structures depending on the count or grammatical category of the inserted name. For a message like You have {count} key(s), avoid the English shortcut of putting an s in parentheses. It is unnatural in many languages and cannot model plural categories reliably.
Create a test fixture with difficult values: zero, one, two, a large number, a very long nickname, a name containing an apostrophe, a name written in another script, and an item title wider than the expected box. The fixture demonstrates whether the localized template can handle real player data without changing gameplay.
Plural language is a game-system concern
English commonly distinguishes “one life” from “two lives,” but its neat one-versus-other model should not become the architecture of a multilingual game. Languages differ in plural categories, agreement, numeral construction and whether a numeral even calls for the same noun form. The localization designer must decide how messages select variants, using locale-aware rules rather than an English string concatenation trick.
Imagine the message 1 enemy remains and 2 enemies remain. A brittle implementation appends an s and assumes all target languages behave the same way. A sounder design gives the translator complete patterns or branches and lets the application choose the correct branch using appropriate plural categories. The exact storage schema is project-defined; it may be a nested object containing variants, or an implementation of an established message-format standard through a library. The important point is that a translator gets grammatical control over the full sentence.
Avoid flattening every problem into a universal template. A mission status line might instead be rewritten as “Enemies remaining: {count},” which can simplify some languages, but not all contexts permit that stylistic change. Dialogue from a character should sound like dialogue, not a spreadsheet label. Test variant selection for more than the familiar values one and two. At least sample zero, one, two, several small numbers and a large value for each target locale, then check the exact grammatical requirements with a qualified language reviewer.
Localization QA is not just a file-parity check here. It needs a language-aware test matrix. A result that displays without a runtime error may still violate the target language’s grammar and player expectations.
Font coverage, shaping and sprite-font traps
You can have perfect translations in JSON and still show squares or question marks on screen. GameMaker projects often control fonts deliberately, and some games use pixel fonts or sprite fonts for their visual identity. A Latin-only glyph range may not contain Japanese kana, Chinese characters, Cyrillic letters or accented characters. Other scripts require shaping and text behavior that cannot be assessed by character count alone. Font selection is a technical localization decision, not a cosmetic flourish to leave until the last day.
Build a font coverage matrix by locale and UI component. For each language, list the actual font asset or rendering method used for menus, HUD, dialogue, chat-like text, achievements and cutscenes. Test representative strings containing digits, punctuation, diacritics and the script’s less common characters. Do not infer full coverage because one screenshot of a greeting looks right. A missing glyph may appear only in an uncommon item name or a late-game character’s line.
Text measurement and line wrapping also depend on the font and the visible text. A string can fit at one size and overflow when bolded, scaled or displayed on a narrow viewport. Do not simply shrink every translated label until it fits. That can harm legibility, especially on small devices. Prefer flexible containers, meaningful line breaks and carefully localized short labels where the design allows them. Preserve controller prompts and icon alignment.
For languages needing bidirectional or complex-script support, assess the actual export target and renderer early. Do not promise that a font file alone resolves every shaping or direction issue. Make a small scene with the toughest representative strings and test it on devices that resemble the release environment. That small experiment is cheaper than translating a thousand lines into a display system that cannot render them correctly.
UI layout QA: verify what the player can do
The reason to localize a menu is to help the player choose an action. That makes interaction the main acceptance test. A button labeled “Continue” must still activate the continuation action after translation. If a long target label overlaps another control or a text box covers a controller hint, the game has lost usability even when the words are accurate. The tester should record a screenshot, the active locale, the view dimensions and what the player attempted.
Start with fixed elements: main menu buttons, dialogue choices, settings toggles, tooltips, quest cards, small notification banners and achievement pop-ups. Repeat tests at the narrowest supported viewport and at the expected UI scale. Check full-word clipping, awkward wrapping, text against backgrounds, baseline alignment, and whether focus highlights still surround the correct button. A phrase can be grammatically excellent and too long for a timed choice panel. Treat that as a design issue first, then consider a context-appropriate shortened form with translator approval.
One useful practice is a screen atlas: for each key, store at least one screenshot of the component in context. The atlas makes both translation and review faster because a reviewer can tell whether “Fire” is a weapon command, a status hazard or a dismissal instruction. Screenshots are evidence, not decoration. Include the screen state needed to reproduce them.
Avoid a common false fix: reducing the entire font size for one language without checking other screens. A quick local patch may solve a title button and make all dialogue harder to read. Track constraints by component and let the game design absorb predictable variation where possible.
Dialogue and branching choices need context preservation
GameMaker projects range from arcade games with a dozen prompts to narrative games with thousands of dialogue lines. In the latter, a translator should never receive only a column of disembodied sentences. A choice such as “Fine.” may express approval, irritation or resignation. The preceding line, speaker, emotional intention and downstream consequence influence the correct target phrase. The localization inventory should connect a dialogue key to that context without making passage order depend on text content.
Use durable dialogue IDs for each utterance and choice. A line identifier should remain stable as its wording is edited, provided the narrative event is still the same. When meaning changes substantially, flag the line for retranslation instead of silently reusing an old target. If the game has gendered or variable dialogue, explain the available speaker and player-state variables to translators. Do not hope that English ambiguity will survive every target language.
During review, walk complete branches, not just individual screens. Confirm that the choice labels correspond to the actions and outcomes they trigger. A translation that reverses “Accept” and “Decline” is a game-breaking error. A phrase that makes a character sound suddenly formal after several informal exchanges is a continuity error. Both matter, though their severity differs. Build narrative test paths that intentionally hit uncommon conditional dialogue and late-game callbacks.
If the story includes text revealed one character at a time, test how that system treats combined characters, line breaks and user-perceived characters. A typewriter effect that slices raw bytes or code units may show broken glyphs. Refer that to the rendering implementation; do not fix it by corrupting a valid translation.
Save files, achievements and persistent language preferences
A localization project is incomplete if the game forgets the player’s language on restart. Design and test where that preference lives. It might be a configuration record that is independent of saved adventures, or it might be attached to a profile in a multi-user game. The choice should match the product’s user experience. In either case, changing locale must not rewrite gameplay state or alter stable IDs.
Save files should generally store identifiers and values that remain meaningful across languages, not translated labels as if they were canonical database keys. Suppose the inventory stores the string Healing Potion and uses it to identify an item. After switching to Spanish, the visible label becomes Poción curativa; if game logic expects the English name, the item can become disconnected from its function. Store something like item.healing_potion as identity and resolve the display name only when presenting it. That separation also protects old save files against editorial changes.
Check achievements, platform overlays and externally supplied interface text as separate surfaces. Some labels may be managed by a storefront or platform account rather than by the GameMaker build’s JSON. Document which owner edits each surface and how it is reviewed. Do not claim a successful in-game language test covers every listing or notification outside the game.
Build a persistence regression: choose a target language, change graphics or audio options, save progress, restart, load, navigate to another room, and confirm both the language and the original progress remain intact. Then update the translation resource file and repeat with an older save. These tests expose bugs that isolated translator previews never see.
Worked example: a multilingual pause menu release
Take a small fictional game, Lantern Harbor. It has three pause buttons, two HUD indicators and one dialogue choice. The developer’s first inventory finds seven translatable values and one dynamic variable, {count}. The team assigns keys under pause, hud and dialogue. The English source file defines each value. The Spanish target file mirrors all required keys and contains reviewer-approved wording. Before testing style, the developer writes a validator that detects missing keys and placeholder mismatches.
During the first run, the Spanish Pause screen shows “Reanudar,” “Opciones” and “Salir.” The labels look correct, but the QA tester notices that “Salir” closes the entire game, while a player might reasonably expect to leave the pause menu. The defect is not an incorrect translation in isolation; it is missing product context. The team renames the source label to “Quit game,” preserves its key only if the underlying action is unchanged, and updates the Spanish target to a phrase that makes the destructive scope clear.
A second defect appears in the HUD at {count}=1. The sentence uses a plural noun because the project simply replaced {count} and selected no number-dependent form. The fix is to introduce a proper variant strategy for that message, not to append an English-style suffix. A third defect occurs on a 720-pixel-wide view: the longer dialogue choice overlaps the confirm icon. The interface gains flexible width and a wrapping rule; the translator checks that the line break has not damaged meaning.
Finally, a reviewer changes language while the pause menu is open. Two buttons update and one stays in English because its text was cached during room creation. The developer adds a refresh hook for that component. This sequence shows why translation speed comes from identifying system boundaries early: each failure has an owner and a durable fix. Retyping labels in more places would only multiply the chance of repeating the error.
Automate what can be checked without interpreting meaning
The quickest safe translation review is two reviews layered together. A machine checks structural properties. A human checks meaning in context. For GameMaker JSON, a lightweight preflight can parse every locale file, compare expected key sets, confirm that required values are strings, compare placeholder sets and flag unexpectedly empty values. It can also warn about duplicate keys in the original source text before ordinary JSON parsing hides one by overwriting another. These are measurable properties and should not consume hours of manual review.
Do not overstate what automation has proved. A key-parity pass does not tell you whether a French imperative suits a button, whether Japanese dialogue respects character voice, or whether a warning sounds urgent enough. Conversely, a fluent human reader may overlook an invisible escape or a missing key. The layers complement each other. Record which tests were performed, what they covered and which issues remain open.
Useful QA reports are short and actionable. “es: missing quest.harbor.accept” is better than “Spanish translation incomplete.” “hud.lives_remaining: missing placeholder {count}” is better than “formatting issue.” Include source file, key, target locale, severity and the path to reproduce a visible bug. Reviewers should be able to close an issue by making one specific edit and rerunning the relevant test.
Prioritize the release-critical paths: main menu navigation, keybindings and control guidance, irreversible choices, safety or age-related notices, then the large body of descriptive copy. A smaller test set that covers core actions is more valuable than a large list of unverified screenshots.
Failure modes that waste the most time
The first recurring failure is hard-coded text that escapes extraction. The game looks mostly translated but flashes English in rare states. The remedy is to maintain a text inventory and periodically scan new feature changes for visible literal strings. The second is key drift: a developer renames an identifier while the translator keeps the old name. The remedy is stable-key governance and a diff that identifies new, changed, removed and missing IDs.
The third is file-format breakage. A target translator edits a JSON file with a trailing comma or the wrong encoding, and the build fails or silently falls back. Protect the source format with editor guidance and automatic parsing on every import. The fourth is font failure, visible as boxes or inconsistent glyphs. Solve it by testing actual fonts and renderers before committing to a target locale. Do not ask translators to replace valid characters merely because a font lacks them.
The fifth is partial locale switching: some UI components render fresh values while others retain cached text. Fix the refresh architecture. The sixth is false confidence from fallback strings. A screen appears legible because English is displayed, but no Spanish value was loaded. In QA, expose the fallback clearly and count it. The seventh is publishing the wrong resource file. A team may revise Spanish locally but package last week’s file. Attach locale file hashes or release identifiers to test builds and check them in the final package.
Each failure suggests a diagnostic question. Is the key in the source inventory? Is it in the target file? Does the application load the file? Does the lookup return the expected string? Can the font render it? Does the screen display it within constraints? Can the user act correctly? Test in that order and the debugging process becomes much faster.
Build a testing matrix that reflects real player routes
A useful QA matrix has four dimensions: locale, platform, gameplay state and UI surface. Testing every possible combination may be unrealistic. The team should therefore choose representative high-risk intersections and make them explicit. For example, test Japanese dialogue on the narrowest mobile viewport, Spanish menu controls on desktop with a controller, and a new locale during save restoration. These are scenarios with different failure mechanisms, not arbitrary boxes on a spreadsheet.
For each scenario, record the source build identifier, target file version, expected behavior and actual observation. A tester should be able to reproduce a defect without needing the translator’s memory of how the line was worded. When testers find linguistic issues, ask them to capture the surrounding two or three lines, not only the target sentence. This supports a proper edit and prevents contradictory corrections in adjacent dialogue.
Include a deliberate negative test: a removed key, malformed target file or unavailable target font in a private build. The test answers whether the game degrades safely and logs the cause. Include a positive end-to-end test: choose language, play tutorial, save, reopen, continue and finish a representative mission. Real player journeys are where independent layers meet.
Plan sign-off responsibilities. Engineering owns parser and runtime correctness; localization owns linguistic meaning; game design owns whether labels accurately describe actions; accessibility review owns legibility and usable controls; release management owns the packaged artifacts. One person can wear several hats in a small studio, but the questions must all be answered.
A release checklist the team can actually finish
Before inviting translators, confirm that the source file is frozen for the release window or that changes are traceable. Confirm that every player-facing string has an ID and context. Confirm that the extraction excludes code and persistent state identifiers. Check that the chosen language files parse cleanly and use a documented encoding. Confirm key parity and protected placeholder handling. Walk one fully localized route for each locale and test language switching in at least one nontrivial screen.
Then test typography. Open real builds on target devices or representative environments. Check glyph coverage, line wrapping, UI scaling, dialogue speed and any on-screen key prompts. Verify that button actions match their translated labels. Load an older save, change locale, restart, and confirm no progress is lost. Ensure the build packages exactly the files reviewers approved, not stale copies. Keep screenshots of major exceptions and a small list of unresolved issues with explicit owners.
Finally, decide what happens after release. New features add strings, and old strings change. Treat localization as a versioned product dependency, not a one-time folder handoff. A good release notes which locale tables belong to which build and how a missing translation will be detected in the next update. When defects appear in player reports, the team should map them back to keys and scenes rather than searching the whole project for an English phrase.
The reward is practical: the developer can change copy without editing every object; the translator can review wording without risking gameplay logic; and the tester can identify whether a failure belongs to data, loading, display or meaning. That is what quick translation should mean in a GameMaker project.
Transfer: use the same reasoning outside GameMaker
This method transfers to another engine because its core boundaries are universal: durable identity, localized value, rendering context, fallback behavior, and release verification. But do not copy the GameMaker file paths or GML examples into Unity, Godot or a web application and expect them to run. Those platforms own different resource formats, loaders and editor workflows. Transfer the questions, not the syntax.
When reviewing a new project, ask where its player-facing strings live, how a locale is selected, whether target placeholders are verified, what happens when a resource is missing, which components need refresh, and how finished builds are checked. A confident answer to those questions is worth more than a long collection of unrelated translation tricks. For engine comparisons already published in this series, consult Unity localization QA and Godot localization QA. Their formats differ, but the boundary between stable keys and displayed words remains important.
For a general treatment of how translation quality is managed across projects, continue to Master Art of Translation. For a deliberate stress test of layout and missing strings, see the published pseudolocalization guide. These links answer adjacent questions; they are not substitutes for a GameMaker-specific implementation test.
Frequently asked questions
Does GameMaker translate games automatically when I change the editor language?
No. The editor and manual language settings change the developer interface. Your project still needs its own player-facing translation resources and runtime lookup strategy. Begin with a list of the strings the game displays, then decide how target values will be stored, loaded and shown.
Is JSON the only way to localize a GameMaker game?
No. JSON is a practical, widely understood format and GML has documented JSON parsing functions. A game can use other supported data arrangements or a suitable localization library. The requirement is not a particular extension: it is stable identifiers, accessible context, predictable lookup and a reviewable export.
Can I translate keys as well as values in my JSON file?
Normally, no. Keys identify resources and connect code to data. Changing them independently in a target file can break lookup. Translate player-visible values. If a key must change, treat that as a coordinated identifier migration and validate all locales together.
What if my translated menu text is too long?
First inspect the UI constraint and whether the container can expand, wrap or use a different layout. If the design truly requires shorter wording, ask a translator to create a context-appropriate form and verify that the button’s action remains clear. Shrinking every font or deleting meaning is not a reliable default.
How should the game behave when a translation is missing?
Choose an explicit fallback, such as a known source-language string, and record the missing key for QA. In test builds, make fallback conspicuous; in player builds, prefer a controlled, recoverable experience. Silent fallback should not count as a completed translation.
Why do numbers and names need special translation checks?
They are dynamic parts of a sentence, not ordinary fixed words. Translators must preserve required placeholders, and the game must insert actual values safely. Plural patterns and language-specific grammar may require more than replacing {count} in an English sentence.
How do I test a language without translating the whole game first?
Build a small but representative slice: a main menu, a dialogue choice, a long tutorial prompt and a HUD number. Populate it with real target text or clearly labelled pseudolocalized text, run through switching and save restoration, and inspect fonts and layout. A successful slice validates the architecture before large-scale translation.
What should a GameMaker translator receive from the developer?
A keyed source table, target-locale list, context notes or screenshots, a glossary, placeholder rules, length-sensitive screens and a method for previewing target text. The translator should not have to reverse-engineer object events to find out what a sentence means.
How can QA tell whether a fault is technical or linguistic?
Check the chain in order: source inventory, translated table, file loading, key lookup, placeholder handling, font rendering and player action. If the correct value is shown but sounds unnatural or misleads the player, it is primarily a linguistic or context issue. If the correct value never reaches the screen, it is primarily a technical issue.
Does a successful desktop test prove the mobile release works?
No. Packaging, file access, viewport constraints, font rendering, input devices and platform overlays can differ. Run representative checks on each supported export target, especially for languages with different scripts and longer phrases.
Summary: make each translated string traceable
The fastest dependable GameMaker localization process is not a shortcut around review. It is a design in which every string can be traced from a stable key, through a validated language table, into the exact screen and action the player encounters. Use JSON if it suits the project, but do not mistake parsing for a complete localization system. Test language switching, dynamic grammar, glyphs, UI constraints and saved progress as real parts of the translation job. When a defect appears, a traceable pipeline gives the team a small place to fix it and a precise test to repeat.
For other practical workflows, return to the How People Translate Quickly series index.
Source documents and further technical reading
The platform-specific mechanics should be checked against the development version actually in use: GameMaker’s Guide to Using JSON, GameMaker encoding and hashing reference, including JSON parsing, and GameMaker’s IDE/manual language guide. A community-maintained option is Lexicon, a GameMaker localization system; study its own versioned documentation before adopting it. These are reading references, not endorsements or claims that third-party code ships with GameMaker.