Multilanguage

[paulbr]

Multilanguage ist ein sehr diskussionsfreudiges Thema, da gehen die Meinungen stark auseinander.
Deshalb mal ein eigenes Thema dazu, denke das macht Sinn.
Es gibt ja im Ansatz schon eine Überlegung hier: http://forum.clansuite.com/index.php/topic,29.msg42.html#msg42

Multilinguale GUI's und kleine Textübersetzungen ist das eine, Datenbanktexte das andere.

Überlegungen
Es gibt Clans die zeigen die texte einsprachlich an, je nachdem in welcher Sprache diese
eingegeben wurden. Andere wollen das strikt nach Sprache trennen.

1. Wie ist das bei den texten aus der DB eigentlich gedacht!
    a) Artikel- Newstexten: wird da in der Tabelle für jede sprache ein weiteres textfeld angelegt?
    b) Statischen Seiten: je nach sprache die entsprechende html/template (_sprache) datei laden?

2. Hilfetexte machen kaum Sinn die mittels {t}{/t} im template zu übersetzen, da die texte
   mitunter sehr gross sein können.

3. Die Metatags sind dann auch noch ein Problem, da diese ja in der clansuite.config.php eingegeben werden.
    Ein auslesen dieser aus der DB je nach Sprache würde Sinn machen (z.B. Suchmaschine).

4. Wie kann das beim hinzufügen einer neuen Sprache Administrativ gehandelt werden?

5. In Vergangenheit hatte ich des öfteren Kunden, die mehrere domains auf denselben account geschaltet hatten:
   - englische domain
   - spanische domain
   - deutsche domain

   Je nach Aufruf der domain im browser musste dann die richtige default Sprache gesetzt werden.
   Hier muss dann anhand der domain die sprache ermittelt und als standard eingestellt werden.
   Der browser schaltet sich ja nicht auf eine andere Sprache um, nur weil ich eine spanische oder
   englische domain eingebe. Eine Browserabfrage ist hier nicht möglich.
   Allerdings darf die Sprache anhand der domain nicht geändert werden, wenn man auf der Seite selbst
   die Sprache ändert 

gruss
paul

[Jens-A. Koch]

Das Thema ist eine unendliche Geschichte

1) Multilinguale GUI's und kleine Textübersetzungen
Derzeit geht es mir darum, Mehrsprachigkeit für GUI und Systemmeldungen mittels Gettext zu ermöglichen. Dazu wird auf bestimmte Tags wie t() oder _() abgestellt. Die Übersetzungen werden gescannt und in eine Gettext PO Datei verwandelt. Das ist die Ausgangsbasis für die Übersetzung in jede beliebige Zielsprache. Diese kann dann ein MO Objekt umgewandelt werden. Das Scannen und editieren wird per Webinterface laufen.

2) Texte die vom User erstellt werden
Das kann man über eine Veränderung des Doctrine Models erreichen.
Dazu fügt man [actAs][I18n] dem Model hinzu und bestimmt die DB-Felder [fields], die der Internationalisierung unterliegen sollen. Doctrine vervielfältigt dann dieses Feld in die Zielsprache(n). Genauer: es wird ein Translation Model zusätzlich erzeugt.

3) Hilfstexte
Es gab zwei Ideen dazu.
a) Die Hilfstext mit ins System zu legen. Also die direkte Ablage der Hilfstexte als html Dateien mit entsprechender Sprachendung. Die werden dann einfach eingebunden.
b) Ein Wiki-Ansatz bei dem die Texte aus dem Wiki geholt werden und auch direkt zu editieren sind.
c) Gettext ist nicht das richtige Mittel um längere Texte zu übersetzen. Das können wir ausschließen. Es gibt zwar Ansätze Gettext für solche Dinge einzusetzen, aber das Verbinden der Werkzeuge ist relativ schwer (gettext, xgettext, po4a chaining).

4) Metatags
Ja - die globale Config ist eher ungünstig. Wird höchstens als Fallback erhalten bleiben und durch Werte aus der Datenbank ergänzt. Denkbar wäre auch theme_info oder module_config als Ablage für diese Werte zu nehmen. Ein Viewhelper {metatag ...} wäre auch denkbar.

5) Mehrere Domains - Wahl der Locale
Also derzeit gibts folgenden Ansatz: über den ACCEPT_LANGUAGE Header des Browsers wird die Sprache des Users bestimmt. Falls der User dann eine andere Sprache haben möchte, dann wählt er diese beispielsweise im Sprachdropdown aus und seine Session wird angepasst.
Der Session Wert bestimmt dann fortan, welche Sprache ausgeliefert wird.

