Skip to main content
A portal declares which locales it allows and which one is the default. Every category and article in that portal has to live inside that declared set — you can’t write a category in a locale the portal hasn’t opted into.

Root and associated, not copies — for articles

The parent page already covers the core idea: a translation is linked to a root, not duplicated as an independent page. Here’s what that link actually does for articles. Categories work differently — see the warning below. Articles carry a root reference and a set of items associated back to it. When you create an article translation, you point it at any existing member of the family: the root itself, or one of its existing translations. Tied resolves the real root automatically and links the new one directly to it. A translation family stays one level deep: whichever member you point a new translation at, Tied links it to the root. A translation family stays one level deep: whichever member you point a new translation at, Tied links it to the root.
This is what stops article translation chains from forming. You can never end up with a Spanish translation of a French translation of the English original — pointing a new article translation at the Spanish version still links it straight to the English root, however deep the family already is.
Categories don’t get this guarantee. A category translation writes its root association straight from what you submit, with no automatic resolution — so pointing a new category translation at an existing translation, rather than at the root, links it to that translation instead, and a translation chain can form. Always point a category translation at its actual root yourself — Tied won’t correct it for you the way it does for articles.
Because a category’s slug only has to be unique within its own portal and locale, a translated category can keep the exact same slug as its root — they’re different rows, not competing for the same URL.

Where an article’s locale comes from

You don’t usually set an article’s locale directly. If it belongs to a category, it takes that category’s locale. If it doesn’t, it falls back to the portal’s default locale. Move an article into a category in a different locale, and its own locale moves with it.

How a reader gets routed

This is the detail worth knowing before you assume it works like a browser might.
A visitor who lands on the bare portal URL is redirected to your default locale — not to whatever language their browser is set to. There’s no automatic language detection. If someone should land in French, they need a URL that says so explicitly: a link from your own site, a language switcher, or a locale segment already in the address.
In practice this means your default locale isn’t just “the first one you happened to add” — it’s the one every reader sees unless something routes them elsewhere.

Plan the root first

Write your ten real questions before translating anything — the parent page makes that call. The reason it matters mechanically: retrofitting a translation structure means going back through articles and categories written independently and manually linking each one to a chosen root after the fact, reconciling whatever drifted between versions in the meantime. Doing it in order — write the root, then translate from it — skips that reconciliation entirely.

Next

Categories and structure

Nesting and locale scope.

Writing and publishing articles

Where an article’s own locale is decided.

Portal settings and custom domain

Where allowed locales and the default are actually set.