Webform

Hallo Lars,

Super, dass du dich um Webform kümmerst. Ich sehe mir deine Übersetzungen schnellstmöglich an. Solltest du noch nicht auf Drupalchat.eu vertreten sein, bitte ich dich, unserer kleinen Gruppe #localize-german beizutreten. Dort findest du jede
Menge hilfsbereite Drupalista, die alle das gleiche Zeil haben wie du. Drupal zu einem besseren und einsteigerfreundlicherem CMS zu machen.

Außerdem würde ich mich freuen, wenn du dir kurz Zeit nehmen würdest, folgende Umfrage auszufüllen. Es dauert auch garantiert nicht lange!

Vielen Dank für deine investierte Zeit.

Grüße

Joachim

Finde die Übersetung „Einreichung“ für „Submission“ nicht gut. Ich hab das Wort im deutschen noch nie so gelesen. Kann mich nicht mehr erinnern, wie ich das zu D7 Zeiten übersetzt habe, aber irgendwas anderes glaube ich was im übertragenen Sinne sich flüssiger anhört. Webform fand ich immer schwer zu übersetzen... an vielen Sachen bricht man sich stundenlang einen ab, wegen dem Wort submission nur um drum herum zu kommen.

Also ich kann mich auch nicht erinnern, aber ich kann den Filter benutzen. Heraus kommt eindeutig Einsendung

to submit übersenden, absenden, etc.
Submission Übersendung, Absendung, Einsendung usw.

https://localize.drupal.org/translate/languages/de/translate?project=web...

Einreichen klinkt für mich nach Amtsdeutsch. aber dass ist nur meine subjektive Empfindung, wie immer eben.

Wörtlich übersetzt mag das sein... wenn du dir aber mal anschaust, was da passiert ist es eher „Speichern“. Die anderen wörtlichen übersetzungen haben irgendwie nichts mit dem Technischen oder Usability-Ablauf zu tun. Der user sendet doch seine Daten nicht ein. Er füllt ein Formular aus und speichert die Daten am Ende.

Na ja bei einer E-Mail hat die Masse auch absenden im Kopf. Klar wird in der Datenbank nur abgespeichert die Frage ist, will dass der Seitenbesucher überhaupt wissen oder denkt er darüber nach? Ich denke eher nicht. PS: hast du die Umfrage oben schon ausgefüllt? Ich wäre auf deine dedizierte Meinung gespannt.

Ich bin mal gespannt, was der Rest so denkt :-D

Im Glossar steht in Zeile 228 bereits speichern

https://docs.google.com/spreadsheets/d/1JGZWWUQGBsXg30aax-0-yQM_KW8vZs9n...

Da die Termen möglichst auf Drupal insgesamt passen sollen und so übernommen werden, dass Sie in der gesamten Übersetzung gleich sind, würde ich @hass sogar beipflichten und in diesem Fall speichern verwenden. Ich habe deinen Issue bereits mit allen im Kanal auf Drupalchat.eu geteilt und hoffe noch auf Rückmeldung, bevor ich hier alleine entscheide. Aus oben genanntem Grund würde ich aber zu speichern tendieren, auch wenn dass nicht in Stein gemeißelt ist. Es muss aber im Team besprochen werden. Schade nur, dass das Team nicht immer Zeit findet solche Dinge zeitnah zu besprechen. Sonst wären auf deinem Konto wahrscheinlich schon wesentlich mehr zugelassene Übersetzungen :-) Kümmer dich aber nicht um die Punkte. Ich hab auch noch zirka 5000 offene Übersetzungen, über die bis jetzt noch keiner entscheiden konnte.

Als Tipp für dich: Such dir einfach noch ein Modul, dass von deinen/euren Projekten benötigt wird und übersetze es indem du dabei das Glossar berücksichtigst und Rechtschreibfehler vermeidest. Dann geht's am schnellsten.

Ach wie herrlich, wenn hier was vorangeht. Ich würde Other im Fall von Webform aber nicht mit andere übersetzen, sondern mit weitere.

https://localize.drupal.org/translate/languages/de/translate?project=web...

Ich weis nur nicht, in wiefern das Umdrehen sinnvoll ist, da ich mir die UI noch nicht angesehen habe. Also

weitere Kontrollkästchen
Weitere Radiobutton
Weiteres Auswahlmenü
Weiteres Element
usw.

1. Formulareingabe speichern
2. Eigene Formulareingaben löschen
4. Formulareingaben

