How to diy excel i18n json generation vs paid localisation platforms like lokalise
- Step 1Count your locales and contributors — One to a few locales, one or two trusted translators, infrequent changes → the spreadsheet route fits. Many locales, external vendors, continuous changes, reviewer approval gates → a platform's workflow features start paying for themselves.
- Step 2Decide where the source of truth lives — DIY keeps the master in an Excel file you own and version in git or a drive. Platforms hold the master in their database and you export. If you want full ownership and no export dependency, the spreadsheet wins.
- Step 3Try the spreadsheet route first — Lay out key + language columns on the first sheet, drop it onto this tool, set
keyColumn/valueColumn, choosenested, and generate one JSON per language. If that covers your needs, you've saved a subscription. - Step 4Identify the missing capability, if any — List what you actually need that the spreadsheet can't do: translation memory, glossary enforcement, screenshots/context, machine-translation pre-fill, branching, reviewer roles. If the list is empty, stay DIY.
- Step 5If you need workflow, evaluate a platform — Lokalise, Phrase, and Crowdin all import/export JSON, so you can start in Excel and migrate later without rewriting keys. Match the platform's pricing tier to your locale and seat count.
- Step 6Keep the Excel→JSON tool as a fallback — Even on a platform, a quick spreadsheet-to-JSON conversion is handy for one-off locales, prototypes, or when you just want to hand-edit a small file without touching the platform. The tool stays useful alongside, not only instead of.
Capability comparison: Excel route vs platforms
Honest feature gaps. The Excel route is this tool plus a spreadsheet; platform features are typical of Lokalise / Phrase / Crowdin (exact features vary by plan).
| Capability | Excel + this tool | Lokalise / Phrase / Crowdin |
|---|---|---|
| Cost | Free (free tier covers most locale files) | Per-seat / per-key subscription |
| Account / upload required | No — browser-only | Yes — cloud-hosted |
| Translation memory | No | Yes |
| Glossary / terminology | No | Yes |
| In-context / screenshot editing | No | Yes |
| Machine-translation pre-fill | No | Yes (built-in MT engines) |
| Reviewer / approval workflow | No (use the spreadsheet's own review) | Yes (roles, states) |
| Output formats | Flat or nested JSON | JSON + many (XLIFF, .po, .strings, ...) |
| Source of truth | Your .xlsx/CSV | Platform database |
| Multi-locale export in one action | No — one file per run | Yes |
Which route by team shape
Rules of thumb, not hard rules. The crossover is roughly where coordinating translators in a spreadsheet starts costing more time than a subscription.
| Team shape | Recommended route | Why |
|---|---|---|
| Solo dev, 1–3 locales | Excel + this tool | No workflow to manage; free; private |
| Small team, infrequent changes | Excel + this tool | Spreadsheet review is enough; no subscription |
| Continuous localisation, many PRs | Platform | Branching + sync beat manual regeneration |
| External translation vendors | Platform | Roles, TM, and context reduce vendor errors |
| 10+ locales, large key count | Platform | Multi-locale export + TM save real time |
| Prototype / one-off locale | Excel + this tool | Fastest path; no setup |
What the Excel tool actually does (and doesn't)
Be precise about the DIY route's scope so the comparison is fair. This is the full feature set.
| Does | Doesn't |
|---|---|
| Read first sheet of .xlsx / CSV | Read multiple sheets |
| Map one key column + one value column | Export all languages in one click |
| Flat or nested (dotted-key) JSON | Other formats (XLIFF, .po, .strings) |
| Trim keys, skip empty-key rows | Translation memory or MT pre-fill |
| Escape values via JSON.stringify | Validate ICU / placeholder syntax |
| Run free, browser-only | Sync to a repo or CI automatically |
Cookbook
Scenarios that decide the route, with the concrete spreadsheet-side action where the Excel tool applies. No platform pricing quoted — plans change; the structural fit is what matters.
Solo SaaS, English + French — stay DIY
Two locales, one developer, occasional copy tweaks. A platform's translation memory and roles add nothing here. The spreadsheet plus this tool is the whole pipeline.
Workflow: 1. Maintain strings.xlsx (key | en | fr) in the repo 2. Run tool: valueColumn=en → en.json 3. Run tool: valueColumn=fr → fr.json 4. Commit both to /locales Cost: $0. Source of truth: the .xlsx you own. No account, no sync, no upload.
Adding a 12th locale with outside vendors — go platform
Once external translators and a dozen locales are involved, coordinating a spreadsheet by email breaks down. Translation memory and reviewer roles justify a platform. You can import your existing JSON to seed it.
Signal you've outgrown DIY: - spreadsheet emailed back with broken columns - no way to enforce glossary terms across vendors - no translation memory → same string re-paid 12x Migration: existing en.json/fr.json import cleanly into Lokalise/Phrase/Crowdin (all accept nested JSON). Keys are preserved, so app code doesn't change.
Prototype: throwaway locale in five minutes
You need a quick German build to demo. Spinning up a platform project is overkill. Type the translations in a sheet, generate, ship the demo.
key | de -------------|------------ home.title | Willkommen home.cta | Loslegen Tool: valueColumn=de, nested=true → de.json Drop in, build, demo. Delete later if unused. No platform project to clean up.
Hybrid: platform for most, Excel for a stray locale
Even on a platform, a one-off locale a contractor delivered as a spreadsheet is faster to convert here than to onboard into the platform just for one language.
Main locales: managed in the platform. Contractor delivers Polish as strings_pl.xlsx. Fastest path: run this tool on strings_pl.xlsx → pl.json, drop into /locales rather than create a platform import job for one file.
Cost reality check for a tiny app
The Excel route's value is avoiding a recurring bill for capabilities you won't use. This isn't anti-platform — it's matching tool to need.
Tiny app: 3 locales, ~120 keys, edited monthly.
DIY: $0/mo, 2 minutes per regenerate per locale.
Platform: monthly subscription + setup, for TM and
roles you don't need at this size.
Verdict: DIY until a real workflow need appears.Edge cases and what actually happens
You need translation memory
Not supportedThe Excel route has no translation memory — the same phrase is re-translated (and, with vendors, re-paid) everywhere it appears. If you translate large volumes of repetitive content, a platform's TM is a genuine cost saver and the spreadsheet route stops making sense.
You want all locales exported at once
One file per runThis tool reads one value column per run and emits one JSON file. A 10-locale release means 10 runs. Platforms export every locale in one action. For a couple of locales the manual runs are trivial; for many they're a chore that favours a platform.
You need in-context or screenshot editing
Not supportedTranslators in a spreadsheet can't see where a string appears in the UI, so length and tone mistakes slip through. Platforms offer in-context editors and screenshots. The Excel route relies on the translator's judgement plus your QA pass.
You need a reviewer-approval gate
Not built inThere's no approval state in the tool. Review happens in the spreadsheet (comments, a status column) on the honour system. Platforms have explicit reviewer roles and locked states. For regulated copy, that gate may be required.
Multiple people edit the same sheet at once
Spreadsheet's problem, not the tool'sConcurrent editing is handled by your spreadsheet (Google Sheets, Excel online), not this tool — the tool only converts a finished export. Merge conflicts and last-write-wins on the sheet are the same risks any shared spreadsheet has.
You want CI to regenerate JSON on every commit
ManualThis is a browser tool, not a CLI or CI step — you run it by hand. If you need automated repo sync, that's a platform integration or a custom script's job. For a tiny project, manual regeneration on change is fine.
You need formats beyond JSON
JSON onlyThe tool outputs JSON (flat or nested). If your toolchain needs XLIFF, gettext .po, or Apple .strings, this isn't the path — platforms export those. For web i18n libraries that read JSON, it's exactly enough.
Key count grows into the thousands
Still works, but coordination strainsThe tool handles large sheets up to the tier limits (10,000 rows free, more on paid). The bottleneck is human coordination of a huge spreadsheet, not the conversion. At that scale a platform's structure usually wins regardless of the tool's capacity.
You're worried about lock-in either way
DIY avoids itThe Excel route's source of truth is a file you own — no lock-in. Platforms hold strings in their database; you depend on their export. If escape-hatch ownership matters, that's a point for DIY. Note platforms do export JSON, so migration off them is feasible too.
Sensitive pre-launch copy
Stays localBecause conversion is browser-only via SheetJS, unreleased copy never reaches a third-party server. A cloud platform necessarily stores your strings on its infrastructure. For confidential launches, the DIY route keeps everything on your machine.
Frequently asked questions
Is the Excel tool a real alternative to Lokalise or Phrase?
For small projects, yes. If you have a few locales, trusted translators happy in a spreadsheet, and infrequent changes, the Excel-to-JSON route covers the whole pipeline for free. It is not a replacement for the workflow features (translation memory, roles, in-context editing, multi-locale export) that platforms provide for larger teams.
When should I pay for a platform instead?
When you need capabilities the spreadsheet can't give: translation memory, glossary enforcement, machine-translation pre-fill, reviewer-approval gates, in-context editing, branching, or one-action export across many locales. External vendors and 10+ locales usually tip the balance toward a platform.
Can I start in Excel and migrate to a platform later?
Yes. Lokalise, Phrase, and Crowdin all import JSON, and your keys don't change in migration, so your app code stays the same. Starting DIY and migrating when you outgrow it is a sensible, low-risk path — you only pay for a platform once you actually need one.
Does the Excel tool do machine translation?
No. It converts the strings a human put in the spreadsheet to JSON; it doesn't translate anything. Platforms offer built-in MT pre-fill. If you want MT, do it in your spreadsheet (e.g. a translate formula) before generating, or use a platform.
What about translation memory — can I get that with Excel?
Not from this tool. Translation memory (reusing prior translations of identical or similar strings) is a platform feature. In a spreadsheet you'd be relying on copy-paste and the translator's recall. For repetitive, high-volume content, that gap is a real reason to use a platform.
Can it export all my languages in one click like a platform?
No. The tool reads one value column per run and outputs one JSON file. Each locale is a separate run. For two or three locales that's trivial; for many it's a manual chore where a platform's single-action multi-locale export is genuinely better.
Is the DIY route safer for confidential copy?
Yes. Conversion runs entirely in your browser via SheetJS — the spreadsheet and the JSON never leave your machine. A cloud platform stores your strings on its servers. For unreleased product copy, browser-only conversion is the more private option.
What output formats does the Excel tool support?
Flat or nested JSON only (the nested flag toggles between them). That covers react-i18next, vue-i18n, next-intl, and i18next. If you need XLIFF, gettext .po, or Apple .strings, a platform exports those; this tool does not.
Will using Excel lock me in?
No — the opposite. Your source of truth is a plain .xlsx/CSV you own and can version anywhere. There's no platform database to escape. Platforms do offer JSON export, so they're not a trap either, but DIY has zero lock-in by construction.
What's the realistic ceiling before I should switch?
The conversion handles large files (10,000 rows free, up to unlimited on Developer). The real ceiling is human coordination: once a single shared spreadsheet, many locales, and external vendors create more friction than a subscription would remove, switch. Until then, DIY is the cheaper, simpler choice.
Can I keep using the Excel tool alongside a platform?
Yes. Even with a platform for your main locales, a quick spreadsheet-to-JSON conversion is useful for a one-off locale a contractor delivered as Excel, or for a throwaway prototype. The tool stays handy as a fallback, not only as a full replacement.
Are there sibling tools for other Excel-to-code conversions?
Yes — the same dev-bridge family includes excel-python-gen for Python data structures, excel-trpc-router for typed routers, and excel-tailwind-export for HTML tables. If your translators keep strings wide across many columns, the un-pivot tool reshapes wide to long first.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.