Closing translation gaps in the shop after updates

Translated text rarely lives in one place in a shop. The core brings its own snippets, every extension brings more, the theme adds another set, and on top of all that sits the layer where the operator has adapted individual wordings to the house style. An update reaches straight into that stack: it creates new keys, renames existing ones, removes those no longer in use and ships a version of all of them in the language the vendor maintains. Your own adaptation on top either stays behind and points to a key that no longer exists, or it is overwritten by the shipped version. Neither is a defect; both are the expected outcome of an upgrade — and neither shows up in a functional test.

The commercial lever behind this is well documented. In a survey of 8,709 consumers across 29 countries, 76 percent (CSA Research 2020) said they choose the product with information in their own language when two offers are comparable, and 40 percent (CSA Research 2020) state they do not buy from websites in other languages. In Germany the share of shoppers who buy exclusively at sites in their own language was the highest of all countries surveyed at 57 percent (CSA Research 2020). A fourth figure from the same study matters most for maintenance: 67 percent (CSA Research 2020) tolerate mixed languages on a website. They do not complain — so the shop hears nothing about the gap. Anyone who aims their update testing after upgrades at functions checks checkout, login and search, but not whether checkout speaks the same language in every enabled locale.

If a snippet is missing in the requested language, the shop system works through a chain: first the exact locale, then the parent language without the regional part, then the configured fallback language, and finally the system language. Only if nothing is found there does the shop output the key itself. The chain makes sense because it prevents an empty page. It is also the reason a gap stays undetected without deliberate measurement. For operations that means the fallback should not be switched off, it should be counted. The same logic applies to maintaining the shop search, where an empty result set likewise produces no error and is still an open task.

For sign-off that leads to a plain rule: a language version counts as checked once somebody has read it in that language. This is more work than it sounds, so it can only be afforded for the paths where money is involved — product page, basket, checkout, order confirmation. Counting carries everything else. Those paths include the order button itself; how its label is to be judged in legal terms is covered in the article on the withdrawal button in the shop.

Updates change the interface, imports change the catalogue. In both cases new text appears, and in both cases it appears in one language first. A product import from the merchandise management system delivers names, descriptions and features in the language that system carries; the secondary language stays empty for every record with no counterpart there. This goes unnoticed as long as the catalogue is growing, because the new articles simply appear without a description in the secondary language. The scale is large enough to deserve attention: gross merchandise volume in German online retail reached 83.1 billion euros (bevh) in 2025, and turnover in mail order and internet retail rose by 10.1 percent (Destatis) in real terms in 2025 year on year. For bilingual catalogues, upkeep of the secondary language is therefore not a side issue but the same kind of work as legal text maintenance — only with more records.

The table reveals a regularity: every gap has a triggering event, and that event is known before the gap appears. This makes the check plannable. It does not belong in an appointment of its own but at the end of the process that causes it — at the update, at the import run, at the release of a new payment method. Anyone running a staging environment can pull most of it forward and only spot-check the live environment afterwards.

A check run only one person knows about is a favour. It becomes maintenance once the sequence, the ownership and the reporting route are written down. Five steps are enough for that, and they can be attached to existing ongoing monitoring instead of creating a separate process.

Whether this sequence runs in house or is outsourced makes no difference to its structure. What matters is commitment: anyone anchoring language upkeep in a maintenance contract with committed response times gets it at the same regular intervals as backups and upgrades — and does not have to start it off each time.

Experience from maintaining multilingual shops can be summed up in one sentence: the language state is not a condition but a balance. Every update, every import and every new payment method books text onto one side, and only upkeep books against it on the other. If the counter-entry is skipped, the gap grows slowly and without a signal — until a customer asks or a language version is replaced by another in search results. That the markup itself is no edge case shows in the 13.5 percent (WebAIM Million 2026) share of the most visited home pages with no document language declared.

The effort is manageable as soon as it is attached to existing processes: two queries, one pass through checkout per language, one reconciliation of references. What makes it expensive is moving it into the incident. A language gap that surfaces during the order process turns into a job for emergency support — the same amount of work as before, only under time pressure and with revenue at stake.

For operators with two or more language versions this is the practical core: the fallback stays active because it rescues the purchase. It is measured anyway, because otherwise it conceals the gap it bridges. Two numbers per language, one pass per update and six lines in the report are enough to turn an invisible task into a visible one.