Dieses Ergebnis ist bei beiden CMSMS-Installationen gleich. Für mich sieht das wie ein Bug in CMSMS aus, bei dem die Language-Tags en und en-GB nicht richtig verarbeitet werden. Zufälligerweise hatte ich genau die in Firefox drin gehabt.

Okay. Hab jetzt mal verschiedene Einstellungen ausprobiert.
Das mit dem walisisch kann ich tatsächlich reproduzieren, wenn ich im Firefox als Sprache "en" einstelle.
Sprachen mit Bindestrich schlagen offenbar einige fehl.
So z.B. "de-de" - wird nicht erkannt -> Resultat englisch.
Nur "de" funktioniert.

en-US funkioniert.
en-GB nicht -> Resultat en-us.

en -> walisisch.

fr -> französisch.
fr-fr -> englisch.

...

Da hätten wir ja schonmal Fehler #1

Yepp.
Zumindest das kann ich leider nicht reproduzieren.
Sobald in der DB ein Wert drin steht, wird mir die dort gespeicherte Sprache angezeigt.

MfG
Jan

@NaN: Danke für den Hinweis für die globalen Spracheinstellungen. Dass die nur für's Frontend und nicht fürs Admin Backend gilt, wusste ich nicht, das erklärt die Wirkungslosigkeit dieser Einstellung,

Habe mal etwas mit den User-Agents rumgespielt und mit Überraschung festgestellt, dass die Admin-UI-Sprache  bei mir ausschließlich durch den Language Tag des Browsers bestimmt wird, nach einem Refresh der Webseite ist die neue Sprache sofort wirksam. Ergebnis:

en,de;q=0.7,en-US;q=0.3
80% Englisch, 20% Welsh (so war bisher meine Useragent-Einstellung)

en-GB,en;q=0.8,de;q=0.5,en-US;q=0.3
80% Englisch, 20% Welsh (genau wie zuvor)

en-US,en;q=0.7,de;q=0.3
100% Englisch, einwandfrei

de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
100% Deutsch, einwandfrei

fr-FR,fr;q=0.8,de;q=0.6,en-US;q=0.4,en;q=0.2
100% Französisch, einwandfrei

it-IT,it;q=0.8,de;q=0.6,en-US;q=0.4
,en;q=0.2
100% Italienisch, einwandfrei

Dieses Ergebnis ist bei beiden CMSMS-Installationen gleich. Für mich sieht das wie ein Bug in CMSMS aus, bei dem die Language-Tags en und en-GB nicht richtig verarbeitet werden. Zufälligerweise hatte ich genau die in Firefox drin gehabt.

Die eigentliche Frage bleibt aber: Warum hat die Spracheinstellung in den CMSMS User Account Preferences überhaupt keine Wirkung? Ist das denn bei Euch anders?

Zeile 76 in adodb_functions wird gar nicht ausgeführt, weil set_names = false.  Der DB-Fehler muss also woanders herkommen.

Ah. So nach und nach gibst Du uns endlich mal relevante Informationen ...
Wenn "set_names = false" ist und Du nicht zufällig "set_db_timezone = true" gesetzt hast, dann lautet der SQL Syntax an dieser Stelle einfach nur:

SET

Was natürlich ein Fehler ist.
Dann bekomme ich auch die von Dir genannte Fehlermeldung (Error 1064).

Sieht man übrigens auch, wenn man sich den PHP-Quelltext anschaut:

function &adodb_connect()
{

 ...

	$p1 = array();
	if($config['set_names'] == true) {
	  $p1[] = "NAMES 'utf8'";
	}
	if($config['set_db_timezone'] == true) {
	  $dt = new DateTime();
	  $dtz = new DateTimeZone($config['timezone']);
	  $offset = timezone_offset_get($dtz,$dt);
	  $symbol = ($offset < 0) ? '-' : '+';
	  $hrs = abs((int)($offset / 3600));
	  $mins = abs((int)($offset % 3600));
	  $p1[] = sprintf("time_zone = '%s%d:%02d'",$symbol,$hrs,$mins);
	}
	$dbinstance->Execute('SET '.implode(',',$p1));
	return $dbinstance;
}

CMSms prüft an dieser Stelle überhaupt nicht, ob es überhaupt etwas zu SETten gibt

Auswirkungen auf die Funktionalität der Spracheinstellungen hatte das bei mir allerdings keine. D.h. egal was ich eingestellt habe, das wurde dann auch angezeigt.*

Was passiert bei Dir, wenn Du set_names einfach mal auf true setzt?

Und was sagt nun Firefox bezüglich "Accept-Language"? Mich wundert dieses walisisch. Die Einstellungen aus der DB nicht laden zu können, ist die eine Sache, aber walisisch saugt sich CMSms ja nicht aus den Fingern. Schau doch mal in den Einstellungen des Firefox unter "Inhalt", was da an Sprachen eingestellt ist. Wenn ich dort walisisch hinzufüge und an erste Stelle setze, und zusätzlich keine Sprache in meinem Admin-Benutzerprofil eingestellt habe, dann habe ich im Backend auch walisisch. Allerdings kann ich die Sprache dann immer noch ändern.

PS:

Die Spracheinstellung für's Backend wird im Benutzerprofil geändert. Nicht in den globalen Einstellungen. Die Sprache in den globalen Einstellungen gelten - entgegen aller Vermutung - nicht global, sondern nur für's Frontend.

* Und noch ein kleiner Fehler im Backend: Wenn Du einfach nur auf "Absenden" klickst und keine Änderung siehst, dann die Seite einfach nochmal neu laden. Manchmal zeigt er sonst noch die vorherige Sprache an. (keine Ahnung woran das liegt)

1 Database eportieren als SQL
2 neue Database anlegen mit richtige Collation
3 importieren der Database

Wenn es dann noch Fehler gibt, dann steckt es in der Database

Dann suchen in exportierten SQL auf Strings die die falsche Locale setzen.

Viel Erfolg,
Jan

In der Datenbank wird default_cms_language für den jeweiligen User korrekt gesetzt, sobald ich die gewünschte Sprache in der GUI verändere. Hat nur keinerlei Wirkung.

Zeile 76 in adodb_functions wird gar nicht ausgeführt, weil set_names = false.  Der DB-Fehler muss also woanders herkommen.

Es sieht für mich inzwischen so aus, als wenn CMSMS versuchen würde, anhand des HTTP_USER_AGENT Strings des Browsers eine (falsche) Entscheidung über die Sprache zu treffen, anstatt über die Einstellung in der Management GUI.

Wie hier bereits beschrieben, nimmt CMSms dazu die Daten aus $_SERVER['HTTP_ACCEPT_LANGUAGE']. Ich hatte anfangs auch den Verdacht, dass da ein Fehler drin sein könnte und habe das mal ausprobiert. D.h. keine Sprache als Voreinstellung gespeichert bzw. mal den PHP-Code auseinandergenommen. Die Spracherkennung funktioniert i.d.R. eigentlich ganz gut. Bei mir war automatich alles auf deutsch.

Deshalb hatte ich hier ja gefragt, was denn Dein Firefox als Accept-Language-Header sendet. Ohne zu wissen was da bei Dir drin steht, kann ich mir leider absolut keinen Reim darauf machen, wieso um alles in der Welt ausgerechnet walisisch ausgewählt werden sollte. (Der Grund dafür, warum da nicht alles auf walisisch steht, ist der, dass die walisische Sprachdatei nicht vollständig ist und CMSms daher auf Englisch zurückgreift)

Abgesehen davon wäre es hilfreich, zu wissen, ob CMSms den Wert nicht korrekt speichern oder nicht korrekt laden kann. Dazu muss man einen Blick in die Datenbank werfen. Danach hatte ich bereits hier gefragt. phpMyAdmin o.ä. dürfte es doch für MariaDB geben. Oder?

Der SQL Syntax zum Laden/Speichern sieht am Ende z.B. so aus:

SELECT preference, value FROM cms_userprefs WHERE user_id = '1'
...
UPDATE cms_userprefs SET value = 'de_DE' WHERE user_id = '1' AND preference = 'default_cms_language'

