Website in Sprache 2 zuerst öffnen

[Ronin570]

Hi,

ne kurze Frage.
Wie kann ich denn das Frontend zuerst mit Sprach Id 2 aufrufen?
Also z.b deutsch (1), englisch (2). Ich möchte, dass die Website standardmäßig in englisch geöffnet wird.
Hab vergessen wie es geht. Da musste man irgendwo ne Datei anpassen...
Ich wollt jetzt nicht unbedingt ne Weiterleitung einbauen...

(Und hat jemand Erfahrung mit Standort/Browsersprache abhängiger Sprachauswahl?)

Dankbar für jeden Tip.

Grüße

R

[Oldperl]

Hi,

kurze Antwort

In der config.php im Mandantenverzeichnis kann man die Id der gewünschten Sprache setzen!

Gruß aus Franken

Ortwin

[Ronin570]

Läuft! dankeschön

[Zuschauer]

Moin Ronin,

(Und hat jemand Erfahrung mit Standort/Browsersprache abhängiger Sprachauswahl?)

pack folgendes in deine .htaccess (Domain und evtl. Sprachkürzel anpassen!):

Code: Alles auswählen

# Redirect to the appropriate speach if none is in the URL
#    When there's nothing behind the domain
#    If the browser's accepted language starts with ..
#    Then go here, show it in the browser (R) and leave the .htaccess (L)
RewriteCond %{REQUEST_URI} ^/$ [NC]
RewriteCond %{HTTP:Accept-Language} ^de [NC]
RewriteRule ^(.*) http://www.DOMAIN.TLD/de/$1 [R,L]

RewriteCond %{REQUEST_URI} ^/$
# en is default for all other languages
RewriteRule ^(.*) http://www.DOMAIN.TLD/en/$1 [R,L]

Gruß
Zuschauer

[Oldperl]

pack folgendes in deine .htaccess (Domain und evtl. Sprachkürzel anpassen!)

Funktioniert aber nur soweit er AMR, entsprechend konfiguriert, im Einsatz hat.

Alternativ zur .htaccess kann man das auch per CHAIN lösen, indem man dort die Sprache des Browsers abfragt und entsprechend die gewünschte Mandantensprache auswählt/vorgibt. Zu beachten ist dabei aber die System-eigene Sprachumschaltung.

Gruß aus Franken

Ortwin

[Faar]

So, jetzt geb ich meinen Senf auch noch dazu

Heikel ist es, wenn man die Sprache zwingend vorgibt.
Manch Deutscher surft im Ausland oder mit fremdem Browser auf eine Seite und ärgert sich, dass er bei jedem Klick zwingend auf die ausländische Sprachversion geleitet wird.
Das kann richtig fatal werden.

Eine Sprachauswahl kann man auch über IP-Kennung gestalten aber diese wechseln hin und wieder ihre Länder und so kann es sein, dass man plötzlich eine IP aus Jemen hat und dann auf Jemenitisch begrüßt wird... oder von der Einreise in die USA abgehalten wird, wie neulich in der Presse stand.
Da ist wieder das gleiche Problem wie oben, zwingende Umschaltung wäre Mut zur Lücke, und nach Murphy würde die Lücke genau von den besten Neukunden besetzt werden.

Ich bekomme ja schon das große Reihern (Kotzen darf man hier nicht schreiben, oder? ), wenn mir auf dem 2560-Pixel Tab zwingend die Mobilseite angezeigt wird, obwohl ich genügend Platz für die komplette Ansicht habe.
Die .htaccess Umleitung würde doch bedeuten, dass bei jedem Aufruf immer auf die Mobile, oder hier die Sprache, umgeschaltet wird und beißt sich da nicht die Katze in den Schwanz?
So wie es "Die von Contenido" gelöst haben, nämlich mit Cookie, finde ich es am besten.

Oldperl hat schon eine komfortable Lösung angesprochen:
Man fragt die Browsersprache ab und ermittelt den Standort durch die IP und errechnet daraus eine Wahrscheinlichkeit zur richtigen Sprache und gleicht das mit dem Eintrag im Cookie ab.
Steht im Cookie Deutsch, bleibt es deutsch, selbst wenn der Standort Armenien aussagt.
Ist ein Besucher aber neu, hat er kein Spracheintrag-Cookie und folglich kann erstmalig eine Sprache vorgeschlagen werden.

So, genug gesenft

[Zuschauer]

Heikel ist es, wenn man die Sprache zwingend vorgibt.
Manch Deutscher surft im Ausland oder mit fremdem Browser auf eine Seite und ärgert sich, dass er bei jedem Klick zwingend auf die ausländische Sprachversion geleitet wird.
Das kann richtig fatal werden.

Nun, meine Lösung greift nur dann ein, wenn die Sprache noch nicht in die URL steht.
Ruft man die Seite aus Griechenland auf, kriegt man Englisch angezeigt, kann aber dann über eine Sprachnavi auf Deutsch umschalten.

Gruß
Zuschauer

[Faar]

Hallo Zuschauer,
bleibt die Sprache dann auch bei jedem Besuch der Seite auf Deutsch, wenn jemand in Griechenland einmal Deutsch eingestellt hatte und die Seite wieder über die Domain besucht?
Hier steht etwas über Accept Language: http://www.w3.org/International/questio ... ng-locales
Viele haben vermutlich nie die bevorzugte Sprache im Browser eingestellt, bekommen die dann auch die englische Seite zu sehen?
Und jedesmal, wenn man die Hauptdomain ansurft, wird doch wieder per .htaccess umgeschaltet, oder?
Die .htaccess greift ja vor dem Programm ein, also bevor ein Cookie abgefragt wird.
Folglich kann an dieser Stelle kein Ablgeich mit dem Cookie erfolgen, behaupte ich mal so

VG,
Faar

[Zuschauer]

Nun, meine Lösung greift nur dann ein, wenn die Sprache noch nicht in die URL steht.

Soll heissen, dass, wenn ich die Domain eintippe, die Sprache anhand der im Browser eingestellte bevorzugte Sprache gewählt wird.
Nutze ich Links in der Seite, steht schon eine Sprache darin und es wird nichts umgestellt.
Surfe ich die Seite das nächste Mal wieder über den reinen Domainnamen an, ist die Sprache wieder automatisch anhand der Browser-Sprachliste voreingestellt.
Speichere ich allerdings einen Link in den Favoriten, steht die Sprache schon mit drin und die automatische Sprachwahl in der .htaccess ändert diese nicht.

Das Verhalten, wonach du gefragt hast, also dass der Browser sich quasi die eingestellte Sprache merkt, wäre, gerade für Internet-Cafés, sehr schlecht, denn der nächste der die Seite aufruft ist vielleicht sogar ein Grieche.

Gruß
Zuschauer

[Faar]

Guten Morgen Zuschauer,

die Erklärung ist deutlich und lässt keine Fragen mehr offen, danke.
Das könnte man auch einem Kunden so kommunizieren, damit er auch entscheiden kann, ob er der Vorteile wegen die Nachteile in Kauf nimmt.

Scheints gibt es keine EierlegendeWollmilchsau, die alle Fälle abdeckt, irgendwo muss man einen Kompromiss eingehen.
An das Internetcafe dachte ich noch gar nicht, wegen der Cookies.

Die Idee mit der Wahrscheinlichkeit aus Browsersprache, Länder-IP und vielleicht Referrer und anderer Daten, geht mir noch nicht aus dem Kopf

VG,
Faar

[Zuschauer]

Nun, wenn du da konkretere Gedanken hast, was genau man in welche Reihenfolge berücksichtigen könnte, möchte ich das gerne mit dir besprechen um (möglichst zusammen) eine optimale Lösung zu entwickeln.

Gruß
Zuschauer

[Faar]

Also,
zuerst könnte man auf das .htaccess verzichten und es mit PHP lösen, und zwar gleich am Eingang.
Ich denke mir, dass die .htaccess kaum zu beeinflussen ist, was das Verhalten zur Laufzeit angeht.
Aber in PHP gibt es die Daten im Prinzip auch:

$_SERVER['HTTP_ACCEPT_LANGUAGE'];
Die Sprache des Browser (en), wie oben schon ausführlich für das .htaccess beschrieben.
Es gibt aber hier zum Teil ausführlichere Angaben, solche wie Accept-Language: fr-fr,en-us;q=0.7,en;q=0.3
http://www.w3.org/Protocols/rfc2616/rfc ... ml#sec14.4
Das heißt, französisches Französisch wird hier bevorzugt aber wenn das nicht verfügbar ist, dann würde auch US-Englisch bevorzugt werden, aber zur Not auch anderes Englisch.
Den Qualitiy-Range q=x habe ich noch nicht ganz durchschaut.

$_SERVER['HTTP_ACCEPT_CHARSET'];
Zum Beispiel iso-8859-1 ist eine westliche Einstellung, also Osteuropa und Asien und der Rest außer USA und Kanada fallen damit weg.
Ist wie oben die Language (en), dann wird es im Zusammenhang mit iso-8859-1 sehr wahrscheinlich auch Englisch sein.
Aber eher nicht Chinesisch.

$_SERVER['HTTP_REFERER'];
Sollte ein Referrer (hier deutsche Schreibweise) angegeben sein und die Domain-Endung lautet .cn, dann würde es zusammen mit utf-8 und Language cn ziemlich sicher auch Chinesisch sein.

$_SERVER['HTTP_USER_AGENT'];

Was kann man damit machen? Das müsste man testen.
Zumindest mit ...

Code: Alles auswählen

<?php
echo $_SERVER['HTTP_USER_AGENT'] . "\n\n";

$browser = get_browser(null, true);
print_r($browser);
?>

... bekommt man auch sowas hier:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

Da steckt die Sprache drin, aber auch das Betriebssystem und der Browser.
Angenommen es ist ein russisches oder chinesisches Betriebssystem samt deren eventuellen eigenen Browser und alles obere passt auch dazu, dann wäre es ein weiterer Hinweis auf die einzustellende Sprache.
Natürlich kann man das bei eigen programmierten Robots das ganz nach belieben und in stetem Wechsel rein schreiben, aber wer macht das schon

$_SERVER['REMOTE_ADDR'];

Die IP-Adresse ist einer der Haupthinweise und daran kann man meistens erkennen, woher jemand kommt.
Die paar Wenige, die eine IP-Farm besitzen und das mit dem User_Agent Profil bunt kombinieren, lassen wir mal gedanklich weg
Es geht recht schnell, wenn man eigene IP-Listen pflegt und die abgleicht mit der Remote_addr.
Aber die Liste muss man halt aktuell halten.

$_SERVER['REMOTE_HOST'];
Zusammen mit der Remote_addr kann man damit den Hostnamen ermitteln, was es ohne Liste leichter macht.

Code: Alles auswählen

<?php
$hostname = gethostbyaddr($_SERVER['REMOTE_ADDR']);

echo $hostname;
?>

Ich nehme an, der Server holt sich zur Laufzeit vom DNS den Namen, und damit hat man die Domain-Endung.

$_SERVER['REQUEST_URI'];
Der Pfad ist nicht ganz unwichtig, sofern man AMR eingeschaltet hat.
Steht da /de/index.html drin, dann soll es wahrscheinlich auch die Deutsche Sprache sein, die gesucht wird, selbst wenn der Besucher aus .ki (Kiribati) kommt. Dann ist es vermutlich ein Deutscher Urlauber.


So, nun soll das alles in richtiger Reihenfolge und richtig gewichtet ausgewertet werden.
Manche Daten sind ja gar nicht greifbar und manchen kann man nicht vertrauen.
Aber wenn man die Daten einfach abruft und sofern vorhanden, auch gleich gewichtet, bekommt man ein schönes Array mit Wichtung und jeweiligen Sprachen.
Damit sollte es möglich sein, ziemlich treffsicher die gewünschte Sprache einstellen zu können.
Natürlich, wenn ein Cookie gesetzt wurde, dann wird die dortige Spracheinstellung genommen.

... und irgendwie beschleicht mich das Gefühl, man müsste hier an die index.php rangehen.
Oder aber man leitet doch aus einer .htaccess ab auf eine Datei, die zuerst die Sprache anhand der Vorgehensweise ermittelt und dann direkt auf den Pfad weiter schaltet.
Was sagt eigentlich xmurrix dazu? Geht das überhaupt?

[Faar]

Da hat einer den Code für ACCEPT_LANGUAGE Auswertung bereits geschrieben:
http://www.thefutureoftheweb.com/blog/u ... age-header
Ich setze es hier nochmal rein, falls die Seite mal offline geht:

Code: Alles auswählen

// Accept-Language header
//en-ca,en;q=0.8,en-us;q=0.6,de-de;q=0.4,de;q=0.2

$langs = array();

if (isset($_SERVER['HTTP_ACCEPT_LANGUAGE'])) {
    // break up string into pieces (languages and q factors)
    preg_match_all('/([a-z]{1,8}(-[a-z]{1,8})?)\s*(;\s*q\s*=\s*(1|0\.[0-9]+))?/i', $_SERVER['HTTP_ACCEPT_LANGUAGE'], $lang_parse);

    if (count($lang_parse[1])) {
        // create a list like "en" => 0.8
        $langs = array_combine($lang_parse[1], $lang_parse[4]);
    	
        // set default to 1 for any without q factor
        foreach ($langs as $lang => $val) {
            if ($val === '') $langs[$lang] = 1;
        }

        // sort list based on value	
        arsort($langs, SORT_NUMERIC);
    }
}

// look through sorted list and use first one that matches our languages
foreach ($langs as $lang => $val) {
	if (strpos($lang, 'de') === 0) {
		// show German site
	} else if (strpos($lang, 'en') === 0) {
		// show English site
	} 
}

// show default site or prompt for language
// This would produce the following structure for my Accept-Language string:

Array
(
    [en-ca] => 1
    [en] => 0.8
    [en-us] => 0.6
    [de-de] => 0.4
    [de] => 0.2
)

[Zuschauer]

zuerst könnte man auf das .htaccess verzichten und es mit PHP lösen, und zwar gleich am Eingang.

Das sollte man dann wohl in der config.php machen, die wird beim Update nicht überschrieben.

$_SERVER['HTTP_ACCEPT_LANGUAGE'];
... Es gibt aber hier zum Teil ausführlichere Angaben, solche wie Accept-Language: fr-fr,en-us;q=0.7,en;q=0.3

Stimmt, diese Angabe nimmt mehrere Sprachen, teilweise mit Land, auf und vergibt über das q die Reihenfolge der Bevorzugung vor.
Im Browser kann man diese Liste verändern: in Firefox -> Einstellungen -> Inhalt -> bei "Sprachen" auf [Wählen].

$_SERVER['HTTP_ACCEPT_CHARSET'];

Klar kann man dies mit einbeziehen, aber nur als großräumiges Erkennungsmerkmal.
Denn 1. kann man in Contenido nicht mal eben das Charset automatisch je Besucher umschalten und 2. ist das Charset nicht an eine Sprache gebunden.

$_SERVER['HTTP_REFERER'];

Dieser Gedanke gefällt mir, den könnte man tatsächlich verfolgen.
Wenn ein Deutscher in den Griechenland ist und etwas sucht, nimmt er, wenn er der Landessprache nicht mächtig ist, google.DE als Suchmaschine und nicht google.GR.

$_SERVER['HTTP_USER_AGENT'];

Die hier aufgeführte Sprache ist die Sprache des Browsers selbst, also die der Oberfläche mit den Menüs usw.
Daraus kann man doch höchstens ableiten was die bevorzugte Sprache zum Zeitpunkt des Downloads des Browsers war.

$_SERVER['REMOTE_ADDR'];

An der IP-Adresse kann man eben NICHT erkennen woher jemand kommt, sondern nur wo er sich aktuell befindet.
Diese Information könnte man als allerletztes Erkennungsmerkmal einsetzen wenn sonst alles versagt.

$_SERVER['REMOTE_HOST'];
...
Ich nehme an, der Server holt sich zur Laufzeit vom DNS den Namen, und damit hat man die Domain-Endung.

Nein, der 'REMOTE_HOST' wird soweit ich weis vom Browser mit übermittelt, kann dann aber von einer Firewall verändert werden.
Diese Information findet man in der Netzwerkkonfiguration und ist entweder die Domain des Rechners, oder aber (wenn keine Domain existiert) dessen Name.

$_SERVER['REQUEST_URI'];

Bei AMR steht die Sprache in die URL, ohne der Paramater $lang.
Sind beide nicht vorhanden, ist keine Sprache angegeben und muss eine ermittelt werden.

