Multilanguag

[Forumsgast]

Hallo@all,

ich weiß das Thema wurde schon oft durchgekaut, allerdings weiß ich nicht genau, welche Lösung in meinem Fall die Beste ist.

Ich arbeite an einem Mandantenfähigem CMS.
Ein Kunde kann unter einer Oberfläche alle seine Seiten(Accounts) verarbeiten.
Jeder Account besitzt seine eigene Datenbank.
Alle Accounts verwenden die gleichen Datein ( Framework, Applicationen, Module, usw. )

Ich möchte als Quelle für die Übersetzungen nicht die DB verwenden, da dies bei änderungen sehr umständlich wäre, alle account Dbs zu updaten. Weiterhin wäre dieser weg von der Performance her wohl auch nicht angebracht.

Ein weiterer Gedanke war es Gettext zu verwenden. Hier habe ich gelesen, dass gettext nicht Multithreadfähig ist. In wie weit ich auf dieses Problem stoßen könnte, kann ich so jetzt garnicht abschätzen.
Die Software Poedit ist nach meiner Erfahrung auch sehr wiederspenstig.

Ich überlege ob ich XML als Quelle verwenden sollte!

Was meint Ihr? Macht das Sinn? Oder sollte man einfache txt Datein verwenden? Wobei es hier schnell Probleme mit UTF8 geben könnte.

[Forumsgast]

Hi,

Ich möchte als Quelle für die Übersetzungen nicht die DB verwenden, da dies bei änderungen sehr umständlich wäre, alle account Dbs zu updaten. Weiterhin wäre dieser weg von der Performance her wohl auch nicht angebracht.

Eine Datenbank bietet den Vorteil, dass der Redakteur seine Werte selbst übersetzen kann. Beim Ausliefern der Seite kannst du dann doch ohne Probleme ein Caching-Layer zwischenschalten.

Ein weiterer Gedanke war es Gettext zu verwenden. Hier habe ich gelesen, dass gettext nicht Multithreadfähig ist. In wie weit ich auf dieses Problem stoßen könnte, kann ich so jetzt garnicht abschätzen.
Die Software Poedit ist nach meiner Erfahrung auch sehr wiederspenstig.

Warum ist Multithreading ein Hinderungsgrund für dich? Ein Webserver wie der Apache verteilen die Anfragen auf unterschiedliche Prozesse, die die Anfragen parallel bearbeiten können. Innerhalb des Apache-Prozesses wird PHP als Thread gestartet und gettext ausgeführt. Da beim Ausliefern der Seite ein rein lesender Zugriff stattfindet sind dinge wie Locking unrelevant.

Ich überlege ob ich XML als Quelle verwenden sollte!

Dann aber besser eine ungecachte Datenbank. XML ist nicht nur unintuitiv für den Redakteur, sondern auch noch mit einigem Overhead gesegnet, der das Auslesen und Verarbeiten nicht gerade einfach und performant gestaltet.

Was meint Ihr? Macht das Sinn? Oder sollte man einfache txt Datein verwenden? Wobei es hier schnell Probleme mit UTF8 geben könnte.

Ich bevorzuge bei flatfile-Ansätzen ini-Dateien. Das Format ist intuitiv, besitzt nahezu keinen Overhead und lässt sich mit PHP-Mitteln sehr schnell verarbeiten (-> parse_ini_file()).

Was das Thema mehrsprachiges CMS angeht, kannst du dir folgende Seiten ansehen:

• http://www.php.de/beitragsarchiv/439...higes-cms.html
• http://adventure-php-framework.org/S...hrsprachigkeit

Cheers,
Dr.E.

[Forumsgast]

Danke erstmal für die ausführliche Antwort.

Hast natürlich recht, xml hat wirklich nen hohen overhead.
Bei der verwendung von ini datein stoße ich auf ein problem oder ich verstehe es einfach nicht.

Wenn ich den Text in die ini Datei schreiben möchte, gibt es ein Problem mit Sonderzeichen.

In der Doku steht folgendes:

