Language codes (im Backend "Codierung" genannt) mit Unterstrich

[noRiddle (revilonetz)]

Hallo Community.
Hat schonmal jemand versucht Sprachen anzulegen deren Code einen Unterstrich beinhaltet ?,
also anstatt
en, en_us (für US-Englisch)
es, es_mx (für Mexikanisches Spanisch)
fr, fr_ca (für kanadisches Französisch)
Das verweigert der Shop nämlich wegen der Funktion xtc_input_validation();

In /includes/modules/set_language_sessions.php wird folgendes gemacht:

Code: PHP  [Auswählen]

$_GET['language'] = xtc_input_validation($_GET['language'], 'char', '');

und in /inc/xtc_input_validation.inc.php leider das

Code: PHP  [Auswählen]

                case 'char':
                        $replace_param='/[^a-zA-Z]/';
                        break;;

was den Unterstrich rausfiltert, die Sprache wird nicht gefunden und der Shop fällt auf die DEFAULT_LANGUAGE zurück.

Ich halte das ehrlich gesagt für einen Bug, denn Codes wie fr_be, fr_ch müssen möglich und können auch seo-relavant sein.

Weiterhin gibt es noch einen Bug, einer der nicht von Meinungen abhängt, der mir nur auffiel weil ich erstgenannten Bug begutachtet habe.
Wir finden in /includes/modules/set_language_sessions.php folgenden Code:

Code: PHP  [Auswählen]

  if (isset($_GET['language'])) {
    $_GET['language'] = xtc_input_validation($_GET['language'], 'char', '');
    $lng = new language($_GET['language']);
  } elseif (isset($_SESSION['language'])) {
    $lng = new language(xtc_input_validation($_SESSION['language'], 'char', ''));
  } else {
    $lng = new language(xtc_input_validation(DEFAULT_LANGUAGE, 'char', ''));
    if (USE_BROWSER_LANGUAGE == 'true') {
      $lng->get_browser_language();
    }
  }

Wenn als im elseif als Parameter für die Instantiierung der language-Klasse $_SESSION['language'] benutzt wird kann das nicht funktionieren. $_SESSION['language'] ist ja auf das Directory gesetzt, also "german", "english" usw. und nicht auf den Language-Code, also 'de', 'en' usw..
Die Klasse verlangt im __construct() jedoch den Language-Code.

Das fiel bislang nur deshalb nicht auf weil der Fall der Kondition der umgebenden if-Clause

Code: PHP  [Auswählen]

isset($_SESSION['language']) && !isset($_SESSION['language_charset']

so gut wie nie vorkommen dürfte, also daß zwar $_SESSION['language'] nicht jedoch $_SESSION['language_charset'] gesetzt wäre.

Es wäre nett wenn zumindest eine Person meine Gedankengänge nachvollziehen würde (jeder kann sich ja irren).

Gruß,
noRiddle

*NACHTRAG*
Habe dazu ein Ticket #1524 erstellt.

Linkback: https://www.modified-shop.org/forum/index.php?topic=39499.0

[noRiddle (revilonetz)]

Es wäre nett wenn zumindest eine Person meine Gedankengänge nachvollziehen würde (jeder kann sich ja irren).

Gruß,
noRiddle

[DieterW]

Ich halte beides für Bugs.

Und man muss den deutschsprachigen Raum gar nicht verlassen um auf den ersten zu stoßen:

de_de: Januar
de_at: Jänner

 

[noRiddle (revilonetz)]

Jau, danke für die Bestätigung.
Ich denke in Europa macht es kaum jemand, obwohl ich für einen schweizer Shop schon de_ch, fr_ch, it_ch verwenden würde, aber es sollte jedenfalls funktionieren.

Wer's benötigt muß einfach in /inc/xtc_input_validation.inc.php das

Code: PHP  [Auswählen]

                case 'char':
                        $replace_param='/[^a-zA-Z]/';
                        break;

zu dem machen

Code: PHP  [Auswählen]

                case 'char':
                        $replace_param='/[^a-zA-Z_]/';
                        break;

Ich denke damit bricht man nicht die Validierung (und somit die Sicherheit) von normalen Strings die mittels der Funktion auf 'char' getestet werden.
Man kann natürlich auch einen neuen Case anlegen dafür und muß diesen dann in der /includes/modules/set_language_sessions.php verwenden (siehe mein erster Post).

Gruß,
noRiddle

[noRiddle (revilonetz)]

Abgesehen davon, daß ich den Grund der if-Clause nicht kenne in /includes/modules/set_language_sessions.php

Code: PHP  [Auswählen]

if (!isset($_SESSION['language']) || isset($_GET['language']) || (isset($_SESSION['language']) && !isset($_SESSION['language_charset']))) {

also warum man gerade abfragt

Code: PHP  [Auswählen]

(isset($_SESSION['language']) && !isset($_SESSION['language_charset']))

müsste der Part

Code: PHP  [Auswählen]

} elseif (isset($_SESSION['language'])) {
    $lng = new language(xtc_input_validation($_SESSION['language'], 'char', ''));

zumindest so lauten

Code: PHP  [Auswählen]

} elseif (isset($_SESSION['language']) && isset($_SESSION['language_code'])) {
    $lng = new language(xtc_input_validation($_SESSION['language_code'], 'char', ''));

womit, wenn $_SESSION['language_code'] nicht gesetzt sein sollte wenigstens der Fallback auf DEFAULT_LANGUAGE greifen würde;
wobei der Fix für die xtc_input_validation() für Language-Codes mit Unterstrich (de_ch, en_us, fr_ca, es_mx usw.) natürlich auch gemacht werden sollte.

Gruß,
noRiddle

*NACHTRAG*
Ach, vergessen: Ticket dazu # 1524

[web-looks]

@noRiddle: Mir war das auch schon aufgefallen in einem Shop mit de_ch. In meinem Fall war der Bug aber willkommen, weil es bei den SEO URL mit Sprachkürzel ohnehin zu Problemen geführt hätte.

Ich denke in den mesten Fällen sollten 2 Zeichen reichen. Welcher Shop hat schon mehrmals Französisch oder britisch und amerikanisches Englisch zur Auswahl? Auch in meinem Fall gab es Deutsch nur einmal (de_ch). So konnten wir es auf 2 Buchstaben umstellen.

[noRiddle (revilonetz)]

Mhh, ich denke Suchergebnisse werden auch am Zielland/an der Zielsprache orientiert.
So lesen Suchmaschinen z.B. auch das lang-Attribute des öffnenden html-tags aus, Beipiel:

Code: XML  [Auswählen]

<html lang="en_us">

Einen Shop in den USA oder in Mexiko würde ich schon lieber auf en_us bzw. es_mx setzen.
Ich finde grundsätzlich sollte das möglich sein, aber ich bin kein SEO-Fachmann.

Der verkehrte Parameter für die Klassen-Instatiierung in /includes/modules/set_language_sessions.php jedenfalls ist auf jeden Fall ein Bug.

Gruß,
noRiddle

[web-looks]

Das ist ein Argument. Google ignoriert zwar die Sprache im html Tag, freut sich aber über einen Vermerk der verschiedenen Übersetzungen im <link rel="alternate">:

https://support.google.com/webmasters/answer/189077?hl=de

Zu dem zweiten Bug gebe ich Dir auch Recht. Es müsste $_SESSION['language_code'] übergeben werden. Wobei das möglicherweise ganz raus kann. In welchem Fall könnte denn $_SESSION['language'] existieren, $_SESSION['language_charset'] aber nicht?