An diesen zwei Zeilen sehe ich keinen Fehler.
Der Fehler muss also woanders (etwas früher in der Ausführung) liegen.

Du schriebst:

D.h. also der Fehler liegt in einer fehlenden schließenden Klammer.
Wenn ich mir den SQL-Syntax anschaue, der zwischen "Initialize Database" und "Done Initializing Database" steht, dann sehe ich da in der Datei /lib/adodb.functions.php in Zeile 76:

$p1[] = "NAMES 'utf8'";

Was am Ende so aussieht:

SET NAMES 'utf8'

Ich sehe da keine Klammer.
Kann es am fehlenden Semicolon am Ende liegen?

Firefox: GUI ist 80% Englisch, 20% Wallisisch, Sprachumschaltung wirkungslos
Edge: GUI ist 100% Englisch, Sprachumschaltung wirkungslos
IE11: GUI ist 100% Deutsch (!!), Sprachumschaltung wirkungslos
Browzar: GUI ist 100% Englisch, Sprachumschaltung wirkungslos

Langsam komme ich mir vor wie bei der versteckten Kamera, das kann doch alles nicht wahr sein!

Es sieht für mich inzwischen so aus, als wenn CMSMS versuchen würde, anhand des HTTP_USER_AGENT Strings des Browsers eine (falsche) Entscheidung über die Sprache zu treffen, anstatt über die Einstellung in der Management GUI. Gibt oder gab es dazu mal in irgend einer früheren Version Funktionen, die so etwas bewirkt haben können und jetzt der Sprachwahl in die Quere kommen?

Hast du evtl. "kurriose" FF-Plugins am laufen? Vllt. kannst du es ja testhalber mal mit einem frischen FF-Profil probieren (gibts einen ProfilManager dafür ).

Welchen Treiber hast du in der config zu stehen, mysql oder mysqli?

Da stand noch mysql drin. Habe es auf mysqli geändert, das ändert allerdings nichts, weder an der MSQL-Fehlermeldung noch an dem Sprach-Durcheinander. Trotzdem ein guter Hinweis, lasse es jetzt auf mysqli stehen.

Habe aber gerade übrigens noch etwas interessantes entdeckt: Eine zweite, ebenfalls akutelle CMSMS-Installation auf einem völlig anderen Server unter SLES11SP3, also mit Mysql 5.5.43 statt MariaDB - beide verhalten sich völlig identisch: Gleiches Sprachkauderwelsch im Admin-Frontend unter Firefox, gleiche Mysql-Fehlermeldung im Debug-Modus, aber sonst fehlerfrei.

Die beiden Installationen haben nichts miteinander zu tun, außer dass sie über die Jahre jeweils über viele Versionen hinweg jeweils upgedatet wurden. Gemeinsame Extensions sind: CMSMailer, CMSPrinting, FileManager, FormBrowser, FormBuilder, Gallery, MenuManager, MicroTiny, ModuleManager, News, Piwik, Search, ThemeManager, TinyMCE. Also nichts besonderes / exotisches.

Ein Datenbank-Crash oder korrupte Dateien kann ich jetzt wohl ausschließen, dieser Fehler hat System!

ich möchte nur proaktiv einen möglichen Fehler beheben, bevor er mir vielleicht (!) beim nächsten Update auf die Füße fällt.

Angesichts der Fehlermeldung kann dir niemand garantieren, dass deine Installation nicht auch noch an anderen Stellen unrund läuft.

Welchen Treiber hast du in der config zu stehen, mysql oder mysqli?

Naja, so exotisch ist MySQL ja nun auch wieder nicht, als dass sich dies nicht in die primäre Maschine einkompilieren ließe .

Ein neuer Layer dürfte aller Wahrscheinlichkeit bei CMSMS einem Fork sehr nahe kommen .

Schade ...

CMSMS läuft hier zusammen mit diversen anderen Webseiten und unterschiedlichen CMS-Systemen auf einem selbst betriebenen und gepflegten OpenSuse-Server im RZ und ich werde bestimmt nicht eine separate VM nur für CMSMS machen, die dann separat gepflegt werden muss.