Webform an sich ist ein Modulname und wird nicht übersetzt, da die Modulnamen auch dann zugeordnet werden können müssen, wenn man nach einem Modul auf Drupal.org in der englischen Dokumentation sucht. Im Kontext dürfte aber auch wieder Formulareingabe herauskommen. Du darfst nicht so kompliziert denken, da wird man ja irre :-D

#12 klingt super.

Klasse dann müssen wir ja jetzt nur noch 1700 Zeichenfolgen übersetzen und anschließen redigieren und korrigieren um sie danach freizugeben. Hach ja in ner Woche sind wir fertig :-) :-) ;-)

Zu #13 Modulnamen werden in der Regel auch nicht übersetzt und eigentlich sollte es hier keine Ausnahme geben. Das gilt auf Jeden Fall für die Seite Erweitern im Administrationsbereich für Drupal.

Webform verwendet deinen Namen auch immn den Original Zeichenketten als Abgrenzungsmerkmal zu dem Begriff Form, da auch die Field-UI Formulare ausgibt.

Das Modul Webform gibt aber eben auch Formulare aus und nichts anderes. Als Admin oder Editor weißt u du aber, dass das Ergebnis deiner Arbeit mit Webform ein Eingabeformular sein wird.

Darum bleibt ein Formular in diesem speziellen Fall eben auch das was es ist. Eben ein Formular und kein Webform oder Webformular. Das ist Gott sei Dank kein Standard Fall der sich so 1 zu 1 übertragen lässt. Vielleicht hilft dir ja

Je kürzer ein Satz oder Begriff desto besser! Um zu verstehen, warum ich nicht jedes Mal Webform-Irgendwas schreiben will.

Schöner ausgedrückt:

Views übersetzen wir ja auch mit Ansichten

Insgesamt haben wir noch 1400 Zeichenfolgen im Modul zu übersetzen.

Ich habe inzwischen die Examples rausgefiltert, zumindest die die ich finden konnte So lässt sich das ganze angenehmer übersetzen und die Tabellen auf l.d.o werden nicht mehr so zerrissen.

Hier geht's lang!

310 übersetzungen in einer Woche. Wenn das so weiter geht, dann könnenen wir Webform bald atakta legen.

972 to go :-)

Hallo Lars,
erstmal vielen Dank für die Vorschläge. Ich weiß, wie kompliziert und langwierig das Übersetzen von Webform ist.
Ein Problem bei den Vorschlägen ist, dass Joachim und ich uns bei Webform z. B. für "submission" auf "Webformular-Eingabe" als Übersetzung vorerst geeinigt haben. Das heißt, deine Vorschläge mit "Einreichung" oder "Einsendung" müssten alle angepasst werden.
Allerdings sehe ich auch viele Vorschläge, die ich zulassen kann und vor allem Vorschläge, die mir das Leben einfacher machen.
Melde dich doch bitte mal unter https://drupalchat.me und dann können wir das Ganze dort besprechen. Wenn jemand das mit mir übersetzt, dann kriegen wir das eventuell bis zum Monatsende fertig, aber alleine macht das eben keinen Spaß. Wenn wir uns da abstimmen könnten, fände ich das super.

Noch 650 immer noch ekelhaft viel, aber machbar.

@markus.

Das machst du super. Bin gespannt, wie viele Übersetzungen nach dem nächsten Cron-Lauf noch übrig sind. Für D8 dürften wir ungefähr bei 500 liegen. Der Rest den bis jetzt keiner Interessiert hat, wird wohl Englisch bleiben. Macht aber nix. Drupal 7 gibt's maximal noch bis 2021 warum soll man sich deswegen noch groß damit aufhalten.

Dir jedenfalls vielen Dank für die Zeit, die du hier reinsteckt.

Problem:

the third option (xor/Eins) is true when EXACTLY ONE of the conditions are met, but the second option (or/alle) is true when ANY ONE of the conditions are met.

problem ist, dass gleiche EN wörter im kontext im DE was andres heißen oder? und vielleicht garnicht gefixed werden kann?
Should be something like 'irgendeine' and 'genau eins'

Hier ist eines der Probleme, das natürlich entsprechend komplex ist: https://localize.drupal.org/translate/languages/de/translate?sid=97958
Das ganze ist im Grunde eng mit https://www.drupal.org/project/drupal/issues/3046985 verknüpft. Das heißt, hier müssten Übersetzungskontexte eingeführt werden. Nur interessieren sich dafür zu wenig Leute, obwohl das dringend nötig wäre.

