What is i18ntranslator?

i18ntranslator is a translation management App for NIZU Cloud WorkSpace. It imports the i18n JSON files of a software application, gives translators a fast editor to work through them — with AI assistance — and exports the finished translations back out, either as files or straight into a GitHub branch.

The whole product is one loop:

Import JSON → Edit (human + AI) → Export (JSON · .po · PHP) → optionally, commit to GitHub

Who it is for

• Software agencies that localise the applications they build for clients.
• Product teams that ship a web, mobile or desktop app in several languages.
• Freelance and sworn translators who receive language files and need somewhere sane to work on them.
• Project managers who need to see how far each language actually is.

What problem it solves

Most teams translate software by emailing JSON files around. That fails in the same predictable ways every time: nobody knows which language is how far along, a translator silently drops a %s and the application crashes in production, the English text changes and no one remembers which translations went stale, and the file that was finally delivered is a fourth revision that nobody can trace back to an original.

i18ntranslator answers each of those directly:

• Progress is visible. Every language has a completion percentage and a breakdown by status.
• Placeholders are protected. Every save, every AI write and every import is checked against the source string. A translation that loses a %1$s, a {count} or a <b> tag is rejected.
• Drift is caught. When the source text of a key changes, every existing translation of that key is flagged outdated automatically.
• Provenance is kept. Files are stored in the NIZU project, and every key can be traced to the exact file it came from.

How it works

Packages

A package is one translatable application. It carries a source language, a list of target languages, a description of the app for the AI, and export settings. A package always belongs to a NIZU project — that is where its source files live.

The import procedure

Importing is deliberately a two-step procedure. First the .json files are uploaded to the project's Files tab, using the platform's normal file module. Then, inside the package, the import picks one of those stored files. The App ships no uploader of its own.

That keeps the project as the single source of truth: the original file stays where the rest of the project's material lives, the file history is the platform's own, and anyone who cannot see the project's files cannot import from them.

Keys, namespaces and statuses

Nested JSON is flattened into dotted keys — {"menu":{"file":{"open":"Open"}}} becomes menu.file.open — and re-nested identically on export. The origin file becomes a namespace, so a project with common.json and errors.json exports back into the same two files.

Every string in every language carries one of five statuses:

• Untranslated — empty.
• Draft — written by AI, or half-finished by a person; not yet confirmed.
• Translated — a human saved it.
• Outdated — the source text changed after this translation was saved.
• Reviewed — a reviewer signed it off.

One key is one string

i18ntranslator does not model plural categories, gender forms or ICU select syntax. A plural set in the application being translated is simply several keys. This is a deliberate simplification that keeps the editor fast and the data model honest.

AI translation

The App has no AI provider layer of its own. It uses the workspace's shared AI stack through an operation registered under Settings → AI → Operations, so translation can be pointed at its own provider, key and model — and its cost can be measured separately from every other AI feature in the workspace. Any provider the platform supports (OpenAI, Claude, Gemini, DeepSeek and others) works without extra setup in this App.

AI output is always saved as a draft. A person confirms it before it counts as translated, and a translation whose placeholders do not match the source is discarded rather than written.

Export formats

• JSON — the round-trip format. It can be imported back, and it is what GitHub sync moves.
• gettext .po — a delivery format. The key goes in msgctxt and the source text in msgid, so two keys sharing the same English text stay distinct.
• PHP $lang[…] — a delivery format, ending in return $lang;.

GitHub

A package can be connected to a repository and branch. Pull fetches the language files, stores them in the project's Files, and imports them. Push builds a single commit with all the changed language files.

If a file changed in the repository since the last sync, the push stops and shows exactly which files moved. Continuing requires an explicit acknowledgement that the repository content will be overwritten, and that acknowledgement is recorded with the name, the time, the files and the resulting commit.

Terms people search for

Translation management system (TMS), software localization tool, i18n editor, JSON translation editor, gettext PO editor, AI translation for software strings, GitHub localization workflow, placeholder validation, translation progress tracking, self-hosted translation platform, NIZU Cloud translation App.

In one sentence

i18ntranslator turns the pile of JSON files that a multilingual application produces into a tracked, reviewable, placeholder-safe workflow that lives inside the project it belongs to.