MSC4247: User Pronouns #4247
MSC4247: User Pronouns #4247
Conversation
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
There was a problem hiding this comment.
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?
turt2live
added
proposal
Co-authored-by: Travis Ralston <travpc@gmail.com>
proposals/4247-user-pronouns.md
Outdated
| } | ||
| ``` | ||
| The example uses it/its pronouns followed by she/her pronouns, both in English. | ||
| The array is ordered by preference, `language` should be a language code, and |
There was a problem hiding this comment.
Would ISO 639 language codes work?
There was a problem hiding this comment.
I think BCP-47 uses ISO 639, but also allows optional subtags for specifying regions (so both en and en-US are allowed in BCP-47, while ISO 639 only has the concept of en)
There was a problem hiding this comment.
I'll switch to BCP-47 then, so there's more flexibility.
proposals/4247-user-pronouns.md
Outdated
| "subject": "it", | ||
| "object": "it", | ||
| "possessive_determiner": "its", | ||
| "possessive_pronoun": "its", | ||
| "reflexive": "itself", |
There was a problem hiding this comment.
I'm not sure if these fields are a good idea, since they seem to be specific to English and probably aren't compatible with any other language. Also, I'd guess most implementations will simply use summary for displaying in the profile and won't even try to apply the other fields.
It might be better to just have the freeform field. Maybe also an enum (non-freeform string) for preferred grammatical gender, although even that could get complicated.
Is there any prior art or research into user-definable pronouns that support internationalization?
If the fields are kept as-is, each of them needs to be defined separately, it's not enough to have them in the example. Keeping the fields may also require an implementation actually using them to show they're useful.
There was a problem hiding this comment.
Thinking more about the enum: it should at least have values masculine, feminine and neuter. The potential complications I can think of are:
- Some languages don't have a real neuter. Maybe that's not a problem though, because clients have to be able to fall back to gender being unknown anyway?
- Some languages have animate and inanimate neuter forms (singular they vs it in English). Does the enum need to have those separately? (
neuter_inanimate) - There might be other types in some weird languages. Are there any, and if there are, do they need to be options too? (and then how do other languages handle those options?)
On the implementation side: pronoun information is generally only needed for rendering state events like profile changes ("X changed his/her/their name"), but those state events don't include this profile info. Fetching the full profile for each profile change state event seems like a bad idea.
In any case, a freeform field should exist to display when viewing someones profile. If the other fields can't be used effectively, then it may be best to narrow this down to only have the freeform field and nothing else.
There was a problem hiding this comment.
I think we may want to throw out subject, object, etc and do the masculine, feminine, and neuter with the animate and inanimate and for languages that don't support some of those, fall back to the closest to neutral.
| array. These fields can be fetched through the | ||
| [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"`. |
There was a problem hiding this comment.
| within `m.pronouns` are optional, exluding `"language"` and `"summary"`. | |
| within `m.pronouns` are optional, excluding `"language"` and `"summary"`. |
(since there is only one more field, it might be better to reverse the wording of this sentence and say that all are required except grammatical gender)
| "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 ne 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).
Rendered
Implementations:
SDK: