8.2 – Ein Build je Sprache

options:
  publishLanguages: [de]

Oder, ohne die Konfiguration zu ändern:

QUARTZ_LANGS=de npx quartz build

Die Umgebungsvariable überschreibt die Option. Alle anderen Sprachen werden vor dem Rendern entfernt; Umschalter, hreflang, Weiterleitungen und Hinweise kennen danach nur noch, was veröffentlicht wird.

Was das bringt

In Verbindung mit einer eigenen quartz.config.yaml je Bau — anderes locale, andere baseUrl — entsteht eine vollständig lokalisierte Site: auch „Backlinks“, „Zuletzt geändert“ und das Datumsformat stimmen, weil sie dem site-weiten locale folgen und das jetzt passt.

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

Zwei Ordner, zwei Deploys, zwei Adressen — etwa example.org und example.org/en, oder zwei Domains.

Was es kostet

	Ein Bau	Ein Bau je Sprache
Oberflächentexte	site-weit, eine Sprache	je Site richtig
Suche	alle Sprachen in einem Index	je Sprache getrennt
Umschalter	springt direkt zur Übersetzung	entfällt
Deploy	einer	einer je Sprache
Pflege	eine Konfiguration	eine je Sprache

Der dritte Punkt ist der, der überrascht: Zwei getrennte Sites wissen nichts voneinander, und das Plugin überbrückt das nicht. Bei einer veröffentlichten Sprache rendert die Umschalter-Komponente gar nichts — sie braucht zwei aktive Sprachen —, und hreflang bleibt aus demselben Grund leer. Wer von der einen Site auf die andere verweisen will, legt den Link selbst, etwa in die Kopfzeile des Layouts.

Erst wenn es nötig ist

Ein Bau ist einfacher, und die meisten Sites kommen damit aus. Der Punkt, an dem sich das dreht, ist meist der, an dem Leser über Oberflächentexte in der falschen Sprache stolpern — nicht der, an dem jemand die Möglichkeit entdeckt.