mod_rewrite und multiviews

[Cyx23]

Hallo,

ich möchte gerne mod_rewrite und multiviews kombinieren, um eine
Sprachumschaltung bei gleicher URI zu ermöglichen.

Beispiel, per multiview erhalte ich bei entsprechender Spracheinstellung
usw. als eine angefragte xy.html die xy.html.de ausgeliefert, und zwar
als die angeforderte xy.html.

Nun wäre es möglich aus der gelieferten xy.html heraus eine xy.html.en.html
zu laden, um eine anderssprachige Version anzuschauen. Kann jetzt per
mod_rewrite diese xy.html.en.html wieder als xy.html ausgeben werden,
müssten dazu Browser- oder Proxycache überlistet werden?

Die Apache-docs sind mir da auch nicht ganz klar:
RewriteEngine On
RewriteBase   /xyz
RewriteRule   ^oldstuff.html$  newstuff.html

Muss "/xyz" bei gleichem Verzeichnis ein "./" sein? (Zitat:'let the server
know that we were reached via /xyz and not via the physical path prefix')

Grüsse

Cyx23

[Pidder Lüng]

Beispiel, per multiview erhalte ich bei entsprechender Spracheinstellung
usw. als eine angefragte xy.html die xy.html.de ausgeliefert, und zwar
als die angeforderte xy.html.

Nun wäre es möglich aus der gelieferten xy.html heraus eine xy.html.en.html

Ein .html reicht.

zu laden, um eine anderssprachige Version anzuschauen. Kann jetzt per
mod_rewrite diese xy.html.en.html wieder als xy.html ausgeben werden,
müssten dazu Browser- oder Proxycache überlistet werden?

a) Das macht keinen Sinn. Wenn Du explizit _über die URL_ eine Sprachversion anforderst, dann sollte die URL auch diese Sprachversion wiederspiegeln.
Anders ausgedrückt: "xy.html" bedeutet "sende mir das HTML-Dokument xy in einer mir genehmen Sprache", "xy.html.en" hingegen "sende mir das HTML-Dokument xy in Englisch". Benutze die URL, die dem Auftrag entspricht.
Bitte verabschiede Dich von dem Gedanken, eine URL könne "hässlich" sein, denn "hässlich" ist immer Geschmackssache. Hauptattribute einer URL sollten "verständlich" und "genau" sein, alles andere hat sich dem unterzuordnen.

b) Nein. Der Browser fragt das Objekt ab, das in der Adresszeile angegeben wird. Um die Adresszeile zu ändern, mußt Du dem Browser eine Weiterleitung zu der gewünschten Adresse (also xy.html) übermitteln. Dann fragt er allerdings wieder nur xy.html ab und bekommt die nach Präferenz des Benutzers am besten passende Sprachvariante geliefert.

Die ganze Problematik der Änderung des Inhalts der Adresszeile ist übrigens kein mod_negotiation-spezifisches Problem, sondern ein grundsätzliches: Eine Änderung der Adresszeile ist von Serverseite aus immer nur mit einer Weiterleitung möglich.

Pidder Lüng

[Cyx23]

Hallo Pidder,

Ein .html reicht.

müssten da nicht bei meinem Beispiel, direkter Link auf eine *.en, zusätzlich die Endung en beim Server festgelegt werden, damit jeder Browser verlässlich weiß was er mit einer *.en machen soll (wenn ich es recht erinnere waren Opera da immer besonders anspruchsvoll)?

zu laden, um eine anderssprachige Version anzuschauen. Kann jetzt per
mod_rewrite diese xy.html.en.html wieder als xy.html ausgeben werden,
müssten dazu Browser- oder Proxycache überlistet werden?

a) Das macht keinen Sinn. Wenn Du explizit _über die URL_ eine Sprachversion anforderst, dann sollte die URL auch diese Sprachversion wiederspiegeln.
Anders ausgedrückt: "xy.html" bedeutet "sende mir das HTML-Dokument xy in einer mir genehmen Sprache", "xy.html.en" hingegen "sende mir das HTML-Dokument xy in Englisch". Benutze die URL, die dem Auftrag entspricht.
Bitte verabschiede Dich von dem Gedanken, eine URL könne "hässlich" sein, denn "hässlich" ist immer Geschmackssache. Hauptattribute einer URL sollten "verständlich" und "genau" sein, alles andere hat sich dem unterzuordnen.

Das wäre sehr wohl sinnvoll. Andernfalls hätte ich drei Adressen auf eine Seite, das kann allerdings "hässlich" sein, zumal bei einem sonst einsprachigem Projekt.
Es macht eben weniger Sinn, wenn ein anderssprachiger Besucher einen Link auf die Sprachversion setzt, genau solche Dinge möchte ich derzeit vermeiden, und mir zugleich andere Techniken, etwa per search, offenhalten.
Ich würde momentan wohl eher auf den Komfort einer Sprachumschaltung verzichten oder etwas per JavaScript anbieten, wenn es keine Lösung gibt die extra angeforderte Sprachversionen mit gleicher URI auszuliefern.

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

Ich würde momentan wohl eher auf den Komfort einer Sprachumschaltung verzichten oder etwas per JavaScript anbieten, wenn es keine Lösung gibt die extra angeforderte Sprachversionen mit gleicher URI auszuliefern.

Auch wenn ich noch nicht so ganz verstanden habe, was du genau willst, aber allein diese Aussage "extra angeforderte Sprachversion mit gleicher URI" kann doch schon nicht funktionieren.

Ich überlege mal: Ein Request ist ein Request ist ein Request. Was vorher und hinterher war, ist (außer du benutzt einen Session-Mechanismus) irrelevant.

Und nun ruft der Browser also index.html ab. Und der Server checkt die Optionen:

1. index.html existiert - dann raus damit.
2. index.html existiert nicht, aber Sprachversionen index.de.html und index.en.html. Dann wird die vom Browser gesendete Sprachpräferenz geprüft, bei Gleichstand die im Server konfigurierte, und im Zweifel wird eine Entscheidungsseite gesendet - ansonsten unter der URL index.html die jeweilige Sprache ausgeliefert.

Da dieser Mechanismus automatisch abläuft und auf Informationen (Sprachpräferenz) basiert, die der Benutzer nicht unbedingt ändern kann, passiert es eben, dass ein Benutzer mit einer für ihn ungeeigneten Sprachversion dasitzt. Wenn man aber die Sprachversion wechseln will, muß das dem Server in irgendeiner Art und Weise mitgeteilt werden.

Möglichkeit 1: Die Sprachpräferenz ändern. Geht aber nicht immer.
Möglichkeit 2: Die URL ändern. Das widerspricht deiner Forderung "gleiche URL".
Möglichkeit 3: Man kann auch ein Cookie setzen, in dem die Sprache steht - klar. Oder eine Session starten und sich die Wahl darin merken. Das sind aber Techniken, die nicht immer funktionieren. Die Änderung der URL funktioniert immer.

Es hängt bei Mehrsprachigkeit natürlich davon ab, wie umfangreich sie ausgeführt werden soll. Ich habe schon mehrere Konzern-Websites erstellt, bei denen grundsätzlich durchgehend alle Seiten mehrsprachig und identisch vorliegen sollten, und dafür die hier schon häufiger beschriebene Variante gewählt, jede Sprache in einen eigenen Verzeichnisbaum zu packen, der identisch aufgebaut ist.

Wenn es bei dir nur um eine einzige oder wenige Seiten geht, dann wäre die von dir angedachte Variante mit Multiviews sicherlich einfacher zu realisieren, aber die explizite Sprachwahl sollte dann zwingend über die URL geschehen (und angemerkt sei, dass die Sprache nicht am Ende des Dateinamens stehen muß).

Nur alles, automatische Wahl, manuelle Wahl und einheitliche URL - das kriegst du nicht zusammen.

- Sven Rautenberg

[Cyx23]

Hallo Sven,

Ich würde momentan wohl eher auf den Komfort einer Sprachumschaltung verzichten oder etwas per JavaScript anbieten, wenn es keine Lösung gibt die extra angeforderte Sprachversionen mit gleicher URI auszuliefern.

Auch wenn ich noch nicht so ganz verstanden habe, was du genau willst, aber allein diese Aussage "extra angeforderte Sprachversion mit gleicher URI" kann doch schon nicht funktionieren.

die vom Besucher unter xy.html erhaltene Datei kann einen Link auf die andere Sprachversion enthalten, mit dem Nachteil dass da auch schon bookmarks angelegt werden können.

Also entweder <a href="xy.html?lang=de">De..  oder <a href="xy.html.de.html">De...

Die dann geladene Datei soll nicht als xy.html.de.html, sondern als xy.html oder xy.html?lang=de ausgeliefert werden.

Eine serverseitige Umleitung auf xy.html und anschliessender Negotiation auf die Browsersprache wäre natürlich witzlos.

Also Link auf xy.html.de.html oder besser xy.html?lang=de, dann Auslieferung der xy.html.de.html als xy.html, oder xy.html?lang=de. Offenbar aber nicht so einfach möglich, SSI ginge vom Aufwand vielleicht noch eher als PHP, aber eigentlich hattte ich gehofft die Adresse im Browser einfacher umbiegen zu können.

Es hängt bei Mehrsprachigkeit natürlich davon ab, wie umfangreich sie ausgeführt werden soll. Ich habe schon mehrere Konzern-Websites erstellt, bei denen grundsätzlich durchgehend alle Seiten mehrsprachig und identisch vorliegen sollten, und dafür die hier schon häufiger beschriebene Variante gewählt, jede Sprache in einen eigenen Verzeichnisbaum zu packen, der identisch aufgebaut ist.

Das habe ich vor Jahren auch schon ähnlich durchgeführt, ein Verzeichnis xyz.de/en/ und dann alles, auch Unterverzeichnisse, doppelt.

Jetzt aber hätte mir eine Umschaltung per Style in nur einer Datei schon gereicht, wenn nicht die display:.. Schieberei zu unsauber geworden wäre (vielleicht hätte ich nur zwei body-Tags nehmen sollen...). Die Umschaltung ist da aber auch notfalls verzichtbar, zumal ich jetzt nicht wegen einer Seite eine Struktur festlegen möchte.

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

Also Link auf xy.html.de.html oder besser xy.html?lang=de, dann Auslieferung der xy.html.de.html als xy.html, oder xy.html?lang=de.

