Companion App Localization for Devices

Quick answer — A companion app has to use the same names as the hardware and the printed guide, and it ships on the firmware release train rather than its own. Pairing, permission and error strings carry the most support risk.

Vitra.ai Universe keeps one product vocabulary across box, app, page and video.

It has a physical dependency

A normal app answers to itself. A companion app answers to a device, which means its strings are constrained by objects the customer can see. If the housing is silkscreened PAIR and the box calls it the pairing button, the app cannot invent a third name in any language. Those names come from the shared glossary, and the app is a consumer of it rather than an owner.

Three string sets, three risk levels

Onboarding is highest because it is the only screen set read simultaneously with another translated asset. Everything visible during setup should be reviewed against the printed guide, in the same language, side by side.

Errors are product content

"Connection failed" is not a message, it is a shrug. A message that names what failed and what to do next resolves the situation without a ticket, and that is as true in translation as in English.

Two rules make translated errors usable. Keep any error code untranslated and searchable, so the customer can paste it and find the support article. And translate the recovery action as an instruction, since a fluent restatement of the problem helps nobody.

The firmware train

The app is released against firmware versions, so its strings are gated by a hardware schedule rather than an app-store one.

That schedule is less forgiving. A string that misses the cut waits for the next firmware window, which can be a month or a quarter, and shipping the English fallback in the meantime is visible to every customer in that market. Continuous localization is the answer to the cadence, and over-the-air string delivery is the escape hatch for the typo that cannot wait.

Practical setup

Run mobile app translation on the resource bundles with the device glossary pinned, so hardware names resolve identically to the guide and the packaging.

Set a length budget per string at design time rather than fixing truncation at QA — buttons and toggle labels are where expansion actually breaks the layout.

Then complete a real pairing flow on a physical device per shipped language. Quality control checks the strings; only a device walkthrough catches a permission prompt that arrives in the wrong order or a state label that no longer matches the LED.

Screens built into the product itself are harder still, because the layout cannot reflow — infotainment string translation. Strings that ship with a build sit inside software localization.

FAQ

How is a companion app different from a normal app? Its strings are constrained by physical objects. Button names, port names and LED states are silkscreened or printed, so the app has to use the same names as the hardware and the guide in every language.

Which companion app strings carry the most risk? Pairing and onboarding, because they are read alongside the printed card, and error messages, because that is where support tickets are created or avoided.

Should error codes be translated? No. Keep the code untranslated so a customer can paste it into search and reach the right support article, and put the translation effort into the recovery instruction instead.

Why is the release cadence harder for companion apps? Because they ship against firmware versions rather than their own schedule. A string that misses the window waits for the next firmware release, so continuous localization and over-the-air string delivery both matter.