Fix typos and grammar mistakes

proposals/2545-emotes.md

@@ -137,33 +137,33 @@ pack name and has a blank state key, then "room" is used.
 When sending an `<img>` tag in an end-to-end encrypted room, the client will make a request to fetch
 said image, in this case an emote. As there is no way to encrypt content behind `<img>` tags yet,
 this could potentially leak part of the conversation. This is **not** a new security consideration,
-it already exists. This, however, isn't much different of posting someone a link in an e2ee chat and
+it already exists. This, however, isn't much different from posting someone a link in an e2ee chat and
 the recipient opens the link. Additionally, images, and thus emotes, are often cached by the client,
 not even necessarily leading to an http query.
 
 # Alternatives
 One can easily think of near infinite ways to implement emotes. The aspect of sending an `<img>` tag
-and marking it as an emote with `data-mx-emote` seems to be pretty universal, though, so the question
+and marking it as an emote with `data-mx-emote` seems to be pretty universal though, so the question
 is mainly on different emote sources. For that, a separate MSC, [MSC1951](https://github.com/matrix-org/matrix-doc/pull/1951)
 already exists, so it is reasonable to compare this one with that one:
 
 ## Comparison with MSC1951
-MSC1951 defines as only emote source a dedicated room. This MSC, however, also allows you to bind emotes
+MSC1951 defines a dedicated room as the only emote source. This MSC, however, also allows you to bind emotes
 to your own account, offering greater flexibility. In MSC1951 there can also only be a single emote
 pack in a room. This could be problematic in e.g. bridged rooms: You set some emotes from the matrix
 side and a discord bridge would plop all the discord emotes in another pack in the same room.
 
 MSC1951 defines a way to recommend using a pack of a different room - this MSC does not have an equivalent
-of that. Instead, this MSC allows multiple emote packs for a room, and allows you to enable an emote
-pack to be globally available for yourself accross all rooms you are in.
+to that. Instead, this MSC allows multiple emote packs for a room, and allows you to enable an emote
+pack to be globally available for yourself across all rooms you are in.
 
 The core difference is how MSC1951 and this MSC define the emotes themselves: In MSC1951 you have to
 set one state event *per emote*. While this might seem like a nice idea on the surface, it doesn't
 scale well. There are people who easily use and want hundreds or even thousands of emotes accessible.
 A simple dict of shortcode to mxc URI seems more appropriate for this.
 
-Additionally, this MSC is already used in the wild since about two years by some clients, while MSC1951
-only exists in MSC form, so far.
+Additionally, this MSC has already been used in the wild for roughly two years by some clients, while MSC1951
+only exists in MSC form.
 
 In general, MSC1951 feels like a heavier approach to emote sourcs, while this MSC is more lightweight
-and thus should allow significantly larger packs.
+and thus should allow for significantly larger packs.