Declare a website’s content language: page defaults and mixed-language passages

Inventory the content that is really published

Read the page heading, paragraphs, navigation, forms and repeated footer. Note the dominant content language and any meaningful passages in another language. Do not infer the whole page from the address, flag icon or language of the WordPress administration interface.

For the museum, retain the English guide and identify the French quotation as a separate passage. If the surrounding controls remain in an unintended language, that is a content-workflow issue as well as a markup review. A declaration cannot make untranslated text understandable.

The translation workflow guide helps separate page content, template strings and publication responsibilities. Use it when a real translation is missing. Avoid treating a metadata edit as proof that the translation work is finished.

Set the default at the correct scope

W3C’s HTML language guidance explains declaring the document language on the root html element and changing it for appropriate passages. The default should represent the actual document, while a local declaration describes the content within its own scope.

Ask the maintainer which theme or publishing setting supplies the root declaration. A page editor may control article text without controlling that outer document. Identify the responsible layer before adding a competing setting that only affects one inner block.

In the example, agree which system owns the English page default and where the quotation’s local language is stored. Keep the rule visible in the content workflow so a future copied page does not inherit a declaration that contradicts its new text.

Use a language value, not a guessed country label

MDN’s lang reference describes a BCP47 language value and inheritance through the document. A regional distinction should reflect a real language choice; a visitor’s location alone is not a reason to relabel the text as another language.

Use the supported language values and controls provided by the publishing system. If the interface offers unfamiliar choices, confirm their meaning in its documentation rather than invent a custom abbreviation. Keep a simple content record naming the intended language and the affected scope.

Inspect descendants when the output is wrong. A correct root value can be overridden by an inner element, while a copied block can retain an old local declaration. Compare the relevant public markup with the editor’s stored intent rather than checking only one outer field.

Mark meaningful language changes without over-labeling

For the museum quotation, declare the actual passage language through the supported content controls or maintainer-owned markup. Keep the quotation and its explanation associated. A local declaration should not accidentally include the following English section because its boundary is too broad.

Do not mechanically relabel every unfamiliar proper name, technical token or borrowed word. Review what the passage means and consult the relevant language guidance where the case is uncertain. Useful language information follows the content’s reading context rather than a list of words that look foreign.

If an embedded component has its own document, ask its owner to review that content separately. An outer page setting is not evidence that every independently supplied component has appropriate language information. Record unavailable inspection as a limitation.

Verify the published page, not only the setting

Reopen the public page after saving through the normal publishing flow. Have the maintainer inspect the root and relevant passage declarations, including repeated templates. Confirm the visible text still matches the declared intent and no unrelated section inherited the quotation’s language.

Where appropriate, review the actual reading journey with supported assistive technology and language support. Do not promise identical pronunciation across all devices or voices. If that review was not possible, distinguish the verified markup from the untested spoken experience.

Carry the decision into future publishing

If the product changes a page’s language after an interaction, inspect the resulting state as well as its first load. In a hypothetical English-to-French switch, the new visible content and the document declaration should be reviewed together. A correct initial response does not establish that a later rendered state kept its language information aligned. Ask the maintainer to document which layer updates that information, and avoid assuming a flag icon or selected menu option proves the whole document changed correctly.

Add the default and local-language checks to translated-page review, rather than rely on one person remembering a hidden theme field. The multilingual page-check guide addresses the separate discovery relationships between genuine variants.

Keep a small example page and the intended declarations in the handover. When templates, imported content or translation tooling change, inspect that representative output again. The result should be language information that accurately follows the published content, without claiming a universal voice, translation or search outcome.