MSC4247: User Pronouns #4247
There are no files selected for viewing
|
There was a problem hiding this comment. @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) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| # MSC4247: User Pronouns | ||
|
|
||
| Many users of Matrix put pronouns in display names. However, that causes screen | ||
| clutter. This proposal defines a standardized pronouns field on top of | ||
| [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). | ||
|
|
||
| ## Proposal | ||
|
|
||
| Profiles may have an optional `m.pronouns` field as an | ||
| array. These fields can be fetched through the | ||
88572 marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. 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. |
||
| [profile API endpoints](https://spec.matrix.org/unstable/client-server-api/#profiles). | ||
| Clients should use these instead of they/them where possible. All fields | ||
| within `m.pronouns` are optional, exluding `"language"` and `"summary"`. | ||
88572 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### Example | ||
|
|
||
| ```json | ||
| { | ||
| "avatar_url": "…", "displayname": "…", | ||
| "m.pronouns": [ | ||
| { | ||
| "grammatical_gender": "inanimate", | ||
|
There was a problem hiding this comment. 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 ( There was a problem hiding this comment. 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 🙂 There was a problem hiding this comment.
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. There was a problem hiding this comment. 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 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!) |
||
| "language": "en", | ||
|
There was a problem hiding this comment. 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. |
||
| "summary": "it/its" | ||
| }, | ||
| { | ||
| "grammatical_gender": "feminine" | ||
| "language": "en", | ||
| "summary": "she/her" | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
| The example uses it/its pronouns followed by she/her pronouns, both in English. | ||
| The array is ordered by preference, `language` should be a | ||
| [BCP-47](https://www.rfc-editor.org/rfc/bcp/bcp47.txt) language code, and | ||
| clients should render the `summary` for the pronouns. Clients SHOULD use the | ||
|
There was a problem hiding this comment. 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. |
||
| `grammatical_gender` if possible in state events. For example, "Alice changed | ||
| her avatar" for `feminine` or "Alex changed its avatar" for `inanimate`. | ||
|
|
||
| ## Potential issues | ||
|
|
||
| Some users may not want to publish pronouns to others, although that is out of | ||
| scope for this MSC. Some users may also complain about "woke", although | ||
| pronouns are a basic part of langauge. | ||
|
|
||
| ## Security issues | ||
|
|
||
| None. | ||
|
There was a problem hiding this comment. Potential for abusive content in the free-text field (obviously no more so than display names though, but I think it's worth noting). |
||
|
|
||
| ## Unstable prefix | ||
|
|
||
| Clients and servers wishing to implement this early may use | ||
| `io.fsky.nyx.pronouns`. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With gomuks/gomuks#574, Gomuks supports rendering pronouns (setting them is not implemented in the UI yet, but is supported on the backend).