How Fan Translation Works: From Japanese ROM to English Patch

GAME TRANSLATE · ROM HACKING · FAN TRANSLATION WORKFLOW

How Fan Translation Works: From Japanese ROM to English Patch

A real-world look at how a Japanese retro game becomes a playable English fan translation — from script extraction and localization to font hacking, reinsertion, debugging, QA and the final patch.

By belfallen · Game Translate · about 14 minutes to read

A finished English patch can make a fan translation look simple: download a small patch file, apply it to the correct Japanese game, and suddenly the dialogue is in English.

Behind that patch, however, is usually a long chain of technical and editorial work.

That means a successful project has to solve two problems at the same time:

• Make the English accurate and natural
• Make the modified game actually work

In this guide, I will walk through the process using two completed Game Translate projects as practical examples: Bakumatsu Kourinden ONI for Super Famicom and Super Robot Wars R for Game Boy Advance.

What Is a Fan Translation?

A fan translation is an unofficial translation made by fans for a game that was originally released in another language.

For retro console games, the translation normally has to be inserted back into the original game data. That is why fan translation is also a form of ROM hacking.

The simplest possible workflow looks like this:

Real projects are rarely that clean.

Extraction may reveal missing text. English may not fit the original windows. A new font may break menus. Moving the script may require new pointers. A perfectly good line may crash one obscure battle because a buffer is too small. Testing finds the problem, the build is revised, and the cycle starts again.

Step 1: Understand How the Game Stores Its Data

Before translating anything, you need to know where the game keeps its text and how the game reads it.

That information is usually not documented.

A cartridge ROM may contain:

• Program code
• Dialogue
• Menus
• Fonts
• Sprites
• Maps
• Battle data
• Sound
• Pointer tables
• Compressed blocks

None of those sections are required to announce themselves with a convenient label.

The first stage is therefore investigation. A hacker may compare the ROM with what appears on screen, inspect raw bytes in a hex editor, view graphics as console tiles, set memory breakpoints in a debugging emulator, or write small scripts to test possible data structures.

Step 2: Extract the Japanese Script

Translating directly inside a hex editor is possible for tiny edits, but it quickly becomes unmanageable for a full RPG.

A proper translation project normally uses an extraction tool that converts the game’s internal text into a format that can be reviewed and edited outside the ROM.

That might be:

• CSV or TSV
• JSON
• Plain text
• HTML
• A custom translation editor or database

A good dump needs more than the Japanese sentence itself. It should preserve enough information to put every line back in the correct place.

FIELD	WHY IT MATTERS
String ID	Gives every entry a stable identity for translation and QA.
ROM / script location	Helps trace where the original data came from.
Japanese text	The source that must be translated.
English text	The localized replacement.
Control codes	Preserves pauses, line breaks, names, portraits or other engine commands.
Context	Speaker, scenario, menu, battle or route information prevents mistranslation.

For Bakumatsu Kourinden ONI, the finished English patch covers 5,088 messages. At that scale, reliable IDs and automated extraction are essential. A single entry read from the wrong offset can become an engine bug later when the translated data is reinserted.

Step 3: Translate and Localize the Script

Once the text is outside the game, the linguistic work begins.

This stage is more than replacing Japanese words with their nearest English equivalents.

A good game localization has to consider:

• Meaning
• Character voice
• Tone
• Context
• Terminology
• Menu space
• Line length
• Story continuity

A sentence that is technically accurate may still sound unnatural in English. A short menu label may need a different solution from the same term used in dialogue. A character speaking formally should not suddenly sound casual because the literal translation was shorter.

Context is especially important in games such as Super Robot Wars R. Scenario dialogue can depend on route choices, characters currently present, story flags or optional events. Looking at a line in isolation can hide who is speaking, what happened immediately before it, or why a particular term is being used.

Consistency Matters Across a Large Game

Long RPGs and strategy games repeat names, attacks, factions, locations and technical terminology constantly.

That means the project needs a consistent glossary and a way to catch identical or related Japanese lines that have drifted into conflicting English translations.

The larger the script becomes, the more valuable automated checks become.

Step 4: Make English Fit the Game

This is where a translation project often stops looking like translation and starts looking like engine work.

Japanese game interfaces were designed for Japanese text.

English usually needs more horizontal space, and its letters have very different shapes.

Possible solutions include:

• Creating a new Latin font
• Changing character width
• Implementing a Variable Width Font
• Widening windows
• Moving labels or values
• Redrawing title screens and menu graphics
• Relocating graphics to make room for larger assets

ONI: The Dialogue Box Had to Change

Bakumatsu Kourinden ONI is a clear example.

The original game prints dialogue in a narrow vertical area that works naturally for Japanese. Trying to force normal English sentences into the same layout would produce an awkward and difficult-to-read translation.

The English patch therefore rebuilds the dialogue presentation as a horizontal text box and uses a new 8×16 English font.

That is not a cosmetic extra. It is part of making the translation readable.

Step 5: Reinsert the English Script

After translation, the English data has to go back into the game.

If every English string were exactly the same size as the Japanese source, this would be easy.

They are not.

English scripts often require considerably more space. Simply overwriting the Japanese text can run into the next string, the next table, graphics, code or unrelated game data.

A reinsertion tool therefore needs to know:

• Where translated strings can be stored
• How the game’s pointers identify those strings
• How control codes must be encoded
• How large each buffer can safely become
• Which areas of the ROM must never be overwritten

Sometimes the ROM Has to Grow

The English script for ONI is much larger than the original Japanese script, so the project expanded the ROM from 4 MB to 6 MB.

Expansion creates space, but it does not magically teach the original game engine how to use that new space.

Code and pointer logic may also have to be updated so the game can correctly reach translated data stored in new ROM banks.

Step 6: Debug Everything That Breaks

The first successfully built English ROM is almost never the final release.

At this stage, the translation begins exposing assumptions hidden inside the original game.

ONI produced several good examples during development:

These problems are why testing only whether the English sentence looks good is not enough.

A fan translation modifies software. It therefore has software bugs.

Step 7: Test the Complete Game, Not Just the Opening

One of the biggest risks in a full translation is false confidence.

The title screen works. The first town is English. The first battle finishes correctly.

That proves very little about the final chapter.

A complete QA process needs to look for at least four different kinds of problems:

QA AREA	WHAT YOU ARE LOOKING FOR
Language	Mistranslations, missing meaning, awkward English, terminology drift.
Layout	Overflow, bad line breaks, clipped menu text, unreadable fonts.
Technical	Crashes, freezes, invalid pointers, corrupt data, broken saves.
Coverage	Unvisited routes, optional dialogue, battle lines, choices and hidden events.

Why Super Robot Wars R Is a Useful QA Example

A strategy RPG is a good reminder that “I finished the game once” does not necessarily mean “I tested all the translated text.”

Super Robot Wars R contains scenario dialogue, intermissions, battle-related text and route-dependent material. Different choices and conditions can lead to different scenes.

A robust workflow therefore tracks what has been translated and what has actually been exercised in the game.

Useful methods include:

• Scenario IDs
• Route maps
• Choice coverage
• Save states
• Debug shortcuts
• Script comparison
• Terminology checks
• Regression testing

Step 8: Build a Patch for Release

Once the translated build passes testing, the project can be distributed as a patch.

The patch contains the differences between the clean Japanese game and the translated version. It does not need to contain the original commercial ROM.

The release should clearly document:

• The exact game and region required
• The required ROM revision if relevant
• A checksum for the correct source file
• The patch format
• How to apply it
• The translation version number
• Known issues, if any

This final step may look small compared with reverse engineering, but it determines whether users can actually reproduce the working translated game.

Two Completed Projects, Two Different Translation Problems

Bakumatsu Kourinden ONI and Super Robot Wars R are useful together because they show that there is no single universal fan-translation workflow.

PROJECT	MAIN CHALLENGE IT DEMONSTRATES
Bakumatsu Kourinden ONI Super Famicom	Adapting a Japanese-oriented text presentation to English: new dialogue layout, new font, larger script storage, ROM expansion and low-level debugging.
Super Robot Wars R Game Boy Advance	Managing and validating a large scenario-driven translation where context, route conditions, choices and coverage are as important as the individual sentences.

The exact tools and technical details differ, but the underlying cycle is the same:

And that cycle repeats until the translated game is not merely readable, but stable enough to play from beginning to end.

Final Thoughts

When players see a finished English patch, most of the work is invisible.

They see English dialogue where Japanese used to be.

Behind it may be months of script extraction, terminology decisions, font work, pointer changes, graphics editing, ROM expansion, debugging and repeated playtesting.

That is what makes fan translation such an interesting branch of ROM hacking.

It sits between language and software engineering.

The goal is not simply to produce English text.

In the next ROM Hacking article, we will look at one of the final pieces of that process: ROM patch formats, including IPS, BPS, UPS and xDelta, what each format actually stores, and why the correct source ROM matters.