Reference
Configuration
Every visible string in Lucid comes from front matter rather than from markup, which is what makes a new language a directory rather than a fork.
Front matter
No layout in Lucid contains a hard-coded sentence. Navigation labels, button text, the breadcrumb name and even the word "Menu" are front-matter keys, so translating the theme never means editing HTML.
nav_install: "Installation"
label_toc: "On this page"
label_prev: "Previous"
A page that omits a key renders it empty rather than falling back to English, which makes a missing translation visible instead of silently monolingual.
Adding a language
Declare the locale in ssg.toml:
[i18n]
default_locale = "en"
locales = ["en", "fr", "de"]
url_prefix = "sub_path"
Then add content/de/ with one file per page. Every page carries a translation_key, and pages sharing a key are treated as translations of each other, which is how hreflang alternates are emitted. The repository's own validation fails the build if a key does not resolve in every declared locale — a half-translated site is a build error, not a surprise for a reader.
The default locale is served from the root and every other locale from its own prefix, so /, /fr/ and /de/ are all real paths with real alternates.
Colour tokens
Colour is declared once, as custom properties, and used nowhere else:
--/* body text */
--/* secondary text */
--/* links, buttons */
--/* raised ground */
Because every pair is verified in CI, changing a token to something that fails contrast fails the build. See Accessibility for the exact thresholds.