Kürzlich wurden viele offizielle Theme-Komponenten zu Crowdin hinzugefügt.
Dies verbessert definitiv die Benutzererfahrung für Komponenten wie Farbschema-Umschalter, bei denen der Tooltip dann in der lokalen Sprache des Benutzers angeboten wird.
Bei Komponenten, die Beispieltexte anbieten, wie z. B. das Suchbanner, macht jede hinzugefügte Übersetzung die Anpassung komplizierter. Zuvor reichte es aus, den Text für die Standard-Foren-Sprache (und das englische Standard) hinzuzufügen, um den Text für alle Benutzer zu ändern. Mit jeder hinzugefügten Übersetzung gibt es eine weitere Version, die angepasst werden muss.
Detailliertes Beispiel
In diesem Beispiel ist die Standard-Locale der Website Englisch (US) und das Discourse-Suchbanner. Dies ist die Standardkonfiguration:
Da es im GitHub-Repository keine Übersetzungen gibt, sehen alle Benutzer, unabhängig von der gewählten Locale:
Wenn ich die Standardzeichenfolgen für Englisch (US) bearbeite
Die Theme-Übersetzungen für alle anderen Locales zeigen immer noch den Standardtext für Englisch (US)
Aber die Zeichenfolgen werden für alle Locales überschrieben, auch für diejenigen, die in den Einstellungen immer noch den Standardtext anzeigen
Nachdem en_GB.yml mit denselben Standardzeichenfolgen zum GitHub-Repository hinzugefügt wurde, reicht die Bearbeitung der Zeichenfolgen für die Locale der Website nicht mehr aus. Die englische Version GB ist von der Änderung nicht betroffen.
Jetzt muss der Administrator beide Versionen anpassen, und je mehr Übersetzungen hinzugefügt werden, desto mehr Zeichenfolgen müssen angepasst werden.
Meine Erfahrung mit Websites mit unterschiedlichen Standard-Locales auf Discourse Discover zeigt, dass Administratoren oft nur den Text der Standard-Locale bearbeiten. Das bedeutet, dass mit jeder Übersetzung, die der Theme-Komponente hinzugefügt wird, weniger Benutzer die angepasste Version sehen.
Deshalb halte ich Übersetzungen für Beispieltexte für weniger nützlich, solange es keine Option gibt, alle Übersetzungen auf einmal zu überschreiben.
