A language belongs to the address, not to the visitor
Capell resolves the site from the incoming URL, and the language arrives with it. A request header never changes what a given address returns, which is what makes per-language URLs safe to link, cache, and submit to search engines.
That much the software guarantees. Authoring the second language is still work your team or your translators do, and the sections below are explicit about where that work starts and what it does not include.
A language in Capell is a property of the address a visitor arrived at. Give a language its own domain, or a /xx path prefix under an existing one, and every page in that language has a stable URL that returns the same content to every visitor and every crawler.
From that one decision the public behaviour follows: the document language and text direction, the interface strings and dates rendered for the request, the per-language page slug, the canonical URL, and the hreflang cluster in the head. A site with a single language emits no cluster, because there is nothing to point at.
What Capell does not do is write the words. Adding a language creates its address; each page still needs its own translation authored, and the tooling that helps is a set of language tabs, a completeness reading, an out-of-date badge, a missing-language filter and a CSV export for translators.
Leave visitor language detection off until the pages a visitor needs are actually translated. It is off by default for that reason.
What a second language changes on the public site
Adding a language creates a site domain for it, or a path prefix under the current one, and page slugs are stored for each language separately. Everything below follows from that single decision.
Add the language before you add the detection
Adding a language in the admin creates the site domain or the /xx prefix and copies the site's own record into the new language. It does not translate your pages. Each page still needs its language authored, and a page with no translation for a language stays out of that language's hreflang cluster until someone writes it.
Because of that, visitor language detection is off by default, and there are three settings to choose between:
- Off. The visitor stays on the address they asked for. This is the right setting while translation is in progress.
- Banner. A dismissible suggestion that a version exists in the visitor's language. Nothing navigates on the visitor's behalf. This is the recommended setting once the key pages are translated.
- Redirect. The visitor is sent to the equivalent page. Google's own guidance recommends prompting rather than redirecting automatically, so treat this as the option with a cost attached. It is also best effort behind a CDN, because a response served warm from an edge cache never reaches the application. Banner mode is unaffected by that.
Redirection only ever goes to the exact equivalent of the page the visitor asked for. Where there is no sibling address, nothing happens. Visitors are never dropped on a language homepage they did not ask for.
While the translation work is running, the admin gives editors something to work against: language tabs carrying a completeness percentage, a badge marking a translation as out of date against its source, a filter on the Pages list for content missing a named language, and a CSV export for handing content to a translator. Read the percentage as coverage rather than quality, because it counts what has been filled in, not whether it reads well.
Choose the addressing before the translation budget
Settle the addressing first, because it is the part that is awkward to change later. Then count the pages, not the languages.
One URL per language The address decides the language. Detection only suggests, and only when you switch it on.
Which text is translated where
The most common misreading is that one tool covers all the text on the site. It does not. Page content is authored in each page's own language tabs. Admin and theme interface strings are Laravel language files, edited by Translation Manager. Knowing which is which saves an evaluation call.
Scroll horizontally to view the full table.
| Text | Where it lives | Who edits it | What to expect |
|---|---|---|---|
| Page content | A translation record for each language, holding the page title, body and metadata. | Editors author it in the per-language tabs on the page itself. | Translation is per language, not per field. A language is either authored on that page or it is not. |
| Admin and theme interface text | Laravel language files in your application and in the packages you have installed. | Translation Manager, which is a free package, edits those files and writes package strings to Laravel's override paths. | A different tool and a different store from page content. The two do not overlap. |
| The admin's own language | A locale on the signed-in administrator, applied by Admin for the length of the request. | Whoever supplies the language files. Admin ships English files only. | The switcher is wired, but there is nothing to switch to until your team adds files for another language. |
| Search results | The search index, queried with the language of the site the visitor is on. | The Search package, which is part of the paid catalogue. | A visitor searching a language sees results from that language. |
| Discovery metadata | og:locale and its alternates, and hreflang alternates inside the XML sitemap. | SEO Suite and Site Discovery, both paid catalogue packages. | The head cluster ships with Frontend. The social and sitemap variants arrive with those packages. |
Capell learning journey
Step 6 of 9: Platform
Trace a CMS decision through Core, Filament Admin, public delivery, and optional packages.
Keep moving through Content
Content, pages, media, forms, search, and languages.