Mehrsprachigkeit der Eingabemaske im Backend

klauswagner commented 10 years ago

Folgendes Vorgehen: Ich lege in meinem mehrsprachigen (Deutsch, Französisch, Englisch) MetaModel "Produkte" eine Eingabemaske "BE Produkt Erfassung" an. In den Einstellungen zur Eingabemaske ist "Übersetzung" aktiviert und die entsprechenden Sprachen sind angelegt. Als Fallback-Sprache ist "Englisch" ausgewählt. In den Einstellungen der einzelnen Attribute des MetaModels "Produkte" sind alle Übersetzungen eingetragen:

Problem: Wenn ich nun in die Eingabemaske wechsle (in diesem Fall BE-Bereich "Inhalte" > "Produkte") und einen neuen Datensatz anlege, werden die Labels und Erklärungen der definierten Eingabefelder auf englisch angezeigt. Das passiert unabhängig davon, welche Sprache ich für diesen Datensatz gerade bearbeite (Sprachauswahl oben rechts). Und unabhängig davon welche Standardsprache im Browser eingestellt ist, bzw. welche Sprache für das Contao-Backend eingestellt wurde. Die Ausgabe der Labels und Erklärungen bezieht sich immer auf die festgelegte Fallback-Sprache. Ändere ich die Fallback-Sprache auf "deutsch", werden die Labels auf deutsch angezeigt...

Wenn ich nun den Fall habe, dass mehrere Personen aus unterschiedlichen Ländern auf der Welt die Produkte pflegen, bekommt eine Person aus China die Labels auf deutsch angezeigt und kann damit dann wenig anfangen. Wäre es da nicht sinnvoll, bei der Ausgabe der Labels zu prüfen, welche Contao-Backend-Sprache der Benutzer momentan eingestellt hat und wenn diese Sprache bei den Attributs-Namen und den Attributs-Beschreibungen eingetragen ist, diese auszugeben. Falls die Sprache nicht vorhanden ist, kann man dann die Fallback-Sprache nutzen.

discordier commented 10 years ago

Diese Pryfung findet in der Tat statt. Du hast jedoch nun de_DE als Spache gewaehlt, bis dato haben MetaModels jedoch nur 2-char language codes verstanden (da dies in Contao auch bislang so war). Die Aenderung auf die langen language codes hatte bislang noch keiner beantragt und beauftragt und ich persoenlich brauchte sie bislang auch noch nicht, daher ist sie nicht enthalten.

Es steht dir frei einen PR zu stellen, oder aber du musst leider abwarten bis wir dazu kommen es zu implementieren. :(

andreasisaak commented 10 years ago

Oder du platzierst es als 3te Alternative als Auftrag bei @discordier

discordier commented 10 years ago

Das ist logischerweise auch moeglich.

tim-bec commented 10 years ago

Wir könnten (finanzielle) Unterstützung bei der Realisierung dieses Features gebrauchen. Hätte @Wagnerwagner vielleicht Interesse sich daran zu beteiligen?

klauswagner commented 10 years ago

@tim-bec: Und zu welcher Fundraising-Kategorie gehört das dann? Dann kläre ich das mal ab. Die "Contao 3 Kompatibilität" ist ja eigentlich schon komplett.

tim-bec commented 10 years ago

@Wagnerwagner zu keiner, die Akzentsprachen sind ein neues Feature. Das "Contao 3 Kompatibilität" war ein Fundraising für genau das: Kompatibilät von MM zu CTO3 herstellen.

Wir haben grad ein wenig über das Feature diskutiert und sind noch auf ein paar offene Fragen gestoßen:

Wir müssen den Fallback erweitern, denn mit der aktuellen Umsetzung würde ein Nutzer der mit de_at ankommt, aber de_at nicht vorhanden ist auf die Fallbacksprache landen, wäre dies en würde er darauf landen, auch wenn devorhanden ist...
Was würde passieren wenn de_de gesetzt ist, aber ein Nutzer mit deankommt? "Hochskalieren" auf de? Das "Upscaling" müssten wir also auch noch integrieren

klauswagner commented 10 years ago

Ich möchte das Thema nochmal aufgreifen.

@tim-bec:

Es bestände ja weiterhin noch die Möglichkeit in der Eingabemaske manuell eine andere gewünschte Sprache per Sprachauswahl-Dropdown oben rechts auszuwählen. In diesem Fall wäre es aber auch sinnvoll erst zu prüfen ob die Hauptsprache (in deinem Beispiel de) verfügbar ist, wenn die Akzentsprache (in deinem Beispiel de_at) nicht vorhanden wäre, statt direkt die Fallbacksprache anzuzeigen.
Das Thema "Upscaling" ist schwierig. Wenn ein Nutzer mit de ankommt, diesen auf de_de zu leiten, wäre eine Annahme, die im Beispiel deutsche Sprachen nur zu einem Drittel korrekt wäre. Denn wenn ein Österreicher nur mit de ankommt, landet er auf de_de statt auf de_at. Vielleicht könnte man sich das "Upscaling" sparen und gibt den "Redakteuren" in der Eingabemaske (Beispiel oben "Inhalte" -> "Produkte") einfach per Infozeile den Hinweis, dass zur aktuellen Sprache weitere Akzentsprachen vorhanden sind und dass man mit der richtigen Browsereinstellung zukünftig direkt auf der "richtigen" Sprache landet.

Der Login ins Contao-Backend kennt übrigens keine Akzentsprachen. Ohne Blick in den Code: Die Spracheinstellungen kommen also definitiv aus den Browsereinstellungen. backend_login

Hat sich nun schon jemand der Implementierung angenommen? Ich traue mich nur nicht an den Code um hier einen PR zu stellen. Aber sonst können wir gerne weitere Unterstützung leisten! Ich persönlich halte dieses Thema für sehr wichtig, da sonst die ganze Mehrsprachigkeit so nicht funktioniert. Wie man einen Auftrag (wie vorgeschlagen an @discordier ) plaziert, hab ich leider noch nicht herrausgefunden ;-)

discordier commented 10 years ago

Der login kennt auch nur die "installierten Sprachen" welche als Ybersetzungsdateien vorliegen.

Da jedoch alle Werte in MetaModels potentiell ja schlussendlich eine eigene "Ybersetzung" (wenngleich mit Akzent oder nicht) darstellen, kann man bei der Sprachauswahl dann alle auswaehlen. Dass hier aktuell alle angezeigt werden, das ist so lange ein Bug, bis dieses Feature implementiert ist.

Hinsichtlich Auftrag, den kannst du jederzeit an info@cyberspectrum.de richten, doch vorher sollten wir hier definieren wie dieses Feature nun umgesetzt werden soll, und dies logischerweise so, dass moeglichst viele was davon haben. ;)

klauswagner commented 10 years ago

Ich teste gerade wieder etwas rum um die Sache noch besser spezifizieren zu können...

@discordier : Du hast jedoch nun de_DE als Spache gewaehlt, bis dato haben MetaModels jedoch nur 2-char language codes verstanden (da dies in Contao auch bislang so war).

Ich habe bisher nur ans Backend gedacht. Alle Übersetzungen werden ja aber auch im Frontend angezeigt. ~~Dort habe ich eine Listenausgabe inkl. Labels. Für die Attribute habe ich Übersetzungen in en (ohne Akzentsprache) und de_de angelegt. de_de ist Fallback-Sprache. Aufruf des Frontend im Firefox: im FF ist nur "en" als Sprache eingetragen und auch im Header der GET-Anfrage steht korrekt "Accept-Language: 'en'". Ausgeliefert werden die Labels aber in deutsch. Stelle ich en als Fallback-Sprache ein, erscheinen die Labels auf englisch. Also scheint auch die Erkennung der 2-char-language momentan nicht richtig zu funktionieren.~~ Edit: Bedienungsfehler.

