Fix trivial typos in EEP-0035

eeps/eep-0035.md

@@ -68,10 +68,10 @@ throughout the entire lifespan of Erlang/OTP. The string
 representation used has also withstood the evolution of Unicode.
 
 It is worth to note that the only functions in the ``string`` module
-that actually is language or region dependent are later additions to
+that actually are language or region dependent are later additions to
 the module. Those functions (like ``to_upper``, ``to_lower``, ``to_integer`` and
-``to_float``), or their binary equivalence, is not part of the module
-interface i suggest for ``bstring`` for the simple reason that they
+``to_float``), or their binary equivalence, are not part of the module
+interface I suggest for ``bstring`` for the simple reason that they
 need language support not yet present in Erlang. A future EEP might
 suggest such language support (i.e. some kind of "locale" support), but
 that is future work not covered by this EEP.
@@ -110,8 +110,8 @@ manipulating strings encoded in binaries:
   separated by spaces imposes a restriction of the relevant languages.
 
 - Left to right or right to left - Notions like left or right to
-  denote the beginning or end of a string is certainly not language
-  independent. While strings in a language has a beginning and an end,
+  denote the beginning or end of a string are certainly not language
+  independent. While strings in a language have a beginning and an end,
   that beginning and end may be placed both to the left, the right or
   even at the top, bottom or center of the graphical representation. A
   string manipulation module should not use naming implying a
@@ -142,9 +142,9 @@ I'll address the different issues below.
 Unicode
 -------
 
-The interface have to support both ISO-Latin-1 and UTF-8. The ``unicode`` module supports even more encodings, but Erlang/OTP uses UTF-8 for all "internal" interfaces and UTF-8 is the expected encoding of a binary Unicode string. Even though UTF-8 is compatible with ISO-Latin-1 in the 7bit ASCII range, characters with codepoints between 128 and 255 are encoded differently in the "plain" ISO-Latin-1 encoding and in UTF-8. This means that all functions in the ``bstring`` module need to have the actual encoding as one or more extra parameters. 
+The interface has to support both ISO-Latin-1 and UTF-8. The ``unicode`` module supports even more encodings, but Erlang/OTP uses UTF-8 for all "internal" interfaces and UTF-8 is the expected encoding of a binary Unicode string. Even though UTF-8 is compatible with ISO-Latin-1 in the 7bit ASCII range, characters with codepoints between 128 and 255 are encoded differently in the "plain" ISO-Latin-1 encoding and in UTF-8. This means that all functions in the ``bstring`` module need to have the actual encoding as one or more extra parameters.
 
-One could invent an more abstract binary string format where the data is for example represented as a tuple with the string and the encoding packed together. However no other module supports such a string construct and I don't think that would really add something, neither functionality nor readability. Consider code like:
+One could invent a more abstract binary string format where the data is for example represented as a tuple with the string and the encoding packed together. However no other module supports such a string construct and I don't think that would really add something, neither functionality nor readability. Consider code like:
 
     bstring:tokens(Bin,latin1,[$ ,$\n])
 compared to: