Hallo

ich kann Deine Frage nicht genau beantworten, dazu müsste man mal eine alte Version an den Start bringen und die locale-Variable auslesen und mit der gegenwärtigen vergleichen.

Gute Idee. Mache ich mal.

…

Daher würde ich denken, dass in der Sprachdatei ein

locale = 'de_DE@euro', 'de_DE', 'de'

ausreichen müsste (ggf. muss man das irgendwie gruppieren in Smarty).

Das was du hier zeigst, ist doch eine in einer Zeile zusammengefasste Angabe in den Sprachdateien, oder? Die PHP-Funktion set_locale nimmt mehrere Parameter mit möglichen Angaben oder ein Array von Angaben entgegen. Das momentan in MLF2 benutzte Schema, mehrere locale-Angaben in jeweils eigenen Zeilen zu notieren, funktioniert, wenn ich die Smarty-Doku zu config_overwrite nicht missinterpretiere, nur, wenn config_overwrite den Wert false hat. Dann wird aus mehreren gleichnamigen Werten ein Array gebildet, wohingegen mit true ein später notierter Wert vorige Werte überschreibt.

Wegen der von magma gefundenen Doppelverwendung von Schlüsseln haben wir das gerade eben für die 2.3.7 auf true umgestellt, was, ohne das bisher getestet zu haben, den Fehler ausgelöst haben könnte.

Tschö, Auge

hallo,
ich bin überrascht, welche Aktivität meine "Laienfrage" hier angestossen hat.
war die Tage ein bisschen mehr offline beschäftigt, deshalb jetzt erst die Antwort auf Eure Fragen:

Bei den Updateschritten (meines aktiven Forums) von 2.3.4 auf 2.3.5 zu meiner aktuellen 2.3.7 hab ich leider gar nicht ins Frontend geschaut, sondern war nur damit beschäftigt, dass das Update funktioniert.

müsste man mal eine alte Version an den Start bringen und die locale-Variable auslesen und mit der gegenwärtigen vergleichen.

Hier liegt noch ne alte 2.3.4 rum, die stillgelegt ist.
In der http://hoefer-bayern.de/forum/lang/german.lang steht in Zeile 7 - 14:

[default]
language =                        de
charset =                         utf-8
locale =                          de_DE.utf8
locale =                          de_DE
locale =                          de_DE@euro
locale =                          de
locale_charset =                  utf-8
dir =                             ltr

Damit hat das noch gepasst mit DE und deutschen Wochentagen.
Die aktuelle 2.3.7 hatten wir dieser Tage ja schon gelesen

Cu u

Hallo

ich habe nun ein wenig rumprobiert und die einzig sinnvolle Lösung scheint ein Zerlegen der Zeichenkette zu sein.

locale = de_DE.utf8, de_DE, de_DE@euro, de

Das ist die zusammengefasste Zeile aller locale-Angaben, wenn ich das recht verstehe?

und im Quellcode dann ein simples:

setlocale(LC_ALL, preg_split("/[\s,]+/", $lang['locale'], null, PREG_SPLIT_NO_EMPTY));

Sieht schick aus.

Das wird auch nicht unperformanter sein, also über das Array in Smarty.

Wenn uns das config_overwrite = true nicht noch in anderen, selten auftretenden Fällen um die Ohren fliegt, können wir es dabei belassen. Falls sich aber noch weitere solche Störungen finden, ist es mMn nicht sinnvoll, ein um's andere Mal mit solchen Lösungen nachzusteuern. Die Rückumstellung auf config_overwrite = false und das umbenennen einzelner Schlüssel in den Sprachdateien ist dann, als einmaliger Arbeitsaufwand, besser und abschließend zu handeln, als das warten auf den nächsten Fall von "geht nicht mehr" (mMn).

Tschö, Auge

Hi,

locale = de_DE.utf8, de_DE, de_DE@euro, de

und im Quellcode dann ein simples:

setlocale(LC_ALL, preg_split("/[\s,]+/", $lang['locale'], null, PREG_SPLIT_NO_EMPTY));

Das funktioniert (bei mir?!) aber nicht, da steht es immer noch in english.
Geändert in admin.inc.php 2 x in contact.inc.php und 2 x posting.inc.php

Hallo Milo

ich habe nun ein wenig rumprobiert und die einzig sinnvolle Lösung scheint ein Zerlegen der Zeichenkette zu sein.

Das wird auch nicht unperformanter sein, also über das Array in Smarty.

Zu dieser Sache haben wir ja bisher nur Rückmeldungen des deutschsprachigen Publikums bekommen. Bemerkenswert – im wörtlichst vorstellbaren Sinne des Wortes – ist aber, dass es keinerlei Fehlermeldungen von anderen Stellen, an denen ein vergleichbarer Fehler auftritt, gibt.

Das wiederum lässt meine Befürchtung, wir hätten uns weitere, bisher verdeckte Folgefehler eingehandelt, unwahrscheinlicher erscheinen. Davon ausgehend habe ich kein Problem damit, die Regex-Lösung in den offiziellen Code zu übernehmen.

Tschö, Auge