Documentation

Editors reach page sets in two places, and there is a third that checks the language configuration behind them.

The mechanics are the easy part. The judgement call is which pages belong together, and there is one rule: link pages that serve the same purpose, not pages that contain the same words.

A page belongs in a set with another when it covers the same topic or purpose, is the direct counterpart in its language or region, and sits at a comparable place in the page tree. The German page "Produkte" belongs with the English "Products"—not with "Services", and not with "Über uns".

They do not have to be identical. Markets write their own copy, drop sections, and add local ones. What has to match is the job the page does for a visitor in that market. A set of pages that are merely similar is still correct; a set of pages that answer different questions is not, however similar the text.

• Start with the market that has the most content. It is the tree every other one will map onto, so it decides the shape of the sets.
• Go page by page, in tree order. Jumping between areas is how pages get missed, and a missing entry invalidates the whole set for every page in it.
• Be consistent. If two equivalent pages exist, link them—leaving one out is a decision search engines will read as an answer.
• Come back to new pages. A page added after the set was built is not in it. The overview module filter "pages without hreflang" is the shortest way to find them.

Off by default:

With it enabled, the page module shows a check of the language configuration of the current page’s root page group. It collects the hreflang codes of every site language across the root pages in that group and reports any code that appears more than once—the situation that makes a set invalid.

The output is either "Hreflang configuration for this page is valid." or "Configuration is not valid!" followed by the duplicated codes and the sites that claim them.

What it does not do: it does not show the resolved tags, the URLs, or the page set itself. It is independent of any page set and returns the same result on a page that has none. It answers "can these root pages form a valid set at all", not "is this page’s set correct".

Despite the name it is not a developer switch—it is the only backend surface that surfaces duplicate language codes, which are otherwise invisible until the tags are wrong in the frontend.

Saving a set reports the three validation errors described in What Is Checked When a Set Is Saved: a missing x-default, an x-default outside the set, and more than one page from the same root page.

The last one rarely happens while building a set—you would have to pick two pages from the same tree on purpose. It shows up later, when a page is moved between root pages and lands in a tree the set already covers. The set was valid when it was saved and is not any more, and the error appears the next time someone edits it.

Two situations produce no error message at all and are worth knowing:

• The field is not there. See the note under Page Properties above.
• A page cannot be selected. Either its root page is in a different group, its doktype is excluded, it is already referenced by another set, or it sits outside the page tree of the chosen root page.