Mehrsprachigkeit von Dateien

  • Hallo zusammen,


    ich schlage vor, dass die Dateien der Filebase bei der Mehrsprachigkeit eher dem Vorbild des ACP (direkt bei der Erstellung mehrere Texte in versch. Sprachen anlegen ohne Dateien doppelt pflegen zu müssen) folgen sollten, und nicht der von Forenthemen.


    Mir ist bewusst, dass dieser Vorschlag bereits im letzten Jahr abgelehnt wurde. Ich denke aber, dass WoltLab auch im eigenen Plugin-Store, welcher auf der Filebase basiert, einsehen musste, dass das Konzept der Mehrsprachigkeit hier sehr schlecht umgesetzt ist. Denn dort werden mehrsprachige Dateien nur mit einem sehr unschönen Hack, der nicht zum Rest des Systems passt umgesetzt.


    Auch wenn das Beispiel des Plugin-Stores bereits ausreicht um zu zeigen, dass das aktuelle Konzept nicht funktioniert, möchte ich an dieser Stelle noch Netzwerg zitieren, der das in einem anderen Thread bereits perfekt zusammengefasst hat.

    Bei bestimmten Dingen wie z.B. Foren-Threads ergibt es ja durchaus Sinn, diese einer Sprache zuzuordnen und nicht mehrsprachig zu machen. Da steht Kommunikation im Vordergrund. Bei der Filebase steht aber der Austausch von Dateien im Vordergrund. Titel/Beschreibung etc. sind nur "Beiwerk". Dieses Beiwerk sollte dann auch mehrsprachig gestaltbar sein.


    Der Datei ist es total egal, in welcher Sprache ihre Beschreibung angezeigt wird. Fürs Downloaden ist das auch egal. Aber wenn man für jede Sprache die Datei neu hochladen muss, dann stimmt etwas nicht. Man muss auf einmal mehrere Einträge pflegen, Download-zahlen sind auf mehrere Dateien verteilt etc. pp.

    Das ist aktuell ein sehr nerviger Zustand, weswegen ich die Filebase in einem internationalen Projekt leider nicht so nutzen kann, wie ich gehofft habe. Das geht sicherlich auch anderen so, daher freue ich mich auf Unterstützung aus der Community und hoffe auf eine Umsetzung durch WoltLab Marcel Werk  Alexander Ebert


    Beste Grüße,

    Daniel

  • Hi Darkwood,

    Du hast genau das geschrieben was ich ganze letzte Zeit mit mir herumtrage. Bei mir sind nur 15 (real 45) Dateien in der Base. Durch die fehlende Sprachunterstützung, die man aus Gründen der Auffindbarkeit aber unbedingt braucht (vereinfacht gesagt SEO) kommen bei 3. Sprachen 45 Downloads zusammen. Jede Datei 3 mal hochladen und in jeder Sprache beschriften.

    Die Pflege ist mühsam.

    Unterstütze deinen Vorschlag absolut.:thumbup:

  • Ich stehe im Moment genauso ratlos davor.

    Seit Stunden fage ich mich wie ich die Dateien mehrsprachig anbieten kann, wenn mir beim Datei-Upload nur Deutsch als Auswahl angeboten wird?????



    EDIT

    Ich habe lange gebraucht, bis ich dahintergestiegen bin, dass der Button "Mehrsprachigkeit von Dateien aktivieren" im ACP der Filebase wohl als (schlechter) Witz gedacht ist.


    Die Seitennavigation erscheint ja sowieso in der ausgewählten Sprache und die Dateibeschreibung kann man dann auch mit der Einstellung "DEUTSCH" gleich mehrsprachig anlegen. Dann im ACP die Auswahl "Mehrsprachigkeit von Dateien aktivieren" auf "NEIN" setzen und dann werden die Downloads auch in allen Sprachversionen angezeigt.


    Was also soll dann also der Auswahl-Button im ACP????

  • Also dieses Feature wäre denke ich wirklich langsam mal wirklich nötig :) Selbst hier im Pluginstore geht das ja mit [de]Deutsch[/de][en]English[/en]...

  • Ich würd's ja selber umsetzen, aber ich habe den Code ja nicht. Die Hoffnung darauf, dass hier eine Verbesserung stattfindet, habe ich verloren. :D

    Meinst Du den Code, wie es in der Filebase integriert ist? Wenn ja, schreibe einfach eine Mail an woltlab@woltlab.com und frage danach. Nach der Lösung wurde mal gefragt und Marcel Werk hat uns den nach Anfrage per Mail zukommen lassen.

  • Schreib uns eine E-Mail an woltlab@woltlab.com, dann stellen wir dir den Code dafür zur Verfügung.

    Nur der Vollständigkeit halber - ich habe den Code erhalten, geprüft und mich dazu entschieden diesen nicht zu verwenden. Die Umsetzung ist sehr "hacky" und einer professionellen Software unwürdig. Bis es keine ordentliche Lösung gibt, kann ich meinen eigenen Store leider nicht mehrsprachig anbieten.


    Ich möchte den Vorschlag also auch nochmal aus der Versenkung holen. Marcel Werk Könnt ihr das Thema bitte nochmal diskutieren? Das ist sicherlich auch in eurem Interesse den offiziellen Plugin-Store sauber ohne Hack betreiben zu können.

  • Ich klinke mich mal hier ein, denn ich glaube, dass ich einer der größten, wenn nicht sogar die größte WL-Filebase, im Einsatz habe. Die Filebase ist m.E. ohnehin nur lieblos hingeklatscht, ein absolut herzloses Produkt. Es wird qualitativ nicht einmal ansatzweise dem Forum gerecht, weil nicht einmal die Grundfunktionen zueinander identisch sind. WoltLab versprach in diversen Punkten Besserung (zu Alexander Ebert schiel, der in einem Ticket selbst zugab: "[...] Kritikpunkte lassen ohne Frage Raum zur Verbesserung [...]".)


    Die fehlende Mehrsprachigkeit bei Einträgen, ähnlich wie bei den regulären Artikeln in der Suite, ist eine Sache, die mir, genau wie euch, sehr missfällt. Meine User, die Content sowohl für Deutsche als auch ausländischer Herkunft erstellen, wodurch die gemeinsame Sprache - zum allgemeinen Verständnis - dann Englisch hilfsweise ist, lösen es momentan so, dass die Beschreibung beide Sprachen enthält (zuerst Deutsch, nach einem <hr> gefolgt von Englisch).

    Leider praktizieren es aber nicht viele, wodurch ausländische User zwangsweise auf einen Übersetzer zurückgreifen müssen, um überhaupt verstehen zu können, was dort auf Deutsch geschrieben steht. Für eine mehrsprachige Plattform, die auch eine multilinguale Zielgruppe hat, ist das einfach Kacke! Alle Files, bei einer Gesamtgröße der Filebase von ~80 GB, doppelt zu hosten, ist schlichtweg unverhältnismäßig (auch wenn die HDD mehr genug Platz bietet, aber darum geht es nicht). Zweifellos begrüße ich hier eine Mehrsprachigkeit!


    Mal am Rande:

    Ich frage mich zum Beispiel auch, warum es nicht möglich ist, die Dateien zeitverzögert zu veröffentlichen oder deaktiviert einzutragen? Sowohl im Forum als auch bei den Artikeln der Suite ist es implementiert, es gehört also - aufgrund letzterem - praktisch zu den Grundfunktionen der Suite. Wie vieles andere fehlt es natürlich in der Filebase, z.B. Benachrichtigungen jeglicher Art (Moderative Benachrichtigungen wie wurde deaktiviert oder gelöscht), um "weitere Autoren" hinzuzufügen oder zu entfernen bedarf es einen manuellen MySQL-Eingriff (warum wird dem Admin dieses Feld ausgeblendet? Logik?) usw.

  • Mit dem neuen Lizenzmodell hat WoltLab ja in Aussicht gestellt, dass es künftig häufiger kleinere Feature-Updates geben wird. Ich hoffe, dass das hier als eines der ersten kleinen Updates umgesetzt wird.

    • Official Post

    Es wird qualitativ nicht einmal ansatzweise dem Forum gerecht, weil nicht einmal die Grundfunktionen zueinander identisch sind.

    In Hinblick auf die Mehrsprachigkeit verhalten sich Forum und Filebase aktuell bereits identisch. Hier im Thema wurde vorgeschlagen, die Funktionsweise der Mehrsprachigkeits-Funktion in der Filebase eben so zu verändern, dass die Funktionsweise nicht mehr mit der des Forums identisch wäre.


    Ich frage mich zum Beispiel auch, warum es nicht möglich ist, die Dateien zeitverzögert zu veröffentlichen oder deaktiviert einzutragen? Sowohl im Forum als auch bei den Artikeln der Suite ist es implementiert, es gehört also - aufgrund letzterem - praktisch zu den Grundfunktionen der Suite.

    Bei der Funktion handelt es sich wie bei vielen anderen Funktion nicht um eine fertige "generische" Funktion. Die Funktion muss deshalb wie viele andere Funktionen für jede Stelle, wo sie Anwendung finden soll, separat implementiert werden - mit dem entsprechenden Entwicklungsaufwand.

  • ier im Thema wurde vorgeschlagen, die Funktionsweise der Mehrsprachigkeits-Funktion in der Filebase eben so zu verändern, dass die Funktionsweise nicht mehr mit der des Forums identisch wäre.


    Das habe ich erkannt! Wenn du mal über mein Profil auf meine wahrscheinlich längste Prali ... quatsch ^^, "wahrscheinlich größte WL-Filebase" gegangen wärst, hättest du auch gesehen, dass ich KEINEN Gebrauch von der "Mehrsprachigkeitsfunktion" der Suite mache, zumindest im Bezug auf die Differenzierung zw. DE und ENG.


    Dröseln wir doch mal deinem Grundgedanken der Funktionsweise auf:

    Jemand, der in meine Plattform kommt und der deutschen Sprache nicht mächtig ist, wird intuitiv ENG als Sprache auswählen und DE abwählen. Er sieht dann rund 5% aller Einträge. Dann kommt das große TamTam, wo ihm erklärt werden muss, dass er BEIDE Sprachen aktivieren muss, um auch die Uploads der Deutschen sehen zu können!

    Das hat für mich nicht das geringste mit "intuitiv" und "benutzerfreundlich" zu tun, sondern fördert eine 2-Klassen-Gesellschaft, die sich gegenseitig ausschließen, weil sie - weil sie nicht der Sprache mächtig sind - die Sprache deaktivieren.


    Ebenso ist die Frage, wo die Logik ist, einen Eintrag 2x in die Filebase hochladen zu müssen, nur weil es mehrere Sprachen gibt?! Was ist denn am Inhalt anders? Lediglich die Beschreibung weicht voneinander ab, aber nicht der downlaodbare Inhalt, denn der ist i.d.R. mehrsprachig. Für den Fall der Fälle kann der User immer noch über die Versionen einen andere Sprachversion downloaden, aber das hat nichts mit dem Eintrag selbst zu tun.


    Heißt also doppelte administrative Arbeit für den Plattform-Betreiber und zugleich zweifache Eintragungs- und Update-Arbeit für den Autor. Und wofür das ganze? Nicht mal ihr selbst betreibt dieses in der ursprünglich programmierten Form, sondern arbeitet, wie oben ersichtlich ist, mit dem BB-Code für eine mehrsprachige Beschreibung.


    Ein Eintrag für beide Sprachen reicht also vollkommen aus, erst recht, wenn man - wie ich - die Filebase in der Gestalt umgstrickt hat, dass der Versionierungs-Käse in einzelne Einträge umbemodelt wird und der Download-Button bei mehreren "Versionen" einfach auf die Seite der verschiedenen Versionen verlinkt, damit sich der User das gewünschte selbst heraussucht und dort downladet, um mehr Nutzerfreundlichkeit zu haben.

    Edited once, last by Wörki: Korrektur ().

    • Official Post

    Für den Anwendungsfall, den du hier beschreibst, ist die Mehrsprachigkeits-Funktion in der Filebase aus meiner Sicht nicht geeignet und auch gar nicht entworfen worden.


    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. Als Beispiel fällt mir hier eine Plattform ein, wo Übersetzungen für eine Software angeboten werden. Datei A ist z.B. die deutsche Übersetzung und wird dementsprechend durch die Mehrsprachigkeits-Funktion nur Nutzern angezeigt, die die deutschsprachigen Inhalte aktiviert haben. Es macht in diesem Beispiel gar keinen Sinn die Datei mehrsprachig mit einem Beschreibungstext zu versehen.

  • Es macht in diesem Beispiel gar keinen Sinn die Datei mehrsprachig mit einem Beschreibungstext zu versehen.

    Hallo Marcel,

    Du hast hier ein gutes Stichwort gebracht. Ich finde schon, daß es Sinn macht, die deutsche Übersetzung auch in anderen Sprachen anzuzeigen.

    Ein Beispiel ist der Shop von VieCode, den ich für meine Sprachdateien nutze. Dort MUSS ich jede Datei (Sprachdatei) in allen meinen 5 Sprachen beschreiben, betiteln und auskonfigurieren. Und das macht 100% Sinn.



    Weil, es kommen zum Beispiel Engländer, US-Amerikaner, Portugiesisch oder Polnisch Sprechende, die zum Beispiel die "spanische Datei" wollen, weil sie eine englische Community haben, die aber (auch) auf spanische Nutzer ausgerichtet ist.

    Besseres Beispiel, es kommt ein Nutzer, der ein polnisches Forum für südamerikanische Reisende in Polen betreibt. Also will der polnische Betreiber eine spanische Datei. Er wird die Datei-Beschreibung höchstwahrscheinlich in seiner Mutter- und Systemsprache "Polnisch" lesen und sehen.

    Das mit VieCode ist zwar einmalig beim Erstellen der Datei, plus Erweiterung, und plus Dateiversion konfigurieren viel Arbeit, die sich dennoch zu 10000% auszahlt. Das die perfekte Mehrsprachigkeit, die Ihr auch mit der gleichen Umsetzung im CMS/Artikelsystem vorgegeben habt.

    Dort im CMS ist das ebenfalls viel Arbeit bei 5 Sprachen, aber Ihr habt es perfekt und genauso realisiert, wie es sein muss. Google zeigt mir das auf erfreuliche Weise...

    Wäre toll, und wichtig, wenn Ihr das auch für Eure Filebase/Store genauso umsetzen könntet.

  • Für den Anwendungsfall, den du hier beschreibst, ist die Mehrsprachigkeits-Funktion in der Filebase aus meiner Sicht nicht geeignet und auch gar nicht entworfen worden.

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

  • Als Beispiel fällt mir hier eine Plattform ein, wo Übersetzungen für eine Software angeboten werden.

    Ich hoffe doch, dass die Filebase nicht für diesen einen speziellen Anwendungsfalls entworfen wurde. Denn dieser würde mit der hier gewünschten Umsetzung optimal abbildbar wie Dukemaster gut beschrieben hat. 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.


    Marcel Werk

    Bitte bedenke bei diesem Vorschlag auch, dass sich hier keine Neulinge zu Wort melden, die die Software nicht verstanden haben. Das ist eine konstruktive Kritik von professionellen Betreibern und Plugin-Store-Entwicklern.


    Ich kann mir nicht vorstellen, dass sich WoltLab mit ihrer [de][/de] Lösung abgefunden hat und hier nicht nachbessern möchte. Ich als Entwickler, der den Plugin-Store aktiv nutzt, möchte mich jedenfalls damit nicht abfinden. Ich möchte mich auch nicht damit abfinden, dass mein eigener Store nur auf deutsch angeboten werden kann.


    Schön zu lesen, dass ich mit dem Problem nicht alleine dastehe.

  • Ich kann mir nicht vorstellen, dass sich WoltLab mit ihrer [de][/de] Lösung abgefunden hat und hier nicht nachbessern möchte.

    Es gibt von mir in den letzten 3 Jahren ein paar Themen. Man will oder kann einfach diesen Misstand nicht beheben. Selbes gilt für die Ausgabe der Lizenz-Namen und Links über die Updateserver.

    Pluginstore und die de-en-Syntax

    i18n-Hinweis im Pluginstore falsch

    Pluginstore, Paketserver und Lizenzen

    Deswegen habe ich hier meine Pakete löschen lassen. Wenn man nicht auf Drittentwickler eingehen will, muss ich meine Software auch nicht hier anbieten. :)