Deutsch
Dies ist die deutschsprachige Website zum Organisieren und Verwalten der Zusammenarbeit zu den WordPress-Teams: Support, Meta, Community, Polyglots und viele mehr.
Wir brauchen jede helfende Hand. Alle sind herzlich willkommen, mitzuarbeiten. Erfahre, wie du bei WordPress mitmachen kannst.
Hier findet die öffentliche Kommunikation der deutschsprachigen WordPress-Teams statt. Wenn du Hilfe zu deiner WordPress-Installation benötigst, kannst du dafür das Forum nutzen.
Am Tisch der Polyglots fanden sich ein gutes Dutzend Personen ein:
Remote haben Johannes Jülg (@timse201) und GTE Christian Herrmann (@presskopp) teilgenommen.
Team-Lead war Christian Sabo (@pixelverbieger), ebenfalls GTE.
Alle Anwesenden hatten schon mehr oder weniger Erfahrungen mit dem Übersetzungssystem unter translate.wordpress.org gesammelt. Trotzdem war der Plan, sich gemeinsam noch einmal die verschiedenen Ressourcen und Werkzeuge anzuschauen, die den Übersetzerinnen und Übersetzern zur Verfügung stehen.
Bevor es allerdings „richtig“ losgehen konnte, mussten erst einmal einige Personen noch den Weg in den deutschsprachigen Slack-Channel der Polyglots finden – wie immer nicht ganz trivial, dank Anleitung aber zu schaffen.
Die Runde der Polyglots war diesmal international besetzt (Luxemburgisch lb_LU, Niederländisch nl_NL, Deutsch de_DE), so dass wir uns zum Einstieg die Übersicht der Translation Teams und Sprachen angeschaut haben.
Die Erläuterung der einzelnen Benutzerrollen (und für was diese gut sind) haben wir am Beispiel der deutschen Team-Seite durchgesprochen.
Als weitere wichtige Punkte standen nun der deutsche Style Guide und das Glossar auf der Tagesordnung. Beide Dokumente sind ja eine wichtige Orientierungshilfe – sowohl für die Einreichungen als auch später für die Freigabe.
A propos „Freigabe“: in Sessions wie dieser aber auch in Einzelgesprächen mit Übersetzern/Pluginautoren sorgt es immer wieder für Verwunderung, aber es ist wahr: PTE/GTEs erhalten keine automatische Benachrichtigung, wenn neue Strings zur Freigabe eingereicht werden!
Hier schließt sich dann der Kreis und es wird klar, warum wir den Leuten unseren Slack-Channel so ans Herz legen 😀
Die beschriebene theoretische Einführung ging nahtlos über in ein klassisches „hands on“: wir haben uns existierende Übersetzungsvorschläge der Anwesenden angeschaut und anhand dieser Beispiele die verschiedenen Funktionen von GlotPress kennengelernt (status, comment, translated by, references, permalinks etc.).
Auch den ein oder anderen Blick in Plugin-Quelltexte haben wir gewagt. So konnten wir uns anschauen, warum manche Texte in Themes oder Plugins nicht als übersetzbar auftauchen und was es mit den PHP-Kommentaren für die Polyglots auf sich hat.
Auch die effiziente Übertragung einer 100%-Übersetzung von de_DE in de_DE_formal haben wir an einem Plugin ganz praktisch durchgespielt. Hierbei kam PoEdit zum Einsatz.
Was wir nicht geschafft haben: die Freigabe der eingereichten Übersetzungen für Luxemburgisch zu erreichen. Zur Zeit gibt es für diese locale nur einen GTE (@gromper), und der scheint nicht mehr aktiv zu sein. Auch Alain Schlesser @schlessera hat schon früher versucht, Kontakt mit @gromper aufzunehmen – leider erfolglos.
Alles in allem denke ich, dass am Polyglots-Tisch jeder etwas gelernt hat und wir fleißig waren. Wie viele Übersetzungen genau gemacht wurden, kann ich allerdings nicht sagen. Freigegeben habe ich kaum etwas, dies haben @timse201 und @presskopp im Hintergrund übernommen – vielen Dank dafür!
Als GTE, der auch bei zahlreichen anderen Gelegenheiten das onboarding macht, kann ich sagen, dass immer wieder die gleichen vier Punkte auffallen:
Ich danke allen, die beim Contributor Day dabei waren und bin gespannt, wann und wo wir uns wiedersehen.
Neben aktuellen Locale-Statistiken ging es heute im Polyglots-Chat um folgende Punkte:
WordCamp-Orga-Teams posten bisher in der Regel nur über ihre jeweilige Website bei WordCamp.org. Nun ist angedacht, ob Orga-Teams in Zukunft zusätzlich Zugang zur „Rosetta“-Site ihrer Sprache (z.B. de.wordpress.org) erhalten sollen, um dort über das anstehende WordCamp zu informieren.
Der Vorschlag befindet sich in einer sehr frühen Phase und wird erst einmal dem Community-Team vorgelegt werden.
(Anm.: Auf de.wordpress.org werden WordCamps im deutschsprachigen Raum eigentlich angekündigt, allerdings fehlt momentan das anstehende WordCamp Berlin.)
Die Teilnehmer/-innen des anstehenden Community Summit im Vorfeld des WordCamp Europe werden dieser Tage benachrichtigt.
Der Contributor Day beim WCEU ist eine seltene Chance für die Polyglots, um sich IRL treffen und „in Echt“ miteinander zu sprechen. Im Vorfeld des WCEU sammeln wir daher Themen, über die wir diskutieren und an denen wir beim Contributor Day arbeiten wollen. Beispiele wären:
Der nächste Global Translation Day ist für September geplant, aber er wird nur stattfinden, wenn sich genügend Polyglots zu einem Orga-Team zusammen finden – Freiwillige vor! 🙂
Du brauchst keine spezielle Organisationserfahrung, sondern lediglich Engagement. Petyas Call for Organisers findest du hier:
Das Redesign des offiziellen Plugin-Repos wurde, nach einer längeren öffentlichen Test-Phase, nun freigeschaltet.
Aus Polyglot-Sicht fällt auf, dass das ehemals grüne Button „Translate this plugin“ verschwunden ist. Stattdessen wird ein Banner bzgl. Lokalisierung dargestellt – momentan allerdings nur, wenn das Plugin voll übersetzt ist, oder noch gar nicht. Sergey Biryukov wird dazu ein Ticket erstellen.
Banner mit Bitte um Übersetzungshilfe im neuen Plugin-Repo
🗓 Der wöchentliche Polyglots-Chat für Europa, Afrika und Amerika findet jeden Mittwoch um 12:00 Uhr im #polyglots-Channel des globalen WordPress-Slack statt.
Das Glossar, welches vorher nur für das WordPress Projekt genutzt wurde, ist nun für alle Projekte der Standard.
Bei Bedarf können aber weiterhin projektspezifische Glossare angelegt werden, um zum Beispiel zusätzliche Begriffe zu ergänzen oder zu überschreiben.
Bei dieser Gelegenheit sollte das aktuelle Glossar nochmals auf eventuelle Fehler und/oder fehlende Begriffe hin überprüft werden. Falls jemand also was findet, dann bitte in den Kommentaren notieren oder direkt im #polyglots Slack Channel (Anleitung für Slack) vorbeischauen. Danke!
Im globalen Polyglots-Chat ging es gestern um 2 Punkte:
„Rosetta“ ist der Spitzname der lokalisierten wordpress.org-Seiten, wie z.B. unsere de.wordpress.org. Im globalen Polyglots-Team geht es momentan darum, wie diese Websites umfangreicher mit Inhalten bespielt werden können – nicht zuletzt auch, um neue Translation Editors zu gewinnen.
Die deutschsprachige Rosetta-Site wird bereits seit Längerem von einem Redaktionsteam betreut und postet neben den üblichen Release-Posts auch community-bezogene Inhalte, wie eine siebenteilige Artikelreihe über Meetups.
📝 Den Post zu Rosetta-Site von Petya gibt es hier, Kommentare sind erwünscht!
Für den Community Summit können sich Locale General Translation Editors und Locale Managers selbst nominieren.
Bitte keine Scheu, liebe Leute! 🙂 Es wäre toll, wenn einige erfahrene Polyglots am Summit teilnehmen und sich im Vorfeld einbringen.
📝 Die Polyglots-Themen für den Community Summit findet ihr hier in Petyas Post.
Input zu den im Artikel gelisteten Themen wäre super-hilfreich – egal, wer am Event selbst teilnehmen kann, oder nicht.
Für den Summit werden darüber hinaus auch noch Freiwillige zur allgemeinen Mithilfe gesucht.
Den Vorschlag an das deutschsprachige Polyglots-Team, die überarbeiteten Übersetzungen aus dem Stringintelligenz-Plugin in die offiziellen, mit der Core-Software ausgelieferten Übersetzungen ab WordPress 4.7 zu übernehmen, haben die Verantwortlichen des Stringintelligenz-Projekts heute zurückgezogen.
Wir reagieren mit diesem „Rückzieher“ auf den Wunsch verschiedener aktiver Personen aus der deutschsprachigen WordPress-Community, der Prüfung des Vorschlags mehr Zeit einzuräumen, sowie auf die Diskussionen der vergangenen Tage, die teilweise eine redaktionelle Aufbereitung unsererseits jenseits unseres ursprünglich angekündigten Redaktionsplans für den Vorschlag selbst erfordern.
Mit diesem Schritt hoffen wir überdies, den Druck für alle Beteiligten zu verringern, den die potenzielle Aussicht auf ein „gegendertes“ WordPress erzeugt haben mag.
Das Plugin Stringintelligenz wird weiterhin gepflegt und weiterentwickelt. Um konstruktives Feedback via Plugin-Forum wird weiterhin ausdrücklich gebeten!
Die Verantwortlichen behalten sich vor, das Projekt zu einem späteren Zeitpunkt (nach WordPress 4.7) erneut zur Prüfung vorzulegen.
Features as Plugins sind ein mit WordPress 3.7 eingeführtes Konzept, neue Funktionalität zunächst als Plugin zu entwickeln und der Community vorzustellen, um es anschließend in den Core einfließen zu lassen. Die so genannten Feature Plugins können laut Benutzerhandbuch von jedem Mitglied der Community vorgestellt und zum Merge mit einer bestimmten WordPress-Version vorgeschlagen werden.
Als OpenSource-Community bemühen wir uns, Barrieren zu beseitigen. Alle sollen sich willkommen fühlen, unabhängig von Alter, Herkunft, sexueller Orientierung, religiösen Ansichten und Geschlecht. Mit seiner Keynote über gender-sensitive Sprache hat Caspar (@glueckpress) auf dem WordCamp Frankfurt/M. deshalb das Thema eines geschlechtergerechten Sprachgebrauchs aufgegriffen, das in der deutschsprachigen Community bereits seit Jahren ausgiebig und kontrovers diskutiert wird.
Aus konkreten Äußerungen von WordPress-Nutzerinnen wissen wir, dass sich viele Frauen durch das verwendete generische Maskulinum sprachlich ausgegrenzt fühlen. Caspar hat in seiner Keynote verdeutlicht: Wer sprachlich vielleicht mitgemeint ist, fühlt sich nicht unbedingt persönlich angesprochen.
Das österreichische Bundesministerium für Arbeit, Soziales und Konsumentenschutz hat diesen Umstand im Leitfaden zum geschlechtergerechten Sprachgebrauch so formuliert:
Texte sind geschlechtergerecht, wenn Frauen und Männer sprachlich sichtbar sind, so dass sich alle gleichermaßen angesprochen fühlen.
Für die Übersetzung von WordPress auf Deutsch haben wir in den vergangenen Jahren gemeinsam einen Translation Style Guide erarbeitet, der für alle Übersetzer verbindliche Richtlinie ist. Dieser Style Guide legt fest
Bei der Übersetzung ins Deutsche ist die sprachliche Gleichbehandlung von Frauen und Männern anzustreben.
Die Umsetzung einer gender-sensitiven Sprache in einer Software wie WordPress ist komplex und erschien vielen, die sich mit der Übersetzung beschäftigt haben, als kaum durchführbar. Unser Style Guide formuliert es deshalb so:
Die generische Form umfasst entsprechend den Regeln der deutschen Sprache beide Geschlechter und ist – mangels praktikabler, gleichermaßen verständlicher und stilistisch ansprechender Alternativen – nach wie vor das Mittel der Wahl.
Um langen Diskussionen Taten folgen zu lassen, hat Caspar einen Vorschlag gemacht, wie eine sprachliche Annäherung gelingen kann. Caspar hat diesen Vorschlag nicht nur verbal geäußert, sondern zusätzlich ein Feature Plugin entwickelt (Plugin: Stringintelligenz), um allen Beteiligten mögliche Auswirkungen zu verdeutlichen. Caspar ist dabei den im WordPress Core-Handbook festgelegten Regeln gefolgt und hat den Team-Leads (in diesem Fall den General Translation Editor für die deutschsprachige Übersetzung) das Plugin rechtzeitig vorgelegt und im Team-Blog ausführlich erläutert.
Caspars Vorschlag zeigt, dass die bisherige Übersetzung Verbesserungspotenzial hat, wenn wir den generisch maskulinen Begriff Benutzer durch einen abstrakteren, aber geschlechtsneutralen Begriff Profil ersetzen. Caspar hat hier genau jene “praktikable, gleichermaßen verständliche und stilistisch ansprechende Alternative” vorgestellt, die der Style Guide voraussetzt.
Ein weiterer Vorschlag, der in Caspars Feature Plugin Berücksichtigung findet, ist die Verwendung einer Schreibweise, die “bei Bezeichnungen von Personengruppen kenntlich machen [soll], dass sowohl die weibliche als auch die männliche Form gemeint ist, ohne beide Genera ausschreiben zu müssen oder das generische Maskulinum zu verwenden.” (Quelle: Wikipedia).
Statt des häufig von Unternehmen und öffentlichen Einrichtungen verwandten Binnen-I hat Caspar zunächst einen Stern (*) als Silbentrennung vorgeschlagen (Administrator*innen), was sich inzwischen als nicht barrierefrei herausgestellt hat (Screenreader geben den Stern sprachlich aus). Hier scheint noch Optimierungsbedarf zu bestehen.
Das Modell [der Features as a Plugin] ermöglicht, eine Funktionalität zu erstellen, testen, verfeinern und abzurunden, bevor sie als Merge-Kandidat berücksichtigt werden kann.
(Quelle: Make WordPress, Core Handbook)
Caspar hat eine Funktionalität vorgeschlagen und wir alle sind jetzt aufgerufen, als deutschsprachige Community diesen Vorschlag zu testen und wo nötig zu verfeinern und abzurunden. Erst wenn wir zu einem für die Community verträglichen Ergebnis gekommen sind, das für den kleinen Blog genauso gut funktioniert wie für große aus dem Enterprise-Bereich, wird der Vorschlag von den Team-Leads der deutschsprachigen Übersetzer abschließend geprüft und in die Übersetzung übernommen.
So ist es laut Core Handbook vorgesehen.
So möchten wir auch gerne vorgehen.
Ziel des des Projekts „Stringintelligenz“ ist es, das sogenannte „generische Maskulinum“ für Personen (oder Begriffe, die als Personen verstanden werden können), im deutschsprachigen User Interface von WordPress durch gender-neutrale bzw. gender-sensible Formulierungen zu ersetzen.
Beispiele für personenbezogene generische Maskulina in WordPress wären Begriffe wie:
Weitere Beispiele wären Komposita wie:
Im Gegensatz zu personenbezogenen Begriffen geht es ganz klar nicht um generische Maskulina für Sachen, wie z.B. „der Computer“. Obwohl mit „Computer“ ursprünglich mal rechnende Menschen gemeint waren, meint der Begriff im allgemeinen Verständnis heute eindeutig eine Sache.
(Die folgenden Zahlen beziehen sich auf die de_DE-Version und stammen aus einer Beta von 4.6. Geringfügige Abweichungen zum aktuellen Stand sind nicht auszuschließen.)
Generisches Maskulinum in WordPress 4.6 (nur de_DE)
WordPress hat 4 Sprachdateien, von denen für unseren Kontext lediglich 3 relevant sind; die vierte enthält nur Kontinente und Städte – also kein personenbezogenes generisches Maskulinum, das uns interessieren würde.
Unsere 3 relevanten Sprachdateien enthalten insgesamt 4.710 Strings.
Von diesen insgesamt 4.710 Strings enthalten 395 ein personenbezogenes generisches Maskulinum.
Wiederum 285 Strings dieser 395 betroffenen Strings enthalten das Wort „Benutzer“ oder eins seiner Komposita.
Die genaue Verteilung sieht so aus:
In Prozent ausgedrückt:
Für 50 Strings (1% des Gesamtvolumens) haben wir bisher keine neutralen Übersetzungen gefunden. Der Großteil davon befindet sich in Hilfetexten; die prominentesten Vorkommen sind die Rollenbezeichnungen auf der „Benutzer“-Seite: Administrator, Redakteur, Autor, Mitarbeiter, Abonnent. Der Begriff „Autor“ kommt außerdem in diversen Filter-Funktionen vor.
Für diese 50 Strings haben wir vorerst auf Endungen mit Gender-Star zurückgegriffen. Aus „Autor“ wurde „Autor*in“.
Wie schon im Foren-Sticky erwähnt:
📢 Die Wahl des Gender-Stars ist momentan eine vorläufige.
Wir sind dabei, Feedback zu technischen Aspekten (Screen-Reader etc.) der verschiedenen möglichen Endungen einzuholen. Ob es von Projekt-Seite beim Vorschlag des Gender-Stars für die betroffenen 1% Strings bleibt, oder ob wir noch auf einen Gender-Gap oder andere Lösungen ausweichen (sollten), darf gerne im Forum diskutiert werden.
Mir persönlich wäre eine 100%ige Lösung ohne „Gender-Endung“ theoretisch am liebsten – noch wichtiger ist mir allerdings eine leichte, intuitiv verständliche Sprache, und dazu tragen die Endungen mit Gender-Star m.E. in der aktuellen Fassung bei. Die Suche nach Alternativen, etwa für die Rollenbezeichnung „Autor“, endete für mich bisher in suboptimalen Ersetzungen, die das Verständnis erschwert hätten. Nur allzu gerne ließe ich mich durch ein gelungenes Ersetzungskonzept für die Rollenbezeichnungen eines Besseren belehren; soll heissen: natürlich darf auch speziell hierzu gerne weiter diskutiert werden – wie z.B. in diesem Topic.
„Das Problem am generischen Maskulinum ist natürlich, dass es ein ganz normales Maskulinum ist, dass also nie klar ist, ob nur Männer oder eben Männer und Frauen gemeint sind, und die psycholinguistische Forschung zeigt, dass es zwar ›generisch‹ verstanden werden kann, dass Versuchspersonen aber zunächst an Männer denken und erst nach einem messbaren Zeitraum zu einer Interpretation kommen, die Frauen mit einschließt.“
Anatol Stefanowitsch, Geschlechtergerechte Sprache und Lebensentscheidungen
🚧 Bloß weil also jemand eine grammatikalisch maskuline Form benutzt und damit angeblich alle meint, heisst das noch lange nicht, dass sich auch wirklich alle als „mit-gemeint“ verstehen.
In einem anderen, ziemlich bekannt gewordenen Artikel von 2011 („Frauen natürlich ausgenommen“) formuliert Stefanowitsch als Schlussfolgerung, es sei …
„… Stand der Forschung, dass ein ›generisches Maskulinum‹ im Deutschen […] aus psycholinguistischer Sicht nicht existiert. Wer das Gegenteil behaupten will, muss sehr gute Belege dafür vorbringen.“
Dieses „nicht existiert“ bezieht sich natürlich auf den Anspruch des „generisch“ Verstanden-werdens einer Ausdrucksweise, die rein grammatikalisch nichts weiter darstellt als ein simples Maskulinum.
Anatol Stefanowitsch ist Sprachwissenschaftler und Professor an der Freien Universität Berlin. Seit 2007 bloggt er über Sprache und macht in Artikeln und Vorträgen immer wieder wissenschaftliche Inhalte einem weiteren Publikumskreis als dem rein akademischen zugänglich, meiner Wenigkeit eingeschlossen.
Der bisherige Style Guide für WordPress-Übersetzungen ins Deutsche bezieht sich auf den Duden, wenn er empfiehlt:
„Die generische [maskuline] Form umfasst entsprechend den Regeln der deutschen Sprache beide Geschlechter und ist – mangels praktikabler, gleichermaßen verständlicher und stilistisch ansprechender Alternativen – nach wie vor das Mittel der Wahl.“
🔥 Dem ist entgegen zu halten: Generisch maskuline Formen umfassen, dem Stand psycholinguistischer Forschung nach, auf Seiten derjenigen, die eine Botschaft verstehen sollen, eben nicht zwangsläufig alle Geschlechter und sind daher eben nicht für Alle gleich gut verständlich.
Stefan Münz, Gründer von SelfHTML, hat Barrierefreiheit im Jahr 2005 so definiert (das Zitat tauchte in der Zeitschrift Internet Intern auf, eine Online-Referenz ist mir leider nicht bekannt):
„Barrierefrei ist, was in den Köpfen der Menschen so ankommt, wie es gemeint ist.“
Genau dies scheint bei einem „generisch“ gemeinten Maskulinum, den oben zusammengefassten Forschungsergebnissen zufolge, nicht unbedingt der Fall zu sein.
👉🏼 Folgen wir Münz’ Interpretation von Barrierefreiheit, bildet das generische Maskulinum eine potenzielle Verständnisbarriere im User Interface von WordPress. Damit widerspricht es der WordPress Philosophy in einigen wichtigen Punkten, von denen einer ganz besonders auffallen muss: „Design for the Majority“.
Die auf wordpress.org formulierte Interpretation des Prinzips „Design for the Majority“ geht darauf ein, dass WordPress auch für Menschen ohne spezielle technische Fachkenntnisse leicht zu nutzen sein sollte.
Für die „untechnische Mehrheit“ zu designen muss aber auch bedeuten, ein User Interface zu schaffen, in dem Menschen sich möglichst leicht zurecht finden. Die Zugänglichkeit eines UI ist keine rein technische Frage. Sie fängt mit Sprache an und damit, wie klar und verständlich die Botschaften des UI in den Köpfen der Menschen ankommen, die sie verstehen sollen.
Lokalisierung bildet eine kritische Schnittstelle zwischen Mensch und Software. Eine Übersetzung sollte Verständnisbarrieren abbauen – und nicht neue, sprachlich bedingte Hürden schaffen.
Daher haben „generisch“ maskuline Formulierungen, unserer Auffassung nach, in der offiziellen deutschen Übersetzung für WordPress nichts zu suchen und gehören durch offene, leichter verständlicher Formulierungen ersetzt.
Eins muss ganz klar gesagt werden: Wir sind weit davon entfernt, etwas „Revolutionäres“ oder „Pionierhaftes“ vorzuschlagen.
Eine (zufällige) Auswahl von Broschüren zu geschlechter-gerechter Sprache, herausgegeben von Stadtverwaltungen, Ämtern, Universitäten und dergleichen findet sich z.B. bei Geschickt Gendern: http://geschicktgendern.de/links/
Solche Broschüren und ihre Veröffentlichungsdaten zeigen auf, wie normal die Verwendung geschlechter-gerechter Sprache im öffentlichen Raum eigentlich schon ist.
Ein „hakeliger“ Punkt scheint allgemein, genau wie in der bisherigen Diskussion zu diesem Projekt, die Frage nach Beidnennung oder verkürzter Endung mit Schrägstrich, Binnen-I, Gender-Gap, oder -Star zu sein. Eine einheitliche Vorgehensweise gibt es nicht, fast überall wird zur Vermeidung solcher Endungen durch alternative Formulierungen geraten. Dieser Empfehlung folgt, wie oben gezeigt, auch die Stringintelligenz-Übersetzung – bisher zu 99%.
Meine persönliche Meinung: Ob wir die Übersetzung einfach ändern „dürfen“, kann überhaupt nicht die Frage sein. Wir sollten, es wird höchste Zeit! Und weil wir sollten und gleichzeitig können, müssen wir auch.
Prominente Änderungen an der Übersetzung gab es in der Vergangenheit bereits, etwa die Ersetzung von „Artikel“ durch „Beitrag“, oder von „Seiten“ durch „Sites“ bzw. „Websites“ (in Multisite). Solche Änderungen wurden bisher innerhalb des Polyglots-Teams vorgeschlagen, diskutiert und nach bestem Wissen und Gewissen entschieden. Warum sollten die Polyglots also nicht auch über den „Stringintelligenz“-Vorschlag diskutieren und entscheiden?
Das „Stringintelligenz“-Projekt vertritt die Sichtweise, dass WordPress in seiner deutschen Übersetzung Menschen aufgrund ihres Geschlechts kategorisch sprachlich ausgrenzt und damit gegen einige seiner eigenen Prinzipien verstößt.
Mit der Einführung gender-sensibler Sprache möchten wir WordPress in Deutsch in Einklang mit einer im öffentlichen Raum schon lange stattfindenden, von wissenschaftlichen Erkenntnissen untermauerten sprachlichen Entwicklung bringen.
Beim WordCamp Frankfurt hatte ich die Ehre, in der Keynote ein Feature Project für die Lokalisierung für WordPress 4.7 vorzuschlagen. Die Video-Aufzeichnung der Keynote stellte sich im Nachhinein leider als technisch unbrauchbar heraus. Daher möchte ich das Projekt und den Vorschlag zur Übernahme des Projekts in die offiziellen deutschen Übersetzungen mit WordPress 4.7 gerne hier noch einmal skizzieren.
Stringintelligenz ist ein Feature-Projekt für Lokalisierung, das sich zum Ziel gesetzt hat, gender-sensitive Sprache in die deutschen Übersetzungen von WordPress zu bringen.
Feature Projects (früher: Feature Plugins) haben zum Ziel, ein bestimmte Weiterentwicklung in den WordPress Core zu bringen. Beispielsweise startete das momentan gängige User Interface für WP-Admin als Feature Plugin namens MP6. Ein Überblick über vergangene Feature Plugins und aktuelle Feature Projects findet sich auf make.w.org.
Feature Projects geben der Community die Möglichkeit, die Entwicklung eines bestimmten Funktionsmerkmals oder Patches zu verfolgen und dessen Core-Tauglichkeit zu testen, ohne dass die Arbeit daran Commit-Rechte für den Core erforderlich macht.
Feature Projects haben den Status eines Proposals (Vorschlags), solange sie vom Core-Team nicht für ein bestimmtes Core Release akzeptiert wurden. Ist dies jedoch geschehen, gilt für das Feature Project der gleiche Zeitplan wie für das jeweilige Core Release, und es wird am Ende als Teil des Releases (und als neuer Teil von WordPress selbst) veröffentlicht.
Meines Wissens ist dies das erste seiner Art. 🙂
Wenden wir das Konzept „Feature Project“ auf die Lokalisierung von WordPress an (hier: die deutschsprachige), ergibt sich eine Verschiebung in den Zuständigkeiten: Nicht das Core-Team von WordPress muss dem Projektvorschlag zustimmen, sondern das Polyglots-Team für WordPress in Deutsch.
Somit bitten wir die deutschsprachigen Polyglots, sowie alle sprachlich Interessierten aus dieser Community, hiermit:
Was konzeptionell und konkret an der Übersetzung verändert wurde, planen wir hier stückchenweise zu verbloggen. Der Redaktionsplan sieht etwa so aus (Änderungen vorbehalten):
Im wöchentlichen Polyglots-Chat wurde ich heute darum gebeten, noch einmal auf den Global WordPress Translation Day 2 am 12. November 2016 hinzuweisen.
Wer in seinem Meetup oder mit einer Gruppe von Teilnehmern eine lokale Veranstaltung plant, möchte sich bitte im für die Planung angelegten Spreadsheet auf Google Docs (https://docs.google.com/spreadsheets/d/1--GaJZFoxCqb6NHBl2QYv4lH3Y6inIGBwr5Ln9SIaic/edit#gid=695788145) eintragen, damit die Veranstaltungen besser koordiniert werden können.
Auch wer gerne bei den Online-Sessions einen Vortrag halten möchte, möchte sich bitte in das Spreadsheet im Tab Speakers eintragen.
Für die Ankündigung lokaler Veranstaltungen (auch auf unserer Team-Website) steht in o.g. Google Doc im Tab „Announcement“ ein vorbereiteter Ankündigungstext zur Verfügung, der gerne individuell angepasst werden kann.
Bisher ist immerhin schon eine Veranstaltung in Würzburg eingetragen. Es darf aber gerne mehr werden. 🙂
Ich möchte zur Debatte stellen, den Begriff „Benutzer“ durch „Nutzer“ zu ersetzen.
Pro: Es ist kürzer, was sich auf Buttons positiv auswirken könnte, ist langfristig 25% effizienter und klingt für meine Begriffe sprachlich schöner.
Contra: Der DUDEN 2, Stilwörterbuch, definiert „benutzen“ u. a. als „a) sich einer Sache bedienen, b) verwenden“ und „nutzen“ u. a. als „aus etwas Nutzen ziehen“ (wie Bodenschätze und Wasserkraft). Sprachlich-konservativ wäre benutzen also korrekt; es bezieht sich offensichtlich auf einen „kleineren“ Gegenstand.
Wie steht ihr dazu?