Checkbox Fallback-Sprache: die Checkbox ist etwas unpraktisch, da es ja eigentlich nur eine Fallback-Sprache geben sollte. Momentan ist es möglich mehrere Fallback-Sprachen zu aktivieren ohne dass ein Hinweis erscheint. Angezeigt wird dann immer die Sprache, die in der Sortierung weiter oben sitzt. Da wäre doch eigentlich ein Radio-Button sinniger. Oder wenn anders nicht möglich, ein Hinweis dass mehrere Fallback-Sprachen ausgewählt wurden.

Zu meinem Kommentar vom 18. September:

Es bestünde ja weiterhin noch die Möglichkeit in der Eingabemaske manuell eine andere gewünschte Sprache per Sprachauswahl-Dropdown oben rechts auszuwählen.

Da habe ich leider auch nicht ans Frontend gedacht. D.h. dort gibt es keine Möglichkeit die Sprache nachträglich zu ändern, wodurch mein Vorschlag eigentlich hinfällig ist.

Deshalb nun der Gedanke: Hauptsprache (2-char) zwingend erforderlich machen um Akzentsprachen anlegen zu können? Dann wäre wenigstens ein Fallback innerhalb der Sprachregion vorhanden, falls ein Benutzer ohne Akzentsprache ankommt. Der Vorschlag "Upscaling" von @tim-bec ist somit auch unbedingt erforderlich.

~~Wie ist das eigentlich, wenn ich eine mehrsprachige Webseite aufbaue, die teils aus MetaModels und teils aus Contao-Core besteht, z.B. mit Sprachcode in der URL? Wenn ein User mit Browsersprache /en/ im /de/-Zweig ist, und eine Seite mit einer MM-Frontendausgabe aufruft, bekommt dieser User ja alle Inhalte auf deutsch, bis auf die darin integrierte MM-Frontendausgabe. Diese wird dann wieder anhand der Browsersprache, also auf en ausgegeben. Oder kann man das mit einem Filter festlegen?~~

Kreativsoehne commented 7 years ago

Wir stehen hier vor einem ähnlichen Problem:

Es gibt eine Seite mit zwei Inhaltszweigen für Deutschland und die Schweiz. Die Sprache ist jeweils deutsch, aber je nach gewählter Domain springt Contao auf den jeweiligen Inhaltsteil; .de landet im Zweig de_de, .ch in de_ch. Alle Inhalte, die von MetaModels stammen, sind in deutscher Sprache hinterlegt, sind aber pro Land unterschiedlich. Surft man die Website nun auf der .ch-Domain an, dann kommen auf den Seiten, auf denen Inhalte aus den MetaModels gezeigt werden sollen, keine Inhalte mit der Meldung, dass nichts gefunden wurde ("Ihre Suche lieferte keine passenden Ergebnisse.")

Offenbar ist dieses Problem ebenfalls auf das hier diskutierte Thema zurück zu führen.

Hat sich da etwas getan? Gibt es vielleicht einen Workaround?

zonky2 commented 7 years ago

nein, da hat sich nichts getan bzw. es wurde "hart" auf zwei Zeichen begrenzt

...und wie schon im Forum zu Deiner Anfrage geschrieben, ist das Posting https://github.com/MetaModels/core/issues/420#issuecomment-44397988 der "letzte Stand", d.h. selbst programmieren und PR einreichen oder programmieren lassen...

zonky2 commented 2 years ago

Das Feature ist auf der Seite von MM (2.2) eingebaut - aktuell gibt es Probleme bei Contao :( siehe https://github.com/MetaModels/core/issues/1458#issuecomment-1014833571

zonky2 commented 2 years ago

Fixed in MM 2.2 - see https://github.com/MetaModels/core/issues/1458

MetaModels / core

Mehrsprachigkeit der Eingabemaske im Backend #420