Should I vibe code
Manage translation keys, contributors, suggestions, and standard file exports
Translation memory is two years of human review in a table. The first careless import overwrites it silently.
?
Their verdict, the Start 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
A string editor is CRUD with a language column, and an agent will hand you a convincing one before lunch. What POEditor actually sells is fidelity and memory: plural categories that differ per locale, placeholders that survive a round trip through your parser and back out, and a review history that took two years of human attention to accumulate. Build it for one project, one format and one editor - yourself - and it is a pleasant weekend. Point it at ten locales and five freelancers and the first import that swallows reviewed strings teaches you why the history feature was never optional.
What actually breaks
not "if". the specific failures.
- Plural rules, which are two forms in English, four in Russian and six in Arabic, and one column in the schema you generated
- Placeholders and ICU message syntax surviving export, hand-editing and re-import without quietly losing a brace
- An import that treats an absent key as a deletion, so a partial file wipes the strings it never mentioned
- Translation memory and review status - the part that is actually worth money - which only exists if you built history before you needed it
- RTL locales, discovered the first time someone pastes Arabic into a textarea you never tested
- External translators, who need accounts scoped to one language on the auth you wrote last Tuesday
- The second file format, added in an afternoon to a parser that had not finished being right about the first
Is that you?
the verdict is a default, not a law
- One project, one file format, and you are the only person who edits strings
- The export is diffed in a pull request before any build consumes it
- Machine translation lands as a suggestion a human accepts, never as the shipped value
- The canonical copy of every string still lives in your repo
- Freelance translators outside your company need logins
- You could not reconstruct a reviewed translation that someone overwrote last month
- The app ships to locales nobody on the team can read well enough to spot a wrong string
- Your format list has grown past the one you started with
If you build it anyway
the checklist, then the prompt that enforces it
- Version every string before you build a single editing screen. Author, timestamp, previous value, review state. History is the product; the textarea is not.
- Make import additive by default. A key absent from an uploaded file is not a deletion, and deletion is a separate confirmed action that shows a count first.
- Round-trip the format as a test: export, re-import, diff, expect zero changes. Use a fixture with plurals, placeholders and escapes, not a hello-world file.
- Model plurals as CLDR categories per locale. One/other is correct in English and wrong in half the world, and the bug is invisible until a user complains in Polish.
- Validate placeholders on save - the target must carry exactly the tokens the source does. Refuse the save rather than shipping a crash in Portuguese.
- Mark machine output unreviewed and never let it overwrite a human-approved string. Hold it as a suggestion and say how many were held.
- If outsiders get accounts, scope them per locale, make revocation one click, and log who changed what. A shared password is not a contributor model.
I am building a translation management tool for my own project's strings. The
asset is the history, not the editor. Apply these and push back if I ask you
to break them.
1. Before any editing UI, build the change log: every string version stored
with locale, author, timestamp, review state and the previous value.
Nothing writes a translation without appending a record.
2. Build export before import, and make export lossless. I must be able to
export, re-import and diff with zero changes. Write that as a test using a
fixture containing plurals, placeholders and escaped characters.
3. Import is additive. A key missing from an uploaded file is not a deletion.
Deleting keys is a separate action that shows me the count and waits for
confirmation.
4. Never overwrite a string marked reviewed during import. Land it as a
pending suggestion and report how many were held back.
5. Model plurals as CLDR plural categories per locale. Ask me which locales I
need and generate the correct category set for each; do not assume
one/other.
6. Treat placeholders as opaque tokens. On save, verify the target carries
exactly the tokens the source does, and refuse the save if it does not.
7. Machine or AI translation may only write suggestions, flagged unreviewed.
It may never write the shipped value.
8. Support exactly one file format until it round-trips perfectly. Ask me
which. Do not add a second format to a parser that still loses data.
9. If external contributors need access, scope accounts per locale, make
revocation one click and log every change. Do not propose a shared link or
a shared password.
10. Give me a one-command full export in the source file format from day one,
not a proprietary database dump.
11. Out of scope unless I ask: translator marketplace, in-context screenshot
capture, glossary enforcement, billing.
12. If I ask for ten locales and outside translators, tell me POEditor bills
by string and not by contributor, so the auth, invite and audit work alone
costs more than the subscription.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
$20 a month for Start, and contributors are free on every tier - you are billed per string, not per translator. The moment somebody outside your company needs to type into it, the invite flow, the per-locale permissions and the audit log you would otherwise write cost more than a year of the subscription. Build your own only while the editor has exactly one user.
$20/mo is cheaper than your weekend.
Keep the strings in the repo in a standard format - XLIFF, .po, or one JSON file per locale - and make your tool a lens over those files rather than the only place they exist. Do that and abandoning it is deleting a web app. Keep them only in a database with a schema you invented and the exit involves writing an exporter for a format you never fully implemented, at exactly the moment you have lost interest in the project.
Active open-source localization platform with translation memory and in-context tooling.
Mature GPL localization tool built around version control, with the format handling and plural rules already fought for.
Questions
The editor really is easy. Why is this only DEMO ONLY and not SHIP IT?
Because the demo and the product diverge on the second locale. A key-value table with an import button demos perfectly and then meets Polish plurals, an ICU placeholder that got mangled in a spreadsheet, and a translator who needs a login. None of those are hard individually; together they are the reason a hosted product exists, and they arrive after you have already migrated your strings in.
What is the single change that most reduces the risk?
Make the repo the source of truth and the tool a view over it. If every string is committed in a standard file and your app only reads and writes those files, a catastrophic bug in your editor is a git revert rather than a lost quarter of review work.
Is machine translation the risky part?
Only if it can write. Machine and LLM output as a suggestion queue is genuinely useful and costs you nothing if it is wrong. The same output written straight into the shipped column, over a string a human already approved, is the data-loss tag on this entry in one line of code.
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.
Keys, screenshots, reviews, CI sync. Individually easy, collectively a product.
Translation management is file sync plus a review queue plus a lot of edge cases.
Tolgee is open source. Vibe-coding a worse one to avoid hosting the real one is a strange place to end up.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice