RPG Maker MV vs MZ translation: what changes for translators

From a translator's perspective, RPG Maker MV and MZ are 90% the same engine. Both store dialogue, choices, items, skills, and terms as JSON. Both use the same event command codes (401 dialogue, 102 choices, 320/324/325 scrolling text). Both honor the same control codes (\C[1], \N[2], \V[3], etc.). The remaining 10% — folder layout, plugin parameter format, a handful of new event codes — is what trips translators up when they move between the two. This post is a quick reference.

Folder layout: the most visible difference

• MV stores data files at www/data/*.json. Game assets, plugins, and the Node-bundled runtime sit alongside.
• MZ drops the www/ wrapper and stores data at data/*.json directly. Runtime is also slimmer (no Node-bundled wrapper by default; MZ ships as a static NW.js-style web app).

For RuneTranslate this is invisible — engine detection looks at both paths and picks whichever exists. But if you're doing anything by hand — copying a translation across games, checking a file with an external editor — remember the prefix.

Dialogue, choices, scrolling text: identical

The event command structure is the same in both engines, which means the translation surface is identical:

• 401— dialogue line in a Show Text command.
• 405— continuation lines of the same Show Text command (when text spans multiple display windows).
• 102— choice option text.
• 320, 324, 325— scrolling-text blocks (used for credits, monologue scenes).

RuneTranslate parses all five identically across MV and MZ. The only thing that varies is which code tendsto appear: MZ scripts use the scrolling-text block more in the default templates, but that's author preference, not engine difference.

Word-wrap at 46 chars

Both MV and MZ break dialogue lines at the message-window edge. The default message window fits roughly 46 single-byte characters per line at the default font size; longer lines wrap to the next visible window. RuneTranslate auto-wraps dialogue at 46 chars on exportin both engines so translated lines don't overflow the speech box.

Caveat: if the game uses a custom font that's wider or narrower, the wrap may need adjustment. For now this is a global constant in the RPG Maker adapter; if you find a game where it looks off, the workaround is to hand-shorten the long lines in the editor before export.

Plugin parameter strings: where MZ diverges

Both engines store plugin configuration in js/plugins.js (MV) or js/plugins.js(MZ — same path, just without the www/ prefix). The format structure is the same: a JS file declaring a PluginManager.parameters block per plugin. Both engines store visible strings inline in that block.

The difference is which plugins ship by default and how they declare their parameters. MZ's default Yanfly-style plugins use structured nested parameter schemas more often, which can produce JSON-encoded strings inside a JSON-encoded string. RuneTranslate handles common nesting depths, but if a plugin uses a custom encoding (Base64-wrapped JSON, for example), you may need to hand-translate that plugin's strings.

Practical advice: if you see strings in the project that look like {"text":"\u3053\u3093..."}— that's a JSON-encoded inner block that the plugin parses at runtime. The Japanese is still there, just wrapped. Use the editor's find-and-replace to spot-check after translation.

Control codes: identical, never let them get lost

Both engines support the same family of control codes:

• \C[n] — switch text color to palette index n.
• \N[n] — print actor n's name.
• \V[n] — print game variable n's value.
• \., \|, \^— pause / wait modifiers.

These must survive translation verbatim. If a provider drops or corrupts \N[1], the game prints raw backslash garbage instead of the player's name. RuneTranslate masks every control code with an opaque placeholder before sending to the provider, then restores them exactly — and if any placeholder fails to round-trip, the unit is marked failed so the original Japanese stays.

Practical workflow tips

• Don't hand-edit the JSON files.Use RuneTranslate's built-in editor for hand-fixes. The editor tracks which units you've edited so re-running the translator preserves your work.
• Translate plugin params last.Most plugin strings are config / UI text that doesn't need much hand-editing. Run the dialogue first, hand-fix the lines that need it, then run plugins in a separate pass with a cheap provider.
• Keep saves across re-translations.Engine players load saves by data-row index, not string. As long as you don't reorder events, players can keep their save files across an English re-translation.

For the full RPG Maker walkthrough, see the RPG Maker engine page. To compare translation providers for RPG Maker games, see The best providers for translating Japanese games.