Hallo @umeyermartin, das ist in der Tat ein gutes, wenn auch komplexes Thema. Ich selbst wollte schon mehrfach einfach mal loslegen und komme immer wieder an einen Punkt, an dem ich mich gern austauschen würde, bevor ich einfach irgendwas vereinheitliche oder gar umkremple. Es gibt nämlich leider eine Reihe von Gründen, warum das in der Praxis alles andere als trivial ist. Ich habe das mit den Kollegen mal versucht zusammenzutragen, auch wenn es sicher noch mehr Hürden gibt:
-
Gendern ist ja nicht gleich Gendern. Es herrscht im Transifex bereits jetzt ein wildes Durcheinander an Übersetzungen: Wo nicht generisches Maskulinum verwendet wird, gibt es mal Sternchen, mal Schrägstrich, mal Doppelpunkt und mal männlich und weiblich in einer Formulierung. Und das sind ja noch nichtmal alle Ansätze für eine gendergerechter(e) Sprache!
-
Es gibt leider nicht oft die eine Stelle, an der das jeweilige Wort vorkommt. Ein Beispiel aus unserem Civi-Alltag: „client“ gibt es derzeit in den Übersetzungen „Klient“, „Klient:in“, „Client“, „Fallklient:in“ und „Fallklient(en)“. Dein Beispiel „Arbeitgeber“ kommt übrigens an mindestens 33 Stellen in verschiedensten Kontexten vor. Dabei reicht es oft nicht, einfach drauflos zu übersetzen (oder zu korrigieren), sondern man sollte sich den Kontext anschauen, wobei ein und derselbe Übersetzungsstring (im Sinne einer Wortgruppe oder eines Satzes) auch gerne mal an verschiedenen Stellen zum Tragen kommt, aber eigentlich für den jeweiligen Kontext unterschiedlich übersetzt werden müsste.
-
Das Zusammenspiel von technischen Restriktionen bei Übersetzungen, Grammatik und Genderregeln ist schwierig! Ein Beispiel: Worte wie „any“ in Zusammenhang mit Variablen müssten im Deutschen anders als im Englischen meist durchdekliniert werden („beliebige, beliebiger, beliebiges, beliebigem“) und machen entsprechend auch so schon oft Probleme. Gendern macht es hier dann nochmal komplexer, wenn zum eigentlich gegenderten Wort noch „seiner/ihrer“ o.ä. oder gar ganze Wortgruppen für das jeweilige Geschlecht durchdekliniert werden müssten.
-
das Deutsche ist wegen des Prinzips der zusammengesetzten Worte oft sowieso schon durchwachsen von „Wortmonstern“, die sich besser für Galgenraten eignen als für ein Benutzerinterface, das möglichst übersichtlich auf den unterschiedlichsten Ausgabegeräten sein soll. Durch einige Gender-Ansätze werden Worte noch zusätzlich „verlängert“ – ich übertreibe mal: Veranstaltungsteilnehmer*innenstatus Da CiviCRM aus dem englischsprachigen Raum kommt, wo man eher mit kurzen Worten hantiert, zerschießen sehr lange deutsche Worte schnell das Layout und machen eine Kontaktübersicht plötzlich nicht mehr ganz so übersichtlich. Das sollte man beim Übersetzen im Hinterkopf behalten … dieses Beispiel zeigt, dass es auch ohne Gendern schon teilweise unschön wird: selbst an einem Desktop-Rechner mit großem Monitor reicht der vorgesehene Platz nicht
-
Leider kann man im Transifex nicht so einfach erkennen, ob ein Übersetzungs-String
- Bestandteil von Code ist, der für den praktischen Einsatz von CiviCRM wenig relvant ist (seltsamerweise werden auch Code-Kommentare für die Übersetzung angeboten),
- ein String für das CiviCRM-Backend ist (also Navigation, Beschriftung oder Hilfetext für den Benutzer) → hier könnte man ggf. zugunsten der Übersichtlichkeit und Benutzbarkeit aufs Gendern verzichten)
- oder ob es sich um Text handelt, der im Frontend an Außenstehende gerichtet ist, wie Bestätigungsnachrichten o.ä., wo Gendern am ehesten „gebraucht“ wird
-
CiviCRM ist ein Community-Projekt – daher sind gemeinsame Regeln für’s Gendern unbedingt ein Community-Thema. So ein Prozess will gut organisiert sein und mit den vorhandenen Initiativen ineinander greifen. Wir finden übrigens, dass es die CiviCRM Community Guidelines hier ganz gut auf den Punkt bringen – es braucht dabei drei anspruchsvolle Dinge in der richtigen Mischung: „Do-ocracy“ und „Collaboration“ und „Promotion“.
Fazit: Unserer Meinung nach ist das Genderthema eines, das zuallererst eine Gruppe von Fürstreiter*innen braucht, die sich für dieses und weitere Übersetzungsbelange in der deutschen Community mit langem Atem stark macht und dauerhaft Freude daran hat, diese kniffelige Aufgabe konzentriert-systematisch und gleichzeitig offen, partizipativ und transparent anzugehen.
Diese Gruppe sollte wohl erstmal eine Bestandsaufnahme machen und Themen zusammen mit der Community sammeln und strukturieren. In weiteren Schritten müssten dann themenbezogen Übersetzungsrichtlinien entstehen, für die es eine allgemeine hohe Akzeptanz gibt und die auch funktionieren.
Einen Ort dafür gibt es bereits mit einem Translation Guide. Dieses Dokument ist ein Anfang, zeigt aber zugleich, wie viel noch zu tun ist. Viele der Angaben darin sind sicher nochmal zu hinterfragen. Wir verstehen zwar zum Beispiel den Grundgedanken hinter „Schreibe zusammengesetzte Wörter als mehrere einzelne Wörter“ (s.o.), leider wirkt das Ergebnis so einer Vorgabe entweder umständlich formuliert, nicht besonders intuitiv bei Hilfetexten oder schlicht falsch.
Auch gab es im Mattermost-Kanal „deutschsprachig“ immer mal wieder ein paar zaghafte Vorstöße.
Richtig wichtig finden wir für den Community-Anschluss z.B. den geplanten Translation Sprint in Portugal – auch wenn der pandemiebedingt noch immer in der Luft hängt, wäre das für oben benannte Fürstreiter*innen eine Möglichkeit, im globalen Umfeld die deutsche Übersetzung weiterzubringen.
P.S.: Übrigens ist eine wichtige Frage auch, ob andere Übersetzungsthemen nicht ehrlicherweise weniger zeitgeistig, aber noch viel drängender sind. Hier ein einfaches und ein komplexeres Beispiel:
-
Wenn man eine Veranstaltung als Teilnehmer*in stornieren wollte, erhielt man bis vor Kurzem die Auswahl „abbrechen“, weil „cancel“ halt systemweit so übersetzt wurde. Gemeint war aber: „stornieren“. Das war so irreführend, dass die gesamte Stornierungsfunktion praktisch nicht wirklich benutzbar war. Solche Probleme gibt es leider nicht wenige. Diese originelle Lösung zeigt aber, dass solche Probleme dennoch manchmal auch einfach zu beseitigen sind.
-
Man kann in CiviCRM konfigurieren, ob Kontakte generell per Sie oder Du angesprochen werden (über die Kommunikationsstil-Optionen → die Standard-Auswahl bestimmt darüber, welcher Anredstil in neuen Kontakten hinterlegt wird, woraus sich dann wieder die Grußformeln ableiten lassen). Die Übersetzungen sollen nun laut o.g. Guide generell in der Sie-Form erfolgen (wobei im Transifex leider ein Mix aus Du und Sie und indirekten Formulierungen herrscht!) – im Englischen gibt es halt nur eine Form. Wenn man nun generell mit Du anreden möchte, was immer mehr Organisationen wollen, hat man ein Problem – vor allem in den systemgenerierten Nachrichtenvorlagen. Sinnvoll wären vermutlich zwei Übersetzungen, einmal Du und einmal Sie (formal/informell). Wodurch dann aber sofort wieder neue Fragen wie Pilze aus dem Boden schießen …