Four kinds of work, and the edges of each

Buttons, menus and navigation, form labels and helper text, empty states, confirmations, notifications and error messages. Each string is translated against the job the element does and the screen it appears on, because the same source word rarely means the same thing on a button, in a heading and in a warning.

Terminology is agreed before the bulk of the work starts. We write down the terms your product relies on and how each one should be rendered, you correct it, and that list is then held to across every screen in scope. It is the single cheapest way to prevent the same idea being named two different ways in two different places.

Where a string cannot be resolved without knowing more - a fragment assembled in code, a word that is both a noun and a verb, a label whose meaning depends on a state we cannot see - it comes back as a query rather than as a guess.

Every design contains a quiet assumption: that the label is about this long. Translation breaks that assumption, and it breaks it unevenly - some strings shorten, some grow by half again, and the ones that grow are rarely the ones with room to spare.

We go through the screens in scope against the translated strings and mark what happens: which controls have to grow, which rows have to wrap or stack, where a fixed width has to become a flexible one, where a truncation is acceptable and where it removes the only part of the sentence that mattered.

The result is a set of decisions for your designers and developers to take, not a redesign. Each note names the element, says what the text does to it, and suggests the smallest change that resolves it.

Files can be perfect and screens still wrong. Strings never reach the build, a fallback shows the source language, a container that was flexible in the design is fixed in the code, a date is formatted by whatever the server happens to be set to.

The pass covers strings left untranslated, text cut or overlapping, controls pushed out of their row, terms used inconsistently between screens, writing direction problems, and dates, numbers, addresses and phone fields that do not match the agreed locale.

Everything found is written down with the screen it was found on and a suggestion for what to do about it, so the list can be worked through, argued with, or handed straight to whoever fixes it.

Where a team wants the findings applied rather than delivered, that is a separate item in the scope, with its own price. Nothing is implemented on the assumption that it was implied.

Without it, the work ends with translated files, annotated designs and the report. That is the default: the people who know the codebase make the changes, and the notes are written so that they can.

Where implementation is included, how we work in your code, what is reviewed and by whom is settled case by case before it starts.