2 sprachige Seite ?

[$xNeTworKx]

Hallo,
Da meine Seite auch schon von französischen Seiten verlinkt wird, würde ich jetzt gerne meine Seite zumindest in deutsch und englisch gestalten. Ich stelle mir das so vor, dass man von der Startseite aus die deutsche oder englische Version wählen kann.
Ich dachte dabei irgendwie an SSI, aber wie kann ich am Besten den Sprachparameter von Link zu Link weitergeben ohne jetzt extra jede Unterseite als CGI Script schreiben und so die Parameter übergeben, weil das finde ich nicht besonders effizient?  Also ich mein damit, wie kann ich mir am Effizientesten die gewählte Sprache merken.
Wenn jemand andere Vorschläge hat, oder selbst schon mal so etwas realisiert hat, wäre ich für ein paar Tips dankbar.

$xNeTworKx.

[Thorsten Steffen]

Hi,

wenn es nur um den Punkt geht, wie du an die nächste Seite weiterreichen kannst welche Sprache gewählt wurde, gibts einige Möglichkeiten. Wobei welche Möglichkeit wieviel taugt davon abhängt wie deine eigentliche Lösung der Sprachvarianten aussieht. Denke dies ist der erste und wichtige Punkt über den du dir Gedanken machen solltest falls noch nicht getan.

Die einfachste Möglichkeit dürfte sein, die Sprachversionen zu trennen und in verschieden Ordner abzulegen. Dann bräuchtest du nichtmal die Sprache jeweils weiterzureichen. Wobei wirklich für jede Sprache eine eigene Version umzusetzen natürlich nicht besonders effektiv ist.
Das könnte dann aber auch so aussehen, das in einem Ordner /de z.B. ein PHP-Skript (kann nur PHP ;) liegt welches das Layout mit der Sprache vereint.

Oder du übergibst die Sprache per URI z.B. index.php?lang=de, den dein skript und wertest diesen aus, der Nachtteil, du müsstest dafür sorgen das dieser Parameter an _jeden_ Link "geheftet" wird. Das bietet sich denke ich nur an wenn du sowieso schon grundsätzlich mit Parametern arbeitest die du dynamisch an die links anhängst.

Ich denke die Möglichkeit Cookies dürfte nicht so extrem praxistauglich (zumindest nicht als alleinige Lösung sein), da du dich darauf nicht verlassen kannst.

Interessant wäre auch falls du diese Möglichkeit besitzt mit der RewriteEngine des Apache-Webservers zu arbeiten. Dann würdest du z.b. einen Request intern umleiten und bräuchtest auch keine Paramter mitliefern und an deinen links nichts schrauben.

... nur mal ein paar schnelle Ideen, bin noch am kochen und ess erstmal was :)

gruss

Thorsten

$xNeTworKx.

[$xNeTworKx]

Hallo,

Interessant wäre auch falls du diese Möglichkeit besitzt mit der RewriteEngine des Apache-Webservers zu arbeiten. Dann würdest du z.b. einen Request intern umleiten und bräuchtest auch keine Paramter mitliefern und an deinen links nichts schrauben.

das hört sich nicht schlecht an. Könntest du mir das genauer erläutern, wie das gemeint ist?
Übrigens, ich habe vergessen zu sagen, dass ich keine Lösungen mit PHP realisieren will/kann, da ich alles mit Perl mache, und nicht extra auf PHP umlernen will.

$xNeTworKx

[Thorsten Steffen]

Hio,

das hört sich nicht schlecht an. Könntest du mir das genauer erläutern, wie das gemeint ist?

Ich versuchs mal grob.
Der Apache hat ab 1.2 (oder so) ein Rewrite-Modul, er ist damit in der Lage (fast) jeden beliebigen Request umzuleiten. Das könnte so aussehen, das ein zugriff auf /de/news.html vom Apache einfach umgeschrieben wird und bei /news.html landen. Dies kann sowohl intern (= der Browser merkt das nicht) oder auch durch einen wirklichen REDIRECT erfolgen (= der Browser bekommt die neue URL mitgeteilt und muss nun selbst einen neuen Request starten, HTTP-Status 302).
Ich denke in deinem Fall interessant ist ein interner redirect, also der Browser bekommt das nicht mitgeteilt.
Da wäre dann z.b. /de/news.pl würde landen bei news.pl dort könntest du einfach per REQUEST_URI herausfinden welche URL der Browser angefordert hat und somit die Sprache ermitteln.
Dazu brauchst du lediglich eine .htaccess-Datei in dem entsprechenden Verzeichnis ablegen. Die folgendermassen aussehen könnte.

