When a project supports multiple languages, the translation itself is only part of the work. The harder problem is keeping keys, nested paths, and project conventions intact while content changes.
A practical workflow looks like this:
- Start with the source files
Collect the JSON, Markdown, or plain-text files that need translation. Keeping the source files together makes it easier to compare the original content with each generated locale.
- Protect structure before translating
A translated value should not accidentally rename a key or change the nesting used by the application. Treat the file structure as an interface: translate the human-readable content while preserving keys and paths.
- Translate incrementally
Not every release changes every string. A diff-like workflow can focus on added or edited content instead of reprocessing the entire project. This reduces review work and makes it easier to see what changed between releases.
- Generate locale files consistently
Teams often have conventions for locale folders and filenames. Mapping project paths to those conventions helps generated files fit naturally into an existing i18n setup.
- Review and export
Before shipping, compare the translated output with the source, check that the expected languages are present, and export the project in a format the team can review or commit.
For teams that want a browser-based workflow, JsonTranslate supports JSON, Markdown, and TXT translation while preserving keys, nested paths, and project structure. It also provides project translation, path mapping, a Web Studio, batch task monitoring, ZIP export, and a CLI for connecting local repositories. Hosted translation and bring-your-own-key options support different model and cost strategies.
The main lesson is simple: localization tooling should protect the structure developers depend on, not just produce translated text.
Top comments (0)