RPG Maker MV/MZ language switch: everything that must react to it

An in-game language switch for an RPG Maker MV or MZ game is a runtime feature with its own checklist, not a matter of loading a different text file. Substituting the translated text is what a plugin handles. What decides whether the shipped game works is where the choice is stored, what happens on first launch, and which parts of the screen do not redraw on their own.

Those three points are where released games break: a save started in Japanese that opens with Japanese party names in English, an options menu still showing the old command names, empty boxes where Chinese glyphs belong. None of these are translation problems, and a translator cannot fix them.

This article covers the switch itself: where the setting lives, how to pick a default, what must react to it, how to test it, and what a store listing promises. Finding and extracting the text is covered in the article titled Localizing an RPG Maker MV/MZ game: where the text hides. If you are a player: the switch, when it exists, is normally on the title screen or in Options.

One build with a language setting, or one build per language

A language choice has two shapes: one build per language, so the player chooses by installing one, or a single build carrying every language with an in-game switch. Separate builds have no switch to get wrong, but every update has to be repeated in every copy, and the copies drift.

Most multilingual RPG Maker releases end up as a single build, where the switch is a feature you own. Text substitution is a plugin decision, covered in the article titled How to choose an RPG Maker translation plugin: the four approaches. The rest of this article assumes a single build.

Where the player's choice lives: with the options, never inside a save file

MV and MZ already have a home for settings that belong to the player rather than to a playthrough: the options data, handled by the core script object called ConfigManager. It holds the volume sliders, it is loaded at boot, and it is written back when the player leaves the Options screen. It sits alongside save files without being one: a file in the save directory for a desktop build, browser storage for a web build. The exact file name depends on the engine version and platform, so confirm it in the storage manager of the core scripts or the official documentation.

The language belongs there. It is a property of the player and the installation, like the volume, and most switching plugins add a key to that object. If you write your own switch, extend it the way the existing options are read and written.

It must not live inside individual save files, for three reasons. Text is looked up at display time, so a save records which item is in the inventory, not what it is called. A save has to open in whatever language the player has chosen now; if the language rides inside the save, loading flips it. And the title screen runs before any save is loaded, so a language kept in saves leaves it with nothing to go on.

One complication is an engine fact rather than a plugin choice: when a new game starts, the engine copies each actor's name, nickname and profile from the database into the actor object, and that object is what gets saved. A game started in Japanese therefore carries Japanese party names in every save, and switching to English later does not change them unless the switching plugin resolves those fields again on load. Check how yours handles this. Names the player typed into a name-entry screen are the deliberate exception and should stay as typed.

On first launch there is no options file, the language key is absent, and the engine falls back to defaults. That absence is the one moment for automatic detection. Detect only when the key is missing, write the result immediately, and never re-detect later; a switch that re-reads the system language at every boot silently overwrites the player's choice.

Choosing the default on first launch: what the game can detect and what it cannot

Desktop builds of MV and MZ run inside NW.js, a Chromium-based runtime, so the game can read navigator.language, which reports the language the runtime believes the operating system is set to; a browser build gets the browser's preferred language. That is the only automatic signal a plain RPG Maker game has. Match it against the languages you ship by prefix, so a regional variant still matches, and fall back to your source language otherwise. Chinese needs care: the region part usually separates Simplified from Traditional, so decide which variant each region code maps to and test it.

What the game cannot see is the language the player chose in the Steam client. Steam keeps a per-game language setting, but a plain RPG Maker deployment never calls the Steamworks API and never learns it. Reading it is possible but is separate work: integrating Steamworks is the usual route, and Steam also documents a launch-option parameter and a per-application registry value. Check the Steamworks documentation for which fits your build. Until then, a player with a Japanese operating system who runs Steam in English gets Japanese, and changing the game language in Steam's properties does nothing.

Because detection can be wrong in both directions, what follows is guidance rather than engine fact. Always offer a manual switch, reachable from the title screen as well as from Options, because a player who cannot read the language they landed in cannot navigate a menu to find the setting. For three or more languages, consider a prompt on first launch, before the title screen, with each language written in its own name; save the answer at once and never show the prompt again unless asked. Do not use flags as labels; they name countries, not languages.

One value not to confuse with the player's choice: the editor records a project locale in the System data, and some engine defaults key off it. MV picks fallback fonts for Chinese and Korean from it, and both versions choose the name-input screen's character table from it, so a Japanese project switched to English still offers a kana keyboard unless something overrides that. The value is fixed at edit time and does not follow the player; check the core scripts of your version for what depends on it.

