3 verschiedene Möglichkeiten für Multilanguages

[deklarmart]

Original geschrieben von wahsaga
Und warum willst du diese sprachabhängigen Daten jetzt im PHP-Code oder Datenbank ablegen?

Ich würde sagen, du möchtest deine Templates in x verschiedenen Sprachversionen anlegen.
Dann pack doch die Templates in einen Unterordner mit Sprachbezeichnung, oder nehme sie in die Dateinamen mit auf.

Ja, das ist gut ausgedrückt! Also die Templates sollen in X Sprachen sein, richtig!
Im Prinzip funktioniert deine Möglichkeit mit jeweils einem Template für
eine Sprache. Aber das ist definitiv zu Statisch! Stell dir vor es ändert
sich was am Layout, oder neue Felder kommen hinzu usw. Dann muss das
in jedem der X Templates geändert werden.

Je länger ich darüber nachdenke, desto sinnvoller erscheint mir die GetText()
Variante... aber ich bin mir nicht sicher. Daher frag ich hier ja nach möglichst
vielen Erfahrungen/Meinungen. Gerade in Bezug auf GetText() und die
verschiedenen Plattformen (wegen der kompilierung) usw.

[wahsaga]

Original geschrieben von deklarmart
Im Prinzip funktioniert deine Möglichkeit mit jeweils einem Template für
eine Sprache. Aber das ist definitiv zu Statisch! Stell dir vor es ändert
sich was am Layout, oder neue Felder kommen hinzu usw. Dann muss das
in jedem der X Templates geändert werden.

Ja, natürlich.

Je länger ich darüber nachdenke, desto sinnvoller erscheint mir die GetText() Variante...

Ach :-)

[deklarmart]

Original geschrieben von wahsaga
Ach :-) [/B]

Und? Ist es die sinnvollste Variante? Vor neuen Dingen mit der Komplexität
bin ich vorsichtig! Nicht, das wir Stundenlange Arbeitszeit in etwas investieren,
was plötzlich Grenzen hat oder so überhaupt nicht für unsere Anforderungen
geeignet ist.
Wenn du Erfahrung mit i18n hast, wäre ich sehr interessiert, diese zu hören.

[Slava]

ich glaube nicht dass du mehrere Templates brauchst.
schau dir bitte noch ein mal mein erster Beitrag(nicht der 2-te)

in deiner Template hast du keine
Produktname: ме-ньше знаешь
Produktbeschreibung: спишьлучше тем спишьспишь луч ше спишь

sondern
{productname} : {beschreibung}
{Produktbeschreibung} : {text_zumbeschreibung}


dann hast du auch eine extra Tabelle(sieh mein erste Posting),
die aufgelistete Begriffe zur einer Seite Binden und zwar mit dem dazugehörigem Platzhalter.
nun wird es beim Parsen entschieden ob in Produktbeschreibung platzhalter ein hinesische oder spanische übersetzung kommt.

also du muss dich von php-sicht von jeder Art von Textausgaben mit echo trennen.

[deklarmart]

Original geschrieben von Slava
dann hast du auch eine extra Tabelle(sieh mein erste Posting),
die aufgelistete Begriffe zur einer Seite Binden und zwar mit dem dazugehörigem Platzhalter.
nun wird es beim Parsen entschieden ob in Produktbeschreibung platzhalter ein hinesische oder spanische übersetzung kommt.

Ja, das setzt aber voraus, das ich JEDES "Beschreibungsfeld" (wie zB.
{Produktname}, {Produktbeschreibung}, ...) in der Datenbank ablegen
muss. Das wird ENORM viel, da es letztlich jedes Attribut, Button, Inputfeld
und was weiß ich noch alles betrifft.
Genau deswegen habe ich ja in meinem ersten Posting folgendes geschrieben:

Original geschrieben von deklarmart
Das System ist keine Homepage in dem Sinne, sondern dient zum verwalten
von (ich nenne es mal) Produkten. Diese Produkte haben eine vielzahl
von Attributen! Es wird also in der Browser-Ansicht später große
Tabellen geben, mit vielen Feld-Beschriftungen und Buttons,
sowie Info-Texten zu den Eingabefeldern.

Klar, es wäre vielleicht machbar, aber im Grunde ein enormer Aufwand,
gerade bei der Entwicklung. Ich habe deine Lösung wie du es beschreibst
auch schon mal angewendet, aber das war für eine einfache Homepage
mit {titel1}, {titel2}, {seitentext}, {weiter}, {zurück}, {löschen}, {abschicken}.
Für den Umfang ist deine Möglichkeit in Ordnung, aber ich denke für
große Sachen ist es zu kompliziert. Oder liege ich damit falsch?!

[Cpt]

Erstmal sorry das ich so einen alten Thread nochmal rauskrame, aber ich beschäftige mich gerade selber mit diesem Thema.

Normalerweise sind Übersetzungen etwas sehr statisches. Daher macht es in meinen Augen keinen Sinn, bei jedem Seitenaufruf diese Übersetzungen aus der Datenbank zu lesen. Viel performanter wäre es doch, wenn man einfach eine Templateengine schreibt die folgendes macht:

- die einzelnen statischen Übersetzungen, unabhängig davon wie diese gespeichert werden (ob in Arrays, Datenbanken etc. spielt keine Rolle) werden von der Engine eingelesen
- die Templates werden kompiliert, d.h. die Platzhalter für die einzelnen statischen Übersetzungen werden durch die konkreten Werten aus dem 1. Schritt ersetzt

Ergebnis: Die Abfrage der ganzen statischen Übersetzungen, wie z.b. Bezeichnungen entfällt, da als Templatedatei eine "kompilierte Datei" verwendet wird. Lediglich die nicht statischen Übersetzungen (z.b. Monatsangaben in einer Datumsanzeige) müssen jetzt bei jedem Aufruf ausgelesen werden und in der Templateengine verarbeitet werden.

Sollte sich das Template verändern, oder eine Übersetzung verändern, müsste man einfach nur noch das Template einmal neukompilieren lassen. Dieser Schritt wird allerdings in einer Produktivumgebung selten nötig sein.

[tontechniker]

Ganz genau so. Noch irgendwelche Fragen?