Open skreutzer opened 9 years ago
Ja, das sollte man möglichst früh berücksichtigen. I18N nachträglich einbauen ist immer doof. Symfony empfiehlt übrigens XLIFF: http://symfony.com/doc/current/book/translation.html#basic-translation
Darüber hinaus müssen auch die Datenbankinhalte sprachabhängig abgelegt werden. Das sollte nochmal konzeptioniert werden, siehe Wiki.
Die Dokumentation empfiehlt, die Locale als Bestandteil der URL umzusetzen. Das ergäbe dann so etwas wie $/de/themenfeld/55cd2a9808985ca80c3c986d. Fallback (falls die Locale nicht gefunden werden kann) wäre Englisch, Default (Standardvorgabe, wenn keine Locale explizit angefragt wird) wäre Deutsch?
Wir haben das mal "geschäftlich" diskutiert, also wie die Realisierung mehrsprachiger Inhalte als Geschäftsmodel funktionieren müsste und sind zu dem Ergebnis gekommen, dass jede Implementierung pro Land (Wegen unterschiedlicher Vertragsrechte zwischen Dembelo und Inhaltsschaffenden) einen eigenen Verantwortlichen bräuchte. Was technisch bedeuten würde, dass jedes Land eine eigene Dembeloinstallation hätte, dessen Spracheinstellung sich über die Domain entscheiden würde. Was die Sprachauswahl einerseits vereinfacht, weil der Ländercode hard codiert sein kann, aber die Herausforderung steigert, weil sie einzelnen Installationen untereinander kommunizieren können müssen. Also z.B. die Logindaten einer anderen Installation anfordern und Nutzer die auf mehreren Sprachversionen registriert sind müssen dazwischen hin und her wechseln können.
Ich weiß nicht ob das schon gesagt wurde: Eine eindeutige Zuordnung zwischen Original und Übersetzung ist nicht notwendig, weil das System darauf ausgelegt sein soll, dass sich die Übersetzung ggf. anders entwickelt als das Original. Und den seltenen Fall, dass jemand das System zum Sprachen lernen verwendet müssen wir nicht im System abdecken, das sollen die Leute doch bitte über Blogs und so regeln.
OK. Das eine ist die Mehrsprachigkeit der Inhalte, wo es Übersetzungen, aber auch unübersetzte Originale in verschiedenen Sprachen geben kann. Diese werden in separaten Installationen vorgehalten. Besteht die Anforderung (oder auch nur die potentielle Notwendigkeit in der Zukunft), dass die Sprache der Benutzeroberfläche einer Installation vom Benutzer geändert werden können muss? Wenn nicht, wäre die Locale bei jeder Installation fest vorzugeben, womit es dann nicht mehr möglich wäre, deutsche GUI-Beschriftungen über eine Datenbank mit englischen Texten zu legen, außer, dies wird generell für die gesamte Installation geändert (statt nur für die Session des Users).
Erstmal ist eine Sprachumschaltung der GUI nicht notwendig. Wir können DE_de in der Konfiguration hinterlegen.
Bitte unter dem Meilenstein "Internationalisierung" auf Teilaspekte runterbrechen.
Internationalisierung an mindestens einer Stelle einbauen, um festzulegen, welche Technik hierfür zum Einsatz kommen soll. Wahrscheinlich PHPs gettext? Die Internationalisierung und Lokalisierung (für letzteres wäre Deutsch und Englisch ganz gut) kann dann zukünftig Schritt für Schritt durch sämtlichen Code gezogen werden.