Es gibt kein "Auslieferung ALS irgendwas". Der Browser ruft eine URL auf und kriegt darauf eine Antwort. Wenn er xy.html?lang=de aufruft, kriegt er exakt diese Ressource. Wenn diese Ressource ein Redirekt ist, dann ruft er eine neue URL unter der neuen Adresse auf. Wenn dort dynamische Mechanismen tätig werden, die nicht tätig werden sollen, dann ist die Aufgabe nicht lösbar.

Was ist schlimm daran, dass sich jemand auf seine Sprachversion ein Bookmark setzt?

Offenbar aber nicht so einfach möglich, SSI ginge vom Aufwand vielleicht noch eher als PHP, aber eigentlich hattte ich gehofft die Adresse im Browser einfacher umbiegen zu können.

Ein Browser, der ein und denselben Request zweimal an den Server sendet, kriegt ganz grundsätzlich zweimal dieselbe Antwort (mal abgesehen davon, dass die Zeit natürlich auch beeinflussend wirken kann). Um verschiedene Inhalte auszuliefern, muß irgendetwas beim einen Request so, beim anderen anders sein. Die Änderung kann in der URL (inkl. Parametern), in der Sprachpräferenz, in Cookies etc. stattfinden, aber es muß eine stattfinden. Denn irgendwie mußt du ja schließlich serverseitig einen Unterschied feststellen, damit du mal die eine Sprache, mal die andere ausliefern kannst.

Welche URL bei alledem angezeigt wird, ist irrelevant. Sollte es zumindest sein.

- Sven Rautenberg

[Cyx23]

Hallo Sven,

Was ist schlimm daran, dass sich jemand auf seine Sprachversion ein Bookmark setzt?

ich hielte es für unangebracht unnötig Links und Bookmarks zu unterstützen die sich womöglich kurzfristig ändern.
Dass ich jetzt noch keine Struktur zur Mehrsprachigkeit, die sich - ausser search- in der Adresse niederschlägt, möchte, sollte doch wohl hinreichend klar geworden sein!

Ein Browser, der ein und denselben Request zweimal an den Server sendet, kriegt ganz grundsätzlich zweimal dieselbe Antwort [....]

Sorry, aber hier entzieht sich dein Posting wohl endgültig dem Zusammenhang.
Wo willst du aus meinen Formulierungen einen gleichen Request hernehmen, wo du sowohl selbst einen Text mit search zitiert hast, als auch den Link auf ..de.html (oder ..en.html) hättest lesen müssen?
Ist das Fernsehprogramm bei dir so schlecht oder drück ich mich wirklich so umständlich aus?

Es ging darum einen unterschiedlichen Request auf die entsprechenden unterschiedlichen Dateien so weiterzuleiten dass möglichst die gleiche Adresse beim Browser auftaucht (z.B. wegen Link), was offenbar per rewrite nicht geht, wobei bislang die Möglichkeiten von search, da gäbe es ja keinen 404 sondern ggf. nur mehr Traffic, gar nicht hinreichend berücksichtigt wurde ausser dass ich geäusserst hatte eigentlich kein php einsetzen zu wollen.

Schliesslich schreibst denn du noch:

"Welche URL bei alledem angezeigt wird, ist irrelevant. Sollte es zumindest sein."

Ja wenn das wirklich so irrelevant ist wie du schreibst, dann kann der Server ja wohl doch die angezeigte URL fröhlich andern!

Also nochmals die Ausgangsfrage, wie kann ich denn doch die URL ändern? Doch nicht etwa mit rewrite?

Grüsse

Cyx23

[Sven Rautenberg]

Moin!

Was ist schlimm daran, dass sich jemand auf seine Sprachversion ein Bookmark setzt?

ich hielte es für unangebracht unnötig Links und Bookmarks zu unterstützen die sich womöglich kurzfristig ändern.

Ok. "Cool URIs don't change".

Was hindert dich, jetzt eine Struktur zu erstellen und später mit entsprechenden Regeln (je Sprachvariante dürfte das exakt _eine_ Regel sein) Redirects zu machen.

Schön, dass du dich um die Dauerhaftigkeit deiner URLs kümmerst - aber du wälzt die Problematik auf den Benutzer ab und ignorierst die Unmöglichkeit deines Vorhabens.

Dass ich jetzt noch keine Struktur zur Mehrsprachigkeit, die sich - ausser search- in der Adresse niederschlägt, möchte, sollte doch wohl hinreichend klar geworden sein!

Ja. Dass ich dir konstant erklären will, dass es nicht funktioniert, offenbar nicht.

Überleg doch mal selbst: Wenn du die Sprachwahl mit einem Parameter "?lang=en" regelst, dann hast du nicht mehr dieselbe URL. Dann hast du außerdem die Aufgabe, später bei Änderungen der URL-Struktur trotzdem (entsprechend deines Anspruchs) eine englische Seite auszuliefern.

Genau dasselbe würde deine Aufgabe sein, wenn du alle Requests nach "/irgendein/pfad/index.en.html" mit mod_rewrite oder RedirectMatch redirecten würdest nach "/en/irgendein/pfad/index.html".

