Homepage Mehrsprachig

[kaepten]

Hallo Forum

Gibts hier jemand der bereits Mehrsprachige PHP-Homepages gebaut hat?

Ich möchte eine solche Mehrsprachige Seite machen und suche nach einem geeigneten Konzept.

Eines wäre gewesen: Sämtliche Texte (Strings) werden in einer mySQL DB gehalten. Bei einem ersten Seitenaufruf werden sämtliche Strings der gewüschten Sprache aus der DB geholt und in die Session gestellt. So kann jede Seite ohne dass sie wieder DB Zugriffe machen muss auf die gewünschten Textfragmente zugreifen. Ich habe aber auf http://www.dclp-faq.de/q-sessions-datenmenge.html gelesen, dass man "massvoll" Variablen in der Session erzeugen soll (??) Ich geh schon davon aus, dass sämtliche Strings der gesamten Site grösser als diese 5kB werden....

Was nun? Gibts noch andere Konzepte?

Vielen Dank für Tipps und Hinweise!
kaepten

[Linksetzer]

Was nun? Gibts noch andere Konzepte?

http://selfhtml.teamone.de/diverses/htaccess.htm#alternative_inhalte

[kaepten]

Hoi Linksetzer

http://selfhtml.teamone.de/diverses/htaccess.htm#alternative_inhalte

Ok, das ist eine Alternative. Ich möchte sie aber nicht berücksichtigen. Wenn ich es recht verstehe gibts dann für jede Sprache eine eigene Seite - das finde ich persönlich keine Alternative. Es ist umständlich und eine redundanz von Dokumenten will ich ja gerade damit verhindern, dass die Texte aus einer Datei in ein und dasselbe Dokument gefüllt wird.

Danke trotzdem
kaepten

[Michael Schröpl]

Hi kaepten,

http://selfhtml.teamone.de/diverses/htaccess.htm#alternative_inhalte
Ok, das ist eine Alternative.
Ich möchte sie aber nicht berücksichtigen.

Solltest Du aber. Siehe auch:
http://aktuell.de.selfhtml.org/artikel/server/alt-http/

Wenn ich es recht verstehe gibts dann für jede
Sprache eine eigene Seite

Ja - das Ergebnis der Negotiation sind eindeutige
Pfadnamen auf dem Server.

Es ist umständlich

Es ist sehr schön übersichtlich getrennt.

und eine redundanz von Dokumenten will ich ja
gerade damit verhindern, dass die Texte aus einer
Datei in ein und dasselbe Dokument gefüllt wird.

Du kannst sehr wohl diejenigen Teile, die in allen
Sprachvarianten gleich sein sollen, via SSI in die
Dokumente jeder Sprache einfügen - oder umgekehrt.
Das ist beides beliebig kombinierbar.

Besuche mal
   http://www.schroepl.net/projekte/mod_gzip/index.htm
mit unterschiedlichen Browser-Einstellungen (mit und
ohne "Deutsch" in Deiner Sprachen-Liste) - und über-
lege Dir, wie wohl die Navigationsleiste in die
Dokumente kommt. Kleiner Tip: Sie steht nicht in der
jeweiligen Dokument-Datei drin ... und es ist auch nur
eine einzige Navigationsleiste, obwohl sie in jedem
Dokument anders aussieht ... und es ist auch keine
serverseitige Programmiersprache. Nur reines SSI.

Andererseits: Du mußt ja nicht dem Apache die Negotia-
tion überlassen - Du kannst das ja auch selbst program-
mieren. gzip_cnc tut das beispielsweise. Es geht nur
darum, die Übermittung der Sprache nach HTTP-Standard
vorzunehmen und nichts Proprietäres zu erfinden.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[kaepten]

hoi Michael

Solltest Du aber. Siehe auch:
http://aktuell.de.selfhtml.org/artikel/server/alt-http/

Das sieht sehr interessant aus, werd mit heute zu Gemüte führen.

Ja - das Ergebnis der Negotiation sind eindeutige
Pfadnamen auf dem Server.

Es ist umständlich

Es ist sehr schön übersichtlich getrennt.

Naja das stimmt schon, dass es übersichtlich ist. Ich gebe zu anfänglich gegen diesen "dynamisierungs-wahn" und "Logik von Layout" trennen auch meine Widerstände gehabt zu haben. Ich fand es einfach sehr unübersichtlich. Trotzdem ist es ein fact, dass eine Seite besser zu warten ist, als wenns von einer Seite noch drei andere in anderen Sprachen gibt (SSI hin oder her)

Andererseits: Du mußt ja nicht dem Apache die Negotia-
tion überlassen - Du kannst das ja auch selbst program-
mieren. gzip_cnc tut das beispielsweise. Es geht nur
darum, die Übermittung der Sprache nach HTTP-Standard
vorzunehmen und nichts Proprietäres zu erfinden.

Proprietär auf keinen Fall. Dennoch klappt das mit dem HTTP-Header auch nicht unbedingt. Denn Du musst Dir vorstellen, dass die angezeigte Sprache nicht unbedingt mit dem Broser (HTTP-Header) zu tun haben muss! Beispiel Schweiz: Du hast hier durchaus Sprache Deutsch, möchtest aber eine Seite dennoch in Französisch anzeigen. Ich meine damit einfach, die Sprache muss auf jeden Fall explizit und jederzeit vom Besucher ausgewählt werden können.

Vielen Dank für Deine Antworten!
kaepten

[Michael Schröpl]

Hi kaeptn,

Dennoch klappt das mit dem HTTP-Header auch nicht
unbedingt.

doch. ;-)

Denn Du musst Dir vorstellen, dass die angezeigte
Sprache nicht unbedingt mit dem Broser (HTTP-Header)
zu tun haben muss!

Doch, hat sie.

Beispiel Schweiz: Du hast hier durchaus Sprache
Deutsch, möchtest aber eine Seite dennoch in
Französisch anzeigen.

Kein Widerspruch von meiner Seite.

Ich meine aber wirklich die Sprache, die via HTTP
übermittelt wird - nicht etwa die Sprache, in der
die Browser-Menüs angezeigt werden.

Ich meine damit einfach, die Sprache muss auf
jeden Fall explizit und jederzeit vom Besucher
ausgewählt werden können.

Hast Du Dir etwa noch nie die Konfiguration Deines
Browser (egal, welcher!) gründlich angesehen?

Viele Grüße
      Michael

[Andreas]

Hallo!
Es geht ja aber in erster Linie darum, das die Benutzer das können! Und das wage ich zu bezweifeln! Ich hatte ja auch schonmal mit dem Gedanken gespielt, ist auch sehr verlockend, aber ich habe es dann doch gelassen, naja. Was man höchtens machen könnte, diese Einstellung als Voreinstellung nehmen, und über Links dann die anderen Alternativen anbieten. Nur dann kann man die Sprache einmal am Anfang auswerten, aber man kann es nicht über die kpl. Seite verwenden, oder?
Grüße
Andreas

[kaepten]

Hoi

Es geht ja aber in erster Linie darum, das die Benutzer das können!

Ja genau! Es geht nur darum. Mich interessiert ehrlich gesagt übeeeeerhaupt nicht was der Surfer fürn Browser hat - von mir aus kann er auch chinesisch als Standardsprache eingetellt haben.

Ich will meine Seiten in einer Default-Sprache anbieten -  ok möglicherweise ermittelt über den HTTP-Header, aber jeder Benutzer sollte via Link, oder Button die Sprache auf der Homepage umschalten können. Und da trennen sich die Wege von Header und was ich anzeigen möchte...

kaepten

[Michael Schröpl]

Hi kaepten,

Ja genau! Es geht nur darum. Mich interessiert
ehrlich gesagt übeeeeerhaupt nicht was der Surfer
fürn Browser hat - von mir aus kann er auch
chinesisch als Standardsprache eingetellt haben.

hat er aber nicht. Mit hoher Wahrscheinlichkeit hat
er eine sinnvolle Default-Sprache - gerade _weil_ er
wahrscheinlich gar nicht weiß, wie man das umstellt.

Ich will meine Seiten in einer Default-Sprache
anbieten -  ok möglicherweise ermittelt über den
HTTP-Header, aber jeder Benutzer sollte via Link,
oder Button die Sprache auf der Homepage umschalten
können. Und da trennen sich die Wege von Header und
was ich anzeigen möchte...

Wie ich bereits sagte: Du kannst die Negotiation auch
selbst erledigen - beispielsweise dann, wenn bei dem
Link, den der Benutzer über den Umschalt-Button er-
reicht hat, ein zusätzlicher Parameter im Query-String
steht, welcher Vorrang gegenüber dem HTTP-Header hat.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Andreas]

Hallo!

hat er aber nicht. Mit hoher Wahrscheinlichkeit hat
er eine sinnvolle Default-Sprache - gerade _weil_ er
wahrscheinlich gar nicht weiß, wie man das umstellt.

Das ist denke ich klar, daher ein guter Indiz für den default-Wert, aber das Problem ist, wenn man es umstellen möchte kann man ja schlecht vom Server aus die Browsereinstellungen ändern!

Wie ich bereits sagte: Du kannst die Negotiation auch
selbst erledigen - beispielsweise dann, wenn bei dem
Link, den der Benutzer über den Umschalt-Button er-
reicht hat, ein zusätzlicher Parameter im Query-String
steht, welcher Vorrang gegenüber dem HTTP-Header hat.

Das Problem ist, das dieser dann bei jedem Request gesendet werden muß! Wie willst Du das machen? Das könnte man höchstens über eine Session machen(hatte ich gar nicht dran gedacht, wäre aber dann Voraussetzung!)
Eine weitere Idee ist folgende:

Man könnte ja mit mod_rewrite ein Unterverzeichnis, z.B. /de/ simulieren! Man läßt alles beim alten, schreibst nur eine entsprechende Rule in die .htaccess und schwupp könntest Du in PHP mit

<?
if(strstr($SCRIPT_URI,"/de/")) {$sprache = "DE";}
elseif(strstr($SCRIPT_URI,"/en/")) {$sprache = "EN";}
//...
?>

ja immer ohne extra Parameter an die Sprache kommen. Ich denke das ist einfacher, als an alle Links manuell ein "?lang=DE" anzuhängen, oder?
Problematisch könnte das nur mit den Verknüpfungen werden, denn der Browser denkt er sei in einem Unterverzeichnis und kommt so nicht mehr an die Dateien, die ja im Hauptverzeichnis liegen. Weißt Du wie man das noch umgehen könnte?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

ja immer ohne extra Parameter an die Sprache kommen.
Ich denke das ist einfacher, als an alle Links manuell
ein "?lang=DE" anzuhängen, oder?

wenn Du ohnehin jeden Zugriff mit serverseitiger Intel-
ligenz auswerten muß, also ausschließlich dynamische
Seiten hast, dann ist das Dranhängen eines Parameters
an alle Links sehr einfach.
Hättest Du statische Dokumente, dann würde ich darin
ein Problem sehen ... aber mit statischen Dokumenten
kannst Du ja eben keine eigene Negotiation machen.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Andreas]

Hallo Michael!

wenn Du ohnehin jeden Zugriff mit serverseitiger Intel-
ligenz auswerten muß, also ausschließlich dynamische
Seiten hast, dann ist das Dranhängen eines Parameters
an alle Links sehr einfach.

Na das stimmt mich ja sehr zuversichtlich ;-)
Dann laß mal hören wie man mal ebenso ohne Session und Cookies dann alle Links umschreiben kann?! Oder wie auch immer Du das so leicht zu können scheinst ;-)

Hättest Du statische Dokumente, dann würde ich darin
ein Problem sehen ... aber mit statischen Dokumenten
kannst Du ja eben keine eigene Negotiation machen.

Auch der Apache selbst nicht? Also im Fall der Fälle andere Dokumente ausgeben, oder die Url umschreiben oder ähnliches?

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

wenn Du ohnehin jeden Zugriff mit serverseitiger Intel-
ligenz auswerten muß, also ausschließlich dynamische
Seiten hast, dann ist das Dranhängen eines Parameters
an alle Links sehr einfach.
Na das stimmt mich ja sehr zuversichtlich ;-)
Dann laß mal hören wie man mal ebenso ohne Session und Cookies dann alle Links umschreiben kann?!

Du mußt sie doch gar nicht "umschreiben" - Du erzeugst
sie in diesem Fall doch alle selbst, muß also jeweils
nur Dein eigenes "print"-Statement anpassen.

Hättest Du statische Dokumente, dann würde ich
darin ein Problem sehen ... aber mit statischen
Dokumenten kannst Du ja eben keine eigene
Negotiation machen.
Auch der Apache selbst nicht?

Nicht so, daß die Inhalte dabei dynamisch umgeschrieben
werden - in _diesem_ Fall sind die Links ein Problem.

Also im Fall der Fälle andere Dokumente ausgeben,
oder die Url umschreiben oder ähnliches?

Wie gesagt: Bei statischen Seiten würde nur Parsen
helfen (und dann wären sie nicht mehr statisch).
Schau Dir gzip_cnc an, wenn Du wissen willst, wie ich
das in den Apache hinein hängen würde - so ein Handler
wäre das dann halt auch.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Christoph Schwarz]

Hallo kaepten.

Wenn es nicht viel Text ist köntest du ja 2 verschiedene Dateien anlegen für die 2 Sprachen.
In dieser Datei könnten dann in From von Variablen die verschieden sprachigen Texte stehen.
Diese Datei kannst du dann mit include einbinden.

Dann kannst du durch Übergabe eine Variable $sprache="deutsch";

die jeweilige Datei einbinden

if(!$sprache)
{
 $sprache="deutsch";//defaultsprache
}
include ("./sprache/".$sprache.".php");
// setzt die verschiedenen Sprachen nach Auswahl um

Bsp:

$WILLKOMMEN="Guten Morgen";

Auf der Seite selbst rufst du dann die Texte mit der Varibale auf.

echo "$WILLKOMMEN";

ich denke das müßte klappen.
Nachteil, man muß immer die Variable $sprache mit übergeben.
Und die Datei sprachexyz.php wird immer mitgeladen.

Hoffe ist nicht zu verrückt diese Idee.

Salut,
Christoph

[kaepten]

Hoi Christoph

Wenn es nicht viel Text ist köntest du ja 2 verschiedene Dateien anlegen für die 2 Sprachen.

Das ist eben der knackpunkt. Ich kann es nicht abschätzen wie viel Text werden kann, bestimmt aber nicht wenig.

ich denke das müßte klappen.
Nachteil, man muß immer die Variable $sprache mit übergeben.
Und die Datei sprachexyz.php wird immer mitgeladen.

Hoffe ist nicht zu verrückt diese Idee.

Ja die Idee ist durchaus durchführbar. Man kann das im selben System anstatt mit Dateien auch DB-Basiert machen (wäre wohl besser). Aber das Problem auch bei Deiner Lösung ist, dass ich jedesmal unzählige Strings/Texte lade, die ich möglicherweise nicht brauchen werde. Das möchte ich vermeiden.

kaepten

[Christoph Schwarz]

Hallo kaepten

Ja die Idee ist durchaus durchführbar. Man kann das im selben System anstatt mit Dateien auch DB-Basiert machen (wäre wohl besser). Aber das Problem auch bei Deiner Lösung ist, dass ich jedesmal unzählige Strings/Texte lade, die ich möglicherweise nicht brauchen werde. Das möchte ich vermeiden.

Stimmt aber im meiner Lösung hat der client damit keine Probleme, nur der Server, da Texte die nicht als Variable aufgerufen werden nicht mitgeschickt werden und es gibt keinen Datenbankaufruf.
Vielleicht könnte man die Dateien auch in mehrer kleine splitten.

Aber ich bin auch mal auf einen bessere Lösung gespannt, weil mir nur meine eingefallen ist und ich zugeben muß, daß die nicht besonders clever ist.

Salut,
Christoph

[Philipp Hasenfratz]

Halihallo ihr zwei

Ja die Idee ist durchaus durchführbar. Man kann das im selben System anstatt mit Dateien auch DB-Basiert machen (wäre wohl besser). Aber das Problem auch bei Deiner Lösung ist, dass ich jedesmal unzählige Strings/Texte lade, die ich möglicherweise nicht brauchen werde. Das möchte ich vermeiden.

Stimmt aber im meiner Lösung hat der client damit keine Probleme, nur der Server, da Texte die nicht als Variable aufgerufen werden nicht mitgeschickt werden und es gibt keinen Datenbankaufruf.
Vielleicht könnte man die Dateien auch in mehrer kleine splitten.

naja, eventuell kann man ja noch eine weitere splittung für _jede_ page vornehmen, also:

/languages/de/index.php
/languages/en/index.php
/languages/de/forum.php
[...]

gibt zwar einiges an Aufwand, aber wär möglich...

das Kriterium "Variablen iniziieren, ohne sie zu verwenden" ist meiner Meinung nach nicht relevant. Solange sich die Datenmenge in Grenzen hält, spielts wegen ein Paar Variablen keine Rolle.

Warum lädst du die Daten nicht in ein assoziatives Array?
Schauen sie mal ins Forum=Take a look at my forum
...

im Hauptprogramm kannst du dann einfach auf das assoziative Array zugreifen und den gewollten Deutschen Text als Key übergeben... Dann musst du nicht die Variablennamen auswendig lernen.

Viele Grüsse

Philipp

[kaepten]

Hallo

naja, eventuell kann man ja noch eine weitere splittung für _jede_ page vornehmen, also:

/languages/de/index.php
/languages/en/index.php
/languages/de/forum.php
[...]

Genau diesen Ansatz überlege ich mir, jedoch DB Basiert. Das heisst ein Record hat nicht nur eine ID, sondern auch eine Spalte in der steht zu welcher Seite der Eintrag gehört. Natürlich sollte es auch einen allgemeinen Teil geben für Texte z.B. auf Buttons die sich wiederholen.

Die Idee mit dem Array ist auch prüfenswert, aber eignet sich wohl nur wenn zweisprachig.

kaepten

[Philipp Hasenfratz]

Halihallo nochmals

naja, eventuell kann man ja noch eine weitere splittung für _jede_ page vornehmen, also:

/languages/de/index.php
/languages/en/index.php
/languages/de/forum.php
[...]

Genau diesen Ansatz überlege ich mir, jedoch DB Basiert. Das heisst ein Record hat nicht nur eine ID, sondern auch eine Spalte in der steht zu welcher Seite der Eintrag gehört.

Und dann noch einen Index auf die Spalte und die Performance ist gesichert ;)

Die Idee mit dem Array ist auch prüfenswert, aber eignet sich wohl nur wenn zweisprachig.

Warum denn? - Die Namen entsprechen dem Deutsch (oder was immer du willst) und der value der _entsprechenden_ Sprache, die der Kunde gewählt hat. Das Array wird beim Programmbeginn mit Werten aus der entsprechenden Übersetzungdatei eingelesen und ist dehalb auch auf 1000 verschienene Sprachen anwendbar. Es würde erst ein Problem geben, wenn du auf _derselben_ Seite zwei oder mehrere Sprachen haben willst und das zur _selben_ Zeit (und das ist wohl nicht Zweck der Übung, oder?).

Viele Grüsse

Philipp

[Andreas]

Hallo!

Ja die Idee ist durchaus durchführbar. Man kann das im selben System anstatt mit Dateien auch DB-Basiert machen (wäre wohl besser). Aber das Problem auch bei Deiner Lösung ist, dass ich jedesmal unzählige Strings/Texte lade, die ich möglicherweise nicht brauchen werde. Das möchte ich vermeiden.

Was hälst Du davon, in der DB eine weitere Spalte einzufügen, nämlich dateiname? Also dann würdest Du zu dem Text immer noch 'index.php'... speichern, dann könntest Du bei einer Abfrage ein "AND dateiname = '$scriptname'" anhängen und Du hättest nur die Strings für eine bestimmte Seite! Das würde ich sogar als erste WHERE Bedingung nehmen, da performanter. Wenn Du das mit einer Array-Lösung kombinierst, könntest Du in das Array-Script evtl einen Array für jede Seite anlegen!!! Das dürfte dann wirklich gut sein, oder? Denn dadurch wird das Script nicht nennenswert größer, könntest dann aber in der Funktion immer nur den Array mit den relevanten Daten einbinden!!!

Viele Grüße
Andreas

PS: Den Thread habe ich vorher gar nicht gesehen;-)

[Philipp Hasenfratz]

Halihallo

Gibts hier jemand der bereits Mehrsprachige PHP-Homepages gebaut hat?

aber mit perl...

Eines wäre gewesen: Sämtliche Texte (Strings) werden in einer mySQL DB gehalten.

das ist schon mal gut...

Bei einem ersten Seitenaufruf werden sämtliche Strings der gewüschten Sprache aus der DB geholt und in die Session gestellt.

So kann jede Seite ohne dass sie wieder DB Zugriffe machen muss auf die gewünschten Textfragmente zugreifen.

ist aber ein wenig Speicherverschwendend... Ich bin bisher ganz gut damit gefahren, wenn ich bei jedem Programm eine DB-Connection aufbaue und die Texte dann immer über diese hole...

Was nun? Gibts noch andere Konzepte?

ich kann dir mal kurz was zu meiner sagen:

erste Variante:
Das erste mal kam ich in Zusammenhang mit <www.swiss.tv> mit Langugageindependance in Kontakt. Dort hab ich ein ziemlich simples Interface dafür gebastelt:
Die zu verwendende LanguageID wird in der Session gespeichert, oder wahlweise über die URL mitgeschleppt. Der Text wird mit gettext( <TextID> ) geholt und ausgegeben. Diese Prozedur funktioniert ganz einfach: TextID aus der Session holen und entsprechenden Übersetzungsrecord aus der DB lesen (SELECT Translated FROM LanguageTranslatedItem WHERE TextID=... AND LanguageID=...).

zweite Variante:
Nun, dann hab ich für ne andere Site ein zweites Interface basteln müssen:
Ich habe bemerkt, dass die Sprachen etwas komplizierter sind... Z. B. bei zusammengesetzen Sprachkonstrukten (wenn ich z. B. eine nicht zu übersetzende URL in eine Übersetzung einfügen muss); oder wenn die Satzstellung sich bei diesen in verschiedenen Sprachen ändern.
Dafür hab ich dann Platzhalter in die Sprachtexte eingefügt, welche dann wohl in jeder Sprache an einem anderen Ort stehen (z. B. "hallo %1, das ist meine Welt" => "hello %1, this is my world"). Eventuell lässt sich so ein Platzhalter auch noch übersetzen (falls es sich nicht um eine URL o. ä. handelt und auch sprachabhängig ist). Da ich unter ziemlichen Zeitdruck bei diesem Projekt stand und ich nicht jeden Record eingenhändig in die DB eintragen wollte, habe ich die gettext-Prozedur erweitert:
Die gettext-Prozedur erhält _keine_ TextID, sondern den deutschen Text, wie ich ihn im Programm haben will (das hab auch den Vorteil, dass man den Programmquelltext viel besser versteht: gettext(209) oder gettext('Hallo %1, füllen Sie bitte das folgende Formular aus')). Falls der übergebene Text noch nicht in der DB auffindbar ist, wird er automatisch eingefügt und später durch einen Übersetzer (menschlicher Natur) übersetzt. Oh, da kommt mir grad eine Idee. Ich könnte den Bablefish anzapfen und eine Vorabübersetzung implementieren ;)

