Mehrsprachigkeit von Dateien

    • Official Post

    Die neue Lösung, die analog zu anderen Mehrsprachigen Inhalten in der Suite (Ausnahme Forum) funktioniert, könnte auch die ganzen anderen Fälle ohne unsaubere Hacks umsetzen.

    Das Forum ist hier nicht die Ausnahme sondern bei den Apps die Regel. Alle WoltLab-Apps verhalten sich in Hinblick auf die Mehrsprachigkeits-Funktion aktuell identisch. Nur CMS-Seiten und CMS-Artikel (also der Core) verhalten sich aktuell anders. Tendenziell ist auch angedacht die Variante von den CMS-Artikeln zukünftig auch für die Dateien in der Filebase anzubieten, weil es da am ehesten Sinn machen könnte. Das wäre dann allerdings ein größerer Umbau der Filebase, der mit Abwärtskompatibilität brechen würde.


    Warum genau setzt ihr dann hier die eurer und meiner Meinung nach ungeeignetste Software genau so ein mit diesem lustigen Sprachen-BBCode-Zeug?

    Die in der Filebase aktuell integrierte Mehrsprachigkeits-Funktion ist für den Plugin-Store in der Tat nicht geeignet und deshalb konsequenterweise dort auch deaktiviert. Ich weiß nicht, warum deshalb gleich die ganze Software "ungeeignet" sein soll. Abgesehen von individuell angepasster Software habe ich bisher selten komplexe Software gesehen, die perfekt auf einen bestimmten Anwendungsfall zugeschnitten ist. In der Praxis muss man immer Kompromisse eingehen.


    Die selbst gebaute Lösung für die aktuelle Mehrsprachigkeit im Plugin-Store ist sicherlich nicht die elegante und sauberste Lösung, funktioniert im Großen und Ganzen aber seit Jahren im Plugin-Store ziemlich gut. Wir sehen dort aktuell keinen akuten Handlungsbedarf. Langfristig (mit der nächsten größeren Überarbeitung der Filebase) ist aber auch hier eine Änderung angedacht.

  • Meine bescheidene Anmerkung wäre:

    Dann brecht, was gebrochen werden MUSS.


    Nachtrag: Als ich das gestern las, war ich enttäuscht. denn ich habe seit fast einem Jahr auf die neue Suite gewartet, ganz besonders auf die Filebase, weil ich dachte ihr meint die ganze Zeit mit Mehrsprachigkeit für Dateien genau diese Umsetzung, also so wie im CMS, oder VieCode.

    Heisst im Umkehrschluss: Noch n Jahr warten? ...bitte nicht...;(

  • Marcel Werk ungeeignet bezog sich auf den expliziten Anwendungsfall hier. Und dafür ist die aktuelle Umsetzung ungeeignet - zumindest lese ich das aus euren Beiträgen so heraus. Von allgemein war nie die Rede. ;)

  • Mehrsprachigkeit bei Einträgen, ähnlich wie bei den regulären Artikeln in der Suite

    Lustigerweise werden die Artikel ja immer alle ausgespielt... :D Also das heißt: Gibt es einen Artikel nur auf Deutsch und eben keine englische Version, wird dem Engländer, der die Seite auf Englisch eingestellt hat und auch den Inhalts-Haken nur bei Englisch gesetzt hat eben einfach der deutsche Artikel angezeigt... Also gerade da, wo es wirklich Sinn machen würde, ist es auch irgendwie nicht gut umgesetzt...

  • einfach der deutsche Artikel angezeigt

    Weiss nicht, ob ich dich richtig verstanden habe, aber ich finde die automatische Inhaltsduplizierung der CMS-Artikel bei WoltLab grade super umgesetzt. Damit meine ich folgendes:

    Du hast z.B. 3 Sprachen, erstellst einen Artikel in deutsch, ohne englisch und die 3 Sprache zu konfigurieren, dann wird der deutsche Inhalt (z.B. Beschreibung) automatisch in die 2. (englisch) und 3. Sprache dupliziert.

    Man kann dann sofort, oder auch später, die Texte nachträglich bearbeiten und übersetzen. Dadurch ist jedoch gewährleistet, daß überhaupt ein Inhalt in jeder Sprache vorhanden ist.

    Dem Engländer aus deinem Beispiel FSAviator , wird dann also nicht wirklich die deutsche Version angezeigt, sondern die englische, aber mit dem duplizierten deutschen Inhalt. Das ist ein kleiner, aber feiner Unterschied. Denn, sobald Du den Inhalt der englischen Version bearbeitest/austauschst/übersetzt, ist er natürlich auch so verfügbar wie es sein sollte.

    Mit anderen Worten, Du bekommst schon die englische Version zu sehen, nur eben mit dem kopierten Inhalt aus der deutschen Version.

    Jedenfalls finde ich es von der Umsetzungs-Logik folgerichtig, auch wenn es uns als Betrachter sinnlos oder falsch vorkommt, was es nicht ist.

  • funktioniert im Großen und Ganzen aber seit Jahren im Plugin-Store ziemlich gut

    Die Aussage verwundert mich etwas. Mit fast 50 Plugins darf ich von mir behaupten den Plugin-Store überdurchschnittlich zu benutzen und ich bin der Meinung, dass es seit Jahren ziemlich schlecht funktioniert. Die Lösung ist fummelig und unprofessionell und ich kenne keinen Entwickler, der behaupten würde, dass die Lösung "gut funktioniert".


    Für den Endkunden sicherlich, da er sich damit auch nicht rumärgern muss, aber geht es nicht auch darum es Drittanbietern so attraktiv wie möglich zu gestalten für WoltLab zu entwickeln? Sollte es zumindest, denn ohne den gut gefüllten Store würde die Konkurrenz auf einmal viel attraktiver aussehen.


    Auch ich ärgere mich etwas über meinen Kauf der Filebase-Lizenz, da es wohl absehbar ist, dass die Lösung für mich die falsche ist. (Ganz klar mein Fehler, da ich die Demo vorher nicht genau genug getestet habe. Dennoch ärgerlich.)

  • Wenn ich dich richtig verstanden habe, hast du eigentlich sprach-neutrale Dateien, die mehrsprachig mit Beschreibungstext versehen werden sollen. Die Mehrsprachigkeits-Funktion in der Filebase ist in ihrer aktuellen Form aber für Dateien gedacht, wo bereits die Datei selber eindeutig einer bestimmten Sprache zugeordnet werden kann.


    Die Dateien sind doch irrelevant, wenn sie selbst bereits mehrsprachig sind oder gar nicht Sprachabhängig sind. Dann spielt nur die Beschreibung eine Rolle, so dass der Endnutzer überhaupt versteht, für was der Download ist und inwieweit es für ihn einen Mehrwert darstellt. Genau diesen Fall haben wir in überwiegender Nutzung vorliegen.

    Als Entwickler sollte man sich doch schon im Vorfeld Gedanken machen, was diejenigen, die es einsetzen würden, für Anwendungszwecke haben. Hier wurde ganz klar am Ziel vorbeigeschossen. Obendrein ist es nicht mal für eure eigenen Anwendungszwecke perfekt:


    Die [...] Mehrsprachigkeits-Funktion ist für den Plugin-Store [...] nicht geeignet und deshalb konsequenterweise [...] deaktiviert. Ich weiß nicht, warum deshalb gleich die ganze Software "ungeeignet" sein soll. Abgesehen von individuell angepasster Software habe ich bisher selten komplexe Software gesehen, die perfekt auf einen bestimmten Anwendungsfall zugeschnitten ist. In der Praxis muss man immer Kompromisse eingehen.


    Ein Entwickler programmiert also sowohl für sich selbst (Eigennutzen), als auch nebenbei zum Verkauf, ein Produkt (wo wir bei "individuell" angelangt wären), was für den eigenen Gebrauch aber auch nur bedingt geeignet ist und wo selbst "Kompromisse" eingegangen werden müssen?
    Jetzt hast du mich aber zum Lachen gebracht...



    Meine bescheidene Anmerkung wäre:

    Dann brecht, was gebrochen werden MUSS.


    Genau meine Meinung! Die User haben es oft genug verlangt und entwicklerseitig wird, wie dem Verlauf entnommen werden kann, nur mit Ignoranz entgegnet.



    Nachtrag: Als ich das gestern las, war ich enttäuscht. denn ich habe seit fast einem Jahr auf die neue Suite gewartet, ganz besonders auf die Filebase, weil ich dachte ihr meint die ganze Zeit mit Mehrsprachigkeit für Dateien genau diese Umsetzung, also so wie im CMS, oder VieCode.

    Heisst im Umkehrschluss: Noch n Jahr warten? ...bitte nicht...;(


    Die Filebase wird leider enorm vernachlässigt und irgendwie passiert rein gar nichts...

    Ich denke, das belegt meine Aussage hinreichend.

    • Official Post

    Anbei ein Bild des aktuellen Entwicklungsstands der mehrsprachigen Dateien von Version 5.3. Die Texte können - wie man es von z.B. CMS-Artikeln kennt - über entsprechende Tabs bequem mehrsprachig hinterlegt werden. In der Datenbank werden die Texte über eine separate Tabelle verwaltet, wodurch dann auch die bisherigen Sprach-BBCodes aus dem Plugin-Store überflüssig werden.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!