Methode 2 erfordert dann, wenn es jemals soweit kommt, eine entsprechende Ergänzung in der Konfiguration (sinnvollerweise RedirectPermanent). Methode 1 erfordert _jetzt_ und später entsprechend dynamische Seitenausgabe, keine statische.

Ich würde Methode 2 wählen.

Ein Browser, der ein und denselben Request zweimal an den Server sendet, kriegt ganz grundsätzlich zweimal dieselbe Antwort [....]

Sorry, aber hier entzieht sich dein Posting wohl endgültig dem Zusammenhang.
Wo willst du aus meinen Formulierungen einen gleichen Request hernehmen, wo du sowohl selbst einen Text mit search zitiert hast, als auch den Link auf ..de.html (oder ..en.html) hättest lesen müssen?

Du willst, ohne dass sich die URL im Browser ändert, zwei Sprachversionen ausgeben. Daraus entnehme ich, dass der Browser für zwei identische Requests zwei verschiedene Antworten kriegen soll. Und das geht eben nicht.

Ist das Fernsehprogramm bei dir so schlecht oder drück ich mich wirklich so umständlich aus?

Das Fernsehprogramm ist so schlecht, dass ich gar kein Fernsehen gucke. Das ist aber leider Dauersymptom des gesamten Fernsehprogramms über die gesamte Woche. Das würde jetzt aber zu weit vom Thema wegführen. :)

"Welche URL bei alledem angezeigt wird, ist irrelevant. Sollte es zumindest sein."

Ja wenn das wirklich so irrelevant ist wie du schreibst, dann kann der Server ja wohl doch die angezeigte URL fröhlich andern!

Ein Server kann die angezeigte URL ändern, indem er Redirects aussendet. Dadurch wird der Browser die in der Zeile angezeiget URL ändern und die neue URL laden und anzeigen. Wenn du von index.en.html redirectest nach index.html, und diese Adresse per Automatik zur Anzeige der deutschen Version führt, weil das im Browser so konfiguriert ist, dann ist das so und führt bei deinem Problem zu keiner Lösung.

Also nochmals die Ausgangsfrage, wie kann ich denn doch die URL ändern? Doch nicht etwa mit rewrite?

Nein, du kannst die URL, die im Browser angezeigt wird, nicht vom Server aus bestimmen. Die URL bestimmt, was im Browser angezeigt wird.

Rewriting ist ein serverinterner Prozess, bei der eine URL, die von außen angefragt wird, intern umgesetzt wird zu einer internen URL.

Das Ergebnis eines Rewritings kann sein:
a) die Ausgabe eines Redirects. Das veranlaßt den Browser dann sichtbar, eine neue URL zu laden
b) die interne Umänderung einer URL, welche dann unter der angefragten URL ausgeliefert wird.

Methode b) würde beispielsweise erlauben, dass man beliebige Grafiken aus einem Verzeichnis abrufen kann - und wenn eine angefragte Grafik nicht existiert, dann wird stattdessen eine Defaultgrafik geliefert.

Was nicht geht: Ein und dieselbe URL in diesem internen Prozess einmal auf die deutsche Seite verzweigen lassen und einmal auf die englische, ohne dass diese Entscheidung sich im gesamten Request irgendwo durch eine Änderung zeigt.

Beispiel aus der realen Welt: Wenn du in der Kneipe beim Wirt einmal bestellst "Gib mir ein Bier" und ein anderes Mal bestellst du "Gib mir ein Bier", dann kriegst du zweimal dasselbe Bier. Erst wenn du durch irgendeine Zusatzinformation deutlich machst, dass du das eine Mal ein Astra, das andere Mal ein Jever willst, kriegst du unterschiedliche Biere.

Du willst derzeit auf deinem Webserver, dass der Besucher durch die Bestellung "Gib mir ein Bier" ganz nach seinem Wunsch mal Astra, mal Jever kriegt, ohne dass Zusatzinformationen die Bestellung verdeutlichen. Dabei ist irgendwie klar, dass man bei "Gib mir ein Bier" vermutlich erstmal die Hausmarke kriegt, und nur, wenn man "Gib mir ein Astra" oder "Gib mir ein Jever" exakt definiert, welches Bier man möchte.

Die Bestellung kann also "Gib mir ein Astra" lauten (entspricht index.de.html), oder meinetwegen auch "Gib mir ein Bier, ein Astra" (entspricht index.html?lang=de), oder du kannst auch ein T-Shirt "Ich bin Astra-Trinker" tragen und "Gib mir ein Bier" verlangen, woraufhin der Wirt, dein T-Shirt lesend, ein Astra liefern wird (entspricht der Content-Language-Negotiation).

Es wird aber nicht funktionieren, dass du nur mit der Bestellung "Gib mir ein Bier" und dem Astra-Shirt ein Jever kriegst. Da mußt du schon konkret werden und "Gib mir ein Jever" oder "Gib mir ein Bier, ein Jever" verlangen.

Alles klar?

- Sven Rautenberg

[Cyx23]

Hallo Sven,

Ja. Dass ich dir konstant erklären will, dass es nicht funktioniert, offenbar nicht.

