MSC3226: Per-room spell check #3226
Conversation
turt2live
changed the title
turt2live
added
client-server
✔️ Done. |
| Clients offering spell checking should default their dictionary to the system language. They should offer | ||
| a way to change it and when the user sets a specific language, then they should store the language code | ||
| as `m.input_language` account data for the room where it was set. Language codes must be | ||
| [RFC3066](https://datatracker.ietf.org/doc/html/rfc3066) compliant. |
There was a problem hiding this comment.
This doesn't seem to say which field to store the language code in
{
"type": "m.input_language",
"content": {
"???": "fi-FI"
}
}There was a problem hiding this comment.
Ha, right. We currently use:
{
"type": "org.gnome.fractal.language",
"content": {
"input_language": "fr_FR"
}
}in Fractal. Would it make sense to have m.input_language as the type and input_language as the field name?
There was a problem hiding this comment.
The field name isn't too important so it's probably easiest to just go with what you're already using.
If you want to bikeshed it more, here's what the spec currently has:
m.room.name->namem.room.topic->topicm.room.avatar->urlm.room.join_rules->join_rulem.room.history_visibility->history_visibilitym.room.guest_access->guest_accessm.room.canonical_alias->aliasm.room.pinned_events->pinnedm.tag->tagsm.ignored_user_list->ignored_usersm.fully_read->event_id
| The language could be defined as a room property: a room administrator could set it once and then every | ||
| member would get it for free. However, not everyone in a given room necessarily talks in the same language | ||
| (or even language variant, e.g. en_US vs en_GB) and there would need to be a way for users to override the | ||
| room property. This MSC could be used as a mechanism to do said override, if such a room property were ever | ||
| defined. Adding a room property requires more work and thought, and can be done in another MSC. It is thus | ||
| considered out of scope for this one. |
There was a problem hiding this comment.
Does it require that much more work and thought to say that m.input_language can be in either room state or room account data, with the room account data taking priority?
There was a problem hiding this comment.
To be honest I don’t know how room properties work that well, and I suspected it might impact room versioning. More work meant at the minimum more investigative work to see what the real impact is.
There was a problem hiding this comment.
It doesn't impact room versioning, only things that change the federation protocol (event authorization rules, state resolution, etc) need a new room version. It works pretty much the same way as account data: invent an event type and put arbitrary JSON inside.
There was a problem hiding this comment.
Alright, sounds good! I’ll update the proposal to add the room property. Thank you.
|
|
||
| Clients offering spell checking should default their dictionary to the system language. They should offer | ||
| a way to change it and when the user sets a specific language, then they should store the language code | ||
| as `m.input_language` account data for the room where it was set. Language codes must be |
There was a problem hiding this comment.
I've seen chats with multiple common languages. Would it make sense to make this an ordered list of languages based on"preference"? I would also happily add a caveat that many clients will just use the first one.
But this could be helpful for using the sum of the dictionaries or similar for spell check.
turt2live
added
the
needs-implementation
|
@afranke, this seems to have been merged without FCP? |
|
I’m so sorry, I messed up trying to adjust my fork to the renamed main branch. I’ll revert right now. |
No worries, just confused a couple of people :) |
turt2live
added
obsolete
Rendered
Signed-off-by: Alexandre Franke afranke@gnome.org