RewriteEngine on
RewriteRule ^(.*)(.php)$ /htmldocs/parser.php

erste Zeile aktiviert die RewriteEngine, zweite Zeile leitet jede Anfrage auf eine PHP-Datei auf /htmldocs/parser.php (ausgehend vom DOCUMENT-ROOT).

Wie das ganze mit PERL umzusetzen ist, oder genauer gesagt welche Probleme sich dort ergeben, kann ich nicht sagen, bin halt PHPler.

Weitere Infos bekommst du auf der Apche-Seite zum Rewrite-Modul http://httpd.apache.org/docs/mod/mod_rewrite.html

Übrigens, ich habe vergessen zu sagen, dass ich keine Lösungen mit PHP realisieren will/kann, da ich alles mit Perl mache, und nicht extra auf PHP umlernen will.

musste auch nicht ;), ich habe meine Beispiel nur in PHP gehalten weil ich selbst nur PHP kann. Perl zwar ein wenig, aber nicht wirklich gut. Perl ist mir einfach zu kryptisch :). Ich denke aber das (fast) alles was sich in PHP umsetzen lässt sich auch in Perl umsetzen lässt, oder umgekehrt.Hoffe verstehst das einigermassen, ist schon spät und bin schon müde,

gruss

Thorsten

p.s.
Hoffe verstehst das einigermassen, ist schon spät und bin schon müde,

[$xNeTworKx]

Hi,

Der Apache hat ab 1.2 (oder so) ein Rewrite-Modul, er ist damit in der Lage (fast) jeden beliebigen Request umzuleiten. Das könnte so aussehen, das ein zugriff auf /de/news.html vom Apache einfach umgeschrieben wird und bei /news.html landen.

Jetzt stellt sich natürlich die Frage, wie ich von vornherein weis, ob ich /en/news.html oder /de/news.html gewählt habe, und das weis ich eben nur, wenn ich die Parameter irgendwie übergebe, was irgendwie auch die Ganze Zeit mein Problem ist =), aber ich glaube da gibt es doch irgendetwas, wo man mit .htaccess die Sprache aus den Umgebungsvariablen herausfinden kann, oder nicht?
Ich habe jetzt ein bißchen gegoogled und bin auf HTTP_ACCEPT_LANGUAGE gestoßen. Wenn ich mir diese Variable auf meinem Webspace ausgeben lasse, bekomme ich folgende Meldung:

de-at, de;q=0.75, en-us;q=0.50, en;q=0.25

Da kommt jetzt sowohl de-at, als auch en-us vor. Wie kann ich nun unterscheiden was das Richtige ist?

$xNeTworKx.

[Thorsten Steffen]

Hi,

Jetzt stellt sich natürlich die Frage, wie ich von vornherein weis, ob ich /en/news.html oder /de/news.html gewählt habe, und das weis ich eben nur, wenn ich die Parameter irgendwie übergebe, was irgendwie auch die Ganze Zeit mein Problem ist =),

Musst du das wissen? Der Benutzer wird sich am Anfang einfach für seine Sprache entscheiden ...

Ich habe jetzt ein bißchen gegoogled und bin auf HTTP_ACCEPT_LANGUAGE gestoßen. Wenn ich mir diese Variable auf meinem Webspace ausgeben lasse, bekomme ich folgende Meldung:

de-at, de;q=0.75, en-us;q=0.50, en;q=0.25

Klar könntest du auslesen welche Sprachen der Browser akzeptiert, aber das dich dieser Ansatz nicht viel weiterbringt siehste ja schon an deiner Frage.

Warum nicht am anfang den Benutzer einfach fragen welche Version er möchte, wenn du schon 2 Version anbietest, dann mach ein Feature draus. Wenn er sich nun 1x entschieden hat ist die Parameterübergabe danach eh kein Problem mehr. Wenn nun jemand beispielsweise auf /news.html direkt zugreift (also ohne Sprachwahl vorher) kannst du ihn entweder zu einer Sprachauswahl leiten oder falls diese schnell erreichbar ist nimmst du einfach deine "default" Sprache, also die meist genutzte.

gruss

Thorsten

[Sven Rautenberg]

Moin!

Ich habe jetzt ein bißchen gegoogled und bin auf HTTP_ACCEPT_LANGUAGE gestoßen. Wenn ich mir diese Variable auf meinem Webspace ausgeben lasse, bekomme ich folgende Meldung:

de-at, de;q=0.75, en-us;q=0.50, en;q=0.25

Da kommt jetzt sowohl de-at, als auch en-us vor. Wie kann ich nun unterscheiden was das Richtige ist?

Diese Angabe solltest du in der Tat verwenden - auf deiner neuen Startseite.

Ansonsten finde ich die Methode mit der RewriteRule sehr spannend.

Ich denke, du hast zunächst folgendes Problem: Deine jetzige Seite ist schon einigermaßen bekannt, von vielen Seiten wurden Links gesetzt. Und ich würde die URL-Struktur deiner Seite _niemals_ ändern. Zumindest die URLs _niemals_ mehr ändern. Du hast mit mod_rewrite oder auch mod_alias die Möglichkeit, alle alten URLs (die weiterhin gültig bleiben) auf deine neue Seitenstruktur umzubiegen. Aber das ist eigentlich gar nicht notwendig.

Idee: Du läßt alles so, wie es ist. Alle Anfragen an deine bisherigen Seiten sollen als Antwort "deutsch" haben - oder vielleicht die laut Browser (siehe oben) gewünschte bevorzugte Sprache. Außerdem schaffst du eine neue Startseite, die die Leute per Link zu zwei weiteren Startseiten bringt: /de/index.html und /en/index.html. Deine deutschen Seiten sind also im URL-Verzeichnis /de/, die englischen in /en/. Alle Links in deinem Projekt sollten relativ sein, d.h. sie funktionieren im Unterverzeichnis genausogut wie im Hauptverzeichnis. Und mit mod_rewrite schreibst du diese URLs so um, dass sie das /de/ oder /en/ vorne verlieren und wieder auf deiner bestehenden Struktur landen. Also: aus "/de/thema/seite.html" wird "/thema/seite.html". Wenn du dynamische Seiten auslieferst, und mit mod_rewrite keinen Redirect ausführst, sondern nur intern die URL umschreibst, kannst du die Original-URL in den Server-Variablen nachschauen und aufgrund von /de/ oder /en/ reagieren.

Zum Sprachwechsel setzt du noch einen Link, der explizit auf die Index-Seite der jeweils anderen Sprache verweist.

Jetzt stellt sich natürlich die Frage, wie ich von vornherein weis, ob ich /en/news.html oder /de/news.html gewählt habe, und das weis ich eben nur, wenn ich die Parameter irgendwie übergebe, was irgendwie auch die Ganze Zeit mein Problem ist =), aber ich glaube da gibt es doch irgendetwas, wo man mit .htaccess die Sprache aus den Umgebungsvariablen herausfinden kann, oder nicht?

Die Information, in welchem Verzeichnis du bist, reicht als "Parameter" doch vollkommen aus, oder? Wenn du es unbedingt willst, kannst du mit mod_rewrite aus dem URL-Bestandteil auch gerne einen Parameter machen.

Ungefähr so
RewriteRule ^/(.{2})/(.*)$ /$2?lang=$1
Bitteschön, ein zweibuchstabiges Verzeichnis am Anfang der URL wird in den Parameter "lang" am Ende verschoben.

Lies den RewriteGuide zu mod_rewrite, dann kriegst du gute Ideen: http://httpd.apache.org/docs/misc/rewriteguide.html
mod_alias: http://httpd.apache.org/docs/mod/mod_alias.html
mod_rewrite: http://httpd.apache.org/docs/mod/mod_rewrite.html

- Sven Rautenberg

[$xNeTworKx]

Hallo,
werd mir mal deine Links ansehen. Ich weis sowieso noch nicht genau, wie ich es am Besten mache. Vielleicht mache ich auch direkt bei den Links auf der Seite jeweils einen für Deutsch und einen für Englisch, aber mal sehen, danke.

$xNeTworKx

[MudGuard]

Hi,

Ich habe jetzt ein bißchen gegoogled und bin auf HTTP_ACCEPT_LANGUAGE gestoßen. Wenn ich mir diese Variable auf meinem Webspace ausgeben lasse, bekomme ich folgende Meldung:

de-at, de;q=0.75, en-us;q=0.50, en;q=0.25

Da kommt jetzt sowohl de-at, als auch en-us vor. Wie kann ich nun unterscheiden was das Richtige ist?

Gar nicht. Denn damit erhältst Du nur, was im Browser konfiguriert ist.
Das muß aber nichts damit zu tun haben, was der User des Browsers wünscht.
Z.B. der französische Kollege, der gerade an meinem PC sitzt, will vielleicht nicht die von mir bevorzugte englische Version, für die mein Browser konfiguriert ist.

Oder Du bist im Internet-Cafe in Thailand. Dort sind alle Browser auf Thai eingestellt. Willst Du jetzt wirklich die Thai-Version einer Seite?

Nur der Mensch, der den Browser benutzt, weiß, welche Sprache er haben will.
Ich will z.B. manchmal nacheinander mehrere Sprachversionen abrufen.

Von daher verbietet sich jeder Automatismus, der nicht durch den User einfach umgangen werden kann.

cu,
Andreas

[$xNeTworKx]

Hallo,
da hast du auch wieder Recht. Daran habe ich noch gar nicht gedacht. Ich hätte es so gemacht, dass bei de-at eine deutsche Seite erscheint, und beim Rest die englische Version, aber da dies sowieso nichts mit der Umgebungsvariable zu tun hat, kann ich es sowieso wieder vergessen =)

$xNeTworKx.

[Christian Seiler]

Hallo $xNeTworKx,

da hast du auch wieder Recht. Daran habe ich noch gar nicht gedacht. Ich hätte es so gemacht, dass bei de-at eine deutsche Seite erscheint, und beim Rest die englische Version, aber da dies sowieso nichts mit der Umgebungsvariable zu tun hat, kann ich es sowieso wieder vergessen =)

Du musst nicht darauf verzichten: Die Startseite (/) leitet einfach auf die Sprachversion des Benutzers weiter. (/de/, /en/) Wenn der diese Sprache nicht will, kann er per Link die Sprache wechseln. Du darfst halt die Auswertung der HTTP_ACCEPT_LANGUAGE nur *dann* ausführen, wenn der Benutzer *nicht* über /en/ oder /de/ "reinkommt", sondern direkt.

Grüße,

Christian

[MudGuard]

Hi,

Du musst nicht darauf verzichten: Die Startseite (/) leitet einfach auf die Sprachversion des Benutzers weiter. (/de/, /en/) Wenn der diese Sprache nicht will, kann er per Link die Sprache wechseln. Du darfst halt die Auswertung der HTTP_ACCEPT_LANGUAGE nur *dann* ausführen, wenn der Benutzer *nicht* über /en/ oder /de/ "reinkommt", sondern direkt.

Genau das meinte ich mit:

jeder Automatismus, der nicht durch den User einfach umgangen werden kann.
cu,
Andreas

[MichaelR]

Hi,

ich hab's so gemacht:

1. MÖglichkeit:
-----------------

per URL-Anhang "meineSeite.htm?Sprache=0" z. B. für Deutsch;
Vorteil: man kanns mit javascript gut auslesen und dann die entsprechenden Sprachwerte auch wieder per js schreiben/setzen

2. Möglichkeit:
-----------------

php nutzen und dort eine gesonderte Sprachdatei in der Form

$Sprache[0] = 'Hallo herzlich willkommen ...';
$Sprache[1] = 'Hello welcome ...';

$Seite2[0] = '';
$Seite2[1] = '';

etc.

<html>
<head>
...

<body>
<p class="CenterTitle"><?php echo $Sparche[$X]; ?></p>

...

Zu Beginn der Php-Seite muss man sich für eine Sprache entscheiden, die wird dann in einer Session (z. B.) gespeichert;

Zum Auslesen dann einfach

$X = $_SESSION['Sprache'];

Also so das Grundprinzip; natürlich fehlt oben an den Stichpunkten noch überall der genaue Ablauf, aber der wird vielleicht klar sein ?

Grüße
M.

[HorstTappert]

Hallo,

tja effizient wärs z.B. wenn du deinen Content aus einer Datenbank holst und einfach z.B. mit PHP verarbeitest.
Hast denn halt ID's für deine Sprachen und kannst denn immer eine Variable weitergeben die Primary Key in deiner DB is.
Könntest die einfach in der URL weitergeben oder mit Sessions...wie du Lust hast.