hinsichtlich der im Browser angezeigten Adresse hatte ich ja schon "Pidder" gepostet :".. dass eine Weiterleitung nur mit transparenter erkennbarer vollständiger URL möglich ist, was hinsichtlich der Eindeutigkeit und Sicherheitsaspekten ..."

Überleg doch mal selbst: Wenn du die Sprachwahl mit einem Parameter "?lang=en" regelst, dann hast du nicht mehr dieselbe URL. Dann hast du außerdem die Aufgabe, später bei Änderungen der URL-Struktur trotzdem (entsprechend deines Anspruchs) eine englische Seite auszuliefern.

Hier würde später immer noch eine Version auffindbar sein und es gäbe keinen 404 oder multiple choice. Solange -z.B. oben rechts i.d. Seite- der Link zur anderen Sprache rasch zu finden ist sollte es für den Besucher eigentlich kein Problem sein.

Du willst, ohne dass sich die URL im Browser ändert, zwei Sprachversionen ausgeben. Daraus entnehme ich, dass der Browser für zwei identische Requests zwei verschiedene Antworten kriegen soll. Und das geht eben nicht.

Wenn natürlich (s.o.) jeder Request im Browser abgebildet wird geht es so einfach allerdings nicht.

Eine Kombination aus Umleitung von einem sprachspezifischen Link und dynamischer Seitenerstellung ginge (vielleicht etwas aufwändig) womöglich doch, z.B. müsste sich der referrer der Zwischenseite als Variable eignen.
Von xy.html wird über einen Link vom Besucher xy-eng.html aufgerufen. Nachteil natürlich wenn der Link gebookmarkt wird. Die aufgerufene xy-eng.html leitet zu xy.html weiter, welche am referrer die gewünschte Sprache erkennt.

Aber ich hatte ja wiederholt mit search auch partielle Änderungen in der URL zugelassen (oder wenn das nicht deutlich geworden ist, zulassen wollen), die bei späterer Umstellung der Geschichte m.E. keine Nachsorge benötigen würde, da die richtige Seite aufgerufen wird und ggf. eine andere Sprachversion gleich wählbar ist.

Beispiel aus der realen Welt: Wenn du in der Kneipe beim Wirt einmal bestellst "Gib mir ein Bier" und ein anderes Mal bestellst du "Gib mir ein Bier", dann kriegst du zweimal dasselbe Bier. Erst wenn du durch irgendeine Zusatzinformation deutlich machst, dass du das eine Mal ein Astra, das andere Mal ein Jever willst, kriegst du unterschiedliche Biere.

Ich möchte die Biere ja nach der Bestellung "Gib mir ein Astra" oder "Gib mir ein Jever" nur in der gleichen Glassorte und auf den gleichen Deckel.

Und wenn es mit search eine einfache Möglichkeit gibt, die sich mit der automatischen Sprachauswahl per multiview verträgt wärs ja womöglich auch gut.

Grüsse

Cyx23

[Pidder Lüng]

Ein .html reicht.

müssten da nicht bei meinem Beispiel, direkter Link auf eine *.en, zusätzlich die Endung en beim Server festgelegt werden, damit jeder Browser verlässlich weiß was er mit einer *.en machen soll (wenn ich es recht erinnere waren Opera da immer besonders anspruchsvoll)?

Browser, die den Datentyp anhand der URL bestimmen und nicht anhand dessen, was der Server ihnen sagt, kann man eigentlich eh in die Tonne treten, denn definitionsgemäß ist der Inhalt der URL in dieser Hinsicht irrelevant. Und insbesondere im hier vorliegenden Fall sind Fehldeutungen ganz und gar unmöglich - beim Typ application/octet-dingens wäre das beispielsweise etwas anders.
Ich kann mir nicht vorstellen, daß ausgerechnet Opera derartigen Mist veranstalten soll (aber wie heißt es doch: Nichts ist unmöglich). Und selbst wenn: Diese Form von Protokollvergewaltigung würde ich schon alleine aus Prinzip nicht unterstützen.

Die Dateiendungen werden vom Server benutzt, um der Datei verschiedene Attribute zuzuordnen. Dem Kürzel .html ist der Typ "text/html" zugeordnet, dem Kürzel "en" die Sprache Englisch.
".html.en" bedeutet also "englische Datei mit HTML-Inhalt" und genau diese Information sendet der Server dem Browser, separat und protokollgemäß mittels Content-Type (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17) und Content-Language (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.12).  Irgendwelche Wahrsagerei auf Basis der URL ist da beim Browser nicht mehr nötig.

Beide Zuordnungen sind normalerweise bereits ab Werk in der Serverkonfiguration vorhanden (wären sie es bei Dir nicht, würde die automatische Wahl nicht funktionieren).

Es hilft in Hinsicht auf das, was der Server dem Browser mitteilt, auch nichts, ".en" noch "text/html" zuzuordnen (oder ".html" doppelt anzugeben). Dann hast Du halt zweimal das Attribut "text/html" vergeben, die Content-Type-Zeile wird aber trotzdem nur einmal versandt.

Kurz: Servereinstellung sind vollkommen zwecklos, eine Unterstützung von kaputten Browsern fragwürdig.

Kann jetzt per mod_rewrite diese xy.html.en.html wieder als xy.html ausgeben werden

