AiNiee: a GUI translator for RPG Maker scripts, EPUB novels and SRT subtitles

What AiNiee actually translates, and who it is built for

AiNiee is a desktop application, not a library. Its job is to take a folder of source files, send the text inside them to a language model, and write translated files back out. The README frames the scope as games, books, subtitles and documents, and the supported list is unusually wide for a single tool: Mtool, Renpy, Translator++, ParaTranzr, VNText and SExtractor exports on the game side, plus I18Next, .trans, Po and CSV data, EPUB and TXT ebooks, Srt, Ass, Vtt and Lrc subtitles, and Word, PDF, MD and PPT documents.

The intended user is a fan translator or a modder working on a game that ships in Japanese, Korean or Chinese and needs a readable English, Chinese or other target version. That user typically does not write code. The three-step flow in the README (configure an interface, drag a folder in, press start) is designed for exactly that person.

There is a second, less obvious audience. Because the input side accepts structured files like Po and CSV, AiNiee can also serve as a bulk translation pass for localization files that a developer already extracted. The difference is that a developer usually wants that inside a build pipeline, and AiNiee is a GUI with a start button.

How the translation pipeline is put together

The repository layout tells you most of the architecture. AiNiee.py is the entry point. UserInterface/ holds the PyQt5 screens, with the settings pages under UserInterface/Setting. ModuleFolders/ contains the working parts, and the README points contributors at ModuleFolders/FileReader and ModuleFolders/FileOutputer for the format readers and writers. Resource/ holds the runtime data: Regex/regex.json for the regex library, Localization/ for the UI strings, and config.json for saved settings.

So the data flow is: a reader parses a source file into text units, the translation layer sends those units to the configured model, and a writer reassembles them into the output format. The README describes several techniques layered on top of that flow, including a lighter intermediate translation format, chain-of-thought translation, an AI glossary, and context linking between segments. Those exist to keep terminology and tone consistent across a long script, which is the failure mode of naive segment-by-segment translation.

Two tables control the output beyond the prompt. The AI glossary pins terms and names, and the AI forbidden-translation table blocks specific strings from being translated at all. There is also a text-replacement table. For a game with recurring character names, the glossary is the mechanism that matters most, and it depends on you populating it rather than on the model guessing.

The dependency list in requirements.txt confirms the model backends: openai, anthropic, boto3 for Bedrock, and google-genai. tiktoken is present, which suggests token accounting, though the README does not document a cost estimator.

Installing AiNiee and running a first subtitle translation

The README's download link points at the GitHub releases page, and the release list shows packaged builds (AiNiee7.2.4, AiNiee7.2.3) alongside a Beta build that the release notes describe as automatically packaged from the latest source. For most users the packaged build is the intended path, and the README does not give a source install procedure.

If you do build from source, the dependencies are declared in requirements.txt. A minimal environment for an API-backed run needs the core packages, not the media and OCR extras:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python AiNiee.py

The first screen you configure is the interface, which is where the API key or local endpoint goes. For a paid online provider the README links a DeepSeek setup page in the wiki. For a local model it points at LM Studio, ollama or Sakura_Launcher_GUI as the runner, with AiNiee talking to whatever endpoint that runner exposes.

Multiple keys are supported for the same account type. The README is specific about the format: separate them with English commas on one line, with no line breaks.

key1,key2,key3

After that, put the files you want translated into their own folder and drag that folder into the input box. The README notes that batch translation works by placing every file in the input folder, and that nested folder structures are accepted. Press start and the task runs. For subtitles and documents, the README says these can be translated directly. Games are different: they need an external extraction tool first, and the translated text has to be injected back into the game by that tool or by a separate patch step.

Where AiNiee stops being the right tool

The most concrete limitation is that game translation is not self-contained. The README is explicit that games need a text extraction tool to cooperate, and it lists Mtool, Translator++, ParaTranz and the RenPy SDK as separate downloads. AiNiee translates the extracted text. It does not extract it, and it does not put it back into the game. If your engine is not covered by one of those extractors, AiNiee's game support does not apply to you at all.

