Note: This is related to T61643 but I oppose merging this ticket to there. I'm proposing something very specific here and merging would just dilute the discussion.

The user story in the description references client-side run javascript files. Such scripts could be updated to use non-gendered pronouns in the absence of a user configured grammar preference, as opposed to omitted that output.

As far as I understand, it was probably a deliberate design choice to not display explicit pronouns when the grammatical gender has not been explicitly selected. First, people are unaware of the grammatical gender option existing in the first place. This results in a majority of accounts not having an explicit grammatical gender set (thus defaulting to "neutral at best efforts").

It would be incorrect to make the tool display "they/them" as if the user themselves explicitly requested they/them pronouns because it is wrong and may mislead users into thinking that so many Wikipedia editors are non-binary. It's a good default to not show pronouns when the user hasn't configured them.

Non-binary people, however, will have the option deliberately unset. It's logical to have that separate from an "unset by default" option.

I agree that Navigation popups should make a distinction between “unknown” and “non-binary”. For example, when I want to refer to someone in third person, I first hover over their user name with Navigation popups. If I see “he/him” or “she/her” there, I stop and use that pronoun; otherwise I try harder (e.g. looking at their user page to see if a pronoun is listed there). If “they/them” would appear in the popup, I could stop there in case of non-binary people as well – but only if that “they/them” would always mean “non-binary”, and never “unknown”.

For the technical implementation: since it’s a third-party gadget, it would in theory be possible to store the non-binary gender somewhere else (e.g. on a user subpage), but I fear that would be a too large burden for many non-binary people, so they would simply not set their gender, and we’re back at the status quo. So I agree that this should be in the preferences, even if MediaWiki and extensions don’t currently make use of it.

Yes, these sort of optional client side javascripts can do lots of things, and do not need to depend on account variables. They can source information from other places.

In T389706#10893924, @Tacsipacsi wrote:

but I fear that would be a too large burden for many non-binary people, so they would simply not set their gender, and we’re back at the status quo.

Note: "English has a singular they that can be used but plenty of languages such as German don't have a singular third person pronoun. In many languages gender also has a more far-reaching effect then just affecting pronouns." - ChristianKl so having gender-neutral pronoun is a challenge for I18n.

Sorry if the task description can be confusing. The pronoun display should ideally use data from T389709, but these two tasks are orthogonal.

Many languages also have grammatical gender that force users to choose between binary (masculine/feminine) forms. Italian is one of those languages but people also advocate for forms like the schwa ǝ: https://italianoinclusivo.it/

Finding ways to be neutral with users is already a challenge for i18n. The existing setting already mentions "Use gender-neutral terms when possible". In some languages this could entail changing the structures of sentences completely so as to not depend on a user's gender.

This does nothing in particular for the translators because the explicit neutral and the implicit neutral should mostly be the same. In the future translators could decide to distinguish between an implicit neutral grammatical gender and an explicit one, which could be another benefit of this.

On the other hand, if T389709 gets done first, the main use case here should just read the pronoun data from that instead. But there should be a single space where a user configures both their grammatical gender settings (used by MW messages) and their pronoun settings (used by scripts, templates, etc)

I don't know/doubt if Navpopups "intentionally" sets the value to nothing by design. The default design pattern in MediaWiki is to consider the third option to be they/them. The initial impetus of the task feels like a gadget-specific misunderstanding that can be rectified on enwiki/other wikis that use Navpopups. I think a good place to start might be to just make an interface-admin request to Navpopups, and if nobody objects, we can change <null> to they/them.

(Note that changing Navpopups itself should not preclude a change to core to modify the gender system, though I do see it as being a non-trivial endeavour that will require a huge amount of effort from folks handling translations)

In T389706#11022407, @Soda wrote:

The default design pattern in MediaWiki is to consider the third option to be they/them.

The default design pattern in MediaWiki assumes that the pronouns cannot be skipped – you can say “thank them for their edit”, “thank her for her edit”, “thank him for his edit”, but you cannot say “thank for edit”. This is why that default design pattern conflates “I don’t care about pronouns” with “I prefer non-binary pronouns”. NavPopups, on the other hand, allows for this differentiation: “I don’t care” is represented by nothing shown, while “I prefer non-binary” could be represented by “they/them” shown. This difference is not inherently NavPopups-specific – any tool that can handle “unknown” and “non-binary” differently could make use of this.

I think a good place to start might be to just make an interface-admin request to Navpopups, and if nobody objects, we can change <null> to they/them.

That wouldn’t solve anything. Taking “they/them” in case of a lack of explicit preference is easy. (This bit is about providing information, not about actually using the correct pronoun, so it’s up to humans to interpret it, and humans can interpret it.) The problem is that there’s no way to represent the presence of explicit preference for they/them. There should be four states, and the API is capable of returning only three different states; no change to the gadget can fix this.

In T389706#11022417, @Tacsipacsi wrote:

In T389706#11022407, @Soda wrote:

The default design pattern in MediaWiki is to consider the third option to be they/them.

The default design pattern in MediaWiki assumes that the pronouns cannot be skipped – you can say “thank them for their edit”, “thank her for her edit”, “thank him for his edit”, but you cannot say “thank for edit”. This is why that default design pattern conflates “I don’t care about pronouns” with “I prefer non-binary pronouns”. NavPopups, on the other hand, allows for this differentiation: “I don’t care” is represented by nothing shown, while “I prefer non-binary” could be represented by “they/them” shown. This difference is not inherently NavPopups-specific – any tool that can handle “unknown” and “non-binary” differently could make use of this.

Assuming we do make a change to return unknown vs nonbinary, how would you expect the thanks example to handle unknown?

I think a good place to start might be to just make an interface-admin request to Navpopups, and if nobody objects, we can change <null> to they/them.

That wouldn’t solve anything. Taking “they/them” in case of a lack of explicit preference is easy. (This bit is about providing information, not about actually using the correct pronoun, so it’s up to humans to interpret it, and humans can interpret it.) The problem is that there’s no way to represent the presence of explicit preference for they/them. There should be four states, and the API is capable of returning only three different states; no change to the gadget can fix this.

My proposal here was/is to synchronize Navpopups with the behavior that we see in the rest of the MediaWiki interface for now until a core change is implemented to give us the four states. I am aware that it won't solve the overarching problem.

In T389706#11022430, @Soda wrote:

Assuming we do make a change to return unknown vs nonbinary, how would you expect the thanks example to handle unknown?

The same way as nonbinary. In contexts where a pronoun is necessary, we cannot meaningfully differentiate, nor should we do so.

My proposal here was/is to synchronize Navpopups with the behavior that we see in the rest of the MediaWiki interface for now until a core change is implemented to give us the four states. I am aware that it won't solve the overarching problem.

I think the current behavior of NavPopups is as close to the reality as possible – the current “Unspecified: Use gender-neutral terms when possible” setting means unknown in 99.99% of the cases, and means nonbinary only in 0.01% of the cases. As explained above, the rest of the MediaWiki interface needs to treat the two the same, so I wouldn’t say NavPopups is out of sync; it just takes the more probable interpretation.