JPKCom DB
Auf GitHub ansehen (öffnet in neuem Tab)

JPKCom Simple Lang — Anleitung & Tipps

Einzelne WordPress-Seiten mit JPKCom Simple Lang pro Beitrag in anderer Sprache anzeigen — Installation, Sprachauswahl, Hreflang und Oxygen-Bedingungen.

JPKCom Simple Lang ist eine leichtgewichtige Lösung, um einzelne Seiten oder Beiträge in einer anderen Sprache als deiner Site-Standardsprache auszugeben. Statt eines vollwertigen Mehrsprachigkeits-Plugins erledigt es genau eine Aufgabe: die WordPress-Locale pro Beitrag im Frontend zu überschreiben — inklusive <html lang="">-Attribut, Hreflang-Tags und Oxygen-Builder-Bedingungen.

Anleitung

Voraussetzungen

  • WordPress 7.0 oder neuer (getestet bis WordPress 7.1)
  • PHP 8.3 oder neuer (mit Strict Typing)
  • Mindestens ein zusätzliches Sprachpaket installiert (optional, aber empfohlen)
  • Multisite wird unterstützt (das Plugin ist netzwerkfähig)

Installation

  1. Lade die aktuelle Release-ZIP von der GitHub-Releases-Seite (öffnet in neuem Tab) herunter.
  2. Im Admin-Bereich: Plugins → Installieren → Plugin hochladen, ZIP wählen, Jetzt installieren, dann Aktivieren.

Alternativ per FTP den Ordner jpkcom-simple-lang nach /wp-content/plugins/ hochladen oder für die Entwicklung direkt klonen:

cd /pfad/zu/wordpress/wp-content/plugins/
git clone https://github.com/JPKCom/jpkcom-simple-lang.git

Sprachpakete installieren

Das Auswahl-Dropdown zeigt nur installierte Sprachen. Neue Sprachen fügst du so hinzu:

  1. Gehe zu Einstellungen → Allgemein und öffne das Sprache der Website-Dropdown.
  2. Wähle die gewünschte Sprache (z. B. „Deutsch", „Français") und klicke auf Änderungen speichern — WordPress lädt das Sprachpaket automatisch herunter (5–10 Sekunden).
  3. Optional kannst du die Standardsprache anschließend wieder zurückstellen; das installierte Paket bleibt verfügbar.

Eine Übersicht aller über 200 Sprachen findest du auf translate.wordpress.org (öffnet in neuem Tab).

Verwendung

  1. Post-Typen freischalten (optional): Unter Einstellungen → Simple Lang legst du fest, welche Post-Typen eine Sprachauswahl bekommen. Standardmäßig sind Beiträge und Seiten aktiv.
  2. Sprache wählen: Beim Bearbeiten eines Beitrags erscheint in der Seitenleiste das Dropdown Frontend Language Select. Wähle eine installierte Sprache oder belasse es beim Standard.
  3. Übersetzungen verknüpfen (optional): Über die Meta-Box Translation Links verbindest du zusammengehörige Beiträge unterschiedlicher Sprachen. Verknüpfungen sind bidirektional — verbindest du Beitrag A mit B, verlinken sich beide gegenseitig; eine ganze Übersetzungsgruppe wird automatisch komplett vernetzt.
  4. Im Frontend: Beim Aufruf wechselt WordPress automatisch in die gewählte Sprache. Übersetzt werden Oberflächen-Strings (Core, Theme, Plugins), das lang-Attribut sowie SEO-Meta-Tags (og:locale); für verknüpfte Beiträge werden <link rel="alternate" hreflang="XX">-Tags im <head> ausgegeben.

Fehlendes Sprachpaket: Schlägt der Sprachwechsel fehl, weil das Paket nicht installiert ist, behandelt das Plugin das seit Version 1.2.9 nicht mehr als Erfolg — vorher wies die Seite lang="fr" und ein passendes hreflang aus, lieferte aber die Site-Sprache. Der Editor warnt jetzt, wenn das Sprachpaket eines Beitrags fehlt, und die gespeicherte Sprache bleibt im Dropdown wählbar. Bis 1.2.8 verschwand sie dort — ein simples „Aktualisieren" löschte die Sprache des Beitrags dann still, ohne dass jemand das Feld angefasst hätte.

