Basti

Natürlich hat Text nichts in den Templates verloren. Es ging doch nur darum, dass mitunter bei bestimmten Spachen andere Templates sinnvoll werden (Leserichtung).

... Aber stimmt, du hast recht, hier scheinen tatsächlich einige die Meldungen in die Templates zu schreiben. Naja, jedem seins.

Basti

Mister Ad

heohni

Ich wollte das nochmal kurz nach oben bringen:

1. Mit den PatTemplates ist das eine ganz interessante Lösung, man lässt den "default" Text im template, umschliesst ihn aber mit einem speziellen Tag. Und je nach Sprachauswahl des Users, werden die entsprechenden ini files geladen, fehlt irgendwo eine Übersetzung, wird der default Wert angezeigt.

Für mich ist das ok, auch um dann die Übersetzer an die Files zu lassen, geht eigentlich auch ganz gut.

Nett, die Default Datei wird automatisch erstellt, ich muss die dann nur kopieren und unter den jeweiligen Sprachnamen abspeichern

2. Datenbanklösung: Heisst das nicht, man fragt für jedes Wort die Datenbank ab? Macht das wirklich Sinn?

Zergling-new

Eher für eine bestimmte Kategorie, außerdem stehen in der DB ja nicht nur Worte, sondern vor allem Textblöcke.

heohni

Was aber nur geht, wenn keine Formatierungs Geschichten vorkommen, denn sobald nur ein [b] vorkommt, brechen die meisten Übersetzer schon zusammen

M3g4Star

Die formatierung sollte ja größtenteils der CSS überlassen werden ...

Basti

Problem dabie ist eben wie gesagt, dass die Zuordnung über den Originaltext läuft und bei einer Änderung dort eben flöten geht, oder werden wie wird das gelöst?

Bei der Frage nach Datenbank oder Textfile (oder ...) geht es nur darum, wie die Daten gespeichert werden. Also auch darum, wie schnell sie Auffindbar sind etc. Das hat aber mit dem grunsätzlichen i18n-Mechanismus, für dan man sich entscheidet nichts zu tun. Du kannst also sowohl Datenbank-Datensätze, als auch Textdateien, als auch PHP-Arrays sowohl mit einem Schlüsselwort, wie auch mit dem Originaltext indizieren.

Ich weiß nicht, worauf du diese Aussage beziehst, aber prinzipiell kommst du praktisch nicht ohne Platzhalter, ggf. sogar Textauszeichnungs-Elementen in Sprachdateien aus, es sei denn du zerpflückst die Texte bis aufs kleinste und dann hast du das Problem, dass du die Reihenfolge der Textblöcke im Template festzimmern musst. Du hast dort also dann die feste, für alle Sprachen geltende Angabe: Text1, Variable1, Text2, Variable2, Text3. Und das beißt sich mitunter mit den unterschiedlichen Satzbauten der unterschiedlichen Sprachen.

Wie weit das zu berücksichtigen ist, hängt aber natürlich (wie alles) von den Anforderungen ab.

Die Tags dienen ja auch nicht zur Formatierung (Art und Weise der Darstellung bestimmter Elemente), sondern zur Strukturierung der Inhalte. Wenn du diese Strukturelemente raus lässt hast du eben genau das oben besprochene Problem, dass du die Telementenreihenfolge fest ins Template schreiben musst (<h1>{_title}</h1>

{_text_part1}{_link1}{_text_part2}</p>).

Basti

fuhrmara

Hi !

In einem älteren Projekt
http://www.phpshadow.de
hatte ich beide Varianten eingebunden.

Die Pflege der Keywords und der Übersetzung wurde in einer Datenbank gespeichert, aus der per Script eine INC-Datei der entsprechenden Sprache generiert wurde.

Somit hätte man beide Vorteile genutzt : Komfortabel per Dialog und Datenbank pflegen, schnell durch einbindung per include.





Grüße
Ralf

Sieht bei mir so aus:

Tatsächlich gibt es am Ende pro jede Sprache ein Skript aber nicht beim Edititeren. Denn, wie Du schon sagst, bei Layoutänderungen ist das dann sehr unpraktisch.

Daher wird ein einziges Template für das Layout benutzt. Darin kannst Du KEYWORDS oder KEYTEXTE in einer einzigen Sprache platzieren. Beim Generieren der endgültigen Skripte in die Verzeichnisse appDE .. appEN ... etc. werden diese KEYWORDS automatisch durch die sprachspezifischen Texte ersetzt. Du brauchst dazu nur einen einfachen Parser und eine Syntax für die KEYWORDS (xml oder selbst definieren z.B: {X der Text oder Textkennzeichen X}).