Thank you, for adding this one. I didn't had time to debug that issue quite well,but it seems that some twig templates suppress adding of the rel attribute. In my case it was https://www.drupal.org/project/ui_suite_dsfr → . So I am happy, to say, that this is not an issue with Drupal CMS. But none the less it's good to have this option in case there is some mess in a theme.
Thanks again for adding that issue here.
Hm,
so I'll reinstall Drupal CMS to see if this issue is gone. I just changed the link to be able to show you that I clicked the link, and the modal doesn't come up.
That is the real issue; as I said, it hasn't to do anything with Klaro
That you can't reproduce that issue just means that the link in the footer is working, right?
If this is the case then It's just a misconfiguration on my side and everything is fine.
Thank you both so much for responding so quickly. Enjoy your holidays.
Hello Jürgen,
Just watch the video. It took me a while to realize that the problem is not really Klaro, but Menu Link Attributes. It's worth watching the 3-minute video.
I am not sure if I understand it quite right but here we go.
In Drupal CMS there is the footer menu with the link pre-configured ton open up the settings Dialog. They just did what is described here. Add a link and put the rel=“open-consent-manager to it.
But when I looked at the source code using Chrome's developer tools there was no rel attribute attached to the link in the footer, so my hope was that we could get a real link instead of the rel-attribute. I tried to figure it out multiple times yesterday, but I didn't find the cause. Something prevented Drupal from adding the rel-attribute to the link although Klaro is set up correctly and all other stuff seems to work fine. As a result the Modal does not come up at all.
Hello Jan,
at least in Drupal CMS this method does not seem to work. In my tests, for example, the rel attribute in the footer was not appended to the link. In the admin area it works fine. For example, when editing the footer menu. For users who are not logged in (if the rel attribute is not attached), it may also be the case that the dialog is not opened. Is there also a direct link that can be accessed instead of the rel attribute? Could you list it here as an alternative method?
joachim namyslo → created an issue.
Das Ding ist durch. Allerdings müssen wir die Entwickler wohl darauf hinweisen, dass das so keinen Sinn macht. Die Korrekturtexte aus dem Java-Skript des eigentlichen Tools sind nach wie vor Englisch. Was soll denn bitte die Übersetzung des Moduls, wenn du ohnehin nur die hälfte der Funktionen in deiner eigenen Sprache angezeigt bekommst und der Rest wieder Englisch angezeigt wird. Nutzerfreundlich ist das nicht. Da kann man das Toll auch gleich wieder deinstallieren, wenn man Editoren und Autoren hat, die gern in einer deutschen UI arbeiten. Das ist mal wieder nicht wirklich zu ende gedacht.
+1 for #2
Is there any initiative for that allready, where I can learn more about this?
joachim namyslo → created an issue.
Also ich bin da ja im Grunde völlig bei dir. Eindeutschen und des Eindeutschens willen macht keinen Sinn. Allerdings, macht eine Übersetzung, in der Englische Wörter vorkommen, obwohl es eigentlich Deutsche äquivalente dafür gibt halt auch keinen Sinn. Und genau darum geht es.
Wir kämpfen hier seit Jahren darum Drupal so einsteigerfreundlich wie möglich zu gestalten. Mit Drupal CMS sind wir sicher auf einem guten weg. Dennoch erliegen viel von uns immer wieder der Versuchung Lieber Anglizismen stehen zu lassen, statt sich einmal Gedanken darüber zu machen, was denn im Deutschen für Wörter existieren könnten, die sich genauso gut eignen wie das Englische Original.
Natürlich kann mein Feedback hier nur lauten Hey nimm doch statt Issue ein deutsches Wort. Solange wir weder auf Krampf Übersetzungen eindeutschen noch den umgekehrten Fall zu Hart praktizieren ist alles gut.
Ein aktuelles Beispiel gefällig?
Natürlich könnte man im Modul AI alles was mit AI anfängt mit AI übersetzen. Man kann aber auch artificial intelligence mit künstliche Intelligenz und das Kürzel AI mit KI übersetzen, solange es nicht wie in Open AI zu einem Eigennamen gehört. Ich glaube auch nicht, daran, dass die Leute, die damals der Drupal Community den Rücken gekehrt haben, dass aus Gründen der Übersetzung getan haben. Trotzdem weiß ich, dass sich viele Leute hier über sogenannte Edit Wars beklagen. Deswegen gibt es dann halt manchmal etwas zu lang geratene Erklärungen. Das ist besser als Missverständnisse zwischen den wenigen Personen, die hier mit großem Engagement und jeder Menge Energie Drupal in Ihre Muttersprache übersetzen.
Ich finde im Übrigen durchaus, dass es abschreckend ist, wenn man Drupal auf Deutsch installiert und alle 3 Meter trotzdem noch über Englische Zeichenfolgen fällt. Das wirkt so unprofessionell.
Gut, dann möchte ich ein kurzes Update zu diesem Thema geben. Um Issues geht es ja in diesem Modul. Ich habe mir das Ganze im Vorfeld der Veröffentlichung von Drupal CMS noch einmal angeschaut und bin froh, dass ich das gemacht habe.
Was mir bei deiner Übersetzung aufgefallen ist, dass du das Wort Issue statt Problem verwendet hast, so wie ich es oben im Kommentar auch gemacht habe.
Das ist nicht sehr klug, wenn man bedenkt, dass wir mit Drupal CMS vor allem Leute zurück in die Community holen wollen, die wir mit der Veröffentlichung von Drupal 8 verloren haben.
Ich weiß schon, dass es vor allem in der Tech-Bubble, in der wir uns bewegen, viele gibt, die glauben, dass die Verwendung von englischen Begriffen oder englisch klingenden Fachwörtern, wie zum Beispiel Teaser statt Anrisstext, uns immer so ein bisschen vom Rest der Welt abhebt. Aber das ist nicht das, was jemand erwartet, der noch nie mit Drupal zu tun hatte.
Deshalb achten wir bei der Übersetzung von Drupal besonders darauf, möglichst keine englischen Wörter zu verwenden.
So habe ich auch das von dir eingeführte Wort „Issues“ durch das Wort Problem ersetzt. Denn das Modul, das wir hier übersetzen, zeigt Probleme im Zusammenhang mit der Barrierefreiheit einer Website an.
Leider werden solche Audits in vielen Unternehmen sehr oft von Leuten durchgeführt, die sonst wenig mit dem Web zu tun haben und auch mit unserem Tech-Bubble. Diese Leute verstehen es leichter, wenn man ihnen sagt, dass es ein Problem auf einer der Unterseiten im Web gibt. Die Google Webmaster Tools zum Beispiel sprechen auch nicht von Issues in Coverage, wenn sie eine Seite nicht crawlen können. Stattdessen sprechen sie von "Abdeckungsproblemen".
Das ist der Grund, warum wir hier Reviews machen und Feedback geben. Wenn du das nächste Mal ein Modul übersetzt, stell dir einfach vor, du machst es für Lieschen Müller. Lieschen weiß nicht, was ein Issue ist, aber sie hat das Problem, dass ihr Chef sie mit der Verwaltung der Website des Unternehmens beauftragt. Jetzt wird sie mit Drupal konfrontiert und muss damit arbeiten, obwohl sie noch keine Ahnung davon hat. Immerhin kann sich die neue Praktikantin um die Zugänglichkeitsprobleme der neuen Website kümmern. Genau für solche Fälle ist die deutsche Übersetzung von Drupal gedacht. Das bedeutet aber auch, dass wir überall dort, wo unsere Sprache ein Äquivalent hat, deutsche Wörter verwenden:
Newsletter Issue wird zu Newsletter-Ausgabe
Issue Report wird zu Problembericht
Issue zu Problem
usw.
Denn wer mit Drupal aus Sicht eines Entwicklers, Designers oder technisch affinen Menschen arbeitet, der kann für Drupal auch die englischen Built-In-Texte der UI verwenden. Seit dem es den Server für die Übersetzung von Drupal gibt, achten wir in diesem Projekt darauf, dass die Übersetzung sich immer an Menschen richtet, die von Technik, dem Web, oder auch nur dem anlegen von Bildstielen keine Ahnung haben.
Selbst die Entwickler hinter Drupal machen das so. Achte mal drauf, wie viel Aufwand hier betrieben wird, um zum Beispiel zu erklären was Breakpoints sind oder Workflows in Drupal funktionieren. Trotzdem heißen Workflows in der Deutschen Übersetzung von Drupal Arbeitsabläufe.
Nur beim Wort Breakpoint geben wir uns geschlagen. Warum? Weil auch die Fachliteratur zum Thema Responisive Darstellung im Web den Begriff Breakpoint von Haltepunkten spricht. Aber genauso wenig spricht man eben im Zusammenhang mit Barrierefreiheitsproblemen von Issues.
Sei mir also bitte nicht böse, wenn ich das wegkorrigiert habe. Das tue ich, damit die Übersetzungen des Moduls zur vorherrschenden Tonalität in diesem Projekte passen.
Ich danke dir recht herzlich für die Mithilfe beim Übersetzen. Es hilft wirklich jeder Vorschlag. Ich habe mit Blick auf Drupal CMS und dessen Veröffentlichung am 15 Januar noch jede Menge Zeichenfolgen, die übersetzt werden müssen. Auch die Reivew muss für jedes in der neuen kuratiertem Auflage von Drupal verbaute Modul dann noch machen. Es bleibt also spannend und genügend Module, die wir bis dahin übersetzen müssen, haben wir außerdem auch. Wenn du also noch etwas übersetzen möchtest, kannst du dir gerne die in diesem Dokument aufgeführten Module schnappen und nachsehen, was noch zu übersetzen ist. Nochmals recht herzlichen Dank für deine Hilfe.
joachim namyslo → created an issue.
I like the idea +1 fpr this one.
Absolut in Ordnung. Mach das ich gebe dir das frei und Pack die Begriffe ins Glossar.
Vielen Dank.
Alles klar.
Ich bin völlig bei dir. Sag einfach noch mal kurz bescheid wenn du fertig bist, weil wir die finalen Wordings ins Glossar packen müssen, damit zukünftig das gleiche Wirsing weiter verwendet werden kann. Was das Wording angeht, seid ihr völlig frei. Es kommt nicht oft vor, dass Modulentwickler selbst übersetzen. Das ist ohnehin schon ein traumhafter Zustand.
++ for #7. That will solve the problem.
Braucht Review, Rechtschreibfehler dürften hier soweit keine Drin sein. Sagt bescheid, wenn ihr Fehler in der Sinnhaftigkeit findet. Besonders im Bezug auf das Modal von Klaro bin ich mir noch nicht sicher, ob alle Zeichenfolgen wirklich korrekt übersetzt sind. Das finden wir aber sehr schnell raus. Eine Korrektur der entsprechenden Zeichenfolge ist dann kein Problem-
Gut dann machen wir da überall Zweck schreiben können, machen wir das. Super. Danke.
joachim namyslo → created an issue.
Mann ist das ein komplizierter Sch... Mist.
Folgende Begriffe habe ich jetzt mnal als Vorschlääge implementiert.
Klaro! consent manager = Klaro! Constent-Manager
Consent notice = Einwilligungshinweis
Klaro! consent manager modal = Einwillligungsdialog
Notice dialog = Einwilligungsdialog (ist das wirklich der selbe Dialog?)
Klaro = Klaro!
purpose = Zweck (Braucht Kontext für Verarbeitungszweck)
Beispiel.:
Zweck:
Einbinden eines Vimeo-Videos
Verarbeitungszweck:
Übermittlung Ihrer IP-Adresse an Viomeo zum Zweck des Erstellens von Abrufzahlstatistiken…
https://localize.drupal.org/translate/languages/de/translate?sid=3013857 (Wo wird dieser Kontext verwendet.) Dort wo im Deutschen Verarbeitunbgszwck steht oder dort wo Zweck steht. Das Wort Zweck als solches gibt es schon in https://localize.drupal.org/translate/languages/de/translate?sid=24648 Dieses bracht aus diesem Grund keinen gesondeten Kontext.
Ähnliches gilt für das recht junge und bereits uterstützte soziale Netzwerk Threads. Ach hier brachen wir eine Kontext, weil sonst in der Dienstliste von Klaro admin/config/user-interface/klaro/services ert mal Themen steht und keiner weis, was eigentlich gemeint ist. DAs lässt sich zwar ändern, deswegen den Kontext weg zu lassen ist aber auch kene Lösung.
Ich muss mir das mal ansehen. Soweit ich das bis jetzt recherchieren konnte, sagt keiner der deutschsprachigen Anbieter was von Einwilligung. Was mich erst mal sehr irritiert hat. Dann hab ich mir mal die Langding-Pages der einzelne Anbieter dazu angesehen. Onetrust, Cookiebot und so weiter. Die sprechen alle von Consent Management, weil wir hierzulande offenbar in der Tech-Branche einfach cooler klingen, wenn wir möglichst viel Anglizismen verwenden.
Wir können also Consent-Manager schreiben.
Hinweis zur Einwilligung ginge als Workaround auch.
Und das sag ich, der in der Regel immer sowas schrieben würde wie DSGVO-Einwilligungs-Verwaltung Oder Zustimmungshinweis zur Datenverarbeitung. Einfach weil ich beim Übersetzen grundsätzlich immer vom DAU ausgehe. Also jemand der keine Ahnung von Drupal hat und trotzdem damit arbeiten möchte.
Ich bin mal gespannt, was der Rest dazu sagt. Mal abwarten.
Da überschneidet sich nix. Ich hab zugelassen was ok war und der Rest ist nach wie vor als Suggestions drin. Du kannst also auch einfach die Suggestions runterladen, dass sollte reichen. Ich kann das auch einpflegen, ich wollte es nur klären, bevor wir beginnen. Wenn es deine Zeit erlaubt, kannst du das gern korrigieren. Wenn nicht, sag bescheid, dann mach ich das.
Hallo Jan, ich hab mir das mal angesehen und im Grunde nur zwei Kleinigkeiten gefunden.
1. Wir benutzen auf dem Server schon immer orthographische Anführungszeichen. („ ")
2. Mir fällt auf, dass ihr in eurem Modul sehr oft Konsens verwendet,wenn ihr von „Consent" sprecht. Das ist zwar richtig. Allerdings spricht die Davon selbst von einer Einwilligung und nimmt das Wort Konsens sozusagen gar nicht in den Mund. (vgl. DSGVO Art. 4 Nr. 11)
Das gilt nicht nur für Artikel 4 sondern tatsächlich für die gesamte Verordnung, weswegen ich das hier noch mal erwähne. Mir währen Worte wie Einwilligungs- zwar auch zu holprig, aber insgesamt sollte das Wort Einwilligung schon öfter in den Übersetzungen vorkommen, wenn doch sogar die EU das in den eigenen Begriffsbestimmungen so bezeichnet.
Super. Danke.
Deine Vorschläge sind zugelassen und sollten in 30 Minuten vom Server als Aktualisierung angeboten werden. Melde dich gern noch mal und berichte, ob das in der Ui jetzt besser aussieht. Ansonsten werde ich das Modul die Tage mal installieren und mir das noch mal ansehen.
Großartig. Ich sehe mir das heute Abend mal an. Vielen Dank
Any updates on this one. It is a valid issue, still.
Vielen Dank euch beiden. Ich hab die Vorschläge so übernommen, sodass wir theoretisch in 30 Minuten noch mal eine UI-Review machen könnten.
@Jan-Kellermann. Wie sieht es mit einem aktuellen Setup-Guide aus, habt ihr den irgendwo? Ich hätte große Lust, die aktuellen übersetzungen noch mal in einer Livr-Umgebung zu prüfen. Dafür müsste Klaro aber auch irgendwas wegblocken, wie YouTube Vimeo oder auch Matomo. Darum die Frage.
Bitte beachten: https://localize.drupal.de/04%20-%20Stilistische%20Hinweise.html
https://localize.drupal.org/translate/languages/de/translate?sid=2662897
Der Hinweis auf den Entsprechenden Issue befindet sich auf folgender Seite. Die iist auf der Startseite der deutschen Übersetzung auf localize.drupal.org verlinkt.
Wir haben uns seit Drupal 6 bereits daruaf geeinigt, dass wir alle Kontrollabfragen mit möchten sie wirklich abfassen.
https://www.drupal.org/project/de/issues/1536556 →
https://localize.drupal.org/translate/languages/de/translate?sid=2999724
Wir haben uns darauf geeinigt, dass wir zum einen einen eine Formale Ansprache verwenden und zum anderen die anrede Sie wenn immer möglich vermeiden.
Hinzu kommt, dass der Text vermutlich hinter einem Kontrollkästchen steht. Somit ist der Satzbau so sicher nicht korrekt.
https://localize.drupal.org/translate/languages/de/translate?sid=2957825
Ähnliches Problem
Der Klassiker:
https://localize.drupal.org/translate/languages/de/translate?sid=1234154
Heißt meist verwalten dafür braucht man aber ein Gefühl, einfach mehr übersetzen.
Ist zugelassen. Vielen Dank
Hab ich gemacht sollte in 30 - 45 Minuten
live sein. Was ist denn die 3.?
https://localize.drupal.org/translate/languages/de/translate?sid=1736588
https://localize.drupal.org/translate/languages/de/translate?sid=1736598
Das ist seltsam. Man könnte jetzt mal z. B. Spanish installieren und nachsehen ob es da auch klein ist. Sonst müssen wir das debugen
Das Ist leider kein Fehler der Übersetzung sondern ein Fehler im Design von Drupal. Wir suchen den Fehler schon seit Jahren und können ihn zumindest hier auf dem Server lässt sich das weder finden noch fixen.
Würden wir das hier auf dem Server finden, wäre der Fehler bereits behoben und wüssten auch wer den „Mist" freigeschalten hat. Ich bin aber sehr sicher, dass die fehlende Großschreibung über eine Eigenschaft im Css erzwungen wird, weil sich die entsprechenden Strings hier nicht zu finden sind.
@ raffaelj
vielen Dank für deine Hinweise. Die Richtlinien sind angepasst und ergänzt und vor 1 Minute in der neuen Version live gegangen.
Wir haben ja einfache Markdown Dateien. Der Grund warum wir dass dann auf gitlab-Pages machen sollten ist, dass die Richtlinien damals auf drupal.de ausgelagert wurde um ein bisschen mehr als nur Text zum formatieren zu haben. Das war damals noch eine Grav-installation. Da der Hoster aber seine PHP-Version aktualisiert hat und damit die Seite gründlich zerschossen wurde, haben wir die Richtlinien von damals mittels Wayback machine wiederherstellen müssen. Wenn die Richtlinien weiter über Drupal.de abrufbar bleiben sollen, dann müssen wir sie dort auch hosten. Eventuell will die DA. allerdings den User-Guide auf MKDocks umstellen. Dann könnten wir die Richtlinien auch auf d.o hosten. Neil Drumm hat sich dazu aber noch nicht geäußert. Lediglich Joe Shindelar von Drupalize.me fand die Idee bis jetzt brauchbar. Deswegen dauert es noch, bis ich weiss, wie wir das lósen.
Ja, die Repo ist die In der die Credits für zugelassene Übersetzungen gespeichert werden. Deswegen sieht die so alt aus. Einfach weil sie es ist. Die ist so alt wie der älteste String auf dem Übersetzungsserver, bzw der älteste Issue im Projekt DE.
Die Repo mit der MKDocks-Version der Richtlinie liegt auf dem Server des Drupal e.V und ist aktuell nicht von außen zugänglich. Eventuell kriegen wir sie aber auf unsere Gitlab-Instanz und können zukünftig GithubPages verwenden, dann wären Merge-Requests möglich.
Mach dir da mal keine Sorgen, ich winke so gut wie alles durch, was sich an die grundlegenden Regeln hält. Wenn du in deinem Modul gendern möchtest. kann ich das auch nicht verhindern. Es ist allerdings so, dass wir das in diesem Projekt bis jetzt nicht gemacht haben und vermutlich nie über das ganze Projekt darüberstülpen werden können. Deswegen wäre es nett, wenn auch du einfach das generische Maskulinum verwendest, damit wir das Projekt so lange sauber halten, bis wir geklärt haben, ob jemand ein zweites eröffnen und betreuen möchte oder ob eine Gruppe von Nutzern aus der Community das gesamte Projekt entsprechend anpasst von Drupal 5 bis 11 in manchen Übersetzungen zu gendern und in manchen nicht macht aktuell keinen Sinn.
Verwende also bitte bis auf weiteres das übliche Benutzer Administrator usw. Wenn damit wirklich ein ernsthaftes Problem hat, dann wird sie oder er schon in diesen Issue schreiben und die Betreuung eines offiziellen Projektes in die entsprechende Richtung in der passenden Issue Queue beantragen. Übersetzungen mit * können wir durchwinken, wenn sich jemand findet, der das zuverlässig implementieren möchte und das auch tut. Mischen werden wir hier vorerst nicht. Das macht nämlich Arbeit und die machen ja eh schon sehr wenige.
Nein, da wirds auch keine Einigung gebebn. Es ist einfach so, dass hier in diesem Projekt Seit Drupal 5 übersetzt wird. Wenn wir uns dazu mal ansehen, wer hier wie viel Übersretzt hat und warukm dann fällt ganz schnell auf, dass der letztplatzierte Nutzer unter den Top 10 der Übersetzer lediglich 2180 zugelassene Zeichenfolgen übersetzt hat. Der Punkt ist, jetzt, dass es Leute gibt, die zwar den Mund aufmachen und sagen, Hey, wir müssen Gendern., aber das scheitert schon mal daran, dass selbst die ungegenderte Version dieses Projektes nicht unbedingt viele Leute regelmäßig voranbringen wollen.
Aus meiner Sicht wäre daher ein unabhängiges Projekt, in dem auf das Gendern achtet und und Dinge wie Glottisschlag ein Sternchen mitten im Wort oder anderes verwendet, die beste Lösung. Vielleicht liegt das daran, dass ich als Franke damit leben muss, dass die Bayern ihren Friestaat um unser schönes Franken außen rum gebaut haben und daher etwas abfärben.
In Bayern heißt es, wer nicht gendern will, der muss nicht.
Ich persönliche hätte das auch gern für Drupal. Ich will weder alle 184428 bis jetzt erstelltem Übersetzungen auf die Notwendigkeit überprüfen müssen. ob da jetzt ein Sternchen, ein Glottisschlag oder sonst was reingehören könnte, noch will ich das als Anwender in der Drupal UI lesen müssen.
Dann gibt's kja aber noch die anderen, die das zu wollen scheinen.
Deswegen halte ich den Vorschlag von Karsten auch für am Besten. Er sagt man solle für dieses Anliegen ein neues Projekt auf localize.drupal.org zu eröffnen.
Wenn das Bedürfnisse nach einer gegenderten Version der Übersetzung der Benutzeroberfläche in der Deutschsprachigen Drupal-Community wirklich so groß ist, dann wird sich auch jemand finden, der das b0treuen und angehen möchte. Aufgrund der Zahlen der zugelassenen Übersetzungen der Top 10 der Übersetzer, die wir Projekt De haben, gehe ich aber eher davon aus, dass das nicht passieren wird. Der Punkt ist nämlich, wenn man etwas möchte, dann muss man nicht nur einen Issue über 4 Jahre pflegen, den keiner weitereditiert, sondern auch was tun. Taten würde sich meiner Meinung nach im Vorhandensein von gegenderten Zeichenfolgen oder eines Issues für das Anlagen eines entsprechenden Projektes äußern. Also etwas das man Anfassen, sehen oder zumindest lesen kann.
Da weder das eine noch das andere vorhanden sind, könnte man den Issue genauso gut schließen. Aber als ich das das letzte mal versucht hatte, wurde da bemängelt, also bleibt er halt offen.
Versteht mich nicht falsch, ich bin nicht generelle gegens gendern. Wenn die Leute das wollen, sollen sie es doch bitte machen, aber dann müssen sie es eben auch tun.
Wahnsinn 2 Leute haben da drüber gesehen und ein dritter findet auf der ersten Seite tatsächlich Fehler.
Ich danke dir. Ich werde die Git-Repo auschecken und das ganze Zeitnah überarbeiten.
I tell you what I did.
Used mkall.sh and built the guide just as usual
Then I used this little guy with this particular addon and all I have to do to get the 11.x version of the guide now, is to fix the tables.
Besides that, importing the HTML files from the guide's German version worked effortlessly.
So perhaps there is a chance we can host markdown files directly on GitHub pages in the future so we can iterate much faster then?
Converting markdown into other formats like epub and mobi as well as PDF shouldn't be that hard I like to test that as soon as I have fixed the tables in the markdown of the guide. If it helps I can take the English source and upload a fixed markdown version here.
mkdocks is, the right approach, at least iin my opinion. This way, we can continue to work directly in the GitHub editor and, if necessary, simply build a new output every x days or hours. Even I can manage that, and I think I know a lot less about DevOps than some other members of the Drupal community. Perhaps a version written in Markdown would just help to speed up the whole process, and thus relieve the DA relatively fast.
joachim namyslo → created an issue.
Also ich hab mir das Ganze jetzt mal in Drupal 11 angesehen und fleißig drauflos korrigiert. Ich weiß ja nicht, wei ihr das seht, aber ich spreche in der Regel nicht von Issues. Ich spreche von Problemen. Also problem-Berichten, (Issue-Roperts) in denen ein bestimmtes Problem) (ein Issue) beschrieben wird, das es zu lösen gilt. Deswegen habe ich zum Beispiel auch aus Issue an dieser stelle auch mal Problem gemacht. Denn wo immer es deutsches Wort für einen Begriff gibt, verwende ich das auch. Ich sage in der Regel auch zu meinen Kunden nicht, ich glaube wir haben da einen Issue. Aber gut, vielleicht machen das manche Menschen tatsächlich.
Ansonsten haben wir hier wieder den Klassiker, dass es keinen Kontext für das Wort Issue im Modul gibt. Deswegen steht da an einigen Stellen dann Ausgabe. Denn ein Issue eines Newsletters ist eine Ausgabe eines Newsletters. Das Wort kommt also aus Simplenews. Ändern können wir daran nichts. Hier fehlt ein Patch für einen einsprechenden Translation Content, dass geht nur im Code des Modules und nicht direkt über den Übersetzungsserver. Ansonsten muss ich jetzt noch ein Bisschen Inhalt Erzeugen, um diese Barrierefreiheitsprüfung vollumfänglich testen zu können. Ich bleib dran.
joachim namyslo → created an issue.