Ob die Domain .co.uk, .de, .fr, .es ist dabei egal.
Diese Seite wird immer in der Benutzersprache ausgeliefert, egal unter welcher Domain.
Voraussetzung ist, dass diese Sprache existiert. Ansonsten Fallback auf Englisch.

Andenken könnte man auch einen Fallback auf die Domain-Sprache. Aber dann muss diese auch existieren!
D.h. Benutzer mit Accept_Language [.de] besucht die Domain [.fr]. Französisch wäre der erzwungene Fallback, wobei zunächst nach [de] gesucht wird und wenn diese Sprache nicht verfügbar ist, dann [fr]. [en] wäre sozusagen, der Fallback des Domain-Fallback.

Benutzersprache über accept_language Header [de] > Domain-Fallback [fr] -> English-Fallback [en].

Gruß Jensa

[paulbr]

Das Thema ist eine unendliche Geschichte

das ist wohl war und es gibt hierfür 1000 und 1 Möglichkeit.

4) Metatags
...Denkbar wäre auch theme_info oder module_config als Ablage für diese Werte zu nehmen...

Themen bezogen macht keinen Sinn, dann hat man auf jeder Seite die gleichen Metatags.

Es macht mehr Sinn Globale Metatag Einstellungen welche sich nicht ändern in die $config
oder DB zu legen, ergänzend dann in module_config spezielle titel + keywords + bodyphrasen.
Wobei die bodytextphrasen wiederum ungeeignet in der module_config sind.
Es macht hier wohl mehr Sinn diese Infos in der Tabelle modules mit zu integrieren, bzw. eine
metatag tabelle mit modulname und entsprechende Matatagsinfos zu erstellen.

Jedes Modul hat ja seine Schwerpunkte, weshalb man entsprechend dafür keywords definieren sollte.

Eine Suchmaschinen Optimierung ist dann einfacher durchzuführen.
Bekanntlich sollte jedes Keyword 5-6% mal im Verhältnis der Wörter im Body einer Seite vorhanden sein,
um eine bestmögliche keyworddichte zu erreichen. Desweiteren sollten Phrasen zu jedem keyword
in den ersten 10 zeilen des bodytextes vorkommen.
Da ist fast unmöglich ohne das man hier kleine tricks anwendet.

Aber das mit der Suchmaschinen Optimierung ist eine Sache welche jetzt zuweit führt darüber zu fachsimpeln.
Man sollte nur im Hinterkopf behalten das man die Möglichkeit der keywords module bezogen dafür benötigt.

Viewhelper {metatag ...} sollte man auf jedenfall einfügen um die flexibilität zu bekommen, wenn
sich die metainfos moduleweise ändern.

Wie du schon sagtest, es gibt zuerst andere wichtigere Dinge zu erledigen.
Aber es kann durchaus Hilfreich sein evtl. jetzt schon die weichen dafür zu stellen.

ACCEPT_LANGUAGE Header des Browsers

Im Prinzip ja, wenn ich nun 3 domains wie in meinem post erwähnt habe, würde ich aber immer
egal welche domain ich aufrufe, de als default sprache bekommen, da mein firefox in deutsch ist.
d.H. ich musste den firefox in 3 verschiedenen sprachen installieren um testen zu können,
ob die jeweilige sprache auch als default ausgewählt wird.
Ich denke das macht nur Sinn, wenn man irgendwo ein flag setzen kann, welche Art oder Reihenfolge der Spracherkennung
greifen soll (erst browser- dann domainsprache oder umgekehrt), da es ja nicht der normalfall sein wird.
Die möglichen Sprachen kann man ebenfalls in der $config setzen. z.B. accept_languages = de, en, es, fr .....

2) Texte die vom User erstellt werden
Das kann man über eine Veränderung des Doctrine Models erreichen.

Das ist super, im prinzip ist es dann ähnlich wie ich es bisher mit postfixes praktizierte.
Je nach Sprache wird das entsprechende textfeld der DB: titel oder titel_1 oder titel_2 ... zurückgegeben.
default sprache ist 0 und braucht keinen postfix

gruss
paul

[Jens-A. Koch]

d.H. ich musste den firefox in 3 verschiedenen sprachen installieren um testen zu können, ob die jeweilige sprache auch als default ausgewählt wird.

Die vom Browser bei der Negotation gesendete Spracheinstellung kannst Du bei jedem Browser setzen. Beispielsweise für FireFox: Einstellungen > Inhalt -> Sprache (Wählen) -> Sprache hinzufügen / Ranking ändern. Beim nächsten Request wird die Seite dann entsprechend dieser Einstellung angefordert.

Der richtige Ort für den "Doppel"-Fallback ist die Datei localization.core.php - genauer, die Methode getLocale() siehe dort unter 3) Fallback. Dort kann man das ergänzen.