Diskussionsbereich zur Idee: Übersetzungs-Center

  • Bitte Vorschläge, wie man das Formular schöner/besser/übersichtlicher gestalten könnte. Die zwei schmalen Felder sind mir etwas zu gestaucht.
    Eventuell Zeile 2 | Quelle 1 | Quelle 2 |
    und Zeile 3 | Übersetzung| Button |
    ?


  • Ich würde es auf zwei Eingabefelder schrumpfen, aus dem einfachen Grund, dass niemanden eine Alternativversion interessiert. Interessant ist die aktuelle Ist-Variante und die Soll-Variante als leeres Eingabefeld.


    Eventuell kannst du dir mal http://translate.mattermost.com ansehen, dort ist es meiner Meinung nach gut gelöst (bin gerade nur mobil, daher kann ich dir keinen Screenshot machen).

  • 1. Warum überhaupt zwischen AE und BE differenzieren, wenn ersteres die gewünschte Vorgabe durch WoltLab ist?


    Es macht praktisch keinen Sinn dann zweimal zu übersetzen und rein phonologisch Änderungen einzufügen, also z.B. dann "summarise" (BE) und "summarize" (AE) zu schreiben. Zu Beginn habe ich selber BE genutzt, weil ich "the Queen's English" sprachlich und stilistisch ansprechender finde, aber habe mir das mittlerweile für die WBB-Umgebung abgewöhnt, verwende auch bei den Blog-Übersetzungen für Cr@@gle und Tom AE, um konsequent zu sein/bleiben. Wir differenzieren auch nicht zusätzlich nach CE oder NZE, weil wir keinen Bedarf dafür haben, von daher reicht eigentlich einmal Englisch und dann AE, oder?



    2. Die ID-Zuweisung war/ist willkürlich, später wird man die Sprachen alphabetisiert vorfinden, um so schneller zur gewünschten Sprache zu gelangen? Das ist einfach nur ein systematisch-strukturierendes Detail.



    3. Die Flagge wird sichtbar, wenn man auf die jeweilige Sprache klickt und dann in der Auflistung der Variablen landet. Das kann so bleiben, aber ich würde die Flagge bereits vorab in der Übersicht einbinden, weil das als Erstübersicht wiederum optisch unterstützt. Nicht jeder achtet auf Titel, sondern geht tatsächlich über die Flagge, was man dann vorab eben anzeigen könnte.



    4. "Variable" ist der Begriff, den wir hier vermutlich alle benutzen (?) bzw. ist das grundsätzlich und auch über den WBB-Rahmen hinaus der Fachbegriff? Ich frage das, weil ich außerhalb der WBB-Domäne mit den Begriffen "Phrase", "Text", "Dokument" usw. arbeite. Das heißt, ich muss je nach Datei einordnen, was genau ich da übersetze und "Variable" als Begriff habe ich nicht vorliegen. Das heißt jetzt nichts, mir geht es rein darum zu erfragen, ob "Variablen" als Bezeichnung wirklich geläufig ist und das jeder weiß oder ob der Begriff eventuell eher nur von Entwicklern der WBB-Welt genutzt wird, wir daher doch noch terminologisch ändern sollten, um für jederman eindeutig zu sein.
    Hierzu ist dann eure fachliche Meinung gefragt.



    5. Frage: Ist das so entwicklungstechnischer Usus, dass bei den Informationen "bottom-up" und nicht "top-down" angeordnet wird? Also so:



    In der generativen Syntax (Linguistik) liegt der Unterschied zwischen beiden Modellen darin, wie man die Bedeutung zuweist. Ich hatte mich gefragt, ob das in der Entwicklung auch unterschieden wird oder nicht, das aber nur am Rande und rein für mich gefragt.



    6. Auch das ist einfach eine subjektive Herangehensweise, die je nach Betrachter anders ausfallen kann. Wenn ich aktuell eine Sprachdatei in der Ausgangssprache Deutsch erhalte, um sie ins Englische zu übersetzen, sehe ich dann in meinem "Übersetzungscenter" (es ist kein reales Center, eine angepasste Systran-Modifikation für Unternehmenslösungen) einfach nur das Textfeld für Deutsch und daneben setze ich meine Übersetzung. Würde ich zusätzlich ins Französische übersetzen, hänge ich einfach einen zusätzlichen Tab an. Die Ursprungsdatei bleibt aber unbehandelt, in ihr selber sieht man dann nicht die Übersetzung/en. Von daher war ich verwundert, warum es sich aktuell so darstellt:





    7. Wie wird das "Überprüft" gesetzt (automatisch, manuell)?



    8. "Überprüft" sagt, dass jemand den Inhalt, also die Variable, kontrolliert hat, es besagt nicht automatisch, dass alles übersetzt vorliegt. Wäre es also nicht passender, wenn wir dann von "Übersetzt" und "Nicht übersetzt" sprechen?
    Analog dazu, sollte man es später nicht dezent vielleicht gar farblich abheben (grün und rot), damit es ins Auge springt?



    .....


    Zwecks Optik machen 3 Kästchen Sinn, wenn der spätere Nutzer tatsächlich die wörtliche Übersetzung und dann die sprachlich sinnvolle Übersetzung benötigt. Also wenn hinsichtlich maschineller und "menschlicher" Übersetzung differenziert werden soll. Das benötigen wir jetzt nicht, von daher, da wäre ich bei Matze's Überlegung, reichen uns eigentlich zwei Boxen. So arbeiten ja auch die kostenfreien Tools wie "Bing Translator" oder "Google Translator". So dann grob:




    Man kann jetzt darüber diskutieren, wo man den Button zur Freigabe platziert, also ob zentriert zu den Boxen rechts, direkt im Übersetzungsfeld (ich übersetze und darunter erscheint dann der Button zum Freigabe-Klick) oder ob man ihn analog zu den Titeln der beiden Boxen auch in die obere Zeile setzt. Wählt man Option 3, müsste aber beim Übersetzen die Leiste mitsliden, weil ich dann ja zum Klicken hochscrollen müsste, was wiederum unpraktisch ist, wenn die Leiste nicht mitscrollt. Da machen Option 1 und 2 mehr Sinn. Beide Ansätze gehen, der Unterschied liegt eher darin, was der Nutzer als "intuitiv" ansieht. Rein optisch würde ich Option 2 nehmen, inhaltlich ist Option 1 etwas intuitiver, denke ich.



    3 Kästchen bzw. die Variante mit Notizen, Synonymen usw. wäre nützlich, wenn wir tatsächlich nach und nach eine Art Glossar aufbauen würden, das Übersetzern zur Verfügung stünde. Ein solches Prinzip sieht man bspw. bei diesen Angeboten:


    http://jabylon.org/screenshots.html (Notizen, Korrekturen&Co.)
    http://www.linguee.com/english…nslation/How+are+you.html (Ausweitung auf Phraseologie)
    http://translate.reference.com/ (Wörterbuch als Zusatz)



    Das ist praktisch, aber ich bin mir nicht sicher, ob das im WBB-Rahmen nicht zu weit geht. Anders formuliert, ich neige dazu zu denken, das würde eher nicht aktiv genutzt und gefüllt. Ursprünglich hätte ich selber für so einen Zusatz votiert, aber nach einigen Gesprächen mit WBBlern und Nicht-WBBlern (zwei Übersetzerinnen, die ich kenne) stellte sich heraus, dass die Leute weniger systematisch an Übersetzungen herangehen, sich nicht aktiv austauschen, sondern eher das Prinzip "Herunterübersetzen" praktizieren. Keiner der WBBler, mit denen ich gesprochen habe, hat je bei einer Übersetzung nachgefragt, sondern im Zweifel wurde es eben einfach nach Gefühl übersetzt und fertig. Aktiver Austausch, das kenne ich von den fachlichen Gesprächen mit eben Kollegen, aber ich kann z.B. wirklich an einer Hand abzählen, wann ich mich fachlich hier mit Leuten ausgetauscht habe. Damit meine ich, der Fokus liegt anders, es geht nicht darum sprachlich ein einheitliches Niveau herzustellen, sondern, lax gesagt, ein Entwickler will einfach sein Plugin übersetzt haben, Punkt.


    Von daher würde ich jetzt fast so weit gehen zu sagen, je simpler, desto besser, weil so schneller und zahlreicher übersetzt werden würde? Angenommen es wird gut aufgenommen, dann könnte man immer noch hergehen und ein Glossar, abgespecktes Lexikon o.ä. integrieren, gar versuchen einen (Inline-)Editor einzupflegen, um manuell Notizen einfügen zu können?







    P.S. Ich bin eher zufällig hierauf gestoßen https://github.com/mmoreram/translation-server, wir können das bzw. Teile davon aber nicht brauchen, oder?

  • 1. Warum überhaupt zwischen AE und BE differenzieren, wenn ersteres die gewünschte Vorgabe durch WoltLab ist?


    Es macht praktisch keinen Sinn dann zweimal zu übersetzen und rein phonologisch Änderungen einzufügen, also z.B. dann "summarise" (BE) und "summarize" (AE) zu schreiben. Zu Beginn habe ich selber BE genutzt, weil ich "the Queen's English" sprachlich und stilistisch ansprechender finde, aber habe mir das mittlerweile für die WBB-Umgebung abgewöhnt, verwende auch bei den Blog-Übersetzungen für Cr@@gle und Tom AE, um konsequent zu sein/bleiben. Wir differenzieren auch nicht zusätzlich nach CE oder NZE, weil wir keinen Bedarf dafür haben, von daher reicht eigentlich einmal Englisch und dann AE, oder?

    Die Sprachen sind prinzipiell erstmal Spielerei. ;)


    2. Die ID-Zuweisung war/ist willkürlich, später wird man die Sprachen alphabetisiert vorfinden, um so schneller zur gewünschten Sprache zu gelangen? Das ist einfach nur ein systematisch-strukturierendes Detail.

    Meinst du in der Sprachenauflistung? Da wird momentan nach countryCode sortiert - aber ja, das ist unschön zumal dieser nirgends angezeigt wird. Ich werde das auf den Sprachtitel in Anzeigesprache ändern.


    3. Die Flagge wird sichtbar, wenn man auf die jeweilige Sprache klickt und dann in der Auflistung der Variablen landet. Das kann so bleiben, aber ich würde die Flagge bereits vorab in der Übersicht einbinden, weil das als Erstübersicht wiederum optisch unterstützt. Nicht jeder achtet auf Titel, sondern geht tatsächlich über die Flagge, was man dann vorab eben anzeigen könnte.

    Wird gemacht.


    4. "Variable" ist der Begriff, den wir hier vermutlich alle benutzen (?) bzw. ist das grundsätzlich und auch über den WBB-Rahmen hinaus der Fachbegriff? Ich frage das, weil ich außerhalb der WBB-Domäne mit den Begriffen "Phrase", "Text", "Dokument" usw. arbeite. Das heißt, ich muss je nach Datei einordnen, was genau ich da übersetze und "Variable" als Begriff habe ich nicht vorliegen. Das heißt jetzt nichts, mir geht es rein darum zu erfragen, ob "Variablen" als Bezeichnung wirklich geläufig ist und das jeder weiß oder ob der Begriff eventuell eher nur von Entwicklern der WBB-Welt genutzt wird, wir daher doch noch terminologisch ändern sollten, um für jederman eindeutig zu sein.
    Hierzu ist dann eure fachliche Meinung gefragt.

    Mir ist prinzipiell egal, was genau dort steht. Das WCF selbst nennt es - glaube ich - "Texte".


    5. Frage: Ist das so entwicklungstechnischer Usus, dass bei den Informationen "bottom-up" und nicht "top-down" angeordnet wird? Also so:

    Inwiefern?
    Die Informationen stehen überall noch ziemlich unsortiert rum, sollten aber schlussendlich dann in eine sinnvolle Reihenfolge. In deinem Screenshot zum Beispiel zunächst genaue Angaben zu der Übersetzung, dann ungenauer bis wir zu den Informationen zum Paket kommen.


    6. Auch das ist einfach eine subjektive Herangehensweise, die je nach Betrachter anders ausfallen kann. Wenn ich aktuell eine Sprachdatei in der Ausgangssprache Deutsch erhalte, um sie ins Englische zu übersetzen, sehe ich dann in meinem "Übersetzungscenter" (es ist kein reales Center, eine angepasste Systran-Modifikation für Unternehmenslösungen) einfach nur das Textfeld für Deutsch und daneben setze ich meine Übersetzung. Würde ich zusätzlich ins Französische übersetzen, hänge ich einfach einen zusätzlichen Tab an. Die Ursprungsdatei bleibt aber unbehandelt, in ihr selber sieht man dann nicht die Übersetzung/en. Von daher war ich verwundert, warum es sich aktuell so darstellt:

    Das ist nicht das Übersetzungsformular, sondern eine Detail-Seite zur jeweiligen Sprachvariable (oder wie auch immer wir es nennen wollen). Dargestellt werden zwar Eingabefelder, deren Inhalt man allerdings nicht verändern (und auch nicht absenden) kann. Hier werden stumpf alle Übersetzungen aufgelistet, die bereits vorhanden sind.


    7. Wie wird das "Überprüft" gesetzt (automatisch, manuell)?

    • Paket wird eingetragen
    • Sprachvariablen werden erstellt
    • Benutzer 1 übersetzt Sprachvariable 1
    • Sprachvariable 1 wird nicht mehr zur Übersetzung angezeigt
    • Sprachvariable 1 taucht nun irgendwann unter "Sprachvariablenprüfung" auf
    • Benutzer 2 klickt auf "sieht gut aus"
    • Benutzer 3 klickt auf "sieht gut aus"
    • Sprachvariable erhält den status checked = 1 und kann exportiert werden


    8. "Überprüft" sagt, dass jemand den Inhalt, also die Variable, kontrolliert hat, es besagt nicht automatisch, dass alles übersetzt vorliegt. Wäre es also nicht passender, wenn wir dann von "Übersetzt" und "Nicht übersetzt" sprechen?
    Analog dazu, sollte man es später nicht dezent vielleicht gar farblich abheben (grün und rot), damit es ins Auge springt?

    Das mit dem farblich darstellen funktioniert noch nicht so ganz (Stichwort Pseudo-Elemente). Dazu muss ich demnächst mal im Beta-Forum nachfragen.
    Korrekt, die Überprüfung erfolgt durch echte Menschen, die auf "sieht gut aus" klicken oder etwas ändern.
    Naja, alles, was zur Prüfung vorliegt, ist übersetzt bzw. hat einen Inhalt. Zu erkennen, ob dieser korrekt oder Unfug ist, ist entsprechend Aufgabe des Überprüfenden.
    Es gibt die Status Nicht übersetzt, Übersetzt, nicht geprüft, Geprüft. Im Testsystem ist leider momentan kein Dummy für den mittleren Status vorhanden, da nur aus den Paketen synchronisierte Werte in der Datenbank stehen.


    Zwecks Optik machen 3 Kästchen Sinn, wenn der spätere Nutzer tatsächlich die wörtliche Übersetzung und dann die sprachlich sinnvolle Übersetzung benötigt. Also wenn hinsichtlich maschineller und "menschlicher" Übersetzung differenziert werden soll. Das benötigen wir jetzt nicht, von daher, da wäre ich bei Matze's Überlegung, reichen uns eigentlich zwei Boxen. So arbeiten ja auch die kostenfreien Tools wie "Bing Translator" oder "Google Translator". So dann grob:

    Guad, dann ändere ich das entsprechend ab. Die Alternativsprache hat übrigens den Sinn, dass wir zum Beispiel von Deutsch und Englisch übersetzen können, je nachdem, was eben vorhanden ist. Sprachen, die der Benutzer nicht spricht, kann er übrigens auch von vornherein ausblenden lassen - sie sind aber weiterhin leicht zugänglich.



    Die Beispiele von dir und @Black Rider muss ich mir in Ruhe mal ansehen und ausprobieren. Dementsprechend bis später oder die Tage - ich gehe erst mal essen. :)

  • @MysteryCode


    Servus du :winke:


    Ich wollte dich kurz wegen einem weiteren Gesprächsteilnehmer ansprechen bzw. seinem Plan. Du kennst vielleicht zumindest rein namentlich GeGeek bzw. Chris? Er ist der Französisch-Übersetzer, der zusammen mit LuFo auch den franzöischen Support-Ableger rund um WBB geführt hat. LuFu leitet die Plattform nicht mehr, GeGeek wiedrum ist noch aktiv in Punkto Übersetzung, aber möchte seine Übersetzungen (WSC, Plugins...) zukünftig nicht mehr kostenfrei anbieten. Er hat mich kontaktiert (es gab schon früher Kontakt), sein Projekt grob skizziert und ich habe ihm von der Übersetzungs-Center-Idee erzählt.


    Er wird seine Plattform aufbauen und ich kann verstehen, dass er nicht mehr komplett umsonst arbeiten möchte, aber heißt das zugleich, er wäre komplett vom Übersetzungs-Center abgeschnitten? Vorsichtig ins Blaue gesprochen: Was wäre z.B., wenn man eben irgendwie auch kommerzielle Angebote zumindest im Übersetzungs-Center erwähnt, anzeigt o.ä.?


    GeGeek würde hier ins Gespräche dazukommen, dann könnte man gemeinsam darüber sprechen, aber dazu wären 2 Dinge nötig:


    1. Einer müsste kurz die Idee auf Englisch erklären, weil er dem besser folgen kann als Deutsch (da es dein Projekt ist, kannst du es natürlich auch erklären; wenn du es nicht tun möchtest bzw. es zeitlich nicht passt, kann ich es machen, sag einfach, wie es dir lieber ist, ja?)


    2. Wir müssten das Gespräch dann auch Englisch weiterführen bzw. zumindest den Part, wo er eventuell ins Spiel kommt, wäre das ok? Sowohl du, als auch Josh usw. sind ja firm, von daher dürfte das kein Problem sein, eventuell melden sich dann auch andere Nicht-Muttersprachler des Deutschen, die sich einbringen möchten?






    Zweiter Punkt: Was meinst du nun wegen der Sache rund um grammatisch-stilistische Richtlinien? Ich hatte dir ja berichtet, was Alexander Ebert gemeint hatte, wie verbleiben wir da nun, was schlägst du vor?

  • Generell, jetzt mal rein objektiv gesehen, müsste man dann entsprechend eine Firma hochziehen, entsprechende Verträge ausarbeiten und dann einen Shop programmieren, der dann speziell auf diesen Zweck abgestimmt ist. Rechtlich muss man das auch alles absichern. Für eine Person wohl erst einmal zu viel Aufwand, sowohl von der Arbeit, als auch vom Geld. Ich will nicht sagen, dass Flo das nicht stemmen könnte, es wäre nur zu viel Risiko, denke ich.

  • Vorsichtig ins Blaue gesprochen: Was wäre z.B., wenn man eben irgendwie auch kommerzielle Angebote zumindest im Übersetzungs-Center erwähnt, anzeigt o.ä.?

    Verlinken könnte man die Angebote theoretisch.
    Alles, was dort übersetzt wird, wird aber auch Open Source bleiben, da sonst jemand Geld für etwas kassiert, das er technisch gesehen nicht allein umgesetzt hat und das würde ich definitiv nicht unterstützen. Vor allem, wenn man diese absolut überzogenen Preise für eine kleine XML-Datei betrachtet, die eine gewisse Person verlangt.


    Generell, jetzt mal rein objektiv gesehen, müsste man dann entsprechend eine Firma hochziehen, entsprechende Verträge ausarbeiten und dann einen Shop programmieren, der dann speziell auf diesen Zweck abgestimmt ist. Rechtlich muss man das auch alles absichern. Für eine Person wohl erst einmal zu viel Aufwand, sowohl von der Arbeit, als auch vom Geld. Ich will nicht sagen, dass Flo das nicht stemmen könnte, es wäre nur zu viel Risiko, denke ich.

    Verkaufen werde ich generell weiterhin nur das, was auch aus meiner Hand stammt. Denn wie du schon sagst, ist es rechtlich ein sehr hoher Aufwand, der sich auch einfach nicht rechnen würde.


    1. Einer müsste kurz die Idee auf Englisch erklären, weil er dem besser folgen kann als Deutsch

    Dafür gibt's die Seite "Die Idee" und einen Administrator namens Gabbid. :P


    Zweiter Punkt: Was meinst du nun wegen der Sache rund um grammatisch-stilistische Richtlinien? Ich hatte dir ja berichtet, was Alexander Ebert gemeint hatte, wie verbleiben wir da nun, was schlägst du vor?

    Da es keine bestimmte Richtlinie gibt, könnte man ja schwammig ein paar Tipps zusammenstellen und auf den Rest pfeifen. Schlimmer als jetzt kann es ja nicht werden. ;)