Device Support Article Translation at Scale

Quick answer — Translate support articles by ticket volume rather than by catalogue coverage. Keep model numbers and error codes untranslated so search works, and connect translation to the publishing system so updates propagate instead of drifting.

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

The catalogue multiplies

A support site covering thirty products in twelve languages is not thirty articles. Each product has setup, pairing, charging, connectivity, troubleshooting, accessories, warranty and disposal content, and older models never leave.

The article count reaches four figures quickly, and translating all of it is neither affordable nor useful — most of those articles are read by almost nobody.

Translate by demand, not by coverage

Support ticket volume by market is the honest ranking signal, because it tells you where a missing article is currently costing money. Ten articles usually account for a startling share of contacts, and those ten deserve human review in every language while the rest do not.

Keep the searchable parts searchable

A customer searching for help types a model number, an error code, or a phrase they saw on the device. All three must survive translation untouched. A translated error code is unsearchable, and a translated model number returns nothing — this is the same do-not-translate discipline the spec sheet needs, applied to the place where the customer is already frustrated. The rest of the article should use the words customers actually use in that market, which are not always the words the brand uses.

Staleness is the real failure

A support article that was accurate at launch and describes a menu that firmware has since moved is worse than no article, and it is invisible until tickets rise.

Connecting the knowledge base to the publishing system so an English update triggers the localised versions is what prevents that. It also removes the manual step nobody owns, which is where the drift actually starts.

Flag articles tied to a firmware version so a release can surface what it invalidated.

Consistency with the product

Every article should use the same button names, LED states and feature names as the manual and the companion app.

Shared translation memory makes that automatic, and quality control can check every article against the glossary rather than a sample — which matters here because the volume makes sampling meaningless. Publishing that volume across markets is global content publishing.

FAQ

Which support articles should be translated first? The ones behind the most support contacts in that market. Ticket volume tells you where a missing article is costing money, and a small number of articles usually account for most contacts.

Should model numbers and error codes be translated? No. Customers search using exactly those strings, so translating them makes the article unreachable at the moment the customer most needs it.

What makes translated support content fail? Going stale. An article describing a menu that firmware has since moved is worse than no article, and it stays invisible until ticket volume rises in that market.

How do you keep support wording aligned with the product? By sharing translation memory and a glossary with the manual and the companion app, so button names, LED states and feature names resolve identically everywhere.