Add gender neutral title "Mx"

The name module allows site builders to define a vocabulary for titles.

I am not sure how Mx would be translated.

Three of the seven options are already gender neutral: Dr, Prof, and 'blank'

Is Mx a gender-neutral title or a non-binary gendered title?

I understand the motivation behind increasing familiarity with gender-neutral titles, but I would question whether a software module is the right vehicle for that goal. Exposure can make something more familiar, but it does not automatically lead to acceptance — people respond to ideas through experience, not repetition alone.

From a practical standpoint, defaults in software are meant to serve the broadest range of users with the least friction. When defaults are used to promote social visibility rather than usability, it can blur the line between function and advocacy. Flexibility already exists for organizations or individuals who wish to add their own titles, without imposing assumptions on everyone else.

In short, it may be wiser to keep defaults focused on clarity and efficiency, leaving social or cultural choices to those implementing the software in their own context.

I agree with Fei's comment that it is important to have a gender-neutral option built in. Please include Mx.

I think it is important to be as inclusive as possible when it comes to titles. Identity is very important. Mx would be an appropriate addition to the defaults.

Inclusion is a worthy goal, but software is a poor place to conduct social experiments. A title field exists to collect information, not to make cultural statements. When defaults are used to advance symbolism, the function is often lost in the gesture.

It’s true that defaults matter — but that is precisely why caution is needed. A default doesn’t merely permit something; it endorses it. Including Mx. “out of the box” subtly promotes a Western, Anglophone understanding of gender and language. Many users around the world do not share that frame of reference. For non-fluent Anglophones, Mx. may resemble a typographical error for 'Mr' or 'Ms', much like the old “manimum” and “miximum” confusion between minimum and maximum. What seems progressive in one context can be perplexing in another.

Site builders who are fluent in English can remove Mx. without difficulty, but the burden falls disproportionately on non-Western, non-English-speaking communities. Drupal has strong multilingual support, yet translation coverage is lowest among the language groups least likely to have established gender-neutral titles. Imposing this default shifts the work to those least positioned to accommodate it, while offering symbolic gain primarily to those most insulated from the consequences. True inclusion is better achieved through flexibility — allowing each community to define titles appropriate to its language, culture, and users.

I am unable to find evidence from the Drupal ecosystem of other projects using Mx. as an honorific. Introducing it without precedent risks imposing novelty and additional workload on contributors—especially volunteers, many from the very groups your advocacy seeks to support, including those defined by ethnicity, nationality, socioeconomic status, language, (dis)ability, age, religion, or political perspective. Well-intentioned advocacy must account for real-world implementation costs.

The claim that failing to include Mx. constitutes exclusion raises a critical question: if inaction is itself an act, where does it end? If the absence of a single honorific is morally exclusionary, then the omission of every possible honorific in every culture would also constitute exclusion. This reasoning collapses under its own universality, making everyone guilty of every omission. Defaults in software should serve the broadest range of users with minimal friction, not enforce ideological symbolism.

Diversity, equity, and inclusion are outcomes we all support, but achieving them in software is procedural: systems must allow flexibility, empower communities, and enable contribution without coercion. A more sustainable path is to document Mx. as an optional honorific in the README, allowing those who wish to adopt it while preserving usability and fairness for all. Inclusion is meaningful only when it respects both ideals and the practical limitations.

As my 2 cents as the original developer.

I spent way to much time looking at naming issues from an international perspective and i18n translation issues by themselves would make this problematic. I would be against the change for that reason alone.

Making simple instructions on how to include this option within the readme would be a welcome addition.

I'll just note the obvious elephant in the room, you can make titles optional. This avoids having to express that you are uncomfortable using a gender title and some people will read the Mx title with negative cogitations

Removing this from the end user interface completely is probably the most inclusive method.

Titles are old fashioned these days, but honorary titles are still commonplace. The best solution could be to add a non-gendered title formatter option.

I.e. Mr, Ms, Mx, ... get removed, Dr, Prof, .. stay.

Then change the default formatting option to use this. Change rather than adding new options that would clutter the initial list.

No update script to change the default formatter.

Possibly implemented using a new specific taxonomic field, and checking that field during formatting.

One quick and easy addition would be to add a conditional warning linked to the title component required settings to rise the issue with site builders within the admin UI

This issue predates those around personal identity with relation to gender equality, so maybe something generic like;

To avoid issues with gendered titles (Mr, Miss, etc), consider including a non-gendered title option (Mx) [when setting this to be required] if you haven't already done so

Title options can be set here.

I'm sure someone can come up with better wording, but no need to go into specifics.

Either always show, adding a warning class when set to required OR only show with the warning class when the title required field is checked (removing the extra text in the sq brackets). I think I'd prefer the latter if toggling the visibility doesn't cause usability issues with elements moving about.

Maybe link issues to a drupal.org page that covers these in more detail. If there are multiple pages, pick the one for gender equality in that this affects over half of the population and this is fairly non-political nowadays.

Any links in the message should open in a new window/tab.

We can initiate the translation process by adding Mx to the Name module. Mr, Miss and Mx in the above warning message should be inserted individually, which will trigger this. :)

If someone is keen to tackle either task, create a couple new child issues for each.

The only barrier I have to adding Mx is the translation issue. I'd be happy revisiting this once a large majority of Name modules translations support it (>95%).

We can leave this as an open parent issue but postponed until there is enough support.

I forgot, a third child issue to make a section of the module readme that rises the issue too.

Something like the following.

Change Resources to Honorific Titles and move this section above the maintainers section (that also needs updating, separate issue)

The module ships with a limited list of title options. These are stored in a vocabulary allowing site builders to easily add or remove title options.

* Mr
* Mrs
* Miss
* Ms
* Dr
* Prof

If your language supports a generic non-gendered title such as Mx, this is a recommended title option to add to the default list, especially if you make the title component required.

* Mx

Here is a comprehensive list of titles if you feel that the standard list is not enough:

* Brother
...

[Edit]
I'm currently on an extended kayaking trip and haven't seen any of the changes done to the module in the last 5 years.

I'm going off a comment suggesting the title options are now only stored in a vocabulary but these use to be in the field settings with the option to use a vocab.

If it is still the same, the wording will need to be adjusted slightly for the field settings warning and readme.