Mehrsprachige Inhalte in PHP verwalten: Datenmodell und redaktioneller Workflow

Eine mehrsprachige Anwendung besteht nicht nur daraus, Beschriftungen auf dem Bildschirm zu übersetzen. Wenn sie auch Artikel, Produktseiten oder andere redaktionelle Inhalte anbietet, muss sie abbilden, welche Sprache jeder Inhalt hat, wie seine Versionen zusammenhängen und wann eine Übersetzung veröffentlichungsreif ist. Ein ungenaues Modell führt dazu, dass veraltete Texte, Links ohne Ziel oder Entwürfe Nutzern angezeigt werden, die sie nicht sehen sollten.

Bei der Planung der Verwaltung mehrsprachiger Inhalte in PHP empfiehlt es sich, Entscheidungen zu Oberfläche, Daten und redaktionellem Workflow voneinander zu trennen. Die Implementierung kann für die Benutzeroberfläche auf Übersetzungsdateien und für veränderliche Inhalte auf die Datenbank zurückgreifen. Diese Aufteilung sollte sich jedoch nach der Fachdomäne und den Anforderungen der Redakteure richten.

Oberflächensprache, Originalsprache und Übersetzung trennen

Die Oberflächensprache bestimmt Beschriftungen, Validierungsmeldungen, Datumsformate und andere produktspezifische Texte. In einer PHP-Anwendung lässt sie sich über Übersetzungskataloge verwalten, zum Beispiel über nach Locale organisierte Dateien, und anhand einer Benutzereinstellung oder einer Sitzungskonfiguration auswählen. Sie sollte nicht mit der Sprache des angezeigten Inhalts verwechselt werden.

Die Originalsprache kennzeichnet dagegen die Sprache, in der ein redaktioneller Inhalt erstellt wurde. Jede Übersetzung ist eine mit diesem Inhalt verknüpfte Version und hat ihre eigene Sprache. Ein Benutzer kann die Oberfläche auf Spanisch nutzen und eine Seite aufrufen, deren Originalinhalt auf Englisch vorliegt. Die Anwendung muss ausdrücklich festlegen, ob das zulässig ist und wie darauf hingewiesen wird.

Speichere normalisierte Sprachcodes und wende bei Bedarf eine einheitliche Richtlinie für regionale Locales an. Setze Sprache und Land nicht gleich: Eine regionale Variante kann sich auf den Text, aber auch auf Formate, Verfügbarkeit oder geschäftliche Anforderungen auswirken. Lege fest, welche Locales das Produkt unterstützt und welche verwendet werden, wenn eine Präferenz unvollständig ist.

Ein Datenmodell wählen, das die Fachdomäne abbildet

Drei gängige Muster haben jeweils unterschiedliche Vor- und Nachteile:

• Sprachspezifische Felder: Spalten wie title_es und title_en sind einfach, wenn es nur wenige Sprachen und einen stabilen Satz von Feldern gibt und direkte Abfragen benötigt werden. Beim Hinzufügen von Sprachen geht Flexibilität verloren, und jede Schemaänderung hängt dann vom Sprachkatalog ab.
• Unabhängige Datensätze: Jede Version wird als eigener Inhalt gespeichert. Das kann sinnvoll sein, wenn die Versionen tatsächlich unabhängige Lebenszyklen oder Strukturen haben; es erfordert jedoch eine andere zuverlässige Methode, sie zu gruppieren. Verwende weder einen ähnlichen Titel noch eine URL als implizite Verknüpfung.
• Verknüpfte Übersetzungstabelle: Ein gemeinsamer Inhalt wird mit einer Zeile je Sprache verknüpft, zum Beispiel über content_id und locale. So lassen sich Sprachen leichter hinzufügen und verfügbare Versionen abfragen. Es sind Einschränkungen erforderlich, die doppelte Übersetzungen derselben Sprache für einen Inhalt verhindern.

Eine verknüpfte Tabelle eignet sich häufig, wenn die Versionen eine gemeinsame Identität und Struktur haben, ist aber keine allgemeingültige Regel. Nicht zu übersetzende Felder – etwa eine interne Referenz – können in der gemeinsamen Entität verbleiben; lokalisierte redaktionelle Felder gehören in die Übersetzung. Kläre außerdem, ob eine Übersetzung eine eigene URL, Suchmetadaten oder ein eigenes Veröffentlichungsdatum haben kann.

Lege in der Datenbank Fremdschlüssel, Eindeutigkeit nach Inhalt und Sprache sowie das Verhalten beim Löschen von Daten fest. Die Anwendungslogik in PHP muss zusätzlich prüfen, ob die Sprache unterstützt wird und der verknüpfte Inhalt existiert. Datenbankeinschränkungen schützen vor konkurrierenden Schreibvorgängen und Fehlern, die eine vorherige Validierung allein nicht verhindern kann.

Versionen verknüpfen, ohne vorauszusetzen, dass alle vorhanden sind

Nicht jeder Inhalt liegt in jeder Sprache vor, und Übersetzungen werden nicht immer gleichzeitig fertiggestellt. Bilde diese Realität ab: Das Fehlen einer Zeile sollte nicht als Integritätsfehler gelten, wenn die Übersetzung optional ist. Ein redaktioneller Status sollte dagegen angeben, was gilt, wenn eine Zeile existiert, aber noch nicht veröffentlicht werden kann.

Vermeide es, in jeder Übersetzung Informationen zu duplizieren, die zum gemeinsamen Inhalt gehören, sofern die Fachdomäne keine Abweichungen erfordert. Wenn Übersetzungen entkoppelt, verschoben oder archiviert werden können, definiere diese Vorgänge und die dafür erforderlichen Berechtigungen. Verwende eine stabile Verknüpfung, um die Versionsgruppe zu ermitteln, und keine Übereinstimmungen bei Text, Slug oder Datum.

Wenn sich eine Übersetzung ändert, speichere die Version des Originals, auf der sie basiert, sofern das Team möglicherweise veraltete Inhalte erkennen muss. Dieser Hinweis beweist für sich genommen nicht, dass die Übersetzung falsch ist; er hilft dabei, eine Überprüfung zu priorisieren. Für manche Produkte genügt eine Kennzeichnung als überprüfungsbedürftig, während andere einen Versionsverlauf und eine Audit-Protokollierung benötigen.

Redaktionelle Status je Sprache festlegen

Der Veröffentlichungsstatus sollte zu jeder einzelnen Übersetzung gehören, wenn jede Sprache unabhängig verfasst, geprüft und veröffentlicht werden kann. Ein Inhalt kann in einer Sprache veröffentlicht sein und in einer anderen noch als Entwurf vorliegen. Ein einzelner Veröffentlichungs-Boolean auf Inhaltsebene bildet diesen Unterschied nicht ab.

Entwirf einen kleinen, klar definierten Workflow, zum Beispiel mit den Status Entwurf, in Prüfung und veröffentlicht. Lege fest, wer die einzelnen Status ändern darf, welche Felder erforderlich sind und ob eine Prüfung eine Freigabe voraussetzt. Veröffentlichungsdatum, verantwortliche Person und Änderungshistorie können für den Prozessbetrieb erforderlich sein. Vermeide Status, denen keine tatsächlichen Aktionen des Teams entsprechen.

Öffentliche Abfragen müssen nach Status und Sprache filtern und dürfen sich nicht darauf verlassen, dass die redaktionelle Oberfläche unveröffentlichte Zeilen verbirgt. Bündele diese Regeln in PHP in einer Domänenzugriffsschicht oder in wiederverwendbaren Abfragen und teste, ob Controller, API und Hintergrundaufgaben sie einhalten. Bei Bearbeitungs- und Veröffentlichungsaktionen müssen außerdem die Berechtigungen für die konkrete Sprache und den konkreten Inhalt geprüft werden.

Fehlende Übersetzungen, URLs und Suche konsistent behandeln

Für fehlende Übersetzungen gibt es mehrere mögliche Richtlinien. Die Anwendung kann den Inhalt in dieser Sprache ausblenden, darauf hinweisen, dass er nur in einer anderen Sprache vorliegt, oder einen Fallback anzeigen. Wähle die passende Variante je nach Inhaltstyp und Auswirkung auf die Benutzererfahrung. Ein Fallback darf nicht als Übersetzung ausgegeben werden. Wird Inhalt in einer anderen Sprache angezeigt, muss dies klar erkennbar sein und die Rückkehr zur angefragten Version möglich bleiben.

Wende unterschiedliche Regeln auf Oberfläche und Inhalte an. Wenn Navigationsbeschriftungen auf einen anderen Übersetzungskatalog zurückfallen, bedeutet das nicht, dass Artikel automatisch durch ihre Originalversion ersetzt werden sollten. Redaktionelle Fallbacks müssen auf zulässige Sprachen und veröffentlichungsfähige Inhalte beschränkt sein und dürfen keine Entwürfe zurückgeben.

URLs müssen eine tatsächlich vorhandene Version identifizieren oder einer dokumentierten Weiterleitungsregel folgen. Suche beim Sprachwechsel die Übersetzung desselben Inhalts. Gibt es keine, biete eine klar erkennbare Alternative an, statt einen gültig wirkenden Pfad zu erstellen. Vermeide aus SEO-Gründen leere oder durch unsichtbare Fallbacks doppelte Seiten. Die Suche darf nur zulässige Versionen indexieren und muss zum Filtern und Darstellen von Ergebnissen die jeweilige Sprache verwenden.

Checkliste vor der Veröffentlichung

• Sind Oberflächensprache, Originalsprache und Sprache jeder Übersetzung im Modell voneinander getrennte Konzepte?
• Wird verhindert, dass zwei Übersetzungen desselben Inhalts in derselben Sprache gespeichert werden?
• Kann eine Übersetzung fehlen, ohne einen inkonsistenten Status zu erzeugen?
• Kann das Team Entwurf, Prüfung und Veröffentlichung je Sprache unterscheiden?
• Prüfen öffentliche Pfade und Links zum Sprachwechsel, ob eine sichtbare Version existiert?
• Ist der Fallback für jeden Anwendungsfall definiert, wird er dem Benutzer mitgeteilt und legt er niemals Entwürfe offen?
• Filtert die Suche nach Sprache und Status und beendet sie die Indexierung einer zurückgezogenen Version?
• Wurden Berechtigungen, gleichzeitige Bearbeitung, Löschung, unvollständige Inhalte und Sprachwechsel getestet?

Teste außerdem das Zurückziehen einer bereits verknüpften Übersetzung, die Aktualisierung des Originals nach der Veröffentlichung einer Version und den direkten Aufruf einer nicht verfügbaren URL. Überprüfe in jedem Fall die Antwort, die Navigation und die Sichtbarkeit in der Suche. Das Ziel ist nicht, alle Sprachen zum gleichen Fortschritt zu zwingen, sondern jeder Version eine Identität, einen überprüfbaren Status und ein vorhersehbares Verhalten für Redakteure und Benutzer zu geben.