Translated Page, Stale HTML Language? Test lang Across Regional Routes

A regional landing page looks fully translated, yet its document still declares the previous language. A screenshot and a successful proxy request will not expose that mismatch. For authorized website QA, compare human-reviewed content with the language metadata that browsers and language-aware tools receive. This guide is a controlled acceptance design, not a claim about tested 98IP pages or assistive-technology compatibility.

1. Define the expected content language independently

Choose owned staging pages with reviewed English, Simplified Chinese and Traditional Chinese content. Agree on the default language tag for each fixture and on any intentionally different-language passages. For example, an owner may choose en, zh-Hans and zh-Hant for those fixtures. These are examples of language and script intent, not a rule that every regional site must use the same tags.

Use a valid BCP47 tag that actually describes the content. A country, IP location, translated selector label or URL folder is not sufficient proof. Do not invent a language code from a market code or replace hyphens with locale-library underscores. Tag validity and correctness for the text are separate checks.

Create an independent expectation sheet: page/route ID, reviewed dominant language, approved tag, two representative passages, intentional language changes and build version. Do not generate the expected answer from the same route-to-tag mapping being tested. A language attribute does not translate the text or prove all of it is localized.

2. Inspect the root and inherited passages separately

For pages served as HTML, inspect the lang attribute on the html element to identify the declared default. A body-only declaration does not cover the document head. Record the raw attribute from the response and the current live DOM after application readiness; a script may change one without the other.

An element without its own language declaration can inherit language. Do not mark every paragraph as unknown merely because paragraph.lang is empty: the HTMLElement.lang property reflects that element's own attribute, not its inherited language. Inspect the relevant ancestor declarations as well as local overrides. An explicit empty lang value sets language to unknown, so it is not equivalent to simply omitting a child attribute.

For a reviewed foreign-language passage, inspect the surrounding element's language declaration and its intended scope. Avoid tagging an entire form as another language when only a short explanatory passage differs. Do not add overrides to every product code or proper name mechanically; establish what the content actually needs with its reviewer.

3. Run a route-and-state acceptance matrix

1. Load the owned English fixture through an approved baseline. Wait for a concrete page/build marker and independently reviewed heading/body content. Record final URL, response root declaration and live root declaration.
2. Inspect an ordinary unmarked paragraph under the root and a separately marked foreign-language passage. Confirm the intended inherited language and local override, rather than comparing only each element's own lang property.
3. Switch locale through the real site control or supported route. Verify the new title, heading, body and approved root tag after readiness. A changed selector label alone is not a language switch.
4. For a single-page application, test both direct loading of the localized route and switching to it from another locale. Return to the first locale and check that neither root metadata nor passage overrides remain stale.
5. Run an isolated negative fixture with reviewed Chinese text but the old English root tag. The content/tag comparison should flag it even though the page renders normally. Correct only the owned fixture's declaration/mapping, then rerun the positive and negative checks.
6. Repeat through the required residential region using equivalent browser preferences, account state, storage and build version. Record actual egress. Change one dimension at a time so a locale preference is not mistaken for an IP effect.

These outcomes are expectations until observed. Do not change a real user's language preference or consent state as a shortcut. If a direct baseline or a localized route is unavailable, record that limitation. For embedded documents, inspect each relevant document's declaration and content separately.

4. Keep language, alternate links and direction distinct

A language switcher, alternate-language link or Content-Language metadata is not a substitute for the HTML default-language declaration. The related hreflang cluster validation guide addresses alternate-page relationships; it does not establish the language inherited by a passage in the current document.

Likewise, language and writing direction are different properties. Do not assume a language tag alone sets the required direction for bidirectional content, or change direction merely because the exit country changes. Review direction in a separate fixture when it is relevant.

Do not repair a missing root declaration by inserting a meta http-equiv Content-Language element. Fix the owning HTML template or application mapping and verify the actual deployed markup. If the document is served as XML/XHTML, consult that format's language-attribute rules separately rather than applying this HTML-only checklist blindly.

5. Diagnose the first mismatch and verify real use carefully

• Text is translated but root tag is stale in the response: inspect the server template, cache variation and route mapping.
• Response tag is correct but the live DOM changes it incorrectly: inspect hydration and client locale state.
• Root is correct but a paragraph inherits a stale local override: fix that component's declared language scope.
• Tags agree but content is partly untranslated: return to content localization; metadata cannot repair missing prose.
• Only one region differs: compare final route, redirects, account/browser locale, storage and deployed build before blaming the IP.

Where the project includes screen-reader testing, record the browser, assistive tool, voice availability and settings, then have a reviewer check representative passages. Correct metadata can support language-aware pronunciation, but it does not guarantee every name is pronounced correctly or certify the site's overall accessibility. Report missing voices or unsupported behavior honestly, and keep that observation separate from the markup check.

Retain only page/build IDs, approved and observed tags, reviewed passage references, response/live-DOM differences, route transitions and egress evidence. Avoid customer content, cookies, authorization headers and proxy credentials. Preserve the mismatched negative control after correction so a check that merely tests for any nonempty tag cannot pass.

6. Use 98IP for a controlled regional comparison

When authorized localization testing needs a residential network perspective, consult the 98IP residential proxy product page and API configuration documentation, then use the method and parameters supported by your account. Keep the session policy stable while comparing the same language fixtures and check actual usage.

A proxy supplies a route; it does not set the page's HTML language, translate content or guarantee browser/assistive-tool behavior. An ordinary non-intercepting HTTPS proxy cannot rewrite the encrypted document's lang attribute. Limit synthetic traffic and respect site authorization.

• Reviewed content and approved language/script tags are independently documented.
• Response and live-DOM root declarations match the intended page state.
• Inherited language and local passage overrides are distinguished from own-attribute properties.
• Direct load, locale switch and return transition agree on content and metadata.
• The wrong-language negative fixture is detected, not just a missing tag.
• Alternate links, direction and real assistive-tool observations remain separate checks with clear limitations.

Does a correct country exit prove the document language? No. Inspect the actual content and declaration.

Must every paragraph repeat the root tag? No. Check inheritance and intentional overrides.

Does a valid tag prove full localization or accessibility? No. It is one metadata check within a broader reviewed workflow.