Sprachen Problem unter Firefox 4

[bluecali]

Aber ich glaube der Fehler was du meinst, ist was anderes speedy. Das gibts schon länger und in etlichen Shops. Bei dem was du meinst geht die Seite zurück ändert aber die Sprache nicht und wenn du nochmal zurück klickst gehst du eine ganze zurück wo du herkommst. Die reihenfolge stimmt erändert bloss die Sprache nicht. Jetzt bleibt der Browser aber komplett hängen. Ich hoffe ihr habt es einiger maßen verstanden.

Nur jetzt habe ich einen neuen Bug entdeckt. Ich kann mit dem Firefox 4 keine Attribute anlegen. Attribut merkmale funtionieren, aber unter Attribut verwaltung kommt die Seite auch aber das was ich anklicke usw. wird nicht gespeichert.

Was mir auffällt, mit dem FF 3.6 dauerte es sehr lange bis die Attribute anlegen seite sich aufgebaut hat und der Browser reagierte währenddessen auch nicht. Das dauerte fast schon ne Minute ( ich habe sehr viele Attribute wegen Felgen ). Jetzt mit dem FF 4 geht der Aufbau sehr schnell, paar sekunden, aber speichert nichts ab.

[Modulfux]

Da ich seit gestern auch den FF4 auf dem Rechner habe und mich freue, dass man damit auch wieder Attribute bearbeiten und zuweisen kann, habe ich versucht den Fehler nachzuvollziehen. Fehlanzeige!

Es liegt defintiv nicht am FF 4. Ich habe eben in einem blanko Shop ein Artikelmerkmal angelegt, eine Artikeloption angelegt und diese auch einem Artikel zugewiesen. Funktioniert alles tadellos.

By the way, der FF aus der 3'er Reihe hatte arge Probleme mit seiner Renderingengine wenn es um große und komplexe Tabellen ging. Da konnte es schon mal passieren, dass der FF ganz ausgestiegen ist. Bis gestern musste ich für die Attributgeschichte immer auf den Chrome ausweichen, der war immer flott genug.

Gruß
Ronny

[web28]

Um die Sprachparameter aus der URL zu entfernen, wird im Trunk Demoshop ein Redirect301 ausgeführt. Dadurch kann man dann mit der Browser Zurück Taste nicht direkt zurück, sondern erst beim 2ten mal.

Auf den Artikelseiten erfolgt seit 1.03 durch das gunnART Modul bei Bedarf ebenfalls ein Redirect301.

[Tomcraft]

Sieht also eher gewollt aus und nicht nach Bug.

Grüße

Torsten

[web28]

Wenn die Sprachumschaltung über den language Parameter erfolgt, lässt sich das nicht vermeiden.

Alternativ wäre eine Kennung im URL-Pfad wie /de/ und /en/
Oder verschiedene Domains domain.de, domain.com

[Tomcraft]

Die Kennung im URL-Pfad wäre eigentlich ganz sinnvoll, denke ich.

Grüße

Torsten

[speedy]

Wie kann denn Google mehrsprachigen Content auseinanderhalten, wenn die URL immer gleich ist ?
Da muss man ja zwangsläufig /de/ und /en/ nutzen oder nicht ?

[Tomcraft]

Macht in meinen Augen auch mehr Sinn als das über einen Parameter-Anhang in der URL zu machen, aber das kam eben erstmal so von ShopStat.

Grüße

Torsten

[web28]

Wie kann denn Google mehrsprachigen Content auseinanderhalten, wenn die URL immer gleich ist ?
[...]

Das kann niemand, selbst Google nicht! Außerdem wird durch einen Parameter der Shop auch nicht in ausländischen Sumas gelistet.

Dafür muss eine Unterscheidung direkt in die URL, idealerweise nimmt man gleich pro Sprache eine andere Domain.

Man muss halt die Unterschiede kennen. Ein weitere Sprache im Shop ist erst einmal nur ein Service für Kunden, mit Suchmaschinenlisting hat das nichts zu tun.
Dafür muss am Shopsystem geschraubt werden, dann klappt's auch mit dem Nachbarn(ländern).

[bluecali]

Also ich kriege viele Anfragen aus dem Ausland und zwar weltweit.

Übrigens, wenn es jemandem interessiert, die Probleme mit den Attributen, die ich hatte, war ein Server-Fehler bzw. eine falsche Einstellung im Programm "suhosin".

[DokuMan]

[...]
Übrigens, wenn es jemandem interessiert, die Probleme mit den Attributen, die ich hatte, war ein Server-Fehler bzw. eine falsche Einstellung im Programm "suhosin".

Das mit "suhosin" ist bekannt und im Handbuch steht auch der Workaround dazu.

[bluecali]

Ich hatte schon mal 'nen Blick rein geworfen, aber nicht richtig durchgelesen. Ich glaube ich hole das mal nach.