Session Replay for Localization Teams

A localized product is tested in a string table and broken on a screen. The German label fits in the spreadsheet and overflows the button; the Turkish placeholder was translated but the validation message next to it was not; the right-to-left layout is fine on the designer's monitor and wrong on a 360-pixel phone. Session replay for localization teams shows the product as users in each market actually see it.

This page covers what a localization team looks for in a recording, how the AnyReplay translation pipeline is built to keep interface strings short and correct, and how glossary terms and reviewed translations put the team in control.

The problem: localization bugs live in context, not in strings

Translation tools are good at strings and bad at layouts. A translated string is correct in isolation and wrong in a 120-pixel-wide button. A pluralized message uses {{count}} correctly in the source and loses the placeholder in translation. A screen gains a new label after the translation batch closed, and it ships in English to every market.

None of these show up in a review of the string table. They show up when a user in that market opens that screen on that device. Localization QA usually catches a sample by walking through the product in each language on a few devices; the rest are found by users and reported, if at all, as vague complaints.

How replay fits a localization workflow

Replay gives the team the walkthrough they cannot do themselves: real users, real devices, real data lengths, in every market. A localization engineer picks sessions from a market and watches the screens that were translated last sprint. Truncated labels, wrapped buttons, untranslated strings and overlapping elements are visible without anyone having to reproduce them.

Because AnyReplay records the DOM rather than a video, the recording carries the actual text, so a string that should have been translated can be found on every screen where it still appears in the source language. For React Native apps, the React Native SDK records the element tree with its text, so mobile screens can be inspected the same way, with two limits: images are recorded as boxes, and only the rendered rows of a FlatList are captured.

For the reverse direction, a reviewer who does not read the target language can turn on session translation and watch the same session in their own. The post on reviewing user sessions in another language covers that workflow; the product managers page shows how the rest of the team uses the same recordings.

What AnyReplay does for localization teams

A translation pipeline that respects interface constraints

Session translation is applied to the recorded event stream before replay, not to the rendered DOM, so seeking, restarts and later mutations stay translated. Strings are extracted with a context: heading, button, label, link, input, attribute or text. Translatable attributes are placeholder, title, alt, aria-label, aria-description and label. Opaque tags such as script, style, code, pre, svg and canvas are skipped.

The context drives register: a button is translated as a button, a heading as a heading. The model is told to keep each label as short as the original, to preserve placeholders such as {name}, %s and {{count}}, and to leave product names, URLs, email addresses and code identifiers unchanged. Results come back indexed, so a dropped item costs exactly one string, which stays in its original language rather than shifting every string after it.

Glossary terms pin your product vocabulary

Every organisation has a glossary: a term and its translation. Up to 200 entries are placed in the prompt and take precedence over the model's own judgement. An empty translation means the term is left exactly as it is, which is how you keep a product name or a feature name out of translation entirely. The glossary term entry describes the rules.

Translation memory with human review

Translated strings are stored per organisation in a translation memory, keyed on the target language and a hash of the whitespace-normalised source string with case kept. Sessions of one application repeat the same interface strings, so after a handful of recordings almost every string is already translated and costs nothing. A localization team can correct any entry; a corrected string is marked reviewed and is never sent to a model again. One translation job runs per session per target language, so asking twice reuses the first.

A dashboard in five languages

The dashboard ships in English, Turkish, German, Spanish and French, with every locale carrying the same keys, so a team reviewing translations does not have to do it in a tool that only speaks English.

Privacy controls that survive translation

Passwords, one-time codes and payment fields are never recorded, and by default the value of every other field is masked too, email and phone fields included, in the browser, so what the translation pipeline sees is the interface rather than the user's data. Elements carrying the ar-block class are not recorded at all. The privacy page has the full model.

Getting started

1. Create a project. The Free plan includes one project and 500 sessions per month; see pricing for the current plans.
2. Install the web SDK snippet, or run npm install @anyreplay/react-native for a mobile app.
3. Add product names and protected terms to the organisation glossary before the first translation job, with an empty translation for terms that must stay as they are.
4. Ship, then pick sessions by market and watch the screens that changed in the last release.
5. Correct any translation the team disagrees with; it is marked reviewed and reused from then on.

Frequently asked questions