Multilingual First
Most CMS products treat “supports multiple languages” as an add-on you install later. Chinaski was built the other way round: language is a structural part of the data model, the URLs, the admin interface, and every page the builder generates. This page walks through what “first-class” means in practice, and what won’t need bolting on later.
Language lives in the data model
Every content type (pages, posts, blocks, documents, categories, navigation items, forms) carries its own language field. Translations are separate rows linked together, not hidden copies. Where visual layouts are shared across languages, the per-language block contents live in a dedicated translations table, so a hero stack, for example, can have different wording per language while sharing structure.
The admin interface speaks the user’s language
The admin UI itself ships with built-in translations, and each user can pick their own admin interface language; it defaults to the site default but overrides per account (this includes people who only ever approve translations). When authors write content, the language selector on every content form is the site’s own configured languages list: nothing invented, nothing mis-spelled; the list comes from the same setting that drives the public URLs.
Right-to-left languages ship built-in
Arabic, Hebrew, Farsi, Urdu, Pashto, Kurdish, Sindhi, Yiddish, and Divehi render with dir="rtl" set on every generated page (and with lang set correctly to each page’s language in every theme template). RTL isn’t a plugin or a theme tweak, it’s in the builder.
Language-aware output everywhere
- Per-language output trees. In path or subdomain URL mode, each language builds its own tree under its own language prefix/subdomain, with correct per-language canonical URLs (per-language subdomains included), hreflang alternates, sitemap entries, and navigation home paths.
- Per-language homepage labels and cookie notices. The blog index title and the cookie-banner text/labels all have per-language settings; one source of config for a whole site’s editorial language set.
- Monolingual simplification. A single-language site never gets language-segment URLs; the mode is derived automatically so monolingual sites stay plain.
Editorial tooling that’s multilingual, not just aware
- Translation coverage is computed per page and post and shown while editing: which configured languages have this content and which don’t.
- Translation workflow templates let you define source language, targets, and content types once and reuse them across the site.
- One-click auto-create: an API (and admin surface) endpoint computes missing target languages for content and creates translated drafts in a batch, audited like everything else.
- AI-assisted tooling rides the same rails: the built-in MCP server exposes translate-and-audit tools (translate content, find pieces missing translations, find content gaps such as missing meta descriptions per language), so multilingual maintenance is also scriptable.
Public-page behavior is language-native
- Search indexes are built per language; searching “es” content searches Spanish.
- The static pages themselves sit under per-language URLs with per-language canonical tags.
- RSS feeds and category archives are generated per language, so each language’s feed is a real feed, not one feed shallowly labeled.
- Scheduled publishing uses one site timezone consistently, so a Spanish post and an English post published “at 9:00” actually appear when you mean them to.
What “first-class” costs
Nothing hides, but the multilingual posture does mean model complexity lives in the data model (slugs differ per language; the translation key pairs equivalents; local URL overrides per language). The practical rule: decide your languages before launch (they drive URL mode), and treat a translation as a full sibling of the source page rather than a variant. When you follow those paths, search engines get correct signals and visitors get complete experiences in every language the site declares.