Vielleicht nicht genau deine Frage, aber auch interessant...

Viele Grüsse

Philipp

[kaepten]

Hoi

ist aber ein wenig Speicherverschwendend... Ich bin bisher ganz gut damit gefahren, wenn ich bei jedem Programm eine DB-Connection aufbaue und die Texte dann immer über diese hole...

Wen kümmert heutzutage Memory? ;-) Java wohl kaum, dort wird mit den Ressource-Files genau sowas gemacht.

erste Variante:
Das erste mal kam ich in Zusammenhang mit <www.swiss.tv> mit Langugageindependance in Kontakt. Dort hab ich ein ziemlich simples Interface dafür gebastelt:
Die zu verwendende LanguageID wird in der Session gespeichert, oder wahlweise über die URL mitgeschleppt. Der Text wird mit gettext( <TextID> ) geholt und ausgegeben. Diese Prozedur funktioniert ganz einfach: TextID aus der Session holen und entsprechenden Übersetzungsrecord aus der DB lesen (SELECT Translated FROM LanguageTranslatedItem WHERE TextID=... AND LanguageID=...).

Ja das scheint mir solide und gut zu sein, ist mir jedoch wegen den vielen einzelnen DB zugriffen nicht so geheuer.

zweite Variante:
Nun, dann hab ich für ne andere Site ein zweites Interface basteln müssen:
Ich habe bemerkt, dass die Sprachen etwas komplizierter sind... Z. B. bei zusammengesetzen Sprachkonstrukten (wenn ich z. B. eine nicht zu übersetzende URL in eine Übersetzung einfügen muss); oder wenn die Satzstellung sich bei diesen in verschiedenen Sprachen ändern.
Dafür hab ich dann Platzhalter in die Sprachtexte eingefügt, welche dann wohl in jeder Sprache an einem anderen Ort stehen (z. B. "hallo %1, das ist meine Welt" => "hello %1, this is my world"). Eventuell lässt sich so ein Platzhalter auch noch übersetzen (falls es sich nicht um eine URL o. ä. handelt und auch sprachabhängig ist). Da ich unter ziemlichen Zeitdruck bei diesem Projekt stand und ich nicht jeden Record eingenhändig in die DB eintragen wollte, habe ich die gettext-Prozedur erweitert:
Die gettext-Prozedur erhält _keine_ TextID, sondern den deutschen Text, wie ich ihn im Programm haben will (das hab auch den Vorteil, dass man den Programmquelltext viel besser versteht: gettext(209) oder gettext('Hallo %1, füllen Sie bitte das folgende Formular aus')). Falls der übergebene Text noch nicht in der DB auffindbar ist, wird er automatisch eingefügt und später durch einen Übersetzer (menschlicher Natur) übersetzt. Oh, da kommt mir grad eine Idee. Ich könnte den Bablefish anzapfen und eine Vorabübersetzung implementieren ;)

Tja diese Idee dünkt mich etwas speziell. Da muss du doch aufwendige "WHERE" abfragen über Texte in der DB machen. Vermutlich nicht sehr performant, das würde ich mich nicht getrauen zu machen, obschon der Ansatz, dass die Seite wenigstens wieder etwas lesbarer wird durchaus seinen Reiz hat!

kaepten

[Philipp Hasenfratz]

Halihallo

[...]

Tja diese Idee dünkt mich etwas speziell. Da muss du doch aufwendige "WHERE" abfragen über Texte in der DB machen. Vermutlich nicht sehr performant, das würde ich mich nicht getrauen zu machen, obschon der Ansatz, dass die Seite wenigstens wieder etwas lesbarer wird durchaus seinen Reiz hat!

Du sprichst einigemale das Thema Performance an und die Anzahl nötiger SQL-queries. Es ist schon klar, dass einiges an P. draufgeht. Aber in meinen Projekten liess sich das nicht anders machen. Die Sprachunabhängigkeit musste jede dyn. generierte Seite umfassen und musste auch einfach wartbar sein. Die Performanceeinbussen konnte ich grösstenteils mit Indizies lösen. Wenn du genügend Spracheinträge hast ist das sogar _schneller_, als wenn du eine andere Variante über z. B. Textfiles einlesen wählst (diese müssten ja sequentiell ausgelesen werden; dafür gibt's keinen AVL-Baum). Übrigens: die .php Solution würde ich nicht empfehlen, da diese vom php - Interpreter _interpretiert_ werden muss ( => Performance!).
Die Anzahl SQL-Queries hängt wohl damit zusammen, wieviele Seiten/Sprachtexte man hat; das ist auch bei den Textfiles o. anderen Lösungen nicht anders ;)

Viele Grüsse

Philipp

[Michael Schröpl]

Hi auch,

Die zu verwendende LanguageID wird in der Session
gespeichert, oder wahlweise über die URL
mitgeschleppt.
Der Text wird mit gettext( <TextID> ) geholt und
ausgegeben. Diese Prozedur funktioniert ganz
einfach: TextID aus der Session holen und
entsprechenden Übersetzungsrecord aus der DB
lesen (SELECT Translated FROM
LanguageTranslatedItem WHERE TextID=... AND
LanguageID=...).
Ja das scheint mir solide und gut zu sein, ist mir
jedoch wegen den vielen einzelnen DB zugriffen
nicht so geheuer.