Das mit der ADOdb-light-Problematik wusste ich noch nicht, das ist ja interessant. CMSMS auf einen anderen abstraction layer zu migrieren oder ADOdb-light für MariaDB zu fixen dürfte aber beides eine ziemliche Herausforderung sein. Leider reichen dazu weder meine freie Zeit noch meine Programmierkenntnisse aus, dabei mitzuhelfen. Sorry.

Trotzdem noch mal Danke an dieses Forum. Auch wenn es keine Lösung gab - eine so schnelle und konstruktive Kommunikation gibt es in anderen Foren nicht so oft. Hut ab!

Dass CMSMS nicht mit MariaDB laufen soll, kann ich kaum glauben.

Wird dir MariaDB irgendwo in der offiziellen Installationsprozedur angeboten?

Nein.

Wie lautet also deine Schlußfolgerung daraus ?

Hat einen relativ simplen Grund - der derzeit von CMSMS eingesetzte Datenbanklayer ADOdb light hat keinen Treiber für MariaDB, und aller Voraussicht nach wird es da auch keinen geben (weil out of support - seit 2005 keine echte Bewegung mehr in dem Projekt). Nicht mal für die ADOdb full gibt es einen ...

Und die Fehlermeldung

(mysql): SET 
Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1

ist IMHO ein Hinweis, dass MariaDB mit dem von CMSMS verwendeten, MySQL kompatiblen Syntax nicht klar kommt.

Wenn du so ein erfolgreicher Migrator bist, möchte ich dich hier nochmals herzlich willkommen heißen. Derartige Man Power haben wir bitter nötig. Wir freuen uns schon alle auf deine Anpassung von ADOdb light für MariaDB. Sag einfach, was du zur Unterstützung brauchst.

Ich wäre der letzte, der den daraus resultierenden Performance-Gewinn ausschlagen würde.

Hmm, so schnell wirfst du die Flinte ins Korn?

Zumindest solltest du alle Optionen ausschöpfen. Pack CMSMS auf eine unterstützte Datenbank und schau, was damit passiert.

Dass CMSMS nicht mit MariaDB laufen soll, kann ich kaum glauben. Dann wäre Ubuntu, Redhat, Suse, Centos, Fedora, Slackware und andere modernen Distributionen als Plattformen gestorben.

Als ob es kein MySQL für diese Plattformen gäbe ...
MySQL ist nunmal Vorraussetzung für CMSms.

MariaDB soll ja ein Fork von MySQL sein. Da würde mich mal der grundlegende Unterschied zwischen den beiden interessieren. Vor allem welcher SQL-Syntax in Deinem Fall Probleme bereitet und ob es da eine Möglichkeit gibt, das kompatibel zu machen.

Denn es sieht so aus, als könnte der Wert der Spracheinstellung aufgrund dieser Unterschiede nicht gespeichert/geladen werden, weshalb es auf die Sprache des Browsers zurückfällt. (anders kann ich mir sonst nicht erklären, warum es nicht en_US nimmt)

Schau doch mal mit dem Firefox Add-On Live HTTP Headers, was da an Header-Daten gesendet wird (speziell "Accept-Language").

Schau außerdem mal direkt in die Datenbank, was da in der Tabelle "user_prefs" für ein Wert bei "default_cms_language" gespeichert ist.

PS:
Aber selbst wenn das Sprachproblem behoben werden könnte, ich befürchte, dass es da noch mehr Schwierigkeiten geben wird.

Dass CMSMS nicht mit MariaDB laufen soll, kann ich kaum glauben. Dann wäre Ubuntu, Redhat, Suse, Centos, Fedora, Slackware und andere modernen Distributionen als Plattformen gestorben. Ich habe schon einige Applikationen erfolgreich zu MariaDB migriert, und CMSMS wäre die erste, die damit nicht zurecht käme.

Ich denke, ich gebe die Fehlersuche mangels aussichtsreicher Lösungsansätze auf. Vielen Dank jedenfalls für Eure Hilfe!