Wichtig: Simple Lang übersetzt nicht deine Inhalte. Titel, Beitragstext, Custom Fields und Medien-Beschriftungen bleiben so, wie du sie schreibst — die Sprache des Inhalts liegt in deiner Verantwortung.

Sprach-Setup prüfen: die Abilities API

Seit Version 1.3.0 registriert das Plugin zwei nur lesende Abilities. Die Abilities API ist ein WordPress-Kernregister maschinenlesbarer Fähigkeiten; KI-Assistenten, MCP-Clients und REST-Automatisierung lesen darüber das Sprach-Setup dieser Site als strukturierte Daten:

Ability Antwort
jpkcom-simple-lang/list-languages welche Post-Typen eine Sprachauswahl haben, was die Site-Standardsprache ist, welche Sprachpakete installiert sind und welche Locales veröffentlichte Beiträge tatsächlich tragen
jpkcom-simple-lang/check-translation-sets welche Übersetzungsgruppen eine unvollständige Hreflang-Auszeichnung ergeben

Die zweite Ability ist der eigentliche Gewinn, weil sie etwas sichtbar macht, das vorher stillschweigend passierte: Lösen zwei Versionen einer Gruppe auf denselben Hreflang-Wert auf — zwei deutsche Seiten, oder Deutsch zusammen mit Deutsch (Sie-Form) —, entsteht ein Eintrag, und die andere Seite ist nirgends ausgezeichnet. Das ist Absicht, denn zwei widersprüchliche Einträge für eine Sprache wären schlechter; nur sagte im Editor bisher nichts, dass eine Seite ausgelassen wurde. Die Prüfung benennt jetzt die Gruppe, den geteilten Wert und die Seiten, die ihn teilen.

Ebenfalls gemeldet werden Gruppen ohne x-default (keine ihrer Versionen trägt die Site-Sprache), Verknüpfungen auf gelöschte Seiten, einseitige Verknüpfungen und Seiten, deren Sprachpaket nicht mehr installiert ist — dort stellt das Frontend den Sprachwechsel bewusst ein, während die Seite die Sprache weiter beansprucht.

Bewusst nicht gemeldet wird eine Gruppe, deren einzige Auffälligkeit eine unveröffentlichte Übersetzung ist: Ein Entwurf ist normale Arbeit, und ein Bericht, der jeden davon anzeigt, wird nicht mehr gelesen. Hat die Gruppe etwas anderes, wird der Entwurf trotzdem aufgeführt — er erklärt, warum weniger Sprachen erscheinen, als die Gruppe enthält.

Beide Abilities verlangen die Fähigkeit edit_posts — nicht read wie bei den Inhalts-Plugins, denn hier geht es um einen redaktionellen Zustand, nicht um veröffentlichte Inhalte. Komplett abschalten in der wp-config.php:

define( 'JPKCOM_SIMPLELANG_ABILITIES', false );

Enger ziehen lässt sich das über jpkcom_simplelang_ability_capability; wie die Abilities nach außen sichtbar sind (REST-Route, MCP-Freigabe, Annotationen), steuert jpkcom_simplelang_ability_meta.

