A support ticket arrives with a screenshot of a browser error page. You read the message, paste a distinctive phrase from it into your codebase search, and get nothing. You search the web for it and get nothing useful either.
Then you look again and notice the page is in German.
This is a small thing that wastes a disproportionate amount of time, and it has a fix so cheap it is almost embarrassing.
Browsers localise the prose and keep the identifier
Chromium's network errors have two parts that behave completely differently.
There is a stable constant, like ERR_NAME_NOT_RESOLVED or ERR_CONNECTION_REFUSED, defined in net_error_list.h with a fixed numeric value and a one-line English description for developers. That identifier does not change between locales, browser versions, or installs.
And there is the text the user actually reads, which is translated into whatever language their browser is running in.
So the same failure that tells you "This site can't be reached" tells somebody else "Diese Seite ist nicht erreichbar" or "No se puede acceder a este sitio web". One underlying condition, one stable code, and dozens of surface strings.
Your instinct when a report arrives is to work from the sentence, because the sentence is the part that looks like information. It is the part that does not survive translation.
Which means the question you are asking is the wrong one
"What did the error say?" is the natural thing to ask and it is subtly the worst version of the question, because it requests exactly the part that is locale-dependent.
"Is there a code, usually in smaller text underneath?" requests the part that is not.
The second question also happens to be easier for a non-technical person to answer, because they are not being asked to transcribe a paragraph or judge what is relevant. They are being asked to find a short string that looks like shouting.
And the answer is searchable. ERR_CERT_DATE_INVALID returns the same results whoever typed it, from wherever. The German sentence does not.
This applies to your own error messages too
Here is the part that costs something, and it is about code you control rather than code you do not.
If your application shows localised error text and nothing else, you have built the same trap. Your Spanish-speaking user reports "Se produjo un error inesperado", you search your source for it, and depending on how your translations are stored you may not find the key, the call site, or the condition that produced it.
The fix is to emit a stable identifier alongside the human text, visible to the user and constant across locales. Something like a short code in the corner of the error state, or in a detail line under it:
Something went wrong. Please try again.
Reference: PAY-4021
PAY-4021 is not for the user. It is for you, and it survives the round trip through a screenshot, a translation, a paraphrase and a support agent's summary, all of which destroy the sentence above it.
The rule of thumb: anything in your error UI that a translator can change is something a bug report cannot reliably carry. If the only distinguishing content in a failure state is prose, you have made every report of it ambiguous by construction.
The wider shape
Localisation is one instance of a general problem with bug reports, which is that the reporter can only send you what the interface showed them, and interfaces are designed for reading rather than for reporting.
The user did not choose to send you an untranslatable sentence instead of a code. They sent you what was on screen. If the screen carried a stable reference, they would have sent that, because it is shorter and more obviously official-looking.
So the next time a report is useless, it is worth asking whether the person failed to describe the problem or whether the screen failed to give them anything describable. Those have different fixes, and only one of them involves the reporter.
Chromium's list of these error constants, with the English description of each, is net_error_list.h. It is worth a bookmark for the next screenshot you cannot read.
Top comments (0)