Why screenshots matter: visual context for translators

Give a translator this list and ask for German:

buttons.open
status.open
hours.open

All three source strings are the word Open. In German they are Öffnen, Offen and Geöffnet — a verb, an adjective and a participle. Nothing in the string tells the translator which is which. They will guess, and they will be wrong about a third of the time.

This is the single most common cause of bad translations in software, and it is not a translation problem. It is a context supply problem, and it is entirely fixable.

What ambiguity actually looks like#

Beyond parts of speech, the recurring cases:

Length constraints that are invisible. A translator has no way to know that a string sits in a 120-pixel button. German runs 20–30% longer than English, so the honest translation overflows and gets truncated.

Placeholders with unknown contents. %{name} — a person’s first name, a full name, a project name, a company? In languages with grammatical gender or case, the answer changes the surrounding words.

Whether it is a heading, a label or a sentence. Capitalisation conventions differ by language, and the right convention depends on the role of the text.

Formality. Languages with formal and informal address force a choice on every sentence. Without a project-level instruction, translators pick individually and the interface reads as though several people wrote it.

Which product noun is being used. Is “workspace” your feature, or the ordinary English word? A term base answers this; nothing else does.

Why screenshots beat written explanations#

You can address all of the above with developer comments, and you should. But a screenshot does something a comment cannot: it answers questions the translator did not know to ask.

Seeing the string in place tells them the part of speech, the available width, the surrounding copy, the visual hierarchy, whether it is a button or a heading, and what the adjacent strings say — all at once, without anyone having written it down. The context that turns out to matter is usually not the context you predicted.

It also shortens the feedback loop in the other direction. A translator looking at a screenshot spots that two adjacent labels use inconsistent terminology, which is a source-copy bug you would otherwise have shipped in every language.

Making it practical#

The objection is always effort, and historically it was a fair objection: annotating screenshots by hand, linking each region to a segment, is tedious enough that it stops after the first sprint.

Two things make it sustainable.

OCR auto-detection. Rather than drawing a box around every string, run text detection across the screenshot and let it propose annotations. In WebTranslateIt this works on the whole image or on a region you select; detected text appears as draft annotations, and clicking one opens a segment search pre-filled with the detected text. Confirm the matches, dismiss the rest. What used to be an afternoon becomes a few minutes per screen.

Capture at the right moment. Screenshots taken when the feature is built are cheap. Screenshots taken six months later require someone to reconstruct the state that produces that screen, which is why it never happens. If your test suite already renders screens, it can save the images.

What to prioritise#

You do not need to screenshot everything. Ranked by value:

1. Onboarding and signup. Highest-traffic, highest-stakes, most likely to be seen by a user deciding whether to stay.
2. Screens dense with short strings. Navigation, settings, toolbars — where ambiguity concentrates.
3. Anything with tight layout. Fixed-width buttons, mobile screens, tables.
4. Error and empty states. Frequently missed, seen at the worst moment, and often written in a hurry.
5. Everything else, eventually, if it earns it.

Long-form content needs screenshots least — it carries its own context.

Developer comments: the cheap half#

Screenshots are the high-value option; comments are the cheap one, and the two are complementary. A good comment answers what the screenshot cannot:

✗ "Button text"
✓ "Verb. Submit button on the invite dialog. Max 18 characters."

✗ "%{name} placeholder"
✓ "%{name} is the invited person's first name only."

✗ "Error"
✓ "Shown when a card is declined. Keep it non-blaming — the user may have done nothing wrong."

The pattern: say what the translator cannot see. Part of speech, what a placeholder contains at runtime, length limits, tone.

The economics are unusually clear. A comment costs a developer about fifteen seconds at the moment they create the string, when the context is already in their head. Reconstructing it later costs a translator a question, a manager a context switch, a developer an interruption, and everyone several days of latency — multiplied by every language, because without a shared place for the answer, each translator asks independently.

That multiplication is the real argument for putting context in the tool rather than in a reply thread: an answer written once is visible to every translator on every language, and to the AI translation engines too, which read developer comments as context.

Screenshots as review, not just as briefing#

There is a second use that teams discover late: showing the translated interface back to the translator.

A translator who has only ever seen strings in a list has no way to know their German label overflowed its button, that two of their choices sit next to each other and read inconsistently, or that a sentence they translated as a fragment is actually a heading. Rendering the localized screens and putting them in front of the person who wrote them catches all three, and it catches them from the one person qualified to judge the fix.

This is cheap if your test suite already renders screens — capture them per locale and attach them. It is the localization equivalent of looking at your own pull request’s diff before asking for review, and it finds the same category of embarrassing, obvious problem.

The general principle behind both uses: the further a translator is from the running product, the more they are guessing. Every step that closes that distance pays for itself, and screenshots are the cheapest step available.

A workable policy#

• Comments are part of writing the string, not a follow-up task. Enforce it in code review the same way you would a missing test.
• Screenshots go up when the feature is built, from the test suite if possible.
• Questions get answered in the tool, never in direct messages, so the answer is visible to everyone and survives the person who asked.
• Project-level instructions cover the decisions that apply everywhere — formality, tone, brand voice — so they are not relitigated per string.

None of this makes translation faster in the moment. It makes it correct the first time, which is the only version of faster that matters.

One measurement is worth taking if you want to justify the effort: count the questions your translators ask, and how many of them are answerable from a screenshot. In most teams that have never supplied context, the majority are — is this a button or a heading, how much room is there, what goes in this placeholder. Each one is a round trip costing days of latency across every language, and each one is a question the translator should never have needed to ask.