When translated documentation falls behind, what should readers see?

How we researched this

We inspected CSA Research's original consumer findings and methodology account, current Kubernetes and MDN localization guidance, W3C language guidance and two Google Search Central references on November 6, 2026. We synthesized a proposed publishing and review policy and constructed a fictional connection-guide change and coverage calculation. No customer content, live product migration or original user experiment was used.

What does the research say about language preference?

CSA Research's July 2020 release reported that 76% of 8,709 surveyed consumers across 29 countries preferred the product with information in their own language when choosing between two similar products. The same release reports a counterweight: 66% would choose the cheaper product even without information in their language. These answers describe stated buying preferences under different conditions. They do not measure whether someone can configure an integration from a translated guide. CSA consumer findings

The firm's methodology account says its screening reduced 31,933 consumer responses to the final 8,709-person sample, with country, age and gender criteria. That matters when repeating the statistic: the headline results are presented against a screened sample of 8,709, and come from 2020. We did not access respondent-level data, verify question-specific response counts or weighting, or reproduce the survey analysis. CSA methodology

For a docs team, the evidence supports taking language choice seriously while leaving a second question open: which page helps this reader complete today's task? A current source-language page and an outdated translation differ on two dimensions at once. A preference survey cannot tell you which combination will work for a particular administrator facing an unfamiliar configuration screen.

Consider a reader who understands the product terminology in English but wants explanatory prose in Spanish. They may need the English label of a button so they can find it in the application. A polished translation that substitutes an invented Spanish button label could make the action harder to locate. Another reader may understand the localized UI and need the localized label. Record which interface the guide describes.

This is why our proposed policy starts with task correctness and then makes language availability explicit. It leaves room for a reviewed local-language explanation, a clearly labeled machine translation, or an offered source-language route. Each option needs its own checks. No single preference percentage establishes that an obsolete procedure is acceptable, or that replacing it with English will work for everyone.

Why does a recent update date fail to establish freshness?

A translated page can be edited today and still describe an earlier product release. The edit might fix punctuation, replace a logo or regenerate a machine translation from the wrong source. Conversely, a page translated months ago might remain fully applicable if its source procedure has not changed.

Track the relationship between the translation and the source revision reviewed for it. Record the product release or operating conditions independently. In the internal record, “reviewed against source revision A” is more informative than “last modified Tuesday.” A source edit then creates a defined review question: does the difference from A change the task this translated page promises to explain?

These fields are a proposed maintenance record, not a requirement imposed by a language standard. They can live in a content system, a pull request or a small registry. Their value depends on being updated when the content changes.

Use change categories that correspond to review work. A corrected command, new permission prerequisite or changed deletion warning needs a different response from a reformatted paragraph. Ask the product owner to identify the behavioral change before sending a translator an undifferentiated diff. Otherwise the most consequential sentence can be buried among layout changes.

Review dependencies as well as the body. A diagram might contain the old order of steps. A shared snippet might have changed without touching the page file. A screenshot caption may be translated while the screenshot still shows the previous control. Decide which dependencies are part of the reviewed revision, and make an unresolved dependency visible in the record.

What do established documentation projects make explicit?

Kubernetes permits localization to start with a defined minimum set of content and expand over time. Its contributor guidance says machine-generated translation alone is insufficient and calls for careful human review before publication. It also describes language-specific content directories. This is an operating policy for that project, not a measured universal threshold for translation quality. Kubernetes localization guidance

MDN's localization page distinguishes community-maintained locales from experimental machine-translated German and Italian locales. It also describes archiving other locales after unmaintained and outdated translated content accumulated around its 2020 platform transition. The page we consulted was last modified May 31, 2026. These choices show that published locale coverage includes ownership and maintenance decisions, not simply a count of generated pages. MDN localization

There is no need to copy either project's entire operating model. A small product can begin with the tasks its target audience needs most. The important decision is what happens after the source changes and the translator is unavailable.

Write that decision down before launching the language selector. Who reviews a warning that changes meaning? Who can mark a page as temporarily unavailable? Where does the user land if there is no replacement? A locale with one maintained onboarding path can be more intelligible than a large collection of pages whose status is unknown, but this is a proposed product choice to test with readers.

Assign both a language reviewer and a product reviewer for consequential instructions. One person may fill both roles when qualified. A linguistically fluent reviewer can miss a changed permission rule, while a product engineer may miss an ambiguous negation. Ask each reviewer to state what they checked.

Avoid treating “human reviewed” as a permanent badge. Record the scope of the review and the source revision it applies to. If an automated process later rewrites the procedure, the earlier review cannot describe the new text. Keep the same discipline for manually edited translations.

A worked example: a connection guide changes

Imagine a fictional analytics product with a guide called “Connect your reporting account.” The English source at revision A describes the existing flow. Its French translation has been reviewed against A. A later source revision B adds a required workspace-owner permission and changes the confirmation screen. The French page still tells any member to complete the connection.

The translation is now missing a prerequisite that affects whether the reader can complete the task. A word-diff alert can identify the edit without deciding what to publish. A task review makes the consequence explicit: a member following the old instructions can reach a permission failure with no explanation.

The table is a proposed decision aid. It does not estimate how often these changes occur or prove that a particular fallback is safe. The reviewer still has to confirm the effect in the actual product.

For revision B, a small reviewed correction might be enough. A qualified reviewer can add the permission requirement, update the screen reference and check that the remaining steps still apply. Record that the review covered the complete procedure, including any reused instructions. Translating one new sentence while assuming the rest is unchanged is appropriate only after checking that assumption.

If the team cannot review the correction in time, remove the misleading claim that any member can proceed. Offer a current source-language guide and an understandable explanation of its language. If the source itself has not been verified against the release, fix that first. Falling back to an unverified source merely moves the uncertainty to another page.

Keep the underlying page identity stable where possible. The temporary state belongs to this task and locale, so returning readers need a clear route back when the translation is ready. A generic language homepage makes them repeat the search and hides which article was unavailable.

What should the reader see while a translation is being reviewed?

A status notice should explain the consequence and offer an action. “Translation out of date” leaves the reader to decide whether the old steps are harmless. “This guide is being updated for the new workspace-owner requirement. Open the current English guide” is more specific. Have the notice itself reviewed in the reader's language, especially when it concerns permissions or irreversible actions.

Use different treatment for different states. A page with a pending wording correction can remain useful. A page with a known wrong command needs stronger intervention. A page available only for an older product release may be correct within that release and should be labeled accordingly.

The appropriate action depends on what is wrong. Withdrawing an unsafe procedure does not require hiding all of its surrounding explanation. Equally, a small warning at the top may be inadequate if search links land directly on an obsolete command farther down. Test both the article entry and the deep link.

Make language and release two separate choices. Switching from French to English should not silently move a reader from release 2 to release 3. If the requested combination does not exist, explain that before showing a different one. Preserve the task destination when possible, including a meaningful section anchor.

Treat the reader's explicit choice as meaningful. A browser setting is useful context, but a person may be reading on a shared device, following a colleague's link or comparing terminology. The fallback should remain discoverable without making that choice impossible to override.

How should language labels and search reflect the actual page?

W3C's language-declaration guidance calls for a default language on the HTML root element and language attributes around content that uses another language. It also notes that bidirectional text needs direction handling. These declarations should describe the text actually rendered. An English body inside a French navigation shell needs deliberate markup rather than an assumption that the URL determines every element's language. W3C language declarations

Google recommends separate URLs for language versions and advises against automatic redirects based on an inferred language. It determines page language from visible content, and warns about translating only the surrounding template while leaving the main content in another language. Its guidance also encourages links that let readers choose another version. Google multilingual-site guidance

Google's alternate-page guidance says language versions should identify themselves and their alternates, with reciprocal links. It provides equivalent HTML, HTTP-header and sitemap methods. An annotation does not review the translated instructions or establish their product compatibility. Google localized-version guidance

Apply those distinctions to the fallback. A language-switch option should tell the truth about what it opens. A localized title attached to an English body can promise more than the destination delivers. An alternate link to a locale homepage does not identify a translation of the original task.

Internal search needs the same clarity. Decide how the result identifies the content language, applicable release and temporary state. If the main result is a translated article with a known wrong procedure, a short excerpt can conceal the warning. Review the result itself and its deep link, not just the full page.

For a practical check, search for the same task in the source language and the target language. Follow the result, switch language, and return using the browser's Back control. Record where the task or release changes unexpectedly. These are proposed acceptance checks for the navigation, not a claim that every query should return equivalent rankings.

When a page is replaced or temporarily withdrawn, review its links and search configuration together. Content owners should make a deliberate publishing decision about the affected URL. A navigation label, an indexing annotation and an article-status banner serve different purposes, so changing one should not be assumed to update the others.

What should a localization dashboard measure?

A raw count of translated pages measures coverage. It does not tell you how many pages describe the supported product, how many consequential changes await review, or whether readers can complete the key tasks. Keep those questions separate so the dashboard does not reward publishing more unverified material.

Consider a fictional site with 100 source pages and 80 translated pages. Suppose the editor identifies ten essential onboarding tasks, of which six have current reviewed translations. The translated-page coverage is 80 of 100, or 80%. The reviewed essential-task coverage is six of ten, or 60%. These denominators answer different questions. Neither figure measures task success, and the numbers are illustrative rather than observations from a product.

A fallback click cannot tell you whether the English instructions worked. A low click rate might mean readers stayed with the translation, missed the option or left. Use the event as a lead for investigation, then inspect the task and ask readers what they expected to happen.

For a focused reader session, define one outcome such as finding the required permission and reaching the correct configuration screen. Ask the participant to explain the next action before carrying it out in an appropriate test environment. Record whether the difficulty comes from language, product access, stale instructions or navigation. Preserve the distinction between a discovered failure and an estimate of its prevalence.

Review demand alongside maintenance capacity. If a team cannot keep an essential workflow current, adding more languages increases the number of publishing decisions it must manage. Start with the task set that has an owner, a review path and an explicit fallback. Expand when the team can maintain those commitments.

A release check for translated documentation

Before publishing a source change, identify the translated tasks it affects. Give each change an owner and record whether it changes actions, prerequisites, examples, screenshots or only wording. That list creates the translation review queue and the temporary reader states.

Before publishing the translation, check it in the actual layout. Long labels can wrap, tables can become difficult to read, and a copied command can accidentally acquire translated punctuation. Verify product labels, command literals, links and expected outputs in addition to prose. For right-to-left content, inspect mixed-direction identifiers and code with reviewers who can use the target language.

Check that status is conveyed in text rather than color alone, that the notice precedes the affected instruction, and that language controls work with a keyboard. These are proposed acceptance checks, not results from a reader study.

Then take the ordinary reader routes. Open the article from a shared URL. Follow a search result to a section. Switch language while viewing an older release. Try a language with no current page. Inspect the status notice on a narrow phone. Confirm that each route makes the content's language and applicability understandable.

Close the change only when the public state matches the review record. If the source is current but a translation remains pending, keep that distinction visible in the publishing system. If a translation is restored, remove the temporary notice and check the routes that previously offered fallback.

The operating goal is a specific promise: when a reader chooses a language and a task, the site either supplies maintained instructions for that context or clearly explains the available route. That promise is easier to review and sustain than treating every translated file as permanently finished.

Limitations

The consumer study reports stated purchasing preferences from 2020, not measured documentation comprehension. Public project policies demonstrate operating choices rather than comparative effectiveness. Our proposed states and checks have not been validated across languages or products. The fictional coverage figures illustrate denominator choices and cannot establish reader success. Language, accessibility, product and legal requirements may need separate specialist review.