Nicht importierbare Übersetzungen (disallowed/malformed HTML) heilen

https://localize.drupal.org/translate/languages/de/translate?project&sta...

Hallo @hexabinaer,

Der kurze Weg ist keine Option. Ich will dir auch verraten warum.

Ich hab durchaus schon das ein oder andere Modul von falsch zusammengesetzten Zeichenfolgen befreit. Im Ergebnis passiert dann folgendes:

1. Die Zeichenfolge ist nicht mehr als übersetzt markiert und kann auf dem Server neu übersetzt werden.
2. Die Datei, die die entsprechende Übersetzung enthält und vom Server zum Download angeboten wird, wird nicht neu angelegt. Das bedeutet, dass beim Installieren des jeweils betroffenen Moduls trotz Entfernung der betroffenen Übersetzung der Fehler bezüglich der falschen Übersetzung immer noch ausgegeben wird.

Die Datei wird nämlich erst dann neu erzeugt, wenn für den betreffenden String eine Alternative zugelassen wird. Das geht aber nur bedingt, weil das Original in einem solchen Fall meist so Falch abgefasst ist, dass man hier keinen Workarround basteln kann.

Das bedeutet, dass wir

1. Falsch abgefasste Zeichenfolgen zukünftig beim extrahieren der Strings, also über das POTX-Modul abfangen müssen.
2. Entwicklern einen Standard an die Hand geben müssen, der beschreibt, wie Übersetzungen in den Quellcode einzufassen sind. Nämlich so, dass sie keine Zusatzattribute oder Platzhalter enthalten die von https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul... nicht akzeptiert werden.

Abschließend brauchen wir dann auch noch eine Funktion im Übersetzungsserver, die alle Dateien. die solche Zeichenfolgen enthalten Erkennen und die jeweiligen Projekte informieren kann, dass der Code entsprechend des Standards, der übrigens immer noch nicht verabschiedet wurde anzupassen sind, um die gefundenen Fehler zukünftig zu vermeiden.

Das ist nichts, was man hier im der Issue Queue lösen kann. Das Problem gehört auf wesentlich höherer Ebene gelöst.

Selbst wenn wir eine Liste der betroffenen PO Dateien und Strings anlegen. Können die nur von Drum oder Gabor manuell gelöscht und dann neu erstellt werden.

Der Benefit wäre lediglich, dass Drupal beim Import der Module keine Fehlermeldungen bezüglich flach formatierter Übersetzungen ausgibt und daher rein kosmetischer Natur. Am eigentlichen Problem. ändert das leider rein gar nichts.

Wäre da anders, hätte ich schon längst eine solche Liste angelegt. Aber ich scheue den Arbeitsaufwand. weil mir das Ergebnis nicht wertvoll genug erscheint, im Verhältnis dazu , dass wir für jede fehlerhaft ausgegeben Zeichenfolge die Datei notieren müssen, die sie enthält und diese Liste, wenn sie jemals fertig wird in die USA weitergeben müssen. Dazu müssten Wir die Distributionen von Varbase, open Social und Thunder sowie einige vereinzelte anderen Module vermutlich jeweils gegen Drupal 9 und Drupal 10 testen, um die betroffenen Dateien zu ermitteln. Mir persönlich ist das zu aufwändig für ein rien kosmetische Maßnahme.

Die Originalzeichenfolgen der Übersetzung enthalten Fehler. Das darf man auch gern genau so lang sehen, bis wir als Community eine ganzheitliche Lösung dafür finden.

Ich bin mir nicht sicher, ob der kurze Weg wirklich keine Option ist. Wenn wir in Übersetzungen irgendetwas reinschreiben, das mit dem Ursprung gar nichts zu tun hat, interessiert das die Logik des Localisation-Server überhaupt nicht. Es wird ja keine logische Prüfung gemacht, ob der übersetzte String wirklich die Übersetzung des Ursprungs-Strings ist.