Mir auch nicht.

Ich würde die Meldungsschlüssel nach Sprache und
Modulname präfixen und jeweils alle Meldungen eines
aufgerufenen Programms mit einem Rutsch lesen:

SELECT <felder> FROM msgtable WHERE msgkey LIKE
"$language$module%";

Präfixmatch über einen Unique Index ist sehr schnell,
trotz LIKE kann der Index verwendet werden.

Dafür hab ich dann Platzhalter in die Sprachtexte
eingefügt, welche dann wohl in jeder Sprache an
einem anderen Ort stehen (z. B. "hallo %1, das
ist meine Welt" => "hello %1, this is my world").

Schon an anderer Stelle erwähnt:
http://www.schroepl.net/pbm/software/united/_dokument/msg_file.htm

Eventuell lässt sich so ein Platzhalter auch
noch übersetzen (falls es sich nicht um eine
URL o. ä. handelt und auch sprachabhängig ist).

Ja - teilweise sind die Einfügungen in meine Meldungen
selbst wieder Inhalte von Meldungen. Das Anwendungs-
programm muß genau wissen, was es tun will.

Die gettext-Prozedur erhält _keine_ TextID,
sondern den deutschen Text, wie ich ihn im
Programm haben will (das hab auch den Vorteil,
dass man den Programmquelltext viel besser
versteht: gettext(209) oder gettext('Hallo %1,
füllen Sie bitte das folgende Formular aus')).

Bei mir steht die deutsche Version der Meldung als
Kommentar im Quelltext.

Oh, da kommt mir grad eine Idee. Ich könnte
den Bablefish anzapfen und eine Vorabübersetzung
implementieren ;)

Ich habe mal so eine Babelfisch-Übersetzung "nach-
bearbeitet" ... weia.

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Philipp Hasenfratz]

Halihallo Michael

hast auf das falsche Posting geantwortet. Du nimmst (fast) nur Bezug auf meine Texte ;-)

Ja das scheint mir solide und gut zu sein, ist mir
jedoch wegen den vielen einzelnen DB zugriffen
nicht so geheuer.

Mir auch nicht.

Ich würde die Meldungsschlüssel nach Sprache und
Modulname präfixen und jeweils alle Meldungen eines
aufgerufenen Programms mit einem Rutsch lesen:

Hm. Ja, das ist ne gute Idee. Ich werd das noch für meine Zwecke so implementieren.

Präfixmatch über einen Unique Index ist sehr schnell,
trotz LIKE kann der Index verwendet werden.

Exakt! Damit arbeite ich auch.

Dafür hab ich dann Platzhalter in die Sprachtexte
eingefügt, welche dann wohl in jeder Sprache an
einem anderen Ort stehen (z. B. "hallo %1, das
ist meine Welt" => "hello %1, this is my world").

Schon an anderer Stelle erwähnt:
http://www.schroepl.net/pbm/software/united/_dokument/msg_file.htm

Hm. Schön, dass sich meine Überlegungen in einem offiziellen Dokument wiederfinden ;-)
Interessant... Vielleicht überarbeite ich mein Firma::Language::Translation - Modul nochmals...

Die gettext-Prozedur erhält _keine_ TextID,
sondern den deutschen Text, wie ich ihn im
Programm haben will (das hab auch den Vorteil,
dass man den Programmquelltext viel besser
versteht: gettext(209) oder gettext('Hallo %1,
füllen Sie bitte das folgende Formular aus')).

Bei mir steht die deutsche Version der Meldung als
Kommentar im Quelltext.

so geht's auch. Arbeitest du mit Templates? - Oder parsed du den generierten Source nach dessen Erstellung nochmals komplett durch? - Bei mir wird das eben gleich im Programm eingefügt, dass der Text auch gleich an den Client zurückgesendet werden kann...

Oh, da kommt mir grad eine Idee. Ich könnte
den Bablefish anzapfen und eine Vorabübersetzung
implementieren ;)

Ich habe mal so eine Babelfisch-Übersetzung "nach-
bearbeitet" ... weia.

:-)
Ja, ja, ich weiss... Wär trotzdem lustig, wenn gleich eine englische Übersetzung käme, obwohl man noch gar nix übersetzt hat (einfach so, kurz eingetippt und schon erscheint die englische Version; irgendwie aufregend was man so alles machen könnte) ;-)

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Michael, nochmals kurz...

Schon an anderer Stelle erwähnt:
http://www.schroepl.net/pbm/software/united/_dokument/msg_file.htm

Hm. Schön, dass sich meine Überlegungen in einem offiziellen Dokument wiederfinden ;-)
Interessant... Vielleicht überarbeite ich mein Firma::Language::Translation - Modul nochmals...

Himmel noch eins, ay caramba!!! - Ich hab nicht mal bemerkt, dass dieses Dokument von dir stammt (bin voll darüber hinweggeflogen)! - Hast wohl absichtlich nix gesagt was??? :-)
Gott sei dank hab ich nix schlimmes gesagt ;-)

Sehr schön find ich übrigens die Singular/Plural-Problematik. Dies hab ich in meiner Umsetzung damals gar nicht weiter beachtet. Müsste ich immer im Quelltext abfragen... Ne ganz feine Sache, wenn das gleich durch das Translation-Modul gefiltert wird...

Viele Grüsse

Philipp

PS: Jetzt hat sich die Frage, ob du das nachträglich parsed oder templateorientiert arbeitest auch ergeben... Dein Programm ist ja in Pascal geschrieben, nicht? - Auf jeden Fall keine Internetanwendung.

[Michael Schröpl]

Hallo Philipp,

http://www.schroepl.net/pbm/software/united/_dokument/msg_file.htm
Hm. Schön, dass sich meine Überlegungen in einem offiziellen Dokument wiederfinden ;-)