The checklist: everything that has to react when the language changes

First, why a live switch produces stale text. Windows in MV and MZ draw their contents into a bitmap when they refresh, and command windows build their entries when created or refreshed. Changing the strings underneath redraws nothing until the next refresh, so a switch made while a menu is open leaves that menu in the old language, and a plugin that read its strings once at boot keeps them forever. Returning to the title screen after a switch recreates every window, which is why it is the safer default. Switching in place is possible, but then you own refreshing every window that exists at that moment, including ones other plugins created.

Each item below stays in the old language if nothing handles it.

• System terms: command names, parameter labels and the stock system messages, from which every menu and the battle log are built. Menus made from them must be rebuilt, not just redrawn; the article titled Translating RPG Maker database terms and battle messages covers that layer
• Database names and descriptions for items, skills, states, actors, classes and enemies, plus the actor fields already copied into existing saves
• Event text: messages, choices, scrolling text and the name box. Choices are drawn by a different window from dialogue and are what a switch misses most often
• Battle messages and the battle log, which combine terms and names at display time
• Plugin parameter strings: wording typed into another plugin's settings is read once at boot and invisible to most switching approaches. Either the plugin offers per-language parameters, or you keep player-facing text out of parameters
• Images with baked-in text: title logo, signs, tutorial pictures, credits. Each needs a file per language and a rule for picking one, such as a language suffix in the filename — a convention you invent, not an engine feature
• The font per language: one font rarely covers Japanese, Chinese, Korean, accented Latin and Cyrillic, so the switch may need to change it, and at the same nominal size Japanese and Latin text differ in apparent height and line spacing
• Window widths and line counts: the message window shows a fixed number of lines, the choice window sizes itself to the longest choice, and options, shop and equipment windows have fixed columns. A language that needs more characters than the source overflows quietly
• The name-input screen's character table, which the engine picks from the project locale rather than the player's language
• The title screen: the title text if drawn, the title commands, which are System terms, the title image if it has text, and the desktop window caption, set from the game title at boot and changed only on reload

Testing the switch: a pass to repeat on every build

Run the same pass every time, in every shipped language, on a deployed build rather than the editor's test play: the two can differ in file layout. Do every step in languages you cannot read too — the text differs from the source, nothing is cut off, no empty boxes.

• Delete or rename the options file so the game believes it is a first launch, then start it: does the detected or prompted default match what you expect?
• Title screen: title text, command names, title image
• Open Options, switch language, leave Options: the game either returns to the title or every open window redraws
• New game, then the first message containing a control code, a choice, and scrolling text if you use it
• The main menu, an item description, a skill description, and the status screen for parameter labels
• A shop: buy and sell commands, prices, the item list
• A battle: the attack command, a skill, a state message, the victory message
• Save, switch language, load: party names, the map display name, the menu, and whatever the save list shows
• A screen with an image that has text in it, and the name-input screen
• Quit and relaunch: the chosen language is still active without re-detection

The bugs this pass finds most often:

• Choices still in the source language while dialogue is translated: the choice window is a separate draw path the switch did not cover
• Menu headings or quest log titles fixed in one language: they came from plugin parameters
• Empty boxes after switching to Chinese or Korean: the font lacks those glyphs; the article titled Empty boxes instead of characters: it's a font problem, not an encoding problem explains how to tell
• Cut-off text in options, choices, or shop and equipment columns: widths were set for the shorter source language
• The language reverting on the next launch: the setting was never written, or detection runs on every boot
• Party names in the old language after loading: they were copied into the save at new game

What the store page promises, and how the in-game switch has to match it

If the game is on Steam, the store page shows a table of supported languages, split into interface, full audio and subtitles, built from what you declared in Steamworks. Players read it as a promise: a language marked as interface means the menus are in that language, not just the dialogue. Declare exactly what the switch delivers; if English menus come with Japanese-only battle messages, the table should not claim interface support, and players will say so in reviews if it does.

Three things that look related are separate. The language the store page is displayed in depends on the viewer's Steam settings and on whether you localized the store text; the article titled Your Steam page shows the wrong language: how to find out why covers that. Steam's per-game language setting is a third thing: players expect changing it to change the game, and without Steamworks integration it does nothing. One sentence in the store description, in every language, saying the language is switched on the title screen and in Options prevents most of that confusion.