a) Das macht keinen Sinn. Wenn Du explizit _über die URL_ eine Sprachversion anforderst, dann sollte die URL auch diese Sprachversion wiederspiegeln.

Das wäre sehr wohl sinnvoll. Andernfalls hätte ich drei Adressen auf eine Seite, das kann allerdings "hässlich" sein,

Wie gesagt, Geschmacksfragen. Ich würde auch eher annehmen, daß meine Besucher sich mit dem Inhalt meiner Seiten beschäftigen, anstatt über die URL zu diskutieren.
Letztere braucht man nur zwei Sekunden zum Ansteuern einer Seite, und für diesen Zweck sollte sich verständlich und einprägsam sein - das ist bei .html.en meiner Ansicht nach durchaus gegeben, bei "Rufe .html auf, klicke auf "English" und Du erhälst die englische Version; das mußt Du aber bei jedem Aufruf machen"..naja.

zumal bei einem sonst einsprachigem Projekt.

Und? Ist doch toll, daß Du eine Seite in mehreren Sprachen anbietest? Du bist sozusagen international aufgestellt. Andere Firmen gehen mit so einer Aussage auf weltweiten Kundenfang ("we value our international customers"), Du versuchst sie zu verstecken.

Es macht eben weniger Sinn, wenn ein anderssprachiger Besucher einen Link auf die Sprachversion setzt, genau solche Dinge möchte ich derzeit vermeiden,

Im Hinblick auf das Weitergeben von Adressen magst Du teilweise Recht haben. Allerdings möchte ich da entgegnen, daß sicherlich eine ganze Reihe Besucher wissen, daß sie die Adresse einer [englischen] Seite weitergeben: Schließlich haben sie ja erst eine [deutsche] geliefert bekommen und mußten sich die [englische] explizit hervorholen.
Weiterhin bietest Du ja wohl auf der englischen Seite auch einen Verweis auf die Deutsche an, oder etwa nicht? Es kann sich also niemand verlaufen.

Und eine Gegenfrage: Warum muß dieser anderssprachige Besucher jedesmal über die Standardadresse kommen, warum darf er nicht gleich die im genehme Seite ansteuern?

Du spielst hier anscheinend irgendwie Deine Bequemlichkeit gegen die der Besucher aus. Aber sind die Besucher nicht doch ein wenig Deine Zielgruppe?

Ich würde momentan wohl eher auf den Komfort einer Sprachumschaltung verzichten oder etwas per JavaScript anbieten,

Deine Entscheidung. Technisch kompliziertere Spezialanfertigungen sind aber nicht unbedingt besser. Insbesondere bei weitläufigen Anwendungen wie offenen Netzwerken öffnet man damit Problemen Tür und Tor.

Du versuchst momentan, ein von vielen Leuten ausgearbeitetes Konzept aus den Angel zu hebeln und durch ein (deiner einzelnen Meinung nach) viel besseres zu ersetzen.
Du versuchst auch (bzw. es läuft darauf hinaus), ein simples Funktionsprinzip durch eine kompliziertere Variante zu ersetzen.

Willst Du das trotzdem machen: Benutze ein Formular mit einem einzelnen <input type="submit" name="lang" value="English">. Dann wirst Du allerdings Deine beiden HTML-Seiten durch ein Skript ersetzen müssen. Aus Verwaltungssicht und möglicherweise auch aus gestalterischer extrem hässlich - aber "hässlich" ist ja wie gesagt Geschmackssache.
Die anderssprachigen Dateien werden auch von keiner Suchmaschine indiziert werden können, da Du Dich ja weigerst, eine feste URL rauszurücken.

Beglückwünschen würde ich Dich für diese Wahl ganz und gar nicht. Das ist Pfuscherei.

Pidder Lüng

[Cyx23]

Hallo,

Ich kann mir nicht vorstellen, daß ausgerechnet Opera derartigen Mist veranstalten soll (aber wie heißt es doch: Nichts ist unmöglich). Und selbst wenn: Diese Form von Protokollvergewaltigung würde ich schon alleine aus Prinzip nicht unterstützen.

ich hatte sowas von Opera (4?) bei png und/oder gif in Erinnerung, aber lasse mich gerne überzeugen es einfacher zu schreiben.

Es macht eben weniger Sinn, wenn ein anderssprachiger Besucher einen Link auf die Sprachversion setzt, genau solche Dinge möchte ich derzeit vermeiden,

Im Hinblick auf das Weitergeben von Adressen magst Du teilweise Recht haben. ..
Du spielst hier anscheinend irgendwie Deine Bequemlichkeit gegen die der Besucher aus.

wenn es so wäre, warum eigentlich nicht? Aber im Gegenteil, es wäre unbequem für die Anwender wenn Links und Bookmark bald zu ändern wären weil ich die Sprachen anders realisieren würde. Dann müsste ich mit redirect o.ä. wieder nachflicken, oder Multiple Choices, das erspar ich mir und den Besuchern besser.
Hatte ich übrigens hier im Thread schon dargelegt, z.B. " und mir zugleich andere Techniken, etwa per search, offenhalten.",
oder Antwort an Sven "zumal ich jetzt nicht wegen einer Seite eine Struktur festlegen möchte." deswegen bin ich erstaunt hier von dir wie übrigens auch von Sven auf meine Frage wohlmeinende aber im Kontext nervende und absolut unpassende Allgemeinplätze bis zu Unfug a la "Pfuscherei" zu erhalten.

Aber trotzdem danke für die Ausführungen zum Suffix, '<input type="submit" name="lang" value="English">.', und den konkreten Hinweis aus deinem vorherigen Posting:".. sondern ein grundsätzliches: Eine Änderung der Adresszeile ist von Serverseite aus immer nur mit einer Weiterleitung möglich.", das soll wohl auch bedeuten dass eine Weiterleitung nur mit transparenter erkennbarer vollständiger URL möglich ist, was hinsichtlich der Eindeutigkeit und Sicherheitsaspekten sinnvoll sein mag.

Da die Weiterleitung auf die Multiviews ja nichts bringt, bliebe nur etwas anderes per search, also xy.html?lang=.., womit bei einer Umstellung auf eine andere Art der Sprachversionen wenigstens kein Multiple Choices oder 404, sondern höchstens etwas Traffic erzeugt würde.
Also müsste wohl ein Script die Versionen xy.html?lang=de und xy.html?lang=en ausgeben.

Grüsse

Cyx23

[Pidder Lüng]

Du spielst hier anscheinend irgendwie Deine Bequemlichkeit gegen die der Besucher aus.

wenn es so wäre, warum eigentlich nicht?

Wenn Deine Besucher Dir egal sind, dann ist dieser Aspekt natürlich belanglos. Dieser Ansatz endet nur regelmäßig in jenen Berichten über Besucher, die nach wenigen Klicks entnervt ein anderes Angebot aufsuchen, oder in Seiten, die mühsam aufgebaut (übersetzt) wurden, aber von niemandem gefunden werden.

Aber im Gegenteil, es wäre unbequem für die Anwender wenn Links und Bookmark bald zu ändern wären weil ich die Sprachen anders realisieren würde.

Wie soll das anders aussehen und -vor allen Dingen- warum solltest Du das ändern wollen? Welche Vorteile haben diese anderen Strukturen?

Dann müsste ich mit redirect o.ä. wieder nachflicken, oder Multiple Choices, das erspar ich mir und den Besuchern besser.

Multiple Choice erhältst Du nur, wenn Du das besagte URL-Anhängsel-Konzept benutzt. Da dieses nur auf diese Weise funktioniert, kannst Du auch nichts dran ändern.

Hatte ich übrigens hier im Thread schon dargelegt, z.B. " und mir zugleich andere Techniken, etwa per search, offenhalten.",

Mit "search" konnte ich nichts anfangen (search=Suchfunktion, aber wer will denn suchen?), URL-Parameter wäre mein Stichwort gewesen. Aber wie dem auch sei: Ich wüsste nicht, was besser daran sein soll, wenn man statt x.html.en x.html?en in die Adresszeile schreibt. Damit hast Du doch auch das Problem gespeicherte URLs.

Und warum und wohin solltest Du umstellen wollen?

oder Antwort an Sven "zumal ich jetzt nicht wegen einer Seite eine Struktur festlegen möchte."

Nochmal: Welche Strukturänderungen? Willst Du auf Verzeichnisse ("/de", "/en") umsteigen? Dann mußt Du nach Änderung auch umleiten und verlierst die automatische Sprachwahl oder mußt sie mit einer Weiterleitung (von "/x" nach "/de/x") manuell implementieren.

Willst Du die Übersetzungen ganz rauswerfen? Dann wäre ein 404 (oder besser 410) genau das Richtige, zusammen mit einem Hinweis, wo ähnliche Dokumente zu finden sein könnten. Letzteres macht sich generell ganz gut und ist bei durchdachtem, d.h. thematischem Verzeichnisaufbau auch einfach umzusetzen. Es sollte auch keinerlei Problem für das Skript im 404 sein, für x.html.en auf x.html, x.html?en oder /en/x.html hinzuweisen.

auf meine Frage wohlmeinende aber im Kontext nervende und absolut unpassende Allgemeinplätze bis zu Unfug a la "Pfuscherei" zu erhalten.

Du bezahlst hier niemanden für eine kommentarlose Problemlösung, Du erhältst Meinungen und Lösungsansätze. Du magst meine Meinung genauso für Unfug halten wie ich die denkbaren Alternativen zum eigentlich angedachten HTTP-Mechanismus für Pfuscherei, aber deswegen ist sie noch lange nicht unpassendes Allgemeingeschwafel. Du hast eine Aufgabenstellung, ich zeige dazu Lösungswege und kommentiere ihre Anwendbarkeit.

Wenn Du mit Kritik nicht umgehen kannst, lass die Fragerei bleiben.

".. sondern ein grundsätzliches: Eine Änderung der Adresszeile ist von Serverseite aus immer nur mit einer Weiterleitung möglich.", das soll wohl auch bedeuten dass eine Weiterleitung nur mit transparenter erkennbarer vollständiger URL möglich ist,

So kann man es auch sagen, ja. Eine Weiterleitung bedeutet immer, dem Browser den Befehl zu geben, eine andere URL zu laden. Und die aktuell geladene URL zeigt jeder Browser in der Adresszeile an.

Pidder Lüng

[Cyx23]

