MB: Vorgehensweise zur Filterung von Sprachen in Webseiten

moin Community,

wie kann man über Nutzer Navigation die spracheinstellungen der Seite festlegen?

  • über URL /de/default/home/index/
  • Über $_SESSION

weitere lösungen fallen mir nicht ein. Ich hab mal mit new $controller( $language ) gelöst. An SESSION-Variable bin ich noch nicht dran gegangen. Welche Vorteile bringen diese beiden Lösungen? Gibt es weitere Lösungen?

vlg MB

  1. Hallo MB,

    wie kann man über Nutzer Navigation die spracheinstellungen der Seite festlegen?

    über Sprachvereinbarung.

    Bis demnächst
    Matthias

    --
    Rosen sind rot.
    1. Hallo Matthias,

      das ist schon ein bisschen zufrüh für meine Fähigkeiten. Spannend ist der Link schon, von W3C und sogart auf DEUTSCH! Ich will nur wissen, auf welche weise ich, per manueller navigation der webseite, sprachen umstellen kann. Ich möchte erst später wissen, wie man Indikatoren in der Verbindung findet, um eine Preferenz Sprach Voreinstellung zum Klienten zu liefern. Eine lösung die ich vorgestellt habe, war ja, das ich die Spracheinstellungen über den Controller Aufruf als Parameter habe. Ich möchte weiter Methoden, Techniken und mit denen verbundenen Vor-. und Nachteile kennen lernen

      vlg MB

  2. Es gäbe noch Cookies.

    Vorteile und Nachteile der Methoden:

    1. URL (Subdomain, virtuelles Verzeichnis, Suffix der Ressource)

    Vorteile: Es muss kein Cookie und keine Session herumgeschleppt werden. Content-Negation und rewrite bearbeitet der Webserver für Dich. Suchmaschinenfreundlich.

    Nachteile: Es müssen ggf. alle URLs in den Links vor Ausgabe der Seite umgebaut werden.

    1. Session / Cookie

    Vorteile: Die Links müssen nicht umgebaut werden. Können aber :) (für die Suchmaschinen)

    Nachteile: Cookie oder Session werden "herumgeschleppt". ggf. nicht Suchmaschinenfreundlich.

    das ist schon ein bisschen zufrüh für meine Fähigkeiten.

    Nicht unbedingt.

    1. moin Regina,

      den Link schau ich mir gleich morgen bzw. heute an! Danke für die AW

      vlg MB

    2. Hallo zusammen,

      ergänzend dazu. Wenn die Sprache nicht in der URL auftaucht kann es zu verschiedenen Problemen mit anderen Tools kommen. Das Problem ist, dass dann verschiedene Ressourcen über die über die gleiche URL ausgeliefert werden. Wenn man dann zum Beispiel mod_cache (http://httpd.apache.org/docs/2.4/en/mod/mod_cache.html) kann es zu "interessanten" Phänomenen kommen. Grund ist, dass mod_cache ausschließlich die URL verwendet zu prüfen ob eine Ressource bereits im seinem Cache liegt. Man kann zwar über HTTP-Header noch einiges machen, die Konfiguration wird dann aber oftmals sehr kompliziert.

      1. Wenn die Sprache nicht in der URL auftaucht kann es zu verschiedenen Problemen mit anderen Tools kommen.

        Das ist absolut richtig. Allerdings würde ich selbst den Einsatz von mod_cache wegen einiger Seiteneffekte längst nicht in jedem Fall empfehlen.

        Nämlich wenn z.B. das Ergebnis eines erfolgreichen Logins in der SESSION oder in einem COOKIE herumgeschleppt wird kann es dazu kommen, dass mode_cache an nicht autorisierte Benutzer Inhalte ausliefert.

        Auch bei der Antwort auf Anfragen, die mittels POST-Request erfolgen muss man dann als Entwickler/Betreiber sehr vorsichtig sein und ggf. ansonsten gesendete Caching-Header abschalten.

        Was aber mit mode_cache immer geht ist die Auslieferung statischen Contents - soweit es keine Beschränkungen hinsichtlich der Abrufbarkeit geben soll. Manche Seiten verwenden deshalb für eben solchen statischen, öffentlichen Content eine Subdomain (webseite auf http[s]://www.foo.example; Grafiken, CSS, JS auf http[s]://static.foo.example. Das muss keine Maschine sein, denn schließlich lässt sich mod_chache aber nicht nur in der server-config sondern auch für virtuelle Hosts (static kann ein solcher sein) und "per dir" konfigurieren, also auch ein- oder oder ausschalten. So wäre es denkbar, zu cachende Inhalte explizit unter http[s]://www.foo.example/static/ unterzubringen und das Caching nur für dieses Verzeichnis zu aktivieren.

        Wird kein statischer Content ausgeliefert kann es zu dem effektiver sein, die Ausgaben von CGI-Skripten oder eben PHP selbst zu cachen, u.a. weil man in einem eigenen Cache sogar gezippte Versionen des Outputs vorhalten kann und den nur für die zwei Abrufe pro Jahr (es gibt kaum http-Clients, die nur ungepackte Daten verstehen) vor dem Versand auspackt. Selbst für packbaren statischen Content , insbesondere alle Dateien, die Text oder ungepackte Daten beinhalten, z.B. bmp) kann man auch mit PHP was stricken...

        1. Wird kein statischer Content ausgeliefert kann es zu dem effektiver sein, die Ausgaben von CGI-Skripten oder eben PHP selbst zu cachen,

          Das Thema hatten wir schon einmal. Wie Du schon sagst, es kann effektiver sein. Gegen einen dezidierten Cache (z.B. Varnish) wirst Du aber mit einem selbstgebautem niemals anstinken können.

          Selbst bei statischem Content kann sich das lohnen!

          1. Wie Du schon sagst, es kann effektiver sein. Gegen einen dezidierten Cache (z.B. Varnish) wirst Du aber mit einem selbstgebautem niemals anstinken können.

            varnish ist durchaus in vielen Fällen eine gute Idee. Allerdings kann ich immer dann gegen ihn "anstinken" wenn sein Einsatz nicht möglich oder nicht geboten ist. Und das trifft deutlich öfter zu als "niemals":

            Zunächst einmal stellt sich die Frage ob man einen "dezidierten" (Du meinst wahrscheinlich "dedizierten") Cache, sei es nun squid, varnish oder ein anderer(*) überhaupt betreiben kann oder will. Viele können es nicht. Denn die Mehrheit der Websites wird auf Servern betrieben, auf denen der "Webmaster" keinesfalls Root-Rechte hat und der Hoster betreibt keinen Reverse-Proxy. Bleibt also, dass man sich als "Webmaster" bzw. Programmierer erstmal selbst darum kümmert, dass die Webseite so schnell wie möglich ausgeliefert wird. Das macht dann einen Reverse-Proxy in sehr vielen Fällen obsolet.

            Selbst bei statischem Content kann sich das lohnen!

            Wenn das WIRKLICH notwendig wird sollte man sich gleich Gedanken um eine Lastverteilung machen. Genau ein varnish vor genau einem http-Server bringt da gar nichts. Und dann muss man im Jahr 2017 auch noch über https nachdenken. Ob der varnisch sich hinter einem nginx noch lohnt? Ich weiß es nicht und habe sogar Zweifel.

            *) Wenn ein Reverse-Proxy gebraucht wird, so wird wahrscheinlich ein reiner Reverse-Proxy (hier also varnish) Vorteile bieteten, denn bei Software gilt im Prinzip: wenn sie weniger kann, dann kann sie das wenige sicherer und schneller. Insofern hast Du mit dem "dedizierten Cache" prinzipiell recht. Freilich kommt es noch darauf an, wie der betrachtete Cache arbeitet und ob er alle benötigten Futures bietet (z.B. Ressourcenunterscheidung anhand von Cookies/Sessions und Post-Daten?)