Gendern im Markup und in Programmiersprachen
von Sven Köppel

Geschlechtergerechte Sprache ist in aller Munde. In diesem Blogpost möchte ich die politische Dimension außer Acht lassen und als gesetzt nehmen, dass in einem (Programmier-)projekt das Gendern von Kund(inn)enseite aus gewünscht ist. Wie ist damit umzugehen? Welche technische Unterstützung und welche Hürden sind zu erwarten?
Eine Momentaufnahme der Internationalisierung und UX
Soziale Strukturen bilden sich in der Software ab, dies ist ein bekanntes Anti-Pattern der Softwareentwicklung. Leider ist die Männerquote in der IT immer noch weit über der absoluten Mehrheit. Das zeigt sich in Systemen, die solche Personen schreiben. Veraltete Libraries sind nicht umbedingt das Problem: So unterstützen Internationalisiserungs-Bibliotheken wie gettext die Sprachgestaltung nicht nur hinsichtlich Pluralformen, sondern mit Kontexten auch hinsichtlich Geschlechtern, vgl. etwa diese StackOverflow-Frage: Handling grammatical gender with Gettext. Ein solcher Kontext würde prinzipiell auch nicht-binäre Varianten erlauben. Eine andere Problematik ergibt sich im User Interfacing (UX): Liberale Positionen sind hier eigentlich schon lange zur Auffassung gekommen, die Wahl der Anrede (zB. du/sie, Herr/Frau, aber auch er/sie/es bzw. komplett Freiform) der ausfüllenden/anmeldenden Person zu überlassen. Aus Perspektive einer Softwareschmiede kann man hier nur die Position einer Unternehmensberatung einnehmen, welche Kund(inn)en darin berät, diese Prinzipien anzuwenden.
Gendern im Markup-Fließtext
Die eigentliche Problematik beginnt aber beim Umgang mit User generated Content, etwa
in seiner freisten Form als Fließtext mit Formatierungsanweisungen (Markup). So habe ich es
vor zwei Jahren einmal bei dem kleinen Zeitungsstartup
Perspective Daily erlebt, welches aus einer progressiven
Autor(innen)schaft bestand, welche seinerzeit das Gendersternchen
verwendete — allerdings in Texten, die mit Markdown
ausgezeichnet wurden. Das Ergebnis war technisches Versagen, denn das Sternchen
(Asterisk, ASCII-Zeichen wird
bei Markdown verwendet, um Kursivschrift zu
markieren. Korrekterweise muss die Person, die einen Text in Markdown gendern möchte, dazu
angehalten werden, das Gendersternchen zu maskieren.
Statt Programmierer*innen
müsste die Autorenschaft dann Programmierer\*innen
schreiben, damit es als Programmierer*innen dargestellt wird. Da dies wiederum als der
Autorenschaft nicht zuzumuten galt, habe ich seinerzeit versucht die Problematik zu entschärfen,
in dem ich mit regulären Ausdrücken als Preprocessing das Gendern erkannt und maskiert habe,
hier etwa in Python (siehe Github Gist
für weiteren Code):
> for x in ["Gender*nnen","foo *bar* baz", "foo *bar*baz", "Und *das* ist wirklich Mensch*nnen *und* toll."]:
> print(re.sub(r"(^|\s)(\w+)\*([^.\s]*\w+)($|\s)", r"\1\2\*\3\4", x))
Gender\*nnen
foo *bar* baz
foo *bar*baz
Und *das* ist wirklich Mensch\*nnen *und* toll.
An den Testbeispielen sieht man, dass der vorgeschlagene reguläre Ausdruck einigermaßen zu klappen scheint, aber die Praxis lehrt, dass der eine oder andere Randfall dann doch unberücksichtigt bleibt. Aus Sicht der Programmierenden handelt es sich um ein klassisches Problem der Kontextwechsel; über dieses Problem hat ein Kollege von mir schon vor über 10 Jahren einen Artikel im Zusammenhang mit SQL-Injections geschrieben, damals noch bei SELFHTML: Programmiertechnik/Kontextwechsel.
Kontextwechsel und Orthogonalität als grundlegendes Problem in der angewandten Informatik
Die Grundproblematik ist also, dass eine Markupsprache wie Markdown davon ausgeht, dass
der Asterisk (also das Sternchen) im Fließtext selten vorkommt. Nur mit dieser Annahme
ist es sinnvoll, den Asterisk als Markup-Zeichen zu verwenden. Das zugrundeliegende
Konzept kann auch mit der Orthogonalität
in der Informatik verglichen werden: Markup-Sprache und zugrundeliegende Sprache stehen
orthogonal aufeinander, weil sie wenig gemeinsame Zeichen teilen. Steueranweisungen und
menschliche Sprache stehen orthogonal aufeinander. Es gibt hier natürlich eine einfache
Lösung, etwa den Wechsel der Auszeichnungssprache, z.B. von Markdown zu
reStructuredText oder
etwa dem MediaWiki-Markup, in welchem
Kursiv- und Dickschrift mit ''einfachen'' Anführungsstrichen
ausgezeichnet werden.
Generell sind diese Markupschriften als vereinfachte Formen von Sprachen wie
HTML oder XML entstanden, welches den Kontextwechsel
stets mit eckigen Klammern vornimmt. Grundsätzlich lässt sich Markup nicht losgelöst
vom Inhalt betrachten. Eine solche Kodierung lässt sich nur ermöglichen, wenn man
maschinennähere Textrepräsentationen erwägt, bei welchen es keine Vermischung mehr
von Inhalt und Formatierungsanweisungen gibt. Im Grunde genommen sind Benutzer:innen
derartiges von Wortprozessoren
gewohnt, die von der internen Textrepräsentation abstrahieren und ein
WYSIWYG-Interface anbieten, was kurz steht für What You See Is What You Get.
Solche WYSIWYG-Benutzerschnittstellen haben in den letzten Jahren etwas an Boden verloren. Der schnelle technische Fortschritt hat da sicher beigetragen, Anforderungen haben sich mehr an den Entwickeldnen als an den Benutzenden orientiert. Das kleine Zeitungs-Startup, von dem ich oben schrieb, verwendete eine Markupsprache, damit sie ihr Zeitungsportal schneller “gelauncht” bekamen. Und soziale Netzwerke wie Twitter verwenden Markup — und dazu zählt konzeptionell auch der berühmte Hashtag — vermascht mit anderem Plaintext zwecks schneller Bearbeitung von Tweets. Eine Notiz hier nur am Rande: Tatsächlich wurden Hashtags von den Benutzenden der Plattform selbst erfunden und eingeführt, die Plattform hat sich diese erfolgreiche Technik letztlich zu eigen gemacht. Diese Erfindung wäre nicht anders als mit einer Auszeichnungssprache, die “ontop” des menschlichen Textes erfunden wurde, möglich gewesen, da Benutzende nicht in die Programmierung der proprietären Anwendung eingreifen können.
Doppelpunkt, Auslassungszeichen oder Sternchen?
Vor dem dargelegten Hintergrund von Vermaschung konstruierter (technischer)
Programmiersprache und menschlicher Sprache ist es doch seltsam, dass der Doppelpunkt
als Genderzeichen (wie in Programmierer:innen
) eingeführt wurde, just um technischen
Limitationen zu umgehen: Es wurde nämlich beobachtet, dass der Doppelpunkt von
Sprachsyntheseprogrammen (Text-to-Speech)
zu einer kurzen Pause führte, welcher ähnlich wie der
Glottisschlag interpretiert wurde.
Es dauert nicht lange, um Beispiele zu finden, wo der Doppelpunkt hingegen wieder
negativ mit der Technik interferiert, etwa innerhalb der verbreiteten
Auszeichnungssprache YAML, in der es (angelehnt
an viele Programmiersprachen) zur Trennung von Schlüssel und Wert bei der Definition
einer Tabelle/Abbildung/Dictionary dient. Die Lösung ist hier, da ein strukturgebender
Kontext vorliegt, allerdings einfacher, da der Wert (Textstring) einfach durch
Anführungsstriche maskiert wird. Aus schlüssel:wert
kann nämlich equivalent
"schlüssel":"wert"
werden, sodass "Programmierer:innen sind":"auch Anwender:innen"
valides YAML ist.
So entsteht eine kleine Matrix, welche Genderform mit welcher Markupsprache einfach zu benutzen (“kompatibel”) ist:
Paarform | Markdown | RST | LaTeX | HTML | YAML |
---|---|---|---|---|---|
Lehrer(innen) |
✅ | ✅ | ✅ | ✅ | ✅ |
Lehrerinnen/Lehrer |
✅ | ✅ | 🟡 (Quirky) | ✅ | ✅ |
Lehrer*innen |
❌ | ✅ | ✅ | ✅ | ✅ |
Lehrer_innen |
✅ | ✅ | ❌ | ✅ | ✅ |
Lehrer:innen |
✅ | ✅ | ✅ | ✅ | ❌ |
Die Tabelle zeigt, dass manche Sprachen wie reStructuredText (RST) oder HTML mit fast jeder Variante klarkommen, wohingegen es in anderen Sprachen häufig Probleme gibt, die eine Maskierung (Escaping) nötig machen. Nur die in natürlichen Sprachen recht häufigen runden Klammern stellen in keiner der verglichenen Sprachen ein Problem dar.
Abgünde des Parsings
Die Probleme mit Markierungszeichen für Sprachformen gehen aber über bloße Darstellungsfehler hinaus: Das Gendern von Texten kann die AnwenderInnen zur regelrechten Verzweiflung bringen. Das Zeitungs-Startup benutzte intern auch das freie Textsatzprogramm LaTeX. LaTeX ist heute der defakto-Standard zum Schreiben von wissenschaftlichen Aufsätzen, vor allem in dem naturwissenschaftlich-technischen Bereich. Es ist außerdem Defakto-Standard für die Repräsentation von komplizierten mathematischen Formeln sowie ihrer Darstellung (Rendering). Latex-Code ist auf dem Kontinuum zwischen Programmiersprachen und Markup-Sprachen noch ein Stück näher an der Maschine, als es vielleicht YAML ist. Im Grunde genommen ist ein Latex-Code ein ausführbares Computerprogramm, welches von dem Interpreter in eine andere Darstellung, etwa ein PDF-Dokument umgewandelt ist. Es ist damit mit der Seitenbeschreibungssprache Postscript vergleichbar, die wiederum die Grundlage für das PDF-Format darstellt. An dieser Stelle möchte ich gerne das Hello-World-Beispiel über Postscript aus Wikipedia zitieren:
%!PS
/Courier
20 selectfont
72 500 moveto
(Hello world!) show
showpage
Dieser Code liest sich wie ein Buch zeile für zeile von links nach rechts. Postscript ist
eine stackorientierte Programmiersprache, weswegen zunächst alle erwähnten Dinge auf einen
virtuellen “Stapel” gelegt werden, wo sie von Anweisungen, die Postscript versteht, dann
“heruntergeholt” werden. So landet auch die Zeichenkette Hello world!
auf dem Stapel,
ehe sie von show
zur Anzeige gebracht wird. Wieder haben wir es mit einem Escape-Problem
zu tun, es wäre gar nicht einfach Hello (cruel) world
zu schreiben, ohne mit den runden
Klammern von Postscript ins Gehege zu kommen. Der binäre Zugang, der allerdings in keiner
praktikablen Programmiersprache gewählt wird, wäre an so einer Stelle im Übrigen die
Definition des Strings als fixed length string, sodass der String selber von keinem
Compiler auf Escape-Sequenzen interpretiert werden muss. Auf diese Weise funktionieren die
allermeisten Netzwerkprotokolle und auch die meisten Stringinterpretationen auf Maschinenebene.
Wer sich darüber etwas informieren möchte, findet mit der
Abstract Syntax Notation One (ASN.1) einen guten
Startpunkt.
Was passiert nun, wenn man bei Latex mit Unterstrich gendert? Probieren wir es mit einem minimally not working example aus:
\documentclass{article}
\begin{document}
DenktMit Programmier_innen sind Gött_innen in schwarz.
\end{document}
Dieses Dokument mit pdflatex
kompliert gibt bei mir folgende Ausgabe:
sven@localhost /tmp/foo % pdflatex gender.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Arch Linux) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./gender.txt
LaTeX2e <2020-10-01> patch level 2
L3 programming layer <2020-12-03> xparse <2020-03-03>
(/usr/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/usr/share/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
No file gender.aux.
! Missing $ inserted.
<inserted text>
$
l.3 DenktMit Programmier_
innen sind Gött_innen in schwarz.
?
PDFLatex ist abgestürzt. Das tut es bei Syntaxfehlern immer, und hier liegt ein
solcher Syntaxfehler vor. Der Unterstrich ist ein
reserviertes Zeichen und
damit Teil der Menge # $ % & { } _ ~ ^ \
. Latex ist eine alte Software mit
vielen Quirks, man sagt nur Latex könne Latex parsen. Je nach Kontext ist der
Unterstrich doch wieder zulässig, etwa in einer Mathematikumgebung (die ihrerseits
mit einem Dollarzeichen $
eingeleitet wird), oder in einer URL (aber
nur, wenn Hyperref das richtig versteht).
Sobald ein Texcode geringfügig komplizierter wird als das hier gezeigte,
sind die Fehlermeldungen schnell kryptisch und die Fehlerursachen nicht mehr
so schnell zu finden, wenn man nicht ein paar Jahre Latex-Erfahrung angesammelt
hat. Wo Markdown einfach still und “resistent” ein Markup erstellt, welches so
nicht gedacht war, stoppt Latex die Ausführung komplett. Für Benutzende ist
das frustrierend.
Quo vadis, Programmiersprache?
Eine Programmiersprache, die sich an den Bedürfnissen der echten Sprache anpasst, ist mir bislang noch nicht begegnet. Es ist eher ein Trial-and-Error, ein gegenseitiges Austarieren zwischen wirtschaftlichem Einsatz von programmierenden und benutzendem Personal. Immerhin haben Sprachdebatten und Neuentwicklungen bei Programmiersprachen eine Gemeinsamkeit: Beide sind geführt vom Geist der Veränderung. Sprache, egal ob natürlich oder künstlich, ist ein menschgemachtes Konstrukt und ein Konsens. Als Entwickler maße ich es mir nicht an, über den Inhalt meiner datenverarbeitenden Systeme zu werten.
Disclaimer
Zuguterletzt gebe ich doch noch meine Meinung zu diesem strittigen Thema ab. Sie ist wahrscheinlich auch schon hier und da durchgeblitzt. Als typischer “alter weißer Mann” und Partner und Vater von Frau(en) versuche ich, mir die systemische Geschlechterdiskriminierung (etwa gegenüber Frauen) und meine “Vormachtposition” gelegentlich zu vergegenwärtigen. Ich lehne das generische Maskulinum ab und halte das “Genus vs. Sexus”-Argument für einen Vorwand, sich mit der sprachlichen und gesellschaftlichen Wirklichkeit nicht auseinandersetzen zu müssen. Ich experimentiere gerne gleichermaßen mit Programmiersprachen und mit natürlicher Sprache. Da ich mir wünschen würde, dass ich etwa vom deutschen Staat nicht mit meinem Geschlecht angesprochen werde, halte ich in diesen Zusammenhängen eine Sprachvorschrift in Behörden oder Firmen für angemessen. Leider argumentieren sowohl Befürworter:innen als auch Gegner_innen sehr offensiv und extrem, an einem Konsens ist oft wenig Interesse. Mehr gemäßigte Mitte und Empathie würde der Debattenkultur gut tun.
Techblog der DenktMit eG
Dieser Artikel ist Teil des TechBlog der genossenschaftlichen Unternehmensberatung DenktMit eG in Oberursel (Rhein-Main). Wir sind eine Gruppe von Experten, die alle Bereiche des Computings abdecken. Unser unique selling point besteht in der ganzheitlichen und nachhaltigen Beratungsleistung, die unsere Kunden zurück in den Fahrersitz ihrer Digitalisierungsstrategie setzen. Wir vereinen Bleeding-Edge Technologiewissen, eine hohe Expertise und starker Fokus auf die Lieferqualität.
Ein Blog-Post von Sven Köppel
Dieser Artikel wurde von Sven Köppel geschrieben. Er ist einer unserer führenden Experten. Persönliche Meinungen können von der Firmenmeinung der DenktMit eG abweichen.
Über Sven Köppel
20 Jahre Softwareentwicklung in diversen Bereichen, davon über 10 Jahre im Bereich Forschung & Entwicklung, in Projektmanagament und Leitungsfunktion (bis zu 15 Mitarbeiter:innen im internationalen Team). Seit 2019 hauptberuflich im Bereich Startups unterwegs. Lehr- und Fortbildungstätigkeiten runden das Profil ab.