CMSimple_XH–Forum

Wie bringe ich dem System bei, auch in einer Zweitsprache Backend, Plugins (Administration) usw. auch deutsch anzuzeigen, also immer die de.php zu verwenden (sofern die Plugins diese auch mit ausliefern). Geht das global?

Die Einstellung in der Konfiguration > Sprache > Voreinstellung, wirkt ja nicht in Zweitsprachen, das wäre auch nicht wünschenswert. Wir bräuchten so eine Option auch in der Sprach-Datei (Languages).

Eine Möglichkeit:
Man löscht oder bennent um cmsimple/languages/en.php, kopiert de.php und gibt ihr den Namen en.php, das wirkt sich aber nicht auf Konfiguration und Sprach-Datei aus (nur teilweise) . Und bei manchen Plugins müsste man auch so vorgehen.

Da war ich auch schon mal dran.
Ich habe dazumal keine zufriedenstellende Lösung gefunden.

Mein Ansatz war im Template auf admin abzufragen und wenn, dann $sl auf de zu setzen.
Das hat aber Probleme mit sich gebracht. Kann ich gar nicht mehr genau sagen, welche.
Eines wäre z.B., dass man die Sprachdateien anderer Sprachen nicht mehr bearbeiten könnte.

Aber ab 1.7.0 sollte das ja eh gar nicht mehr funktionieren, denke ich.

Es bleibt der lange, mühsame Weg, das Anpassen der Sprachdateien.
Nur DE kopieren kann auch ins Auge gehen. Nicht alles ist nur immer fürs Backend gedacht.

lck wrote:Wie bringe ich dem System bei, auch in einer Zweitsprache Backend, Plugins (Administration) usw. auch deutsch anzuzeigen, also immer die de.php zu verwenden (sofern die Plugins diese auch mit ausliefern). Geht das global?

Das ist eigentlich nicht vorgesehen, weil davon ausgegangen wird, dass der Admin einer Zweitsprache diese auch gut spricht.

lck wrote:Die Einstellung in der Konfiguration > Sprache > Voreinstellung, wirkt ja nicht in Zweitsprachen, das wäre auch nicht wünschenswert. Wir bräuchten so eine Option auch in der Sprach-Datei (Languages).

Das erscheint mir nicht notwendig; wenn dann ließe sich das auch über eine Konfigurationsvariable steuern (etwa use_default_language_in_backend).

Allerdings müsste dann in cms.php umgebaut werden; derzeit ist es so:

1. ermittle $sl (die per URL gewählte Sprache)
2. lade passende Core-Sprachdatei
3. prüfe ob als Admin eingeloggt

(3) müsste aber im Zweifel vor (2) erfolgen. Das dürfte aber ein paar Probleme verursachen.

Als Workaround wäre es vielleicht denkbar, die Reihenfolge beizubehalten, aber falls der User ein Admin ist, und $sl ungleich der konfigurierten Standardsprache ist, zurück zu springen; siehe https://gist.github.com/cmb69/7f89430c5 ... 3c3d83d2ee.

olape wrote:Mein Ansatz war im Template auf admin abzufragen und wenn, dann $sl auf de zu setzen.
Das hat aber Probleme mit sich gebracht. Kann ich gar nicht mehr genau sagen, welche.

Das im Template abzufangen, ist zu spät. So mancher Request erreicht das Template nie, und zumindest kann auch vorher schon HTML generiert worden sein, das dann die "falsche" Sprache enthält.

olape wrote:Eines wäre z.B., dass man die Sprachdateien anderer Sprachen nicht mehr bearbeiten könnte.

Stimmt. Das ginge auch mit meinem Hack von weiter oben nicht – und der funktioniert sowieso nicht, denn wenn $sl zu früh geändert wird, dann wird ja auch die falsche content.htm gelesen etc. Eigentlich dürfte man $sl überhaupt nicht manipulieren, da manche Plugins es nutzen, um die gewünschten Inhalte zu laden (z.B. Calendar). Lädt man aber nur die Sprachdateien, und belässt $sl, dann gibt es auch wieder Probleme, weil manche Plugins eben weitere Lokalisierungen gemäß $sl laden (z.B. JavaScript).

olape wrote:Es bleibt der lange, mühsame Weg, das Anpassen der Sprachdateien.
Nur DE kopieren kann auch ins Auge gehen. Nicht alles ist nur immer fürs Backend gedacht.

Man kann sich diese Arbeit vermutlich etwas einfacher machen, wenn man alle default.php mit den Inhalten von de.php ersetzt, und dann in den anderen Sprachdateien alle Sprachtexte entfernt, die nur für das Backend relevant sind.

Ich bin auch der Meinung, dass die Backendsprache nicht unbedingt gleich der Zweitsprache sein soll.
Vor Urzeiten - als grad unicode eingeführt wurde - habe habe ich mal eine englische Touristenseite mit Zweitsprache japanisch gemacht. Soweit ich mich erinnere, haben wir einfach das japanische language file mit englischen Werten gefüllt. Das war wohl nicht nicht ganz perfekt, aber es hat getan.

manu wrote:Ich bin auch der Meinung, dass die Backendsprache nicht unbedingt gleich der Zweitsprache sein soll.

Okay, aber wie soll das technisch gelöst werden? Im Prinzip bräuchte man dafür wohl zwei "Variablen" – eine, die die Sprache der Inhalte, und eine andere, die die Sprache der Sprachtexte angibt. Und dann müssten eventuell noch Grenzfälle besonders (z.B. template_text) gehandhabt werden. Ideen?

cmb wrote:Ideen?

Leider keine Idee.
Aber, ich könnte mich Manus Argumentation anschließen.
Allerdings sollte das optional sein, da es ja auch unterschiedliche Admins (für englisch und japanisch) geben könnte.

cmb wrote: Okay, aber wie soll das technisch gelöst werden? Im Prinzip bräuchte man dafür wohl zwei "Variablen" – eine, die die Sprache der Inhalte, und eine andere, die die Sprache der Sprachtexte angibt. Und dann müssten eventuell noch Grenzfälle besonders (z.B. template_text) gehandhabt werden. Ideen?

Hm, es wird nur über zwei getrennte Variablen funktionieren.
Eine mögliche Lösung für Templatetexte hatte ich dir vor wenigen Tagen per PN gesendet. Die sollte doch funktionieren. Oder?

cmb wrote:Ideen?

IMHO braucht es keine teschnische Lösung. Die pragmatische Anpassung des language files reicht völlig. Mir gehts nur drum, den grundsätzlichen Ansatz im Auge zu behalten. Die Zweitsprache ist nicht zwingenderweise die Backend Sprache. Wenn ich auf meinem Textsystem einen französischen Brief schreibe, lade ich mir nicht das französische Textsystem. Evtl. ein französisches keyboard aber das wars schon.