Tatsächlich ist das komplex. Und warum ist das komplex? Weil die Maintainer zu Drupal 6 Zeiten noch keine Kontexte hatten und Zu Drupal 7 Zeiten den Fehler nicht erkannt hatten. Jetzt ist Drupal 9 blad da und er taucht mal wieder auf.

Dröseln wir das Ding mal auf, damit wir verstehen, was hier passiert:

Logik

Das Element bzw. der Wert X ist sichtbar wenn entweder Keine, Alle oder eine bestimmte Bedingung zutreffen.

In Drupal gilt grundsätzlich die Logik wenn kein Block, Keine Entität , usw. Ausgewählt ist, dann werden alle Blöcke, Entitäten ... angezeigt.

Darum haben wir hier All (Alle) Any (Keine) und Eine. Was eigentlich besser mit irgendeine übersetzt werden sollte.

Wenn X oder X oder X dann ...

Sprachlich bringst du ohne Kontext aber alles durcheinander, wenn du Alle mit Keine übersetzt, weil der Core den String Any und None unterscheidet.

Das verstehe ich beim Hinschreiben kaum.

Und jetzt sollen wir:

1. Diese logik begreifen
2. Erkennen, warum Webform die Logik die im Core vorherrscht hier aufdröselt und umdreht
3. Den betreffenden String finden. Nämlich All und entweder All mit Keine übersetzen oder Jacob einen Context-Patch liefern und ihm in Englisch erklären, warum du für die Deutsche Übersetzung hier einen Kontext brauchst, um die Werte im Dropdown richtig darstellen zu können aber dabei gleichzeitig, die Logik, die für alle Dropdowns im Core gilt nicht durcheinander zu bringen.

Wie man in Franken so schön sagt: „Gud Nachd Gaddendürla“ Was auf Hochdeutsch so viel bedeutet wie Um Gottes willen, wie sollen wir dass denn schaffen?

In meinem speziellen Fall ist das noch schlimmer. Ich kann nämlich überhaupt kein PHP. Das heißt, selbst wenn ich die Logik hinter dem Problem erkannt hätte, hätte ich mangels Fachkenntniss immer noch keinen Ansatz für einen entsprechenden Patch.

Und dann bin ich wieder bei Markus. Der sagt:

„Für die Problematik und das Thema Kontext in Übersetzungen interessieren sich viel zu wenig Leute“

Damit hat er recht und ich glaube sogar er meint damit nicht unbedingt die deutsche Community. Auch den Modulmaintainern ist nicht immer bewusst, wofür genau ein Kontext gut ist. Du kannst ja auch nicht von jedem eigentlich sogar von keinem Maintainer erwaten, dass er 115 Sprachen fließend spricht und dann die entsprechenden Kontexte gleich mitliefert.

Frage 1:

Wer erkennt die Logik dahinter und kann überprüfen?

Frage 2:

Wer ist in der Lage diese Logik programmatisch umzusetzen?

Frage 3:

Wer ist in der Lage die Logik dahinter verständlich ins Englische zu transferieren, um en Patch zu contributen und sicher zu
stellen, dass die Jungs hinter Webform bereit sind den Patch in ihre Codebase/Nächste Release aufzunehmen, in dem er ihnen in Englisch plausibel darlegt wozu das gut sein soll?

Wenn ihr mir die 3 Fragen beantworten könnt und mir jemanden besorgt, der die Antworten auf alle 3 Fragen kennt oder 3 Leute, die die Antwort auf jeweils eine dieser Frgen darstellen bzw den Patch liefern und das ganze dem Webfrom-Maintainrn erklären können, dann können wir diesen Bug fixen.

Wenn nicht, bleiben die Einträge im Menü halt kacke!

Oh Entschuldigung. Ich meine natürlich, dann wird es für dieses Problem wohl so schnell keine Lösung geben.

Das Problem haben wir übrigens nicht nur hier, sondern auch auf der Einstellungsseite des Views-Moduls und was weiß ich wo noch. Das ist also gar kein reines Webform-Problem, sondern schlichtweg ... Na ja ich erspare es mir und euch jetzt einfach dieses Wort hier noch einmal zu wiederholen.

@Nico Gefixt werden kann das bestimmt. Aber halt nur dann, wenn jemand bereit und sowohl fachlich als auch sprachlich in der Lage ist, den entsprechenden Patch zu programmieren und die Notwendigkeit der Implementierung des Patches dem Maintainer von Webform bzw. den Core Maintainern klar zu machen.