So, nun soll das alles in richtiger Reihenfolge und richtig gewichtet ausgewertet werden.
Manche Daten sind ja gar nicht greifbar und manchen kann man nicht vertrauen.
Aber wenn man die Daten einfach abruft und sofern vorhanden, auch gleich gewichtet, bekommt man ein schönes Array mit Wichtung und jeweiligen Sprachen.
Damit sollte es möglich sein, ziemlich treffsicher die gewünschte Sprache einstellen zu können.
Natürlich, wenn ein Cookie gesetzt wurde, dann wird die dortige Spracheinstellung genommen.

Die beiden wichtigsten Angaben bei der Erkennung, sofern keine Sprache in die URL steht, sind m. E.:

• die "bevorzugte Sprache im Browser" ('HTTP_ACCEPT_LANGUAGE').
  Hieraus die Sprachen der Reihe nach durchtesten ob sie vorhanden sind, der erste Treffer ist auch gleich der wichtigste (zusätzlich zur q=-Angabe stehen die Sprachen auch noch in der richtigen Reihenfolge, aber man kann diese auch zuerst in ein Array danach sortieren).
• der Referrer ('HTTP_REFERER').
  Kommt jemand von eine deutschsprachige Seite (besser eine deutsche Domain, denn z. B. .com und .eu sind sprachunabhängig), dann möchte er/sie wohl diese Sprache angezeigt bekommen.
  Dies funktioniert aber nur wenn 1. die Seite nicht durch Adresseingabe aufgerufen wurde und 2. die Top-Level-Domain einem Land zuzuordnen geht.
  Und auch dann nicht zuverlässig, denn eine Zeitlang gab es in D auch sehr viele Websites mit .co.uk, da würde man dann auf GB schließen.

Charset und User-Agent würde ich eher nicht berücksichtigen, diese Informationen haben kaum Bezug zur bevorzugten Sprache.
Und wie gesagt die IP-Adresse als allerletzte Möglichkeit, nur dann wenn man sonst nichts findet (mit bevorzugte Sprache und Referrer).

... und irgendwie beschleicht mich das Gefühl, man müsste hier an die index.php rangehen.

Nein, wie anfangs schon erwähnt in die config.php, denn da wird die Sprache voreingestellt.
Alternativ ginge evtl. auch eine config.local.php, aber die wird erst nach der config.php geladen (wenn vorhanden) und dann wurde in der config.php bereits eine Sprache voreingestellt.

Oder aber man leitet doch aus einer .htaccess ab auf eine Datei, die zuerst die Sprache anhand der Vorgehensweise ermittelt und dann direkt auf den Pfad weiter schaltet.
Was sagt eigentlich xmurrix dazu? Geht das überhaupt?

Das kann auch ich beantworten: klar, geht, dann leitet man eben nicht mehr auf die front_content.php weiter.
Aber das ist unnötig, da in der front_content.php zuerst die config.php und dann (wenn vorhanden) die config.local.php geladen werden.
Und in der config.php werden schon $client und $lang festgelegt wenn nichts in der URL ermittelt wurde, also ist das doch die optimale Stelle zum ansetzen.

Gruß
Zuschauer

PS: Code for die accepted languages habe ich auch, aber schon so dass eine Sprache als Fallback genutzt wird (im von dir gefundenen Code wird dann nach eine Sprache gefragt).

[Faar]

Aus alle den Angaben kann man eine Wahrscheinlichkeit ableiten.
Die Gewichtung ist wichtig, z.B. würde in Deinen Augen der Charset nicht als wichtig gelten, bekäme also wenig Wichtungs-Punkte.
Bei Google auf Google.de zu kommen ist manchmal gar nicht so einfach, also kann auch ein Deutscher in Griechenland mit griechischem Google unterwegs sein.
Auch Deine anderen Zweifel muss man berücksichtigen, es sind nur Hinweise.
Darum meine ich ja: Wahrscheinlichkeit.
Aber wenn alles passt, ist es zusammengenommen wahrscheinlicher als wenn man nur die accepted_language auswertet.

Eine Frage die noch offen ist, ist die des Cookies.
An welcher Stelle wird das Cookie abgefragt, bezw. gesetzt?
Man möchte dann ja zur Auswertung auch das Cookie nehmen, das heißt, wenn im Cookie die Sprache bereits gesetzt ist, wird diese genommen.
In eigen programmierten Projekten ist das manchmal so einfach aber hier muss man das CMS berücksichtigen und man kommt nicht überall ran.

VG,
Faar