Hallo Pidder,

Du spielst hier anscheinend irgendwie Deine Bequemlichkeit gegen die der Besucher aus.

wenn es so wäre, warum eigentlich nicht?

Wenn Deine Besucher Dir egal sind, dann ist dieser Aspekt natürlich belanglos.

das steht da nicht, da ist erstmal ein Äbwägen unter wirtschaftlichen Aspekten beschrieben.
Eine elementare Sache die dir warum auch immer vielleicht weniger wichtig ist wenn du eine negativ besezte
Formulierung wie "ausspielen" dafür verwendest.

Wie soll das anders aussehen und -vor allen Dingen- warum solltest Du das ändern wollen? Welche Vorteile haben diese anderen Strukturen?

Das will und muss ich ja jetzt eben noch nicht klären.

Dann müsste ich mit redirect o.ä. wieder nachflicken, oder Multiple Choices, das erspar ich mir und den Besuchern besser.

Multiple Choice erhältst Du nur, wenn Du das besagte URL-Anhängsel-Konzept benutzt. Da dieses nur auf diese Weise funktioniert, kannst Du auch nichts dran ändern.

Multiple Choice erhalte ich wenn ichs richtig bebachtet hatte auf eine nicht vorhandene xy.html.en bei vorhandener xy.html, was mich jetzt allerdings daran hindert auf vorhandene *.en zu linken wenn diese später vmtl. geändert werden.

.. URL-Parameter wäre mein Stichwort gewesen. Aber wie dem auch sei: Ich wüsste nicht, was besser daran sein soll, wenn man statt x.html.en x.html?en in die Adresszeile schreibt. Damit hast Du doch auch das Problem gespeicherte URLs.

Keine 404, keine multiple choice, aber die richtige Datei wird ausgeliefert. Ggf. in der falschen Sprache, was aber dann mit einem Klick vom Besucher zu ändern ist.

Nochmal: Welche Strukturänderungen? Willst Du auf Verzeichnisse ("/de", "/en") umsteigen? Dann mußt Du nach Änderung auch umleiten und verlierst die automatische Sprachwahl oder mußt sie mit einer Weiterleitung (von "/x" nach "/de/x") manuell implementieren.

Das ist nach meiner Erfahrung die sauberste Variante wenn alles mehrsprachig ist und nicht nur eine Seite. Aber "Das will und muss ich ja jetzt eben noch nicht klären."

Du bezahlst hier niemanden für eine kommentarlose Problemlösung, Du erhältst Meinungen und Lösungsansätze. Du magst meine Meinung genauso für Unfug halten wie ich die denkbaren Alternativen zum eigentlich angedachten HTTP-Mechanismus für Pfuscherei, aber deswegen ist sie noch lange nicht unpassendes Allgemeingeschwafel. Du hast eine Aufgabenstellung, ich zeige dazu Lösungswege und kommentiere ihre Anwendbarkeit.

Du bezahlst hier auch niemanden. Ich hab jetzt nicht den Ehrgeiz das Forum zu diskutieren, zumal nicht klar ist ob tatsächlich Verbesserungen eintreten, aber vielleicht sollte die FAQ mal um ein paar Punkte erweitert werden hinsichtlich einer Antwortkultur.

Wenn Du mit Kritik nicht umgehen kannst, lass die Fragerei bleiben.

Wenn Du mit Kritik nicht umgehen kannst, lass die Antworterei bleiben.

".. sondern ein grundsätzliches: Eine Änderung der Adresszeile ist von Serverseite aus immer nur mit einer Weiterleitung möglich.", das soll wohl auch bedeuten dass eine Weiterleitung nur mit transparenter erkennbarer vollständiger URL möglich ist,

So kann man es auch sagen, ja. Eine Weiterleitung bedeutet immer, dem Browser den Befehl zu geben, eine andere URL zu laden. Und die aktuell geladene URL zeigt jeder Browser in der Adresszeile an.

Da habe ich den Server mächtiger eingeschätzt, intern temporär ein xy.html.en als xy.html festzulegen und so auszugeben oder darauf weiterzuleiten, der eigentliche Knackpunkt bei meinem Ansatz.

Also entweder eine Lösung mittles "URL-Parameter", oder derzeit keine Sprachumschaltung durch den Besucher, oder wenn keine 404 dann zumindest lästige multiple choice falls ich es später umstelle und die sprachspezifischen Anfragen nicht umleite.

Grüsse

Cyx23

[Cyx23]

Hallo,

ich möchte gerne mod_rewrite und multiviews kombinieren, um eine
Sprachumschaltung bei gleicher URI zu ermöglichen.

[ ... ]

Nun wäre es möglich aus der gelieferten xy.html heraus eine xy.html.en.html
zu laden, um eine anderssprachige Version anzuschauen. Kann jetzt per
mod_rewrite diese xy.html.en.html wieder als xy.html ausgeben werden,

da offenbar diese xy.html.en.html erstmal nicht als xy.html ausgeben werden kann, habe ich jetzt 'rewrite' bzw. Ausgabe und multiviews bzw. automatische Sprachwahl vorläufig per SSI realisiert, die URI bleibt und bei Wechsel wird nur search bzw query angehängt.

Grüsse

Cyx23