Ich glaube allerdings der Core ist die falsche Stelle weil man damit die Logik im Core komplett über den Haufen werfen würde und dass dan für alle Module gilt. Im core macht das also keinen Sinn, weil dort der Aufwand dann vermutlich zu groß ist, da sich der Patch dort auf alle Contrib-Module auswirkt. In Webform nur auf Ein Modul.

# Gelöscht. Geht nicht durch den Mallformed-Filter, wengen des <div>-Tags.

<300 Irgendwann kriegen wir das Ding auch noch klein. Bei einem Abend mit 10 Leuten, wären das 30 für jeden. Ich verstehe einfach nicht, warum hier keiner mithilft, bis diese Module auf 0 Zeichenfolgen sind. Das macht die Übersetzung beim nächsten Modul-Release um so vieles einfacher Den Beweis erbringt der Coere jetzt bereits seit 8.6. Nur begriffen haben das offenbar noch zu wenige Leute.

Hier hat's noch 100 Stück unübersetzte Zeichenfolgen. Allerdings sind die meisten davon Formularbeispiele in YML. Na ja vielleicht können wir ja Ende 2021 endlich einen Haken hinter dieses Modul machen, dass für sich genommen mindestens so Groß ist, wie das Kernsystem.

Mal wieder Webform. Webform enthält hier auf dem Übersetzungsserver C. a. 150 Zeichenfolgen Formularbeispiele, die in YML-Code abgefasst sind. Es ist nicht möglich, diese Beispiele direkt hier auf dem Übersetzungsserver zu übersetzen, da andernfalls beim Import dr Übersetzung bei Fehlerhaftem YML-Code die komplette Drupal-Installation beschädigt werden kann.

Webform enthält stand Heute keine Weiteren Übersetzungen mehr, die noch übersetzt werden können. Eine Review ist erforderlich, um herauszufinden, ob die Übersetzung mittlerweile wieder fehlerfrei importiert werden kann.

https://localize.drupal.org/translate/languages/de/translate?sid=2575681

Ach Webform. Jedes mal wenn es hier Updates gibt sitz ich da und muss YAML-Examples mit teilweise 168+Zeilen in einem Textfeld ohne Validierung und ohne Synthax-Highlighting fehlerfrei abtippen. Dass ist auch der Grund warum über 90 Webform Beispiele noch nicht übersetzt waren.

Das habe ich heut geändert. Ich hab auch schon zwei fehlerhafte Strings gefunden, die waren nicht von mir sondern von den berühmten Multiple Users, damit bloß keiner sagen muss wer's war, aber egal.

ich habe korrigiert und fertig. Wenn dass soll läuft, wie ich mir dass vorstelle, haben in gut 30 Minuten keinen einzigen Fehler in keinem einzigen der neuen 98 Strings, korrigieren dann mal eben die eine gelöschte Zeichenfolge uind haben dann genau noch einen unübersetzten String in Webform, den man aber überhaupt nicht übersetzen muss, weil er ohnehin nur Platzhalter enthält. Und damit wäre Webform dann nach 8 Jahren endlich einmal komplett fertig. Ich meine dass ding ist insgesamt größer als der gesamte Core aber es ist trotzdem eine Leistung. Vielen Dank euch allen fürs mithelfen.

Danach können die konstruktiven Kritikäusserer wieder aufstehen und mir hier im Issue erzählen, welche Stings alle nicht korrekt übersetz sind und warum.

Ich beiße auch nicht, ich bin für jeden Hinweis dankbar :-D

2 fehlerhafte Strings sind noch da. Die kommen aus Webform examples. Ich fix die Asap einfach zu finden sind sie hier allerdings nicht. Wenn sie jemand finden und hier verlinken kann, lösch ich sie raus. Ansonsten müssen wir uns leider gedulden bis ich Zeit habe sie zu suchen.

Oh Gott. Bitte es wäre mir lieb wenn niemand mehr dieses Pflefachkraft Beispiel übersetzt. Da ist der Platzhalter für die Telefonnummer im Link falsch. Ich denke wir sollten jetzt wieder alle bösen Strings raus haben.

Liste der. 3 Strings die raus müssen

https://localize.drupal.org/translate/languages/de/translate?sid=2869094

https://localize.drupal.org/translate/languages/de/translate?sid=2750342

https://localize.drupal.org/translate/languages/de/translate?sid=2810011

Einen hab ich gerade noch gelöscht. Jetzt ist beten, weil keiner versteht, wann dieser Server seine Dateien neu erzeugt, nachdem Änderungen gemacht wurden.

Ich denke wir geben dem ganzen mal bis Samstag. Ich schaue zwischendurch immer mal wieder, ob dich dass auflöst.