Internationalization

Multilingual publishing is built into Chinaski’s bones rather than bolted on after the fact: every piece of content carries its own language, every URL scheme is language-aware, and whole subsystems (menus, forms, search, feeds, the admin interface itself) exist per language. This page orients you to the picture; the linked pages take each piece apart.

Why language is “first-class” here

Language isn’t a plugin or an afterthought in Chinaski; it’s a structural fact of the data model. Every content row (page, post, block, document, category, menu item, form, stack, snippet) carries a language, and the system enforces it:

• Content lives uniquely per language; an English and a Spanish page can share a slug, and the two editions are paired (via translation keys or matching slugs) for SEO and switching.
• Builders and URLs operate per language: output trees, sitemaps, feeds, canonical URLs, and hreflang alternates all respect the site’s language configuration.
• The admin itself speaks your language: it ships localized, and each user picks their own admin interface language independent of the site’s language set.

Every piece of content is either published, draft, scheduled, or gone (trash); that’s true for every language at every moment.

The pieces you’ll touch

• Active languages (Settings → General): the list of language codes your site publishes in; everything downstream keys off this list.
• URL modes: how the language code appears in URLs: path (/en/about), none (single language, no prefix), or subdomain (en.example.com). This is derived from your language count rather than set by hand (multilingual → path; single-language → none), see URL Modes.
• Permalink settings: post and page URL structure, chosen per site, with per-language post-prefix overrides if your languages need their own URL shapes.
• Home redirect: which page or feature the language root points to.
• Translation pairing: matching slugs or explicit translation keys that link editions together for hreflang and switching links.
• Per-language site copy: blog titles, cookie-notice texts, and button labels all have per-language settings, so your site reads naturally in each language you’ve configured.

Where to learn more

• URL Modes: how URLs are shaped per language, and what changes.
• Hreflang & Switching: the SEO signal layered on every page, plus the public language switcher.
• Multilingual First: the design argument and its consequences for content workflows.

Where it touches what you already know

A monolingual site is the simplest case: no language prefix, no alternates, no admin language options beyond the interface preference. It behaves as a single-tree static site from day one, and everything above is out of the way until you need it.

A multisite, multilingual site gets the full machinery: one URL set per language, alternating canonical URLs, a shared search with language-scoped results, and a static language switcher in every page’s header. Content lives under the language’s own URL; linking to a version in your own language (hreflang) is emitted automatically from verified pairings, and the search is likewise language-scoped.

Migration notes for multilingual sites in transition: publishing a language’s content in the admin the first time updates the site’s language configuration. New languages are additive; nothing breaks. If a language is removed while content still lives under it, the admin refuses (you’ll see the count of orphaned pages/posts/blocks): the cleanup path is to delete or reassign that content first.

The public side in practice

Visitors see a language switcher on every page; search engines see hreflang alternates, a language-scoped sitemap, and per-language canonical URLs: every URL signal agrees with every other. Once you configure languages, almost nothing else is needed: most sites need nothing beyond picking languages and (optionally) running subdomain mode, and the built-in defaults behave correctly.

What isn’t automatic

• Translating is manual (or via the documented translation workflows / MCP tools); a translation key pairs editions; it doesn’t translate for you.
• Menus are per language (a Spanish-only nav is normal); you manage each language’s menu separately.
• The cookie notice, blog title, and other configurable strings have per-language fields; those override rather than fall back quietly; a language with its own text shows the language’s copy.

In this section

• Languages
• URL Modes
• Translating Content
• Hreflang & Switching