8.2 – One build per language

options:
  publishLanguages: [de]

Or, without touching the configuration:

QUARTZ_LANGS=de npx quartz build

The environment variable overrides the option. Every other language is removed before rendering; switcher, hreflang, redirects and notices then know only what is being published.

What that gains

Combined with a quartz.config.yaml of its own per build — a different locale, a different baseUrl — a fully localized site comes out: “Backlinks”, “Last updated” and the date format are right too, because they follow the site-wide locale and that now fits.

QUARTZ_LANGS=de npx quartz build --output public-de
QUARTZ_LANGS=en npx quartz build --output public-en

Two folders, two deploys, two addresses — example.org and example.org/en, say, or two domains.

What it costs

	One build	One build per language
Interface texts	site-wide, one language	right on each site
Search	every language in one index	separate per language
Switcher	jumps straight to the translation	gone
Deploy	one	one per language
Maintenance	one configuration	one per language

The third point is the one that surprises: two separate sites know nothing of each other, and the plugin does not bridge that. With one published language the switcher component renders nothing at all — it needs two active languages — and hreflang stays empty for the same reason. To point from one site at the other, place that link yourself, in the layout’s header for instance.

Only when it is needed

One build is simpler, and most sites manage with it. The point where that turns is usually the one where readers trip over interface texts in the wrong language — not the one where somebody discovers the possibility.