Mehrsprachige Blogs mit Sveltia CMS betreiben

Erzeugen Sie zu Beginn eines mehrsprachigen Blog-Ablaufs lokales HTML eines repräsentativen Artikels und prüfen Sie Text, title, description und interne Links. Verknüpfen Sie nach Google: Localized Versions nur vorhandene Sprachversionen. Nehmen Sie Übersetzungsdienst und fertige öffentliche Seiten getrennt ab.

Ergänzung vom 26. September 2026: Die folgenden Schritte mit Copilot dokumentieren die Einführung vom Juni 2026. Die Übersetzungserstellung wurde inzwischen auf OpenAI Batch umgestellt. Japanisch bleibt die maßgebliche Quelle; übersetzte statische Seiten bleiben das Veröffentlichungsformat.

Aktueller Übersetzungsablauf (September 2026)

Wenn ein japanischer Artikel oder UI-Quelltext auf main geändert wird, startet der Workflow zur Batch-Einreichung. Er wartet 15 Minuten auf weitere Änderungen, prüft den aktuellen main-Stand und reicht dann die Übersetzung ein. Der Abhol-Workflow gleicht die Ergebnisse mit dem aktuellen sourceHash ab, verwirft veraltete Ergebnisse und erstellt einen Übersetzungs-PR. Der Merge-Workflow aktiviert die automatische Zusammenführung nur für geeignete PRs. Begriffe, Links, Fakten und Sprachqualität müssen weiterhin geprüft werden.

1. 1 Japanische Quelle aktualisieren Eine Source-Änderung auf main löst einen Übersetzungs-Batch aus.
2. 2 sourceHash vergleichen Bei der Abholung Ergebnisse ausschließen, die nicht mehr zur aktuellen Quelle passen.
3. 3 Übersetzungs-PR integrieren Die Validierung kann Auto-Merge ermöglichen; der Inhalt braucht eine separate Prüfung.

Einführung im Juni 2026

Acecore bearbeitet Inhalte hauptsächlich auf Japanisch, veröffentlicht den Blog aber in 9 Sprachen. Entscheidend ist: Text in der Oberfläche übersetzen und lokalisierte Seiten veröffentlichen sind verschiedene Dinge.

Browser-Übersetzung hilft Nutzern beim Lesen. Sie erzeugt aber keine /de/blog/.../ URL, keine lokalisierten Metadaten, kein RSS, keine Sitemap und kein hreflang.

Wenn mehrsprachiger Content auch Suchtraffic bringen soll, muss Übersetzung Teil des Veröffentlichungsprozesses sein.

Struktur

• Japanische Quelle: src/content/blog/{slug}.md
• Übersetzungen: src/content/blog/{locale}/{slug}.md
• URLs: /blog/{slug}/, /en/blog/{slug}/, /de/blog/{slug}/
• Bearbeitung: Sveltia CMS
• Übersetzung: GitHub-Copilot-PRs
• Veröffentlichung: Build und Review

Sveltia CMS ist die Oberfläche für die japanische Quelle. Übersetzungen laufen über Pull Requests, damit Review, Historie und CI erhalten bleiben.

Wann UI-Übersetzung reicht

Sie eignet sich für interne Lektüre, einmalige Recherche, Admin-Seiten oder Inhalte ohne Suchstrategie.

Das ist leichtgewichtig, erzeugt aber keine indexierbaren Sprachseiten.

SEO-Vorteile statischer Sprachseiten

Suchmaschinen, Social Previews und RSS-Reader arbeiten mit URLs und HTML.

Wenn nur die japanische Seite existiert, bleiben title, description, strukturierte Daten, RSS und Sitemap japanisch, auch wenn der Browser dem Nutzer eine Übersetzung zeigt.

Mit statischen Übersetzungen erhält jede Sprache eine URL.

/blog/copilot-translation-pipeline/
/en/blog/copilot-translation-pipeline/
/de/blog/copilot-translation-pipeline/
/fr/blog/copilot-translation-pipeline/

1. Jede Sprache ist direkt crawlbar

Google kann JavaScript verarbeiten, dokumentiert aber auch Einschränkungen und empfiehlt statisches oder serverseitiges Rendering als stabilere Lösung. Andere Crawler und RSS-Reader sind oft weniger leistungsfähig.

2. Metadaten sind lokalisiert

Frontmatter kann pro Sprache übersetzt werden:

title: "Mehrsprachige Blogs mit Sveltia CMS betreiben"
description: "Workflow für Übersetzungs-PRs mit Sveltia CMS und GitHub Copilot."

Das wirkt auf Suchergebnisse, OGP, Related Cards und RSS.

3. hreflang verbindet Varianten

Google empfiehlt hreflang, wenn verschiedene URLs verschiedene Sprachen oder Regionen bedienen. Ohne lokalisierte URL gibt es nichts zu verbinden.

4. RSS und Sitemap werden mehrsprachig

Mit Übersetzungsdateien kann die Website /de/rss.xml und lokalisierte Sitemap-URLs ausgeben.

Rolle von Sveltia CMS

Sveltia CMS übersetzt nicht. Es hält die Bearbeitung der japanischen Quelle schlank:

• japanische Artikel
• Autoren
• Tags
• japanische Source-JSON
• Bilder
• Frontmatter wie date, FAQ und linkCards

Die CMS-Einrichtung steht im Sveltia CMS Einrichtungsleitfaden.

Regeln für Copilot

Der Übersetzungs-PR muss klar trennen, was erhalten bleibt und was lokalisiert wird.

Keep:

- slug
- image path
- author id
- tag ids
- external URLs
- code blocks

Localize:

- title
- description
- FAQ
- body text
- internal blog URLs when locale-specific URLs exist

Lehren aus den PRs

• Alte Artikel nannten noch Pages CMS, obwohl die Implementierung Sveltia CMS nutzt.
• Bleibt date alt, erscheint ein neu geschriebener Artikel nicht oben im Blog.
• Slugs müssen über Sprachen hinweg stabil bleiben.
• Interne Links sollten zur Locale des Lesers führen.
• KI-Übersetzung spart Zeit, braucht aber Review.

Quellen

• Google Search Central: Localized Versions of your Pages
• Google Search Central: Managing Multi-Regional and Multilingual Sites
• Google Search Central: JavaScript SEO Basics
• Google Search Central: Spam Policies
• Sveltia CMS Einrichtungsleitfaden

Fazit

UI-Übersetzung hilft beim Lesen. Lokalisierte statische Seiten machen jede Sprache zu echtem Website-Content.

Sveltia CMS bearbeitet Japanisch, GitHub Copilot erstellt Übersetzungs-PRs, und Astro build prüft das Ergebnis vor der Veröffentlichung.