Enthält ein Wert in der ini Datei nicht alphanumerische Zeichen, so muss dieser von doppelten Anführungszeichen (") eingeschlossen sein.

Wenn ich jetzt einen text mit einem ! speichere muss der zu speichernde String in "" stehn.

In der ini Datein steht da als Beispiel folgendes:
test = \"Hallo!\"

Wenn ich die ini Datei wieder Auslese mit parse_ini_file ist der string wieder etwas anders.

Array
(
    [System] => Array
        (
            [test] => \Hallo!\
        )

)

Das würde bedeuten, dass ich beim schreiben immer alle Strings in "" setzten muss natürlich drauf achten das dies auch nur einmal passiert und das ich dann beim auslesen das Array Parsen darf und die Backslashes zu entfernen.

Sehe ich das richtig? Oder habe hier einen Grundlegenden Fehler?

P.s. Der 2 Link ist Kaput

[Forumsgast]

wenn du " in deinem Text selbst nutzen willst musst du das " escapen mit dem \ escapen:

baa = "Foo \" Baa\""

Dann enthält baa später

Foo "Baa"

[Forumsgast]

P.s. Der 2 Link ist Kaput

Jetzt nicht mehr.

[Forumsgast]

Mir geht es ja um das schreiben in eine ini Datei. Wenn ich Zeichen wie " Verwenden möchte im string das diese escapt werden müssen ok, aber das ist doch unpraktisch.

Ich möchte nicht direkt in der Datei arbeiten, sondern die Datei mit hilfe eines skriptes editieren und erweitern. Und wenn ich einen String in "" setze, dann wird diese nicht so wie in deiner Doku dr.e. gespeichert.
# [de]
# Form.Name = "Ihr Name"
# Form.EMail = "Ihre E-Mail-Adresse"
# Form.Subject = "Betreff"

Sondern so:
test = \"Hallo!\"
Beim auslesen verschwinde die "" ich möchte eigentlich nicht, dass man beim übersetzten drauf achten muss das man " escapt.

[Forumsgast]

Für das Schreiben von ini-Dateien hat mal jemand hier im Forum eine nette Klasse gepostet. Ich glaube mich erinnern zu können, es war Avedo. Such mal danach, diese nimmt dir das Problem bereits ab.

Ich möchte nicht direkt in der Datei arbeiten, sondern die Datei mit hilfe eines skriptes editieren und erweitern.

Dort kannst du derartige Sonderfälle ja programmatisch abfangen, doer nicht?

[Forumsgast]

Mir geht es ja um das schreiben in eine ini Datei. Wenn ich Zeichen wie " Verwenden möchte im string das diese escapt werden müssen ok, aber das ist doch unpraktisch.

Ich möchte nicht direkt in der Datei arbeiten, sondern die Datei mit hilfe eines skriptes editieren und erweitern. Und wenn ich einen String in "" setze, dann wird diese nicht so wie in deiner Doku dr.e. gespeichert.
# [de]
# Form.Name = "Ihr Name"
# Form.EMail = "Ihre E-Mail-Adresse"
# Form.Subject = "Betreff"

Sondern so:
test = \"Hallo!\"
Beim auslesen verschwinde die "" ich möchte eigentlich nicht, dass man beim übersetzten drauf achten muss das man " escapt.

Wenn du willst dass einText in " steht sollte das dann wohl so aussehen:

baa = "\"Text in Anführungszeichen\""

Das erste und das letzte " sind für die ini selbst wichtig um auch über Zeilenumbüche hinweg zu erkennen was zum String gehört und die escapten " sind dann die die du in deinem text haben willst, wenn du sowas mit php generieren willst sähe das grob vereinfacht so aus:

$uebersetzungen = array();
$uebersetzungen['baa'] = '"Text in Anführungszeichen"';

foreach($uebersetzungen as $key => $value) {
    echo $key . ' = "' . str_replace('"', '\"', $value) . '"' . PHP_EOL;
} 

Oder du nimmst eine fertige Klasse die das escapen und alles automatisch macht wenn nötig, z.b. Zend_Config_Writer (kann arrays, ini und xml)

[Forumsgast]

Ich habe vor einem ähnlichen Problem gestanden und verwende jetzt für mein Yana-Framework den OASIS-Standard XLIFF.

1. Man kann aus einem vorhandenen HTML-Dokument mit einem geeigneten Generator XLIFF exportieren
2. das Format ist relativ simpel
3. es gibt kostenlose und auch professionelle Translation-Memory Software für XLIFF, die richtig gut ist. Also: Workflow-Unterstützung, Unterstützung für Übersetzungsteams, Glossar, Einbindung automatischer Übersetzungssoftware, Rechtsschreibkontrolle et cetera
4. XLIFF ist ausreichend flexibel damit ich bei Bedarf Luft habe mich zu erweitern: alternative Übersetzungen, die nur für bestimmte Kontexte gelten, ist versionierbar über SVN, Gruppierung zusammengehöriger Texte, oder parallele Anzeige des Originaldokuments während der Übersetzung
5. auf PHP-Seite ist die Umsetzung einfach: mit SimpleXML die XLIFF-Datei lesen und mit XPath alle Ids und Werte extrahieren. Das ist bestenfalls ein 10-Zeiler. Danach geht es genauso weiter wie mit einem gewöhnlichen Array.
6. XLIFF kann man natürlich auch aus Datenbanken exportieren und umgekehrt - solange man mindestens eine Id-Wert-Zuordnung hat ist das kein Problem.

Nachteile gibt es natürlich auch. Dies sind aber eher Unzulänglichkeiten der verfügbaren kostenlosen Tools. Will man die Hobbyübersetzer mit ins Boot holen, muss man sich daher eventuell stark einschränken.
Wer aber selbst regelmäßig damit arbeiten möchte, für den sind kommerzielle Pakete für um die 100 Euro bereits preiswert zu haben. Damit kann man dann alle Features vollumfänglich nutzen.

#edit Links vergessen:
OASIS XML Localisation Interchange File Format TC OASIS XLIFF-FAQ
What Is XLIFF? Tutorial von SUN
XML in localisation: Use XLIFF to translate documents Tutorial von IBM
https://open-language-tools.dev.java.net kostenloser XLIFF-Editor
Swordfish Translation Editor kommerzieller XLIFF-Editor