was ist ein 'offizielles Dokument'? ;-)

Himmel noch eins, ay caramba!!! - Ich hab nicht mal
bemerkt, dass dieses Dokument von dir stammt (bin
voll darüber hinweggeflogen)! - Hast wohl
absichtlich nix gesagt was??? :-)

War der URL denn nicht aussagekräftig genug?

Sehr schön find ich übrigens die Singular/Plural-
Problematik. Dies hab ich in meiner Umsetzung
damals gar nicht weiter beachtet. Müsste ich immer
im Quelltext abfragen... Ne ganz feine Sache, wenn
das gleich durch das Translation-Modul gefiltert
wird...

Ich habe mal gehört, im Spanischen (oder Portugiesi-
schen?) gäbe es noch einen dritten Fall für "zwei
Stück" ... den habe ich nicht implementiert.

PS: Jetzt hat sich die Frage, ob du das nachträglich
parsed oder templateorientiert arbeitest auch
ergeben...

Direkt "daneben" gibt es noch einen zweiten Artikel,
der die Bedienung des Meldungssystems erklärt:

http://www.schroepl.net/pbm/software/united/_dokument/meldung.htm

Dein Programm ist ja in Pascal geschrieben, nicht?
Auf jeden Fall keine Internetanwendung.

Borland-Pascal für pures DOS:

<img src="http://www.schroepl.net/pbm/software/united/screen.gif" border=0 alt="">

... und der Hauptgrund dafür, daß ich noch keine Linux-
Maschine daheim habe. Ich komme einfach nicht dazu,
ca. 50000 lines of Pascal code nach Linux zu portieren
(den FreePascal-Compiler gäbe es ja, aber ich müßte
ich trotzdem erst mal dort einarbeiten).

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Philipp Hasenfratz]

Halihallo Michael

Himmel noch eins, ay caramba!!! - Ich hab nicht mal
bemerkt, dass dieses Dokument von dir stammt (bin
voll darüber hinweggeflogen)! - Hast wohl
absichtlich nix gesagt was??? :-)

War der URL denn nicht aussagekräftig genug?

Doch, aber ich hab doch tatsächlich gar nicht darauf geschaut, sondern nur die Page geöffnet und gleich den Inhalt überflogen (das rechtszentrierte 'Michael Schroepl' hab ich auch noch übersehen)... Keine Ahnung, wie sowas passieren kann, aber es ist passiert... Anscheinend war ich so gespannt auf den Inhalt, dass ich alles um mich herum bzw. alles was nicht linksbündig und nach Text ausschaut überlesen bzw. vergessen habe...

so was aber auch :-)

Sehr schön find ich übrigens die Singular/Plural-
Problematik. Dies hab ich in meiner Umsetzung
damals gar nicht weiter beachtet. Müsste ich immer
im Quelltext abfragen... Ne ganz feine Sache, wenn
das gleich durch das Translation-Modul gefiltert
wird...

Ich habe mal gehört, im Spanischen (oder Portugiesi-
schen?) gäbe es noch einen dritten Fall für "zwei
Stück" ... den habe ich nicht implementiert.

Oh, dann werd ich das gleich mitimplementieren; und wenn wir schon dabei sind bis zu n-Mal (warum denn nur ein oder zweimal? - Wir wollen doch nicht so beschränkt wie DOS mit den Laufwerksbuchstaben sein, nicht? - Ich halte da lieber an Linux) :-)

PS: Jetzt hat sich die Frage, ob du das nachträglich
parsed oder templateorientiert arbeitest auch
ergeben...

Direkt "daneben" gibt es noch einen zweiten Artikel,
der die Bedienung des Meldungssystems erklärt:

http://www.schroepl.net/pbm/software/united/_dokument/meldung.htm

Sehr interessant! - Wie weit bist du mit der Programmierung? - Ich würde mich für den Source des Moduls sehr interessieren (verspreche auch, dass ich es nicht in gleicher Weise weiterverwenden würde - das geb ich dir auch schriftlich oder per signiertem Mail). Allgemein: Ich sehe immer gerne Sourcecodes von anderen an und hier würd mich auch der Inhalt interessieren.

Dein Programm ist ja in Pascal geschrieben, nicht?
Auf jeden Fall keine Internetanwendung.

Borland-Pascal für pures DOS:

Ist ne lange Zeit her, aber damit hab ich mich auch einige Jahre vergnügt... BP7.0 juhee! - Aber auf einen 50000-Zeiler hab ich's bisher in dieser Sprache nicht geschafft. :-)

Viele Grüsse

Philipp

[Michael Schröpl]

Hallo Philipp,

http://www.schroepl.net/pbm/software/united/_dokument/meldung.htm

Sehr interessant!
Wie weit bist du mit der Programmierung?

Von dem Zeug? Hast Du Dir das Änderungsdarum des
Dokuments etwa auch nicht angeschaut? :-\

Ist ne lange Zeit her, aber damit hab ich mich
auch einige Jahre vergnügt... BP7.0 juhee! -
Aber auf einen 50000-Zeiler hab ich's bisher in
dieser Sprache nicht geschafft. :-)

Ich auch nicht (UNITED/PC sind 33xyz).

Aber Du mußt auch
    http://www.schroepl.net/pbm/software/
komplett zusammenzählen ...

Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael

[Ole]

hi kaepten

ich habe ein recht großes mehrsprachiges projekt in coldfusion realisiert, ist zwar nicht ganz php, aber den ansatz kann man ja vieleicht übernehmen.

das projekt ist mit nur 2 sprachen gestartet, da wir aber wußten das noch mindestens 6 weitere folgen werden haben wir sämtliche texte von vorneherein in einer datenbank hinterlegt und diese dann über templateseiten dynamisch ausgegeben.

das ganze hatte 2 nachteile:

1. der aufbau der seiten dauerte recht lange, da jede seite aus einer menge text-fragmenten bestand
2. unser nicht grade überdimensionierter server ging in stoßzeiten regelmäßig in die knie

also haben wir unseren ansatz etwas modifiziert.
die texte iegen auch weiterhin in einer mysql datenbank, aber...und das sit der clou ;)...alle seiten sind dynamisch statisch.
klingt komisch, ist aber so :)

wir halten für jede seite ein template und die entsprecheneden text-frakmente in der datenbank vor.
wird nun eine neue seite erstellt, wird

1. das template erstellt und
2. die texte in die datenbank geschrieben...in allen sprachen

der trick ist jetzt
3) das erzeugen von statischen seiten aus den templates und den db-einträgen, je eine seite pro sprache und template. festplattenplatz kostet ja nichts mehr.

so haben wir nur noch ein minimum an datenbank anfragen wenn ein user eine seite aufruft, weil diese schon komplett vorhanden ist.

wird nun ein text geändert, muß nur einmal die statische seite neu erzeugt werden.
ähnliches bei einer neuen sprache:
einfach alle vorhanden texte übersetzen und aus den templates die seiten erzeugen...fertig :)

hoffe dir ein wenig geholfen zu haben und dir vieleicht den einen oder anderen ansatz geliefert zu haben :)

so long
ole
(8-)>

[kaepten]

hi ole

Den geschilderten Ansatz werde ich nochmals genau durchdenken. Aber ich befürchte dass, da meine Seiten durchwegs dynamische Daten (weitere Daten aus DB und Berechnungnen) enthalten, dieser Ansatz nicht funktionieren würde (?).

hoffe dir ein wenig geholfen zu haben und dir vieleicht den einen oder anderen ansatz geliefert zu haben :)

Vielen Dank!
kaepten

[Ole]

hi kaepten

Den geschilderten Ansatz werde ich nochmals genau durchdenken. Aber ich befürchte dass, da meine Seiten durchwegs dynamische Daten (weitere Daten aus DB und Berechnungnen) enthalten, dieser Ansatz nicht funktionieren würde (?).

zusätzliche abfragen sind ja kein problem, die kannst du ja in die feritgen seiten einbauen, dann hast du was dynamisch-statisch-dynamisches *g*.
du erzeugst einfach nur die dateien soweit wie sie nicht grundsätzlich dynamisch sien müssen (z.B. werden alle texte eingebunden, dinge wie ein dynamischer ticker etc. bleiben aber wieterhin dynamisch). damit minimierst du die zugriffe aud die ladezeit :)

so long
ole
(8-)>

[Matti Maekitalo]

use Mosche;

Ich möchte eine solche Mehrsprachige Seite machen und suche nach einem geeigneten Konzept.

Einige grosse Projekte (wie das KDE-Projekt (<www.kde.org>, ein *ix-Desktop) nennen das ganze i18n (internationalization). Bei KDE wird das ganze so gemacht:

du schreibst alles in einer Sprache (zB deutsch). Gleichzeitig bekommt aber jeder (zusammengehörende) String ein "Tag" mitgegeben, der den String markiert. Vor dem Senden des Textes an den Client werden alle Tags rausgefilter und der entsprechende Text in irgendeiner Art von Datenbank nachgeschlagen. Das Problem ist allerdings, dass du alle Ausgaben deines Programms noch filtern musst - ob du es über einen Apache-Handler machst oder mit irgendwelchen PHP Mitteln (kenne ich nicht so gut), bleibt dir überlassen.

use Tschoe qw(Matti);

[kaepten]

hoi

Einige grosse Projekte (wie das KDE-Projekt (<www.kde.org>, ein *ix-Desktop) nennen das ganze i18n (internationalization). Bei KDE wird das ganze so gemacht:

Ja von dem habe ich gehört und gelesen. Das soll in Varianten von Perl integriert sein. Es klang aber so, dass es sich um etwas speziellere handeln würde (selbst kompilieren und so teufelszeug ;-))

du schreibst alles in einer Sprache (zB deutsch). Gleichzeitig bekommt aber jeder (zusammengehörende) String ein "Tag" mitgegeben, der den String markiert. Vor dem Senden des Textes an den Client werden alle Tags rausgefilter und der entsprechende Text in irgendeiner Art von Datenbank nachgeschlagen. Das Problem ist allerdings, dass du alle Ausgaben deines Programms noch filtern musst - ob du es über einen Apache-Handler machst oder mit irgendwelchen PHP Mitteln (kenne ich nicht so gut), bleibt dir überlassen.

Ich werde das nochmals genauer anschauen, obschon ich mich nur auf sog. "Standard-Konfigurationen" wie sie auf den allermeisten Providern vozufinden sind verlassen möchte.

Gruss
kaepten

[Philipp Grashoff]

Hi kaepten,

Ich habe gerade erst ein 2sprachiges Projekt gemacht, dass in ein paar Tagen fertig ist...

Nun, was ich gemacht habe, stand bei einigen schon so in ungefaehr drinnen, aber nie genau das gleiche:

nun, ich habe einfach erstmal alle Dinge, die in beiden sprachen gleich sind (bilder, reine php-dateien ohne ausgabe usw) in ihre ordner gemacht;
den Rest der hp (ist dann ja nur html- und php quelltext, also klein) habe ich dann einfach kopiert, beides in unterverzeichnisse mit dem sprachennamen (also de oder en ;) und nur den betreffenden text umgeschrieben... auf der loginseite wird man dann halt entweder zu der index.php in de oder en weitergeleitet...

So hat man keinerlei DB-Zugriff -> wenig Serverlast, und die Texte sind trotzdem einfach zu aendern (eh sei denn, man schreibt absolut unuebersichtlichen quelltext oder packt alles in eine datei).

MFG

Philipp