PVFirms ist mein mehrsprachiges Verzeichnis von Unternehmen der Solarindustrie. Die Plattform verwendet Laravel, Inertia, React, TypeScript und PostgreSQL. Der Inhaltsworkflow umfasst die geplante LLM-Generierung, die durch n8n orchestriert wird, mit Überprüfungen der Lokalisierungsabdeckung und einem englischen Fallback.
Das Projekt umfasst 31 Regionen und ein Quellset von etwa 1.600 Übersetzungsschlüsseln für die Benutzeroberfläche. Diese Zahlen beschreiben den Umfang der Implementierung. Sie implizieren nicht, dass jeder Unternehmensdatensatz in jeder Sprache gleich vollständige Inhalte hat oder dass der generierte Text keiner Überprüfung bedarf.
Die Sprache der Benutzeroberfläche und der Unternehmensinhalt sind unterschiedlich.
Ein übersetzter Suchbutton ist ein Interface-Anliegen. Eine Unternehmensbeschreibung ist ein Inhaltsanliegen. Die beiden erscheinen zusammen auf derselben Seite, haben jedoch unterschiedliche Quellen, Aktualisierungszyklen und Qualitätsprüfungen.
Ich trenne sie, wenn ich über Vollständigkeit nachdenke. Eine Locale kann eine benutzbare Schnittstelle haben, während einige Unternehmensinhalte in dieser Sprache noch nicht verfügbar sind. Umgekehrt machen übersetzte Beschreibungen die Navigation, Validierungsnachrichten oder Kontobildschirme nicht vollständig.
Diese Unterscheidung macht Fortschritte messbar. Anstatt ein Gebiet als „fertig“ zu bezeichnen, weil ein Generierungsjob ausgeführt wurde, muss das System vergleichen, was existieren sollte, mit dem, was tatsächlich in jeder Inhaltsklasse verfügbar ist.
Ein Fallback sollte die Benutzerfreundlichkeit bewahren
PVFirms verwendet Englisch als Fallback. Der Zweck ist es, die Anwendung benutzbar zu halten, wenn ein lokalisierter Wert fehlt. Laravel unterstützt eine Fallback-Sprache für fehlende Übersetzungsstrings, aber der Anwendungsinhalt benötigt dennoch eine eigene gezielte Handhabung.
Ein Fallback kann auch unfertige Arbeiten verbergen, wenn niemand sie misst. Eine Seite kann erfolgreich gerendert werden, weil ein englischer Wert gefunden wurde, obwohl die angeforderte Locale keine Übersetzung hat. Daher behandle ich erfolgreiches Rendering und Locale-Abdeckung als separate Fragen.
Für eine Überprüfung möchte ich wissen, welche Schlüssel fehlen, welcher Inhalt absichtlich zurückfällt und welche Werte leer oder fehlerhaft sind. Ein grüner Generierungsstatus allein beantwortet diese Fragen nicht.
Automatisierung benötigt eine stabile Quelle
Die geplante Inhaltspipeline macht wiederholte Arbeiten in vielen Regionen handhabbar. Ihre Nützlichkeit hängt von einer stabilen Quellidentität ab: Der Job sollte wissen, an welchem Schlüssel oder Datensatz er arbeitet und welchen Quellinhalt er transformiert.
Meine Designfragen für diese Art von Pipeline umfassen, wie eine Quelländerung eine ältere Übersetzung veraltet macht, wie man fehlende Arbeiten von abgeschlossenen Arbeiten unterscheidet und wie man sicherstellt, dass ein erneuter Versuch nicht versehentlich einen überprüften Wert ersetzt. Die genaue Implementierung kann variieren; die Notwendigkeit, diese Unterscheidungen zu bewahren, bleibt jedoch bestehen.
Übersetzungen haben auch strukturelle Anforderungen. Platzhalter, Links und Produkt- oder Firmennamen müssen möglicherweise unverändert bleiben. Ein Satz kann natürlich klingen, während er eine Schnittstelle bricht, wenn ein erforderlicher Platzhalter verschwindet.
Verzeichnisfakten benötigen einen anderen Standard als Prosa
Ein Unternehmensverzeichnis kombiniert beschreibendes Schreiben mit faktischen Feldern. Namen, Standorte, Websites und Dienstleistungskategorien sollten nicht erfunden werden, nur um ein Profil vollständig erscheinen zu lassen. Ein LLM kann helfen, bereitgestelltes Material zu transformieren, aber generierte Flüssigkeit ist kein Beweis dafür, dass eine Unternehmensbehauptung wahr ist.
Für die Inhaltsüberprüfung unterscheide ich zwischen einer quellenbasierten Tatsache, einer Übersetzung dieser Tatsache und neu generierter erläuternder Prosa. Dies erleichtert die Entscheidung, was automatisch veröffentlicht werden kann und was einer zusätzlichen Überprüfung bedarf. Es verhindert auch, dass ein fehlendes Feld stillschweigend zu einem selbstsicheren Satz wird.
Das gleiche Prinzip gilt für mehrsprachige Entdeckung. Eine lokalisierte Seite sollte die zugrunde liegende Unternehmensidentität bewahren, anstatt sich wie ein anderer Datensatz zu verhalten, nur weil sich die Formulierung geändert hat.
Betreiben Sie den Inhalt als Teil der Anwendung
PVFirms hat Lokalisierung, generierte Inhalte und gewöhnliche Anwendungsentwicklung in einem Produkt vereint. Mein Fokus liegt auf Abdeckung, Wiederherstellbarkeit und verständlichem Inhaltszustand, neben den Seiten, die die Besucher sehen.
Ein mehrsprachiges Verzeichnis wird wartbar, wenn Betreiber erkennen können, was existiert, was fehlt, was zurückfällt und was überprüft werden muss. Das ist die nützliche Ausgabe eines Content-Systems: eine wiederholbare Methode, um Informationen kohärent zu halten, während sowohl das Verzeichnis als auch seine Sprachen wachsen.
Technischer Hinweis: Laravel-Dokumentation zu Lokalisierung und Fallback-Sprachen.
Aktualisiert am 26. September 2026.