Deshalb denke ich schon, dass die HTML-Tags problemlos korrigiert werden können, ohne dass dies den zukünftigen Prozess irgendwie beeinträchtigen würde. Und ich fände es auch sehr hilfreich, wenn diese Korrekturen gemacht werden würden, denn die Fehlermeldungen sind für uns mehr als nur kosmetischer Natur. Wir behandeln bei uns Fehler als zwingende Handlungsaufforderung, sprich bei jedem Fehler wird ein Issue eröffnet, welches bearbeitet werden muss. Ignorieren ist keine Option.

In dem Fall werde ich Anfangen müssen zu sammeln. Nur das wir nicht irgendwas in die Strings schreiben können, weil das so in die Ui übernommen würde. Letzten Endes müssen die Fehler aber dennoch aus dem Sourcecode.
Das der Server das aktuell nichts prüft ist mir bewusst. Wir benötigen aber eine Möglichkeit, Projektbetreuer auf fehlerhafte Quellzeichenfolgen hinzuweisen, wenn das in Zukunft gelöst werden soll. Ein Mechanismus diese bereits beim vor Release einer neuen Modulversion zu erkennen fehlt. Genau wie eine Routine, die vorhandene Pot/PO Dateien auf eben solche Fehler überprüfen kann und eine entsprechende Liste generiert.

Das gehört entweder ins Potx Modul oder in die Version 3.x des Servers. Sonst sind solche Vereinigungsaktionen auch in Zukunft noch regelmäßig notwendig.

Ich werde mich die Tage mal an eine Liste setzen. Sollte euch in der täglichen Arbeit was auffallen, postet bitte in diesem Sammelthread.

Vielen Dank

Super @Joachim Namyslo und herzlichen Dank, dass Du das Thema angehst.

Nur mal ein Beispiel: in commerce ist folgender Übersetzungsstring drin:

Für diese Bestellung sind keine <a href=":url"">Zahlungsgateways</a> verfügbar.

Der ist falsch wegen des doppelten Anführungszeichens und wird deshalb mit der Meldung `... was skipped because of disallowed or malformed HTML.` ignoriert.

Ein anderes Beispiel in Webform ist Folgendes, wobei ich das keinen Fehler finde und da gibt es auch gar nichts zu übersetzen:

<div class="webform-custom-options-buttons">
{% for value, text in options %}
  <div class="webform-custom-options-button" data-option-value="{{ value }}" style="text-align:center">
  {{ text }}
  {% if descriptions[value] %}<div class="description">{{ descriptions[value] }}</div>{% endif %}
  </div>
{% endfor %}
</div>

In Webform gibt es auch den String <front> als Übersetzung, was ebenfalls falsches HTML ist und eigentlich gar nicht übersetzt werden sollte.

Wenn ich noch weitere Beispiele finde, dann melde ich mich wieder.

Für diese Bestellung sind keine Zahlungsgateways verfügbar.

https://localize.drupal.org/translate/languages/de/translate?sid=2661980
Fixed. - Muss noch gemeldet werden

in Bezug auf #7 →

Wir benötigen aber eine Möglichkeit, Projektbetreuer auf fehlerhafte Quellzeichenfolgen hinzuweisen, wenn das in Zukunft gelöst werden soll. Ein Mechanismus diese bereits beim vor Release einer neuen Modulversion zu erkennen fehlt. Genau wie eine Routine, die vorhandene Pot/PO Dateien auf eben solche Fehler überprüfen kann und eine entsprechende Liste generiert.

Wäre es evtl. nicht die elegantere Variante Übersetzer*innen schon beim Abspeichern des Übersetzungsvorschlags auf unerlaubte Zeichenfolgen hinzuweisen, so daß solche problematischen Zeichenfolgen erst gar nicht erst in der Datenbank abgelegt werden? Das würde auch Maintainer*innen extra Aufwand bzgl etwaigen Korrekturen im Nachgang ersparen.

Ich weiss nicht. Ich persönlich fände es wesentlich eleganter, wenn übersetzer zukünftig gar nicht mehr mit Fehlerhaften Strings arbeiten müssten oder besser dagegen. Fehlerhafte Strings entstehen dort, wo Module geschrieben werden. Wenn wir die Entwickler soweit kriegen keine Fehler mehr zu machen und bereits vorhandenen Fehler auszumerzen, dann läuft alles rund.So einen Fehler gibt es ja nicht nur in der Übersetzung für Deutsch, sondern immer in den Source-Strings. Dies bedeutet, der wirkt sich auf alle Sprachen aus. Wenn die UI 115 Sprachen unterstützt macht 1 falsch abgefasst er Originalstring potentiell 115 Fehlermeldungen. Ein ganzheitliche und gut durchdachte Lösung eliminiert an dieser Stelle die Möglichkeit, dass Übersetzer falsch abgefasst Zeichenfolgen überhaupt zu Gesicht bekommen. Aber dazu muss man die bereits vorhandenen fehlerhaften erst Mal finden und eliminieren.

Fehler komplett zu vermeiden bleibt wohl ein frommer Wunsch. Aber Fehler früh zu erkennen und zu melden, ist realistisch.

Ich denke, wir sollten die Validierung in die gitlab CI Templates mit aufnehmen, damit alle Module bei jeder Änderung immer automatisch geprüft werden und die Entwickler eine Fehlermeldung erhalten, wenn ein string falsch ist.

Siehe https://drupal.slack.com/archives/CGKLP028K/p1712081707946159?thread_ts=...

Das ist ein guter Ansatz. Ich habe die Zeichenfolge

{% for value, text in options %}

{{ text }}
{% if descriptions[value] %}

{{ descriptions[value] }}

{% endif %}

{% endfor %}

aus Webform entfernt und zumindest ich hab keinen Fehler mehr, wenn ich das Modul installiere. Kann das bitte jemand verifizierren. Dann können wir auf die art und weise weitermachen.

Perfekt, webform importiert ohne Fehlermeldung! :-)

Alles klar, dann machen wir an der Stelle genauso weiter.

https://localize.drupal.org/translate/languages/de/translate?sid=2922192
https://localize.drupal.org/translate/languages/de/translate?sid=2890191
https://localize.drupal.org/translate/languages/de/translate?sid=2888203

Enthalten offenbar alle fehlerhaftes HTML. Erst mal Löschen, dann drüber nachdenken.

Beim Lesen der Kommentare bekam ich kurz Puls, weil das ja keine Frage von Entweder-Oder ist :-D Aber darauf lief es ja gar nicht hinaus.

Ich denke, wir sollten die Validierung in die gitlab CI Templates mit aufnehmen, damit alle Module bei jeder Änderung immer automatisch geprüft werden und die Entwickler eine Fehlermeldung erhalten, wenn ein string falsch ist.

Jawoll, das brauchen wir auf jeden Fall. Unterstützung bei der Fehlervermeidung wo immer es geht. Deshalb bin ich ja auch für das Rausschreiben von fehlerhaftem HTML beim Übersetzen. Nicht als einzige Maßnahme, aber eine, die die Nerven derjenigen schont, die Übersetzungen importieren.

Bei unseren eigenen Patzern sind wir dazu übergegangen, als erstes die Übersetzungen zu fixen, einfach weil's schnell geht. Wir notieren die Übersetzung zusammen mit den Source-Korrekturen, so dass wir sie schnell zur Hand haben, wenn das nächste Release rauskommt.

#19

Ich bin da absolut bei dir. Es ist aber tatsächlich so, dass wir mit der Korrektur falscher Zeichenfolge verhindern, dass das Thema an der richtigen Stelle ankommt. Korrigieren, bzw rauslöschen, war bis jetzt immer der Way to go. Das führte aber nur in den seltensten Fällen zur Besserung der Originale. Ich denke wir behindern uns mit dieser Methode selbst. Der Endanwender hat jetzt kein Thema mehr. Aber der Übersetzer, der seine Tätigkeit unentgeltlich ausführt durchaus. Wem sollen wir dass denn Bitteschön darlegen, damit im Endergebnis bereits vorhandene falsch abgefasste Zeichenfolgen nicht nur mittels Patch neu abgefasst, sondern nachhaltig entfernt werden? Ich finde das braucht Aufmerksamkeit. So laut und so lang bis es so weh tut, bis wir eine gute Lösung für die Zukunft haben. Wo soll es denn weh tun, wenn nicht beim Import? Geht ja nur da.

Die Lösung mit der Pipeline ist gut, aber leider nur die halbe Miete.