Tipps & Tricks

  • Richtiger Einsatzzweck: Simple Lang ist für gelegentliche Seiten in einer Zweitsprache gedacht (Landingpages, Doku, rechtliche Seiten, Client-Präsentationen). Brauchst du vollständige Site-Übersetzungen, Sprachumschalter oder Übersetzungs-Workflows, sind WPML oder Polylang die bessere Wahl.
  • Hreflang ohne Konfiguration: Verknüpfte, veröffentlichte Beiträge erhalten selbstreferenzierende Hreflang-Tags, deterministisch sortiert und früh im <head> (vor den meisten SEO-Plugins). Seit Version 1.2.9 ist auch ein x-default dabei — es zeigt auf die Version in der Standardsprache der Site und entfällt, wenn keine der verknüpften Versionen diese Sprache trägt.
  • Hreflang jetzt mit Region (1.2.9): Die Tags sind echtes BCP 47, also de-DE, de-AT, pt-BR. Vorher wurden de_DE und de_AT beide zu hreflang="de" — zwei verschiedene URLs bekamen denselben Wert, und genau regionale Varianten sind der Zweck von hreflang. WordPress-Varianten-Suffixe fallen weg (de_DE_formal → de-DE); lösen zwei Versionen auf denselben Tag auf, entsteht ein Eintrag statt eines widersprüchlichen Paars. Auch das lang-Attribut am <html> trägt jetzt die Region (lang="de-DE" statt lang="de"). Prüfe nach dem Update deine hreflang-Auszeichnung, wenn du dich in Monitoring oder Tests auf die alten zweibuchstabigen Werte verlassen hast.
  • Locale-Format: Gültig ist, was WordPress über get_available_languages() kennt, plus en_US. Damit funktionieren seit 1.2.9 auch Varianten-Locales wie de_DE_formal, de_CH_informal oder pt_PT_ao90 — die bot die Meta-Box zwar an, beim Speichern wurden sie aber kommentarlos verworfen.
  • Oxygen-Builder-Bedingungen: Bei installiertem Oxygen stehen drei Conditions zur Verfügung: „Post Language Is" (bestimmte Sprache), „Post Has Custom Language" (überhaupt eine Sprache gesetzt) und „Post Uses Default Language" (Standardsprache). Damit blendest du Elemente sprachabhängig ein oder aus.
  • Helfer-Funktionen für Entwickler: jpkcom_simplelang_get_post_language( $post_id ) liefert die gesetzte Locale (oder null), jpkcom_simplelang_get_current_language() die aktive Frontend-Sprache. Für Sprach-Auszeichnung nimm jpkcom_simplelang_get_bcp47( 'de_DE_formal' ) — das ergibt de-DE und ist seit 1.2.9 das, was Plugin-intern für lang und hreflang verwendet wird. jpkcom_simplelang_get_language_code( 'de_DE' ) gibt es weiterhin und liefert unverändert den reinen Sprachcode (de); für Auszeichnung ist es die schlechtere Wahl, weil ein nacktes Subtag die Region nicht ausdrücken kann.
  • Template-Overrides: Plugin-Dateien lassen sich im Child-Theme ({child-theme}/jpkcom-simple-lang/{datei}), Parent-Theme oder in MU-Plugins ({WPMU_PLUGIN_DIR}/jpkcom-simple-lang-overrides/{datei}) überschreiben. Die Suchpfade erweiterst du per Filter jpkcom_simplelang_file_paths.
  • REST-API & Daten: Die Sprache liegt als Post-Meta unter dem Schlüssel _jpkcom_simplelang_language und ist bei entsprechender Konfiguration über die REST-API erreichbar. Eine Bulk-Zuweisung gibt es nicht — dafür update_post_meta() mit demselben Schlüssel verwenden.
  • Deaktivieren ist gefahrlos: Nach dem Abschalten zeigen Beiträge wieder die Standardsprache; die Meta-Daten bleiben erhalten und greifen bei erneuter Aktivierung sofort wieder.
  • Performance: Eine Meta-Abfrage pro Beitrag, ein einmaliger Locale-Wechsel pro Request, keine zusätzlichen Tabellen, kein Frontend-JS/CSS.
  • Updates & Sicherheit: Das Plugin aktualisiert sich sicher über GitHub mit SHA256-Prüfsummen-Verifikation; ein bevorzugter Abgleich gegen die download_url des Manifests verhindert, dass ein manipuliertes Manifest die Prüfsumme umgeht.

Weiterführende Informationen