Revert per room spell check language MSC

This reverts commit 70192e8e1143ea3450db001b78b05039a3ef58b1.
This reverts commit 1b8f4e22b61196ce37dee0b230ae2c173aaa6676.

proposals/3226-per-room-spellcheck-language.md

@@ -1,42 +0,0 @@
-# MSC3226: Per Room Spellcheck Language
-
-It is common for people on the Internet to talk in more than one language. English will probably be
-the most used one, but for many it is not their mother tongue and they will use the latter as well.
-
-Clients can offer spell checking functionality, but in order to provide helpful suggestions they need
-to know which language the user is currently writing in. When spell checking is available, the language
-can usually be selected e.g. via the right click menu, but it becomes tedious when one switches back and
-forth between two or more of them.
-
-This proposal aims at providing users with a way to set a language per room, so that switching between
-conversations held in different languages automatically switches to the appropriate dictionary.
-
-
-## Proposal
-
-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.
-
-
-## Alternatives
-
-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.
-
-The feature can also work without actually adding it to the Matrix specification. There is indeed already
-one existing implementation (see [Unstable prefix](#unstable-prefix) below). Standardising the account data
-type though has the benefit that it is not client specific anymore, and the setting can be more easily reused
-by any number of clients.
-
-
-## Unstable prefix
-
-Fractal already successfully offers this proposed feature. It stores the language code under the
-`org.gnome.fractal.language` account data type. This was released on the stable channel as part of
-Fractal 4.4 on August 7th 2020.