The second limitation is operational. AiNiee is a GUI with a start button, and the README does not document a command-line mode, a resume-after-crash mechanism, or a rollback of a partially written output. For a 200,000-line script that runs for hours, that matters. A crash mid-batch leaves you reasoning about which files were written and which were not, from the file system rather than from a job log.

Cost is the third gap. The README recommends paid online interfaces as good value and notes that local models need no GPU-free assumption reversed, meaning a local model needs a GPU. But nothing in the README gives a token estimate or a projected spend before a job starts. On a long novel or a large game script, the first signal of cost is the bill.

Finally, the licence is AGPL-3.0, and the README's own notice restricts the tool to personal lawful use, stating that direct or indirect for-profit activity is outside the authorized scope. If you were considering this for commercial localization work, that combination is worth reading carefully before you build a workflow around it.

AiNiee against GalTransl and BallonTranslator

The related searches around this project include GalTransl and BallonTranslator, and the difference in approach is real rather than cosmetic.

GalTransl is oriented toward automated game translation pipelines, the kind you run from a script over a directory of extracted scripts and let finish unattended. AiNiee's centre of gravity is the opposite: a visual three-step flow where a human drags a folder, watches progress, and adjusts prompts, glossaries and style settings between runs. If your problem is one game you care about and you want to tune names and tone, AiNiee's glossary and prompt controls are the point. If your problem is fifty games and you want them done overnight, a pipeline tool fits better.

BallonTranslator comes from the image side. It is built around translating text inside manga and comic images, with detection and inpainting as part of the job. AiNiee does not do image work; its inputs are text-bearing files and it never sees a rendered page. A PDF goes through AiNiee as a document with extractable text, not as a scan to be read visually. If your source is a scanned manga page, AiNiee is not the tool.

The README also links two sibling projects worth knowing about. AiNiee-Next is described as an engineering rewrite of AiNiee's core logic as a command-line version using uv, aimed at long unattended runs, server deployment and automation. That is the answer for anyone who reads the previous section and concludes the GUI is the blocker. ainiee-translate-skill is described as a separate agent-native novel translation system. Neither is part of this repository, so evaluate them on their own terms.

Maintenance, configuration migration and licence cost

The repository is not archived, and the last push was on 2026-09-09. The release history shows AiNiee7.2.3 on 2026-07-01, AiNiee7.2.4 on 2026-09-01, and a Beta build on 2026-09-09, so the project is moving at a pace of roughly monthly tagged releases with a rolling beta channel on top.

Upgrading has one documented step. The README states that configuration is stored in resource/config.json and that you can copy that file from your old install into the new version's resource folder to carry your settings over. That is the whole documented migration path. It also means your API keys, glossary and table data live in a plain file you should back up before replacing a version, and that a version which changes the config schema could leave you reconciling fields by hand. The README does not describe schema versioning or an automatic migration.

On licence: the repository is AGPL-3.0. The practical consequence for anyone embedding this in a service is the network-copyleft clause, which is a question for your own legal review rather than something this article can settle. Separately, the README's notice limits use to personal lawful purposes and states that for-profit use is not authorized or supported. Those two statements sit alongside each other, and a team planning commercial use should treat both as open questions to resolve before adoption, not after.

Editorial conclusion

Adopt AiNiee if you translate RPG Maker, Ren'Py or Krkr game text and already have an API key or a local model you are happy to spend GPU time on. Skip it if you need a headless pipeline, a per-job cost estimate before you start, or a documented way to resume a half-finished batch. Before committing, verify three things on your own files: that your extractor's output format is in the supported list, that the AI glossary and forbidden-term tables actually hold your character names across chapters, and that the regex library in Resource/Regex covers your engine's control codes.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. NEKOparapa/AiNiee on GitHub
4. README
5. Releases