Should I vibe code
Use a managed localization workspace instead of operating the open-source stack
Tolgee is open source. Vibe-coding a worse one to avoid hosting the real one is a strange place to end up.
?
Their verdict, the Team price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The unusual thing about this entry is that build-versus-buy has a third option sitting in plain view: Tolgee is open source, and Tolgee Cloud is the hosted version of a platform you can run yourself for nothing. Writing your own therefore costs the most and delivers the least. If you do it anyway, the surprise will not be the key-value CRUD — it will be ICU message format, where a plural that reads fine in English needs four categories in Polish and six in Arabic, and a naive interpolation ships grammatically broken sentences to people who cannot file a bug in a language anyone on your team reads. The second surprise is delivery: fetch translations at runtime and your little translation server is now on the critical path of every page, in every locale, forever.
What actually breaks
not "if". the specific failures.
- ICU plural and select rules, which are not a formatting nicety — they are the reason a sentence that works in English is nonsense in Polish, Russian or Arabic, and nobody on your team will notice
- Placeholder integrity. A translator or a machine drops the {count} and the string renders raw or throws at runtime, in a locale nobody tests
- Runtime delivery, which makes your translation store a hard dependency of the app. Cache it too aggressively and a fix never lands; cache it too little and a slow query becomes a slow page in eleven countries
- Machine translation writing over reviewed human text, which is a data-loss event dressed up as a sync
- Key deletion. Removing a key still referenced by a released mobile binary is not reversible the way the web has trained you to think it is
- The in-context editor, which injects an editing surface into your running application — a feature that must never be reachable in production by anyone who is not you
Is that you?
the verdict is a default, not a law
- Two or three languages, one repository, and JSON files in version control — which is not this product and is usually the right answer
- You wrote the source strings and you are also the only translator
- Translations ship inside the build and nothing is fetched at runtime
- External or agency translators need logins, which means accounts, roles and a review workflow — in other words, the actual product
- Your app pulls strings at runtime and you have no cache invalidation story
- You are localising anything with legal weight: terms, disclosures, safety instructions, medical or financial copy
- Any target language has plural rules you could not recite on request
If you build it anyway
the checklist, then the prompt that enforces it
- Validate ICU syntax and placeholder sets on write, not on render. A broken message should fail the import, never the user's page.
- Never let machine translation overwrite human-reviewed text. Machine output lands in a separate, visibly-labelled state that a person promotes deliberately.
- Keep full revision history per key per locale and make rollback one action, because the fastest fix for a bad publish is always the previous version.
- Ship translations with the build, or cache them with an explicit version plus stale-while-revalidate. A page render must never wait on your translation server.
- Fall back to the source language visibly rather than rendering a raw key. A key in the UI is a bug report from somebody who cannot write one.
- Make key deletion a two-step with a grace period, and refuse to delete keys still referenced by a released client.
- Gate the in-context editor behind authentication and disable it in production builds by default.
I am building a translation management tool for my own app. Correctness of the message format and safety of the publish path matter more than the UI, so do those first.
1. Use ICU MessageFormat as the storage format from the first commit. Do not
invent a placeholder syntax and do not treat plurals as concatenation.
Explain that Polish needs four plural categories and Arabic six, and that
this is correctness rather than polish.
2. Validate on write: parse every message, check the placeholder set matches
the source exactly, and reject the save. A malformed message must never
reach render time and become a runtime error in a locale I cannot read.
3. Every key in every locale keeps full revision history with author and
timestamp, and rollback is one action. Build this before editing.
4. Machine translation writes to a distinct state, never over a reviewed human
string. Promotion is an explicit human action the UI makes obvious.
5. Import is the dangerous operation. Make it diff-first: show which keys would
be added, changed and removed, require confirmation on that list, and never
silently overwrite reviewed content.
6. Key deletion is soft, with a grace period and a check against keys still
referenced by a released client. Warn me that a deleted key in a shipped
mobile binary cannot be fixed by a deploy.
7. Default to build-time delivery: export files the application bundles. If I
ask for runtime fetching, tell me the translation server becomes a hard
dependency of every page load, then implement it with an explicit content
version, a CDN, stale-while-revalidate and a bundled fallback.
8. Missing translations fall back to the source language, visibly flagged.
Never render a raw key to a user.
9. The in-context editor is off by default, requires an authenticated session,
and is compiled out of production builds.
10. Out of scope, and say so rather than approximating: translator accounts and
permissions, review workflow, glossaries and translation memory. Those are
the product — self-host Tolgee or pay for it.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Self-host first. The platform is open source, and running somebody else's hardened localization stack removes the entire maintenance argument for free. Pay the €49 a month when you want the operations gone too, or when translators outside your team need accounts — which is the point where you would otherwise be building user management, permissions and a review queue, and none of those are localization.
$49/mo is cheaper than your weekend.
Keep everything in standard interchange formats — flat JSON, XLIFF or PO keyed by a stable key — and the exit is an export. That is also what Tolgee, Crowdin, Lokalise and POEditor all import, so the only thing that genuinely fails to travel is review state and translation memory. Since translation memory is years of human judgement, keep it in a table you can dump rather than only in an index.
The open-source platform behind Tolgee Cloud, self-hostable with translation memory and in-context editing.
Long-running open-source localization platform built around tight version-control integration.
Questions
The product is open source. Is there any honest case for building my own?
One: you have two languages, one repository, and JSON files in git. That is not building a localization platform, it is not having one, and for most teams it is correct for longer than they expect. The moment you need somebody outside the repository to edit strings, you need accounts and review, and at that point self-hosting the real thing is strictly cheaper than writing a worse one.
Why is runtime delivery scored as a risk rather than a feature?
Because it moves your translation store onto the critical path of page rendering. Ship strings in the build and a translation outage is impossible. Fetch them at runtime and you have added a network dependency to every page in every locale, with a cache you now have to invalidate correctly — and the failure shows up as raw keys on screen for users who cannot tell you what went wrong.
How bad is a machine translation overwriting a reviewed string?
Worse than it sounds, because it is silent and it is bulk. A single sync can replace hundreds of sentences that a human considered and approved, and unless you kept per-key revision history there is nothing to compare against. The reviewed translations, not the source strings, are the asset you are actually accumulating.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Translation management is file sync plus a review queue plus a lot of edge cases.
Translation memory is two years of human review in a table. The first careless import overwrites it silently.
Keys, screenshots, reviews, CI sync. Individually easy, collectively a product.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice