In-depth practical guides

Build a multilingual journey acceptance plan

Test from discovery to decision: an acceptance plan connecting navigation, search, language switching, tools, forms and error recovery.

Updated :

Keyboard keys carrying multiple character sets.

Keyboard keys carrying multiple character sets. Documentary context photograph; it does not depict an Alexis Roux ZG assignment or equipment. © Alexander-design · Source · CC0. Resized and converted to WebP; cropped display.

Can a user complete their task in every language?

A translated page is insufficient if its menu returns to French, search ignores its words or the form produces an unexplained error. Test observable tasks and complete states. This complements text and URL reviews by examining what users can actually accomplish. The following situations are preparation examples, not claimed assignments.

  1. Inventory tasks

    List page families and actions: find a definition, compare sources, open a profile, compose a reference, calculate or make contact. Give each task a starting point, destination and expected result. Include secondary pages, not only primary menu entries.

  2. Describe covered states

    Include initial state, long content, active filter, no result, invalid input and recovery. Use clearly labelled synthetic data. For contact, separate local validation, safe server rejection and explicitly authorised delivery testing: do not send real messages by default.

  3. Follow language and context

    Enter through a deep profile and switch language. Check preservation of the entity, filter or selected source where relevant. Inspect lang, direction, labels and messages. Canonicals and hreflang describe equivalent versions; they do not establish that the switcher works.

  4. Test actual discovery

    Write representative queries for each script, with accents, variants and multiple words. Check relevance, result links, pagination and no-result states. A sitemap URL may still be hard to reach through navigation. Test related links and the route back to the section.

  5. Perform actions

    Use tools with a normal input and a boundary case. Compare output with the expected result and check reset, copy or export. Test forms by keyboard and errors near fields. Distinguish journeys working without JavaScript from functions requiring it, which should explain that requirement.

  6. Decide and retest

    Record expected and observed results, evidence and severity relative to the task. Fix the shared cause, repeat the failing case and affected languages and components. Passing acceptance means the defined matrix passes; it does not mean every possible use and device has been tested.

Situations and decisions

Typical situations for preparing a check. They do not describe completed assignments or actual observations.

Language changes but the profile is lost

From a selected source, the English button opens a default profile. Preserve the public entity parameter, then compare all six destinations. Do not put private notes or drafts in these URLs.

Search exists without being useful

An accented query misses an existing profile. Check normalisation and the language index, then multiple words, results and pagination. Equal record counts do not establish relevance.

A form error disappears

After rejection the message is off-screen or unassociated with the field. Check localisation, announcement, focus and retention of non-sensitive entries. Retest using a deliberately invalid submission that cannot send a message.

Record to retain

  • Case identifier, task, starting URL, language, state and test data.
  • Expected result, observed result and useful screenshot or HTTP response.
  • Defect, responsible component, correction and review date.
  • Matrix coverage and limits: delivery, physical devices and external services not tested.

Official references

Related protocols

Checks before reaching a conclusion

  • Does changing language preserve the selected record or public object without transferring a private form draft?
  • Does an error explain the problem, identify the affected field and allow recovery without losing useful information?
  • Can the journey still be completed by keyboard and without JavaScript for content that does not require it?

Frequently asked questions

Must every page be tested?

Inventory every route and language, then cover each template’s tasks and states. Add targeted checks for unusual profiles and parameters.

Should language switching preserve input?

Keep useful public context where intended. Avoid placing drafts or sensitive information in URLs; explain when an action resets input.

Is automated testing enough?

It detects reproducible regressions. Visual review and keyboard journeys remain necessary to assess readability, understanding and action order.

When is acceptance complete?

When the defined criteria pass and remaining defects are explicitly documented. Fix and retest defects blocking the priority task before approval.