MSC4247: User Pronouns

[88572]

Rendered

Implementations:
SDK:

• Implement arbitrary fields for RespUserProfile mautrix/go#337

[turt2live]

Implementation requirements:

• Client
• Server

[tcpipuk]

Conduwuit already supports this by supporting arbitrary fields in #4133 so I'd assume this MSC only requires a client implementation that can read/write the field?

[nexy7574]

With gomuks/gomuks#574, Gomuks supports rendering pronouns (setting them is not implemented in the UI yet, but is supported on the backend).

[uhoreg]

Seems pretty straightforward. A few mostly-nitpicky comments.

[sumnerevans]

What grammatical genders are available? I think they need to be enumerated. I don't know what grammatical gender "they/them" would be, for example.

I also think they need to be prefixed (m.male for example) and defined what that means in terms of how the UIs should adapt their rendering. This will also allow for future grammatical genders from other languages or linguistic innovations to be defined later (and use unstable prefixes).

[tcpipuk]

Some languages distinguish between "animate" and "inanimate" so @everypizza1 may want to consider whether it's important to consider bot accounts as "inanimate" or whether we just anthropomorphise every user, but from brief research into a few African, Asian, and European languages, I think this should cover most of them:

{
    "m.pronouns": [
        {
            "grammatical_pattern": "masculine",
            "forms": {
                "en": {
                    "subject": "he",
                    "object": "him",
                    "possessive_determiner": "his",
                    "possessive_pronoun": "his",
                    "reflexive": "himself",
                    "dependent": "him"
                }
            },
            "display": { "en": "he/him" }
        },
        {
            "grammatical_pattern": "feminine",
            "forms": {
                "en": {
                    "subject": "she",
                    "object": "her",
                    "possessive_determiner": "her",
                    "possessive_pronoun": "hers",
                    "reflexive": "herself",
                    "dependent": "her"
                }
            },
            "display": { "en": "she/her" }
        },
        {
            "grammatical_pattern": "neuter",
            "forms": {
                "en": {
                    "subject": "it",
                    "object": "it",
                    "possessive_determiner": "its",
                    "possessive_pronoun": "its",
                    "reflexive": "itself",
                    "dependent": "it"
                }
            },
            "display": { "en": "it/its" }
        },
        {
            "grammatical_pattern": "common",
            "forms": {
                "sv": {
                    "subject": "hen",
                    "object": "hen",
                    "possessive_determiner": "hens",
                    "possessive_pronoun": "hens",
                    "reflexive": "sig",
                    "dependent": "hen"
                }
            },
            "display": { "sv": "hen/hens" }
        },
        {
            "grammatical_pattern": "plural",
            "forms": {
                "en": {
                    "subject": "they",
                    "object": "them",
                    "possessive_determiner": "their",
                    "possessive_pronoun": "theirs",
                    "reflexive": "themself",
                    "dependent": "them"
                }
            },
            "display": { "en": "they/them" }
        },
        {
            "grammatical_pattern": "epicene",
            "forms": {
                "en": {
                    "subject": "ze",
                    "object": "zir",
                    "possessive_determiner": "zir",
                    "possessive_pronoun": "zirs",
                    "reflexive": "zirself",
                    "dependent": "zir"
                }
            },
            "display": { "en": "ze/zir" }
        },
        {
            "grammatical_pattern": "none",
            "forms": {
                "fi": {
                    "subject": "hän",
                    "object": "häntä",
                    "possessive_determiner": "hänen",
                    "possessive_pronoun": "hänen",
                    "reflexive": "itsensä",
                    "dependent": "hänen"
                }
            },
            "display": { "fi": "hän/häntä" }
        }
    ]
}

There are extra forms not covered here, e.g. some languages have "noble" versions, but this MSC might want to just state an assumption that a chat protocol does not necessarily need or want to record the nobility level of the user 🙂

[88572]

may want to consider whether it's important to consider bot accounts as "inanimate" or whether we just anthropomorphise every user

It's not just bot accounts that would have that - some users also use inanimate pronouns. The extended classes of pronouns will probably end up being removed, because most users will just want the summary and grammatical gender.

[dbkr]

To nudge this back on point, I agree that these really could do with being enumerated: free text isn't useful here as clients need to know what values are possible and how to handle them. I don't think they need m. prefixes as I doubt we'd ever allow custom reverse DNS values here. I do think that expanding on JContact's definitions by giving the sets of pronouns they're intended to map to (in whatever language) alongside each one, and probably setting a standard for the set of English pronouns to use. For example, it's unclear what "animate" is actually supposed to mean given that in English there would be animate-feminine, animate-masculine, etc.

I'd also argue for giving some hints as to how clients might use these. For example, I'd suggest offering a dropdown of common sets of pronouns and then also allowing free text. If the user picks a common one, the grammatical_gender can be set accordingly. If they enter free text, grammatical_gender gets omitted.

Also also, I'd argue that we don't need to get this 100% complete on the first go. I'd suggest starting off simply with the common English ones: 'neuter' meaning (they/them), 'masculine' (he/him), 'feminine' (she/her) and 'inanimate' (it/its) - anything else is expressed with free text (or a client could even add others to the dropdown if it chooses, it would just leave grammatical_gender unset). Others mappings between pronouns and grammatical_gender can be added in other MSCs.

We could also remind clients that "Not specified" must be an option (indeed, the default!)

[tulir]

@ara4n pointed out JSContact (RFC9553) in #4175 (comment). Looks like they have a pronoun field and ended up with basically the same design of declaring a grammatical gender and summary: https://www.rfc-editor.org/rfc/rfc9553.html#name-speaktoas

Main difference is that they only allow declaring 1 grammatical gender, which seems quite dumb. It's also a lot more complicated overall (translations are in an entirely separate top-level object and I have no idea what those k19 and k32 keys are)

[dbkr]

With regards to this being an array, note that JContact is a dictionary with context and preference order which means it's possible to designate different pronouns for different situations, and also to have pronouns of equal preference. However, given that this also has to be easy for a user to input and read, I think I'm leaning towards the solution of an array and assuming that if some are context-dependent then it will be apparent to the reader which to use when. In any case, a machine won't know this context so it's useful to express a default for this. I do think it's worth adding as an alternative though: this proposal lacks an alternatives section and it could probably use one.

[dbkr]

I would probably vote for removing 'language' here, at least for a first cut of this feature. It's not 100% clear whether it's describing just the summary field or the grammatical_gender field too, and what the latter would mean. I feel like it's probably a vestige from when this MSC had the full set of pronouns individually. If it is included, I think it would need a fair bit of explanation on how it would actually be applied.

[dbkr]

Firstly, this is duplicative with the first paragraph of the proposal. Secondly, this is nontrivial. I think we need to give clients some hints on how they'd actually do this, ie. by picking an appropriate translation using the grammatical_gender field, accepting that this might get quite complex in different language, however I think it's okay to leave the specifics of what to use in different languages to the clients. I think it's worth specifying that they should be using grammatical_gender and not trying to parse the summary.

Also, I wouldn't use the phrase "state events" here (the events themselves are protocol-level), I would generalise to whenever the client refers to the user as you did above, calling out display name changes as an example.

[dbkr]

Potential for abusive content in the free-text field (obviously no more so than display names though, but I think it's worth noting).

[chri-k]

unlike display names, this is expected to inject arbitrary text into completely unmarked parts of the client's interface. clients should be reminded that nothing prevents the pronouns from being set to someone else's name or an entire paragraph which looks suspiciously like the surrounding UI text

[ranidspace]

From what I can tell, state events are changed based on the grammatical_gender field which clients would have to implement each one manually. It should fall back to the default neutral set when encountering a grammatical_gender it cant handle, and then any instances of summary, as it would appear in a profile or next to a message, can be marked similar to a username. This is my guess though, I feel like the MSC should be more explicit on how to actually handle these fields.

[Merikei]

Think what the order is should be defined too (presumably "most preferred first"?)

Example based on content/client-server-api/modules/search.md:

• rank, which returns the most relevant results first.