Staff saw error codes and '1 days' instead of sentences

Your staff are using the app, something goes wrong, and instead of a sentence telling them what to do, the screen shows a line of code. Or a count reads “1 days”. They do what anybody does: they ring the office.

Each of those calls costs the same as having no message at all. And nothing in the software reports it as a fault. The app carries on looking healthy while the user reads a raw identifier.

This is what we found in a field-sales system. The server was sending back error codes the web portal had no wording for, and the phone app’s counts were broken in a way nobody had seen, because every layer was being helpful.

What was actually going on

The server deliberately sends codes, not sentences, because it has no business knowing what language the reader speaks. Each screen turns the code into words. That is the right design, and it creates an obligation it does not enforce: every code the server can send needs wording on every screen.

We compared the codes the server actually sends with the portal’s wording file and found forty-seven with nothing behind them. Not obscure ones either. Several sat on paths a user hits in normal work.

Nobody had done anything wrong in a single change. Each round of server work added a few codes. Each round of screen work added wording for the codes it knew about. The gap grew one release at a time, and it was invisible because the failure shows up as text, and text looks like a design choice.

A second fault sat in the phone app. The counts on the sync bar, such as writes pending and writes failed, had wording defined for the plural case. The translation software had moved to a different way of marking plurals two major versions earlier, so it no longer recognised the old marking and showed the singular form for every count. The wording was present, spelled correctly and never displayed. Two counts were reading “1 days”.

A third was a stock alert that printed a quantity exactly as it came from the server, a decimal with four places, in the middle of a sentence written for a person.

What we changed

We added a check that runs with the routine checks. It looks up every piece of wording the screens use, through the same software that runs in production, and fails on anything that does not resolve. It tests every count at zero, one and more than one. And it compares the codes the server can send with the wording each screen has, in both directions: missing wording is a fault users see, and wording for a code that no longer exists is usually a sign the code was renamed on one side only.

The result is a number that means something: ninety-seven codes the server can send, none missing from the portal, checked automatically rather than asserted in a status update.

The new wording does two things, not one. It says what happened and what to do next, because a message that only names the failure leaves the user nowhere to go. Numbers and money inside sentences are formatted like everything else on the screen.

What it did not fix

The check tells you the wording exists, resolves and reads correctly as a count. It does not tell you whether the wording is any good. That is still a judgement made by reading the screen, and only somebody looking at the screen catches a message that resolves but reads badly.

The pattern, for anyone with an app their staff use

You do not need a second language to have this problem. A raw code on screen is a fault in English. A quantity shown with four decimals is a fault in English. “1 days” is a fault in English. They are correctness faults that happen to live in the wording layer, and every one was visible to users in the only language the product supported.

So ask: if the server added a new error tomorrow, what would your staff see, and who would find out first? And have somebody read the real screens, not the file of wording.

Where this ends up

The same gap matters most where one piece of work is read in two places. In Sazinga Field, an order taken on a phone in a shop is the order the office sees, so a code the server can send reaches a screen either way, and one without wording is read raw by whoever gets there first.