21 · Language versions without a hub

A language version here is a separate instance: its own subdomain, its own worker, its own database. Not one site with a switcher but two sites that know about each other. The reason is the same one that makes the address belong to the author — the English version has to be able to live, fail or disappear independently of the Polish one.

That leaves the question of how they are to recognise one another. The language switcher has to build the address of the same text next door, and the slug is in the language of the content, so `zalozenia-wyjsciowe` and `initial-assumptions` have nothing in common as strings.

The first answer that comes to mind is a map: a file stating what corresponds to what. Rejected. A map is a structure somebody has to remember to update, and it will be forgotten precisely when somebody changes a slug — that is, at the moment it was the only reason for it to exist.

The second answer is more ambitious and worse: a central directory. One site knows every language and every mapping, the instances ask it and need not know about one another. It sounds like order. It is an intermediary — exactly the one this engine was built against. A site that has to ask somebody in order to assemble its own menu has a platform above it, even if the engine's own author runs that platform. Two practical consequences follow as well: when the hub is down the switcher fails everywhere at once, and the directory still has to learn the slugs from somewhere, so the map returns — only now in one place, from which it breaks everyone.

The solution reverses the direction of the question. Entries and series carry a `key` field — a stable identifier, shared across languages, deliberately neutral: `arch-21`, not the name of anything. Slugs may change, keys may not. The switcher assembles the address `<version>/i/<key>` and there its knowledge ends. The `/i/` route on the other side resolves the key to a local address and redirects.

The whole trick lies in who answers the question. The destination instance answers, because it is the only one that knows its own paths — and the only one that cannot be wrong about them. There is no map, because there is no place where a map would be needed.

The same route handles hreflang. At build time a script asks each neighbour about every key in turn: it receives a redirect or a 404, and assembles the list of counterparts from that. When a neighbour is silent, the build finishes with a thinner hreflang rather than an error — because somebody else's site being unreachable is not your site's outage.

There is one cost and it deserves naming: keys have to be assigned to every entry, and the later that is done the worse it gets. At thirty-four it is a script and one review of the diff. At a hundred and thirty it is the same operation that nobody will read.