Font-Tags im DOM: Ein Gruß aus 2005

Die Tage meldete sich ein Steuerberater, der gerade Taxaro ausprobiert und berichtete davon, dass er beim Versuch einen Vorgang anzulegen in einen Fehler läuft. Das ist so ziemlich das zentralste Konzept der ganzen Software und wenn man etwas nicht will, dann, dass ein User in der Probephase an dieser Stelle scheitert – schon gar nicht an einem Bug.

Das Ding war nur: Diese Stelle ist nicht nur gut getestet, sie wurde seit der letzten relevanten Änderung auch tausende Male von anderen Anwendern genutzt, ohne dass etwas zu Bruch ging.

Beim genauen Blick in die Logs waren sich Claude Code und Codex dann einig: Die automatische Übersetzung war schuld. Und das ging so: Das HTML-Dokument, in dem die React-App eingebettet ist, nutzte als Sprache "en". Englisch war allerdings auf dem deutschen Windows-System und im Edge-Browser des Anwenders nicht verfügbar. Daher schlug ihm dieser beim ersten Aufruf von Taxaro vor, die Inhalte auf Deutsch zu übersetzen. Darauf folgte eine Manipulation des Quellcodes, u. a. durch eingefügte Font-Tags (sic!) ins DOM. In weiten Teilen der Anwendung war das kein Problem, aber an dieser spezifischen Stelle verschluckte sich React dann schließlich und die App ging in die Brüche.

Darauf wäre ich wahrscheinlich auch beim 5. Blick auf den Stacktrace selbst nicht so schnell gekommen, auch wenn ich vmtl. 1999 das letzte Mal selbst Font-Tags genutzt habe.

Die Lösung lag dann einfach darin, das translate-Attribut auf dem HTML-Tag auf "no" zu stellen.

Aber ein wenig fühlte es sich an wie eine Reise ins Jahr 2005 oder 2010, als derartige Überraschungen in Browsern – früher Internet Explorer, später Safari – gefühlt an der Tagesordnung waren. Tatsächlich habe ich schon seit Jahren keine derartigen Kapriolen mehr erlebt.