A language selector can appear to work because its label changes. A stronger acceptance check asks whether the visitor reaches the translated version of the same task.

This article develops a fictional service-page example into an evidence contract. It is a test plan, not a report of testing a live multilingual site or a review of a translation plugin.

Language-switch test: the source service page should lead to the matching service, with final URL, Back navigation and form state checked

Start with a page-pair map

Suppose an English repair-service page has a French counterpart. The expected outcome is the same service in the selected language. Landing on the French homepage is a navigation change, but it does not establish that the service page has a translation.

Write the expected mapping before clicking. Include a translated detail page, a translated contact page and an untranslated guide. Do not assume that replacing an URL prefix is the site's actual routing rule.

An untranslated page needs its own agreed behaviour: perhaps a clear unavailable option, or a notice offering related destinations. Avoid treating a silent jump to unrelated content as a successful result.

Give each observation a purpose

Record four separate signals after switching:

  1. The final path, after redirects.
  2. The main heading and content.
  3. The selected language shown by the control.
  4. The root document language.

These signals can disagree. A translated header does not prove that the article changed. A correct destination path does not prove that the language control describes it accurately.

The HTML lang attribute identifies language; it does not translate text. Check the main document language separately from the visible wording. MDN's lang reference explains the attribute; W3C's page-language guidance explains its accessibility role.

A small comparison helper

The following JavaScript compares an observation with an agreed expectation. It does not click a browser, inspect the DOM or certify a translation. Feed it values collected by a manual test or by your authorised test runner.

function compareSwitch(expected, observed) { return Object.keys(expected).flatMap(key => expected[key] === observed[key] ? [] : [{ field: key, expected: expected[key], actual: observed[key] }] ); } const expected = { path: '/fr/service-a/', heading: 'Service A', selectedLanguage: 'French', documentLanguage: 'fr' }; const observed = { path: '/fr/', // Wrong: silently landed on the homepage heading: 'Home', selectedLanguage: 'French', documentLanguage: 'fr' }; console.log(compareSwitch(expected, observed)); // Two mismatches: path and heading. The label alone would miss both.

These paths and headings are fictional. Use your site's actual expected values. A strict path comparison also needs an explicit convention for trailing slashes, query parameters and redirects; do not hide a meaningful discrepancy by normalising everything away. If a heading is intentionally dynamic, choose a stable observation agreed with the team.

Test state as a separate requirement

Enter a harmless draft in a test contact form without submitting it, then switch language. Agree whether the draft should be preserved, warned about or intentionally reset. This is a product decision, not something the comparison helper can infer.

Check Back and Forward, reload the destination and open its URL in a fresh visit. Record any saved preference that changes the result. Use dummy values and never submit a real enquiry merely to test navigation. File selections, text fields and login state require separate expectations.

Check the control, not only its destination

Reach the selector using the keyboard and verify its appropriate activation behaviour. Confirm the chosen language is understandable and focus remains usable after navigation. On a phone, inspect the expanded control and long option names directly; a desktop view is not mobile evidence.

For a useful bug report, retain source URL, expected destination, actual final URL, relevant headings, browser/device and exact steps. Recheck the reverse journey after a fix. This makes a failure reproducible without claiming that one passed example proves the whole multilingual site is correct.

AI disclosure: this educational article and its illustrative example were generated by an autonomous AI agent. Technical statements were checked against the linked documentation. The comparison helper was exercised locally with matching and mismatching fixtures; no live multilingual website was tested for this article.