Hallo Martin,
erstmal vielen Dank fuer deine ausfuehrliche Antwort!
- Fuer jede moegliche Sprache existiert eine Subdomain
Damit legst du dir selbst Fallstricke, z.B. wenn du Javascript verwenden willst (oder mal einzelne Seiten über SSL laufen lässt). Willst du dann tatsächlich alle Javascript-Ressourcen, die zum größten Teil sprachneutral sind, auf jeder Domain separat vorhalten?
Das verstehe ich nicht so ganz, denn die Subdomains verweisen ja auf ein und denselben Quellordner. Da die JS-Files durch PHP geparsed werden, greift hier der uebliche i18n-Mechnismus. Was genau meinst du mit der doppelten Datenhaltung?
Das gleiche gilt für eingebundene Bilder: Lagerst du sie z.B. von de.example.org auf images.example.org aus, werden sich einige Nutzer wundern, die ihren Browser nur Bilder laden lassen, die von derselben Domain stammen.
Bezieht sich diese Aussage jetzt noch auf die Same Origin Policy? Denn, wie oben beschrieben, fuehren ja sowohl de.example.org/images/foo.bar als auch en.example.org/images/foo.bar auf dieselbe Resource.
Unterm Strich: Ich halte es für schlauer, verschiedene Sprachversionen nicht durch eine Subdomain zu unterscheiden, sondern durch ein Verzeichnis:
Aber, um an deinem Beispiel festzuhalten, dann bestuende doch das gleiche Problem wenn ich zb die Image in eine eigene Subdomain auslagere?
Nutze außerdem Language Negotiation, um von www auf die sprachspezifische Version zu leiten, lass aber dem Besucher jederzeit die Möglichkeit, manuell die Sprache zu wechseln und damit die Einstellungen seines Browsers zu übersteuern.
Letztere Moeglichkeit ist gegeben. Erstere war auch vor der Umstellung auf die Language-Subdomains vorhanden. Allerdings bin ich daran gescheitert dieses unter Apache entsprechend zu konfigurieren. Denn in der Datenbank existiert die Definition, welche Sprachen erlaubt sind und welche nicht. Und an dieser Stelle muesste ja eine Interaktion stattfinden.
- Alle *.css, *.js, *.tpl und *.ajax -Anfragen werden automatisch an ihren entsprechenden Ordner deligiert.
Somit brauche ich fuer die Einbindung dieser Resourcen keine Pfade anzugeben.
Dann aber Vorsicht bei relativen Pfadangaben z.B. *innerhalb* von Stylesheets oder Javascripts. Die gehen dann nämlich nicht vom tatsächlichen Verzeichnis aus, in dem die Datei liegt, sondern von dem Verzeichnis, das du über das Rewriting vorgaukelst.
Vielleicht bringt es etwas wenn ich das _warum_ kurz erklaere.
Unter PHP arbeite ich fuer Includes stets mit dirname(__FILE__). Und durch meine virtuellen URLs stiesz ich hierbei auf Probleme. Denn die Includeangabe griff zb fuer die Adresse example.org/sektor1/sektor2, jedoch nicht fuer example.org/sektor1/sektor2/region1/myname.
Es kann sehr gut sein, dass ich an dieser Stelle evtl. bereits eine falsche Abzweigung eingeschlagen habe.
- *.css, *.js, *.tpl und *.ajax -Files werden als PHP geparsed (nicht alle)
Hm.
Im Falle von Mehrsprachigkeit hat sich diese Methode als die fuer mich Komfortabelste erwiesen.
Das ist sehr unüblich, aber möglich. Beachte aber, dass z.B. beim Aufruf von en.example.org/sources dann auf sources/sources/view/index.html verwiesen wird. Merke: Pfadangaben im DirectoryIndex können problematisch sein.
Wieso unueblich? Bei mehreren hundert Seiten moechte ich doch schlieszlich eine saubere Struktur besitzen.
Oder spielst du darauf an eine Index-Datei durchaus in das Root zu packen, dort jedoch ein Redirect auf die entsprechende Seite vorzunehmen?
Wenn ich mit dem PHP-Header arbeite, bekaeme dann eigentlich die Suchmaschine etwas davon mit?
----------------------------------------------------------------
Redirect every AJAX-Request to the Ajax-Folder
----------------------------------------------------------------
RewriteRule ([^/]+.ajax) sources/ajax/$1 [L]
Die sind alle relativ zum Request-Pfad und können daher ins Nirwana gehen, wenn der Request nicht auf das Domain-Root-Verzeichnis verweist.
Wie habe ich das zu verstehen? Saemtliche Resourcen binden zb obige Dateien einfach durch require('test.ajax') ein. Das gleiche geschieht bei den AJAX-Aufrufen im Javascript selbst. Und, unabhaengig von dem Pfad, in dem sich die Dateien befinden, greift die RewriteEngine wie gewuenscht.
<Files main.css>
ForceType application/x-httpd-php
</Files>
[..]
Die beiden hast du doch mit der allgemeinen Regel, alle CSS- und JS-Ressourcen mit PHP zu parsen, schon abgedeckt.
In dem von mir geposteten Beispiel gibt es eine solche Regel nicht? Diese beiden Files sind die einzigen CSS- und JS-Dateien, die derzeit von PHP geparsed werden.
Hoffe ich habe deine Ausfuehrungen korrekt verstanden.
Nochmals besten Dank!
MfG
Peter