Support » Plugin: Stringintelligenz [discontinued] » Warum nicht als eigene Sprachdatei?

  • Ich möchte hier (gänzlich unaufgeregt, ernsthaft und nicht mit nach vorne gerecktem Hals) einmal die Frage stellen, warum das Ganze nicht als eigene Sprachdatei angeboten werden soll. Also zu de_DE, de_DE_formal noch ein de_DE_gender oder wie auch immer.

    Damit wäre sehr sehr viel Aufregung vom Tisch.

    Eine solche Lösung hätte den Vorteil, dass jede Person, die WordPress installiert, selber entscheiden kann, was sie sich, Kundschaft oder Leserschaft präsentieren möchte.

    Außerdem (und das schreibe ich aus Sicht eines PTE) hätte die Plugin-Lösung den Vorteil, dass nach und nach jedes Theme und jedes Plugin auch mit dieser –nennen wir es dritten– Sprachdatei versorgt werden könnte. Peu à peu, Schritt für Schritt – und ganz nach Bedarf. Wer genderneutrale Sprache möchte, übersetzt sein Lieblingsplugin, reicht die Strings ein, die PTE geben frei, bingo.

Viewing 15 replies - 1 through 15 (of 15 total)
  • Anonymous User 7658014

    (@anonymized_7658014)

    Das war tatsächlich meine allererste Version der Idee gewesen. 😉 In den zahlreichen Gesprächen im Vorfeld wurde mir, u.a. von sehr erfahrenen Personen aus den globalen Teams bei make.wordpress.org davon abgeraten, diesen Ansatz weiter zu verfolgen, weil die Implementierung einer weiteren Locale im WordPress Core wahrscheinlich abgelehnt werde.

    Das lässt sich nachvollziehen: Core muss immer global denken und für alle. Wenn eine zusätzliche Locale für einen Ausnahmefall genehmigt würde, wer wollte dann eventuelle Forderungen nach weiteren Ausnahmen für Core-Locales ablehnen?

    Zudem kam auch folgende Argumentation zur Sprache: Wenn es sich um ein Problem mit der Übersetzung handelt, sollte es auch in der Übersetzung gelöst werden. Sei das Problem nicht wichtig genug, um deswegen die bestehenden Übersetzungen anzupassen, sei es mit Sicherheit nicht wichtig genug, um den Core dafür zu ändern.

    @pixelverbieger: Deinen Vorschlag finde ich sehr gut. Ich möchte ebenfalls, dass jeder WordPress-Nutzer selbst entscheiden soll, welche Übersetzung er angezeigt bekommt. Allerdings müsste es dann aber vermutlich sogar 4 Sprachdateien geben: de_DE, de_DE_formal, de_DE_gender und de_DE_formal_gender.

    @caspar: Wenn diese Vorgehensweise im Core nicht realisierbar ist, sollte die gender-sensitive Sprache einfach als Plugin optional nutzbar sein. Eine Anpassung der aktuellen Sprachdateien mit der damit verbunden Zwangsnutzung finde ich nicht optimal.

    Nur ein kleines Beispiel: einer meiner Kunden betreibt einen Blog, der von Männern für Männer geschrieben ist. Ich vermute, diese Herrschaften werden nicht sonderlich begeistert sein. Und ich sehe es nicht als meine Aufgabe, mit meinen Kunden das Thema gender-sensitive Sprache zu diskutieren und sie von selbiger zu überzeugen. Gleiches gilt auch für andere gesellschaftspolitische Themen: ich möchte mich bei der Arbeit für meine Kunden auf die technische Aspekte von WordPress konzentrieren. Diese bieten bereits genügend Diskussionsstoff und nicht selten Konfliktpotential. Wenn jetzt noch gesellschaftspolitische Themen hinzukommen, wird es nicht unbedingt einfacher.
    Und der Aufwand, diese Änderungen durch selbstgepflegte Sprachdateien wieder rückgängig zu machen, bliebe vermutlich auch erst einmal an mir hängen.

    Also: gender-sensitive Sprache = gute Sache, aber bitte optional.

    Allerdings müsste es dann aber vermutlich sogar 4 Sprachdateien geben: de_DE, de_DE_formal, de_DE_gender und de_DE_formal_gender.

    Es ist schon jetzt schwierig den Freiwilligen Übersetzern zu erzählen, dass sie immer in beiden Sprachdateien Änderungen vornehmen sollen. Diesen Aufwand noch zu verdoppeln ist nicht praktikabel.

    Wenn diese Vorgehensweise im Core nicht realisierbar ist, sollte die gender-sensitive Sprache einfach als Plugin optional nutzbar sein.

    Ohne Anbindung an Kollaborationstools wie GlotPress ist eine Wartung eines solchen Plugin immens aufwändig. Ich sehe das nicht.

    Ich verstehe auch nicht so ganz das Problem: Einen String wie “Release Lead” mit Release-Leiterin zu übersetzen, wenn Helen Hou-Sandí die Release-Leitung innehat, ist gender-sensitiv. Und auch solche Änderungen finden sich in dem Plugin. Worum geht es also eigentlich?

    Es ist schon jetzt schwierig den Freiwilligen Übersetzern zu erzählen, dass sie immer in beiden Sprachdateien Änderungen vornehmen sollen. Diesen Aufwand noch zu verdoppeln ist nicht praktikabel.

    Verständlich. Es würde dann aber trotzdem noch 2 verschiedene de_DE Übersetzungen für DU und SIE geben?

    Ich verstehe auch nicht so ganz das Problem: Einen String wie “Release Lead” mit Release-Leiterin zu übersetzen, wenn Helen Hou-Sandí die Release-Leitung innehat, ist gender-sensitiv. Und auch solche Änderungen finden sich in dem Plugin. Worum geht es also eigentlich?

    Völlig OK. Ich glaube, das Problem ist derzeit der Bereich der Benutzerverwaltung. Daran reiben sich ja derzeit viele in den Diskussionen bei Slack und diversen Blogs. Das ist halt auch der Bereich, in dem die gender-sensitiven Begriffe am ehesten im Blog-Altag gesehen werden, vor allem die vorläufigen Übersetzungen der Rollen mit *.

    Ganz konkrete Frage zu diesem Bereich:
    Bisher heißt die Seite “Users” “Benutzer” und der “Username” “Benutzername”. Jetzt soll die Seite “Profile” heißen und der Benutzername mit “Zugangsname” übersetzt werden. Finde ich nicht schlüssig. Entweder müsste die Seite “Zugänge” heißen oder der Username müsste mit Profilname übersetzt werden. Wobei mir persönlich beides nicht gefällt. Ideal wäre für mich, wenn “User” im Deutschen verwendet werden könnte. Im Alltag mit den Kunden sprechen wir meistens über “User” und nicht einmal über “Benutzer”.

    Es würde dann aber trotzdem noch 2 verschiedene de_DE Übersetzungen für DU und SIE geben?

    Ich verstehe die Rückfrage nicht so ganz. Ja, es gibt aktuell zwei Sprachsets: default und formal. Daran wird sich nichts ändern. Und du hast vollkommen Recht, dass es dann ja am Ende vier Sets geben müsste. Aber dieser Gedanke ist ja ohnehin vom Tisch, da es von Seiten wp.org kein weiteres Set geben wird (siehe Beitrag von Caspar).

    Finde ich nicht schlüssig.

    Die Diskussion über dieses Thema findest Du hier:
    https://wordpress.org/support/topic/rollenbezeichnungen/

    Ich denke auch, dass dies der neuralgische Punkt des Ganzen ist. Bring deine Idee am besten in dem Thread ein. Und *bitte* erläutere etwas länger, warum du es nicht schlüssig findest. Das hilft uns GTEs sehr, wenn wir konkrete Informationen haben. Danke!

    Noch eine Sprachdatei finde ich nicht so gut. Entweder man entscheidet sich, modern und auf der Höhe der Zeit Autor/in zu schreiben oder man bleibt konservativ. Aaaaber … ich würde das Plugin jetzt auch nicht aktivieren wollen, weil mich das Sternchen stört. Mich stören übrigens auch Unterstriche. Beides zerreisst das Wort und es sieht sperrig und unnatürlich aus. Gegen Autor/in hätte ich nichts einzuwenden und es würde auch auf einer seriöseren Businesswebsite gut aussehen. Mit dem Sternchen springt es gleich als ungewöhnlich ins Auge und es sieht aus, als sei man gerade einem Feminismusverein beigetreten. Ich bin für ein schlichtes, unauffälliges Einpflegen in die Sprachdatei mit einem Schrägstrich / so wie es auch im täglichen Leben und auf offiziellen Formularen benutzt wird, ohne dass es gleich nach einem Gender-Glaubensbekenntnis aussieht.

    Hallo Esther

    Der/die Autor/inn/en können ihre Beiträge nicht veröffentlichen, findest du besser?

    Screenreader lesen Schrägstriche auch vor.

    Und wieso sehen Schrägstriche nicht auch so aus, was wäre man “einem Feminismusverein” beigetreten? Ich sehe da keinen Unterschied, ob jetzt * oder _ oder – oder I oder () oder / den Lese- und Vorlesefluss stören.

    Bitte verstehe meine Fragen pragmatisch, soll kein Aggro-Angriff sein 🙂

    Alternativformulierung

    Schreibrollen können eigene Beiträge nicht veröffentlichen..

    Alternativ-Vorschläge werden dort ausgearbeitet, wäre schön, wenn sich mehr beteiligen würden ->
    https://wordpress.org/support/topic/rollenbezeichnungen/

    Hallo Angelika, ich habe jetzt hauptsächlich an das Frontend gedacht. Der/die Autor/innen geht natürlich gar nicht. Da muss man dann auf alle Fälle die Artikel weglassen. Also einfach “Autor/innen können …”
    (Schreibrollen können keine Beiträge veröffentlichen, hört sich für mich total blöd an. Was soll denn eine Schreibrolle sein? Administrator ist auch eine Schreibrolle … jedenfalls können Administratoren schreiben. Ich wüsste mit dem Begriff nix anzufangen.)

    Da es ja (im Frontend) in der Hauptsache Metainformationen sind, die betroffen sind, kommt das Wort im Fließtext nicht vor. Wenn der Screenreader dann bei den Metaangaben einen Schrägstrich vorliest hört sich das vielleicht besser an als so ein Schluckauf Loch, der durch ein Sternchen entsteht (Sternchen liest der Screenreader nicht?). Ich möchte jedenfalls keine Sternchentexte im Text haben wollen (jedenfalls nicht im Frontend).

    • This reply was modified 7 years, 4 months ago by Webmatter.
    • This reply was modified 7 years, 4 months ago by Webmatter.
    • This reply was modified 7 years, 4 months ago by Webmatter.

    Das war von mir nur ein erdachtes Beispiel. Tatsächlich kommt irgendwo eine*r Autor*in momentan im Plug-in vor. Was aber nicht bedeutet, dass es in den über 47.000 Plug-ins auch so sparsam verteilt sein wird. Und Artikel werden sich garantiert nicht immer vermeiden lassen.

    Duden sagt zum Schrägstrich:

    Der Schrägstrich dient der Angabe mehrerer gleichberechtigter Möglichkeiten: Frau / Herrn, Arzt / Ärztin, Patientinnen / Patienten, jede / jeder. Beim Splitting von Wörtern, die sich nur durch die Endung unterscheiden und bei denen sich kein Vokal ändert, kann mithilfe des Schrägstrichs verkürzt geschrieben werden; der Ergänzungsbindestrich vor der Endung ist notwendig: Mitarbeiter / -innen als Kurzform von Mitarbeiter und Mitarbeiterinnen, Assistent / -in als Kurzform von Assistent und Assistentin, jede / -r als Kurzform von jede und jeder. Wortpaare wie Arzt / Ärztin, Bauer / Bäuerin oder Bischof / Bischöfin können also nicht verkürzt geschrieben werden. Darüber hinaus soll sich ein grammatisch korrektes und leicht lesbares Wort ergeben, wenn der Schrägstrich weggelassen wird. Wortpaare, bei denen auch die maskuline Form eine Endung aufweist (Kolleg-en und Kolleg-innen), sollten deshalb nicht mit dem Schrägstrich verkürzt werden (nicht: Kollegen / -innen). Auch von der Verwendung zweier Schrägstriche in solchen Fällen ist abzuraten (nicht: Kolleg / -inn / -en). Bei unterschiedlichen Endungen innerhalb einer Wortgruppe sollte man ebenfalls alle Formen ausschreiben: Wir suchen eine erfahrene Bilanzbuchhalterin / einen erfahrenen Bilanzbuchhalter.

    1. Schau bitte mal, wie das korrekt geschrieben werden müsste / -
    2. Funktioniert Schrägstrich nicht bei “Wortpaare, bei denen auch die maskuline Form eine Endung aufweist (Kolleg-en und Kolleg-innen), sollten deshalb nicht mit dem Schrägstrich verkürzt werden (nicht: Kollegen / -innen)”
    3. würde der Screenreader vorlesen: “Mitarbeiter Schrägstrich Bindestrich innen”.
    4. sind Doppelnennungen (mit oder ohne Schrägstrich) aus Platzmangel keine Alternative

    Über weitere Alternativen lass uns bitte in dem bereits verlinkten Forum weiter “reden” 🙂

    Hallo Angelika, ich habe jetzt hauptsächlich an das Frontend gedacht. Der/die Autor/innen geht natürlich gar nicht. Da muss man dann auf alle Fälle die Artikel weglassen. Also einfach “Autor/innen können …”

    Stört mich auf subjektiver Argumentationsebene genauso wie dich die * stören. Und nun? 🙂

    Anonymous User 7658014

    (@anonymized_7658014)

    @matthiaspabst „Profilname“ ist auf der Roadmap (die ich übrigens mal dringend öffentlich updaten müsste).

    Ideal wäre für mich, wenn “User” im Deutschen verwendet werden könnte. Im Alltag mit den Kunden sprechen wir meistens über “User” und nicht einmal über “Benutzer”.

    Welchen Genus hat der Artikel, den du für das eingedeutschte „User“ im Singular verwendest?

    Welchen Genus hat der Artikel, den du für das eingedeutschte „User“ im Singular verwendest?

    Gute Frage. Normalerweise “der User”, wobei wir dann schon wieder beim Maskulinum sind. Da spielt es dann eigentlich keine Rolle, ob man der Benutzer oder der User sagt.

    Werde mal schauen, ob ich unter https://wordpress.org/support/topic/rollenbezeichnungen/ noch etwas zu dem Thema beitragen kann.

    Gute Frage. Normalerweise “der User”, wobei wir dann schon wieder beim Maskulinum sind. Da spielt es dann eigentlich keine Rolle, ob man der Benutzer oder der User sagt.

    Vielleicht wäre “Mitglied” eine Option für user? Und Abonnent “Einfaches Mitglied” als Rollenbezeichnung.

    • This reply was modified 7 years, 4 months ago by Webmatter.

    @webmatter: Ich weiß nicht. “Mitglied” hat für mich eher was mit Vereinen oder Clubs zu tun. Ich glaube, dann würden mir eher noch die Bezeichnungen mit “…profil” gefallen. Vielleicht aber auch Gewöhnungssache.

    Ich weiß nicht. “Mitglied” hat für mich eher was mit Vereinen oder Clubs zu tun. Ich glaube, dann würden mir eher noch die Bezeichnungen mit “…profil” gefallen. Vielleicht aber auch Gewöhnungssache.

    Ja, ich denke auch, dass Gewöhnung da eine große Rolle spielt. Abonnent verbinde ich z.B. mit regelmäßigem Empfang von Inhalten (RSS Feed abonnieren, Newsletter abonnieren etc.). Wenn sich jemand auf einer Seite registriert, ist es ja so etwas wie eine Mitgliedschaft. Welche Rechte damit verbunden sind, entscheiden die jeweiligen Websitebetreiber (z.B. kommentieren, bestimmte Inhalte ansehen, die nur Mitglieder lesen dürfen oder Funktionen, die eine Mitgliedschaft erfordern). Zum Lesen ist ja in der Regel keine Mitgliedschaft (Registrierung) erforderlich. Und zum Abonnieren von RSS Feed etc. auch nicht (was die Bezeichnung Abonnent etwas impliziert).

    Uups .. jetzt bin ich durcheinandergekommen. Hier geht es ja um user, nicht um Abonnent. Aber Mitglied würde auch zu user passen, Abonnent wäre dann ein einfaches Mitglied. Ist nicht einfach das ganze …

    • This reply was modified 7 years, 4 months ago by Webmatter.
    • This reply was modified 7 years, 4 months ago by Webmatter.
    • This reply was modified 7 years, 4 months ago by Webmatter.
Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Warum nicht als eigene Sprachdatei?’ is closed to new replies.