“Is Spanish done?” sounds like it has a number for an answer. It does, but which number depends on what you decide counts as done — and the gap between the optimistic and the honest reading of the same file is routinely twenty points.
Three different kinds of not done
The cell is empty. Nobody has touched it. This is the only one a spreadsheet can count for you, and it is the least interesting because it is the one nobody misses.
The cell still holds the source text. The export pre-filled every target column with the English so translators had something to work from, and these rows were never reached. They are non-empty, so every naive count treats them as finished. This is where the twenty points go.
The cell holds a placeholder. TODO, TBD, a dash, a copy of the key. A convention some team adopted and nobody wrote down. You can only find these by looking at what repeats.
A completeness figure that only counts the first kind is not wrong so much as answering a different question — how much of the file has something in it, which is not what anyone wanted to know.
Why “same as source” is not automatically a bug
The obvious move is to treat every target cell matching the source as untranslated. That is too strong, and a tool that quietly deleted or flagged them all as errors would be wrong often enough to be annoying.
Plenty of strings are legitimately identical across languages. Product names. OK. Email. Numerals and units. Interface strings that a team deliberately keeps in English. In a Spanish column, Wi-Fi is correct and identical, and no amount of translating will change it.
So the honest treatment is to count them separately rather than to fold them into either bucket: report how many cells match the source, and let the person who knows the product decide which are finished and which were never started. It is a number to look at, not a verdict.
The useful signal is the shape of the count. Three identical strings in a column of 1,200 is normal. Three hundred is an export that pre-filled and a translator who stopped.
Length, and why a fixed threshold is wrong
The other question a review has to answer is whether anything will break the interface. Translations grow, and a button that fits in English overflows in another language.
The common approach is a fixed rule: flag anything more than, say, 30% longer than the source. This produces a useless report, because the expected growth is a property of the language pair, not a constant. German and Finnish routinely run substantially longer than English; Japanese and Chinese run considerably shorter. A fixed threshold flags most of the German column and nothing at all in the Japanese one, including the Japanese string that is genuinely three times too long.
The approach this site’s editor takes instead is to learn the norm before judging it. For each target column it measures every row’s length ratio against the source, takes the median of those ratios as that column’s baseline, and flags only the rows that stand well clear of their own column’s normal. German is then compared against German, and the outlier that surfaces is a string unusual for that language, which is the only kind worth a person’s time.
Two details that matter in practice. Very short strings are skipped, because a two-character source turning into six characters is a 300% increase and means nothing. And length is counted in code points rather than in UTF-16 units, so a Japanese character counts as one and an emoji does not count as two.
Counting it honestly
A completeness pass worth running produces, per language:
- Non-empty as a percentage of total rows — the ceiling, and the number people usually quote.
- How many of those are identical to the source — the correction to that ceiling.
- The empty rows themselves, as somewhere to jump to rather than a count to read.
- Length outliers, measured against that language’s own norm.
Run it per language and not for the file as a whole. A file that is 80% translated overall may be four languages at 100% and one at nil, which is a completely different situation from five languages at 80% and needs a completely different next action.
When the number is the wrong question
Two cautions on completeness figures, both learned the hard way by people who shipped on one.
100% translated is not the same as reviewed. Every cell being non-empty and distinct from the source says nothing about whether the text is right, fits the context, or uses the terminology the rest of the product uses.
A key that changed makes the count meaningless. If the source string was edited after translation, its targets are complete and stale at the same time, and nothing in the file records that. This is the failure a spreadsheet hand-off is worst at, and the reason keeping the key column intact matters more than any percentage.
Doing it here
The editor on this site reports progress per language when it recognises a translation layout: how many rows are filled, what percentage that is, how many are still identical to the source counted separately, and how many rows are unusually long for that language pair.
The untranslated rows are a filter rather than a number — turn it on and the grid shows only the rows still needing work in the language you are on. Comment columns stay out of the count entirely, because they were never work to be done.
Nothing is uploaded: the file is read and checked by your browser. Everything else it does with a translation file — column detection, the source lock, the notes — is on the TSV and CSV translation file editor page.