[cspiegl]

HI,
ich programmiere derzeit eine komplett neue Homepage und wuerde diese gerne Multilangual aufbauen also mit mehreren verschiedenen Sprachen.
Jetzt stellt sich mir die Frage, ob jemand ein Tutorial kennt welches das beschreibt.
Oder auch eine Klasse welche ich mir dann mal angucken kann und mir Ideen holen kann.

Wuerde mich wirklich freuen.

[ljungi]

Kommt drauf an, wie du es angehen willst.

Es gibt die Möglichkeit, einfach den Content 2x zu übersetzen, die Menüeinträge entweder in der DB oder in Dateien jeweils einzeln über define() oder Arrays zu setzen, oder aber mit i18n-Tools zu arbeiten, wie z.B. über XLIFF-Dateien.

[$traight-$hoota]

Nur mal so, es heit multilingual (sowohl im Englischen als auch im Deutschen).

Bevor Ben dazu kommt, hier mal gleich die Links zum Zend-Framework: *gg*
Übersicht über Localization und Zend_Translate

[Ben]

Schau dir mal Zend_Translate an.
Da werden einige interessante Dinge angesprochen. Folgelinks sollte es auch geben.

Ansonsten mal die Forensuche bemühen .. das ich das mal sagen werde.


---
Ich hab nix gesagt.

[Ben]

Nachtrag, um ein paar Links zu streuen:
http://www.developers-guide.net/foru...tze-perfomance
[PHP] Ein eigenes Templatesystem schreiben (inkl. Sprachdateien)
Sprachvariablen aus der Datenbank ersetzen

usw. ...

[cspiegl]

also erstmal danke fuer die vielen Antworten.
Ich habe mir das ganze jetzt mal angesehen und bin (immernoch) von der Datenbankmethode besonders begeistert.
Da ich kein Freund von 'Daten in Dateien' (ausser der Code Selbst) bin.
Allerdings werde ich es so machen das die Daten per Admininterface aenderbar sind und ausserdem gecached werden (somit eigentlich in einem Array gespeichert werden).

Der Uebersetzer braucht also letzten Endes keine Programmierkenntnisse sondern schlicht und ergreifend die Kenntnis wie man mit einem Formular auf einer Homepage umgeht.

Ich werde mal gucken was draus wird. Der Spannendste Teil ist (meiner Meinung nach) wie man die Daten in die DB speichert (da ich nur sehr ungern wegen jeder Sprache eine neue Spalte mache, habe ich es mir bis jetzt so ueberlegt, das ich fuer jede Sprache eine Tabelle anlege und dazu gibt es dann eine Master Tabelle in welcher festgelegt ist, welche Sprache welche ID hat und diese ID ist in dem Tabellennamen der SprachTabelle auch enthalten. Wenn hierfuer jemand eine Idee hat/einen Verbesserungsvorschlag, bitte schreiben)

Jetzt wirft sich mir noch eine Frage auf: wie macht man das am sinnvollsten in den Templates, wie definiert man am "einfachsten" was wohin gehoert.
Mit Platzhaltern / Variablen, soweit bin ich schon (habe ja auch schon ein eigenes Template System).
Die Frage ist sollte man "angelehnt an eine bestimmte Sprache" die Variablen benennen oder kann man auch z.B.: die ID eines Wortes dort einsetzen (wobei ich denke das ziemlich die Uebersicht floeten geht).

Ich bin schon auf eure Antworten gespannt.

[dr.e.]

Ich werde mal gucken was draus wird. Der Spannendste Teil ist (meiner Meinung nach) wie man die Daten in die DB speichert (da ich nur sehr ungern wegen jeder Sprache eine neue Spalte mache, habe ich es mir bis jetzt so ueberlegt, das ich fuer jede Sprache eine Tabelle anlege und dazu gibt es dann eine Master Tabelle in welcher festgelegt ist, welche Sprache welche ID hat und diese ID ist in dem Tabellennamen der SprachTabelle auch enthalten. Wenn hierfuer jemand eine Idee hat/einen Verbesserungsvorschlag, bitte schreiben)

Mehrere Tabellen anzulegen ist IMHO nicht notwendig. Eine Tabelle, die ein Schlüsselwort, Sprache und Übersetzung beinhaltet reicht völlig. Wenn man Sprachen nochmals normalisieren möchte, reicht auch

- Key
- Übersetzung
- Referenz auf Sprach-ID

Jetzt wirft sich mir noch eine Frage auf: wie macht man das am sinnvollsten in den Templates, wie definiert man am "einfachsten" was wohin gehoert.
Mit Platzhaltern / Variablen, soweit bin ich schon (habe ja auch schon ein eigenes Template System).
Die Frage ist sollte man "angelehnt an eine bestimmte Sprache" die Variablen benennen oder kann man auch z.B.: die ID eines Wortes dort einsetzen (wobei ich denke das ziemlich die Uebersicht floeten geht).

Wenn du schon ein "eigenes Template System" hast ist es doch ein leichtes, diesem einen generischen Token samt Parser beizubringen, der an Hand eines Keys eine Übersetzung in der richtigen Sprache aus der Datenbank - oder dem Cache - zieht. Einzige Voraussetzung ist, dass dein Template System das Attribut "Sprache" kennt, sprich dieses in der Erstellung, Befüllung und im Rendering genutzt bzw. beachtet wird. So man man beispielsweise bei einem Gästebuch die sprachabhängigen Teile einfach im Template durch den angesprochenen Token füllen lassen. Beispiel:

------------- template_guestbook_header.html -------------
<h1>[languagetext key="Guestbook_Title"]</h1>
<br />
[languagetext key="Guestbook_Description"]
<br />
<br />
<br />
[include file="/path/to/my/listing/template.html"]
------------- /template_guestbook_header.html -------------

Wichtig an diesem Beispiel ist, das das hier inkludierte Template "template.html" auch die Sprache des aktuellen kennt, so dass dort vorhandene Sprachtexte (z.B. für die Bezeichungen der Felder) auch korrekt ausgegeben werden. Die Implementierung des Tags muss dabei so intelligent sein, dass bereits in den Speicher geladene Texte (-> Mehrfachdarstellung) auch vom Speicher und nicht aus der Datenbank geladen werden.

Man kann sich nun sicher noch für die Administration überlegen, welche Gruppierung man für Übersetzungen generiert, damit sich der Übersetzer besser orientieren kann. Letztlich ist das aber nur Kosmetik, die Basis (Ausgabe) funktioniert aber identisch.

Hinweise hierzu findest du auch unter
- http://www.adventure-php-framework.org/Seite/TagLibTags, Kapitel 2.2.3. Getstring
- http://www.adventure-php-framework.o...getstring.html (Implementierung des Tags für sprachabhängige Werte aus Dateien)
-

[cspiegl]

danke fuer die ausfuerliche Antwort. Ich werde mich dem ganzen morgen nachmittag mal widmen, da es jetzt doch schon etwas spaet geworten ist

Also melde ich mich dann nochmal...

P.S.: das ganze klingt auf jeden fall recht logisch.