I’m evaluating a small tool idea; no app exists yet. It would compare two CSV localization exports and flag changed source strings whose translations stayed unchanged, plus added/removed keys.

Synthetic example: “Collect 5 herbs” becomes “Collect 8 herbs”, while the Ukrainian translation still says “Зберіть 5 трав”. The report would say “needs review”, not automatically declare an error: some wording changes need no translation update.

It would run offline in a browser, without translating or modifying files. I’m considering a one-time $15 price, but first want to understand the problem.

How often has this happened in your recent projects? How do you currently find and review the affected translations?

Update: I built a small free beta so the idea can be tested as a working tool rather than discussed in the abstract:

https://hickery68.itch.io/localization-change-review

It is a single-file offline browser tool for wide CSV files with stable keys. It flags source-changed / translation-unchanged rows for human review, plus added and removed keys. It does not translate, modify files, or replace gettext/PO workflows that already provide reliable fuzzy flags.

If anyone tries it on a real CSV workflow, I’d especially value feedback on whether the report catches something your current process misses.

One thing that changed this for us: store a hash of the source string in the translation file itself, as an extra column beside each translated cell, instead of diffing two exports.

The difference is where staleness lives. A two file diff only tells you which rows moved between export A and export B, so you have to keep the previous export around, and a reordered or regenerated export muddies it. A stored source hash makes staleness a property of one row in one file: if the hash of the current source doesn’t match the recorded one, that translation was reviewed against different text. Added and removed keys fall out of the same pass.

Keep the short source string rather than only its hash and the report can also show what the line used to say, which is usually a two second decision for the reviewer.

That’s roughly what gettext fuzzy flags are, with the bookkeeping already done for you.

In Return From the Tavern (the only game of mine I had translated), the text files don't use CSV but use custom tags to refer to in-game variables, icons, character names, key identifications and scene transitions. How do you adapt to the need of custom tags?

Sorry Irog, I skipped your question.

The trick is to hash a normalised copy of the source line rather than the raw one. Before hashing, replace every custom tag with a positional placeholder, so an icon tag and a variable tag both become tokens like {1} and {2} in the order they appear. Then keep two hashes beside the translation, one of the normalised prose and one of the tag sequence.

That splits the two kinds of change that actually matter. If the prose hash moves, the translator has real work. If only the tag hash moves, a variable or an icon was renamed or reordered, which is usually a mechanical fix and often not the translator's job at all.

It also stops a pure retag from flagging a whole file as stale, which is what made us stop hashing raw lines.