Merge open-i18n#228

228: Fix several spelling errors r=behnam a=RaphaelAddile



Co-authored-by: Raphael Addile <[email protected]>

Author: bors[bot]

CONTRIBUTING.md

@@ -92,7 +92,7 @@ Please consider running through these steps before submitting a PR for UNIC:
 
 7.  For pre-`1.0.0` development, we try to have a new release after each new
     Rust release. Therefore, there's no need to make new releases after each
-    major or minor component, and as a result, no reason to bump verion in PRs.
+    major or minor component, and as a result, no reason to bump version in PRs.
 
 ## Miscellaneous
 

README.md

@@ -17,7 +17,7 @@
 to provide high-quality and easy-to-use crates for Unicode
 and Internationalization data and algorithms. In other words, it's like
 [ICU](http://site.icu-project.org/) for Rust, written completely in Rust, mostly
-in *safe* mode, but also benifiting from performance gains of *unsafe* mode when
+in *safe* mode, but also benefiting from performance gains of *unsafe* mode when
 possible.
 
 ## Project Goal
@@ -38,7 +38,7 @@ Please see [open issues](https://github.com/open-i18n/rust-unic/issues) for chan
 planed.
 
 We expect to have the `1.0` version released in 2018 and maintain a stable API
-afterwards, with possibly one or two API udpates per year for the first couple
+afterwards, with possibly one or two API updates per year for the first couple
 of years.
 
 ## Design Goals
@@ -138,10 +138,10 @@ Some of the reasons to have a combined repository these components are:
     cross-depend only on what they need, allow users to only bring in what they
     consume in their project.
 
-*   **Shared bootstraping.** Considerable amount of extending Unicode/i18n
+*   **Shared bootstrapping.** Considerable amount of extending Unicode/i18n
     functionalities depends on converting source Unicode/locale data into
     structured formats for the destination programming language. In a combined
-    repository, it's easier to maining these bootstraping tools, expand
+    repository, it's easier to maintain these bootstrapping tools, expand
     coverage, and use better data structures for more efficiency.
 
 ## Documentation

apps/cli/README.md

@@ -2,7 +2,7 @@
 
 [![Crates.io](https://img.shields.io/crates/v/unic-cli.svg)](https://crates.io/crates/unic-cli)
 
-This package provides comman-line tools for developers, helping with common
+This package provides command-line tools for developers, helping with common
 Unicode tasks, like generating, transforming, and inspecting strings.
 
 
@@ -102,4 +102,4 @@ $ unic-inspector Hello سلام
 ```
 
 Soon, this tool will allow selecting which properties to show, as well as
-support grouping characters by Grapheme Clusters, Words, Sentenses, etc.
+support grouping characters by Grapheme Clusters, Words, Sentences, etc.

docs/Unicode_API.md

@@ -16,7 +16,7 @@ more in *Unicode Character Database (UCD)* ([UAX\#44](http://www.unicode.org/rep
 
 Some of these properties are now *deprecated*, meaning that they are no longer recommended for
 use. Some other properties are considered *contributory* properties. Neither of these groups of
-properties will be support in UNIC, unless there is clear demand for them.
+properties will be supported in UNIC, unless there is clear demand for them.
 
 Other specifications published by the Unicode Consortium, like the *Unicode IDNA Compatibility
 Processing* ([UTS\#46](www.unicode.org/reports/tr46/)) and the *Unicode Emoji*
@@ -28,14 +28,14 @@ implemented by UNIC. See the [Unicode Technical Reports](http://www.unicode.org/
 for a complete list of these specifications and their current status.
 
 
-### Naming Convension
+### Naming Convention
 
-The character properties defined in Unicode specifications follow a common naming convension.
-Each charcter property and (non-numeric) property value has a name and an abbreviation.
+The character properties defined in Unicode specifications follow a common naming convention.
+Each character property and (non-numeric) property value has a name and an abbreviation.
 
-The UNIC API for character properties is based on this convension and tries to stay as close as
+The UNIC API for character properties is based on this convention and tries to stay as close as
 possible to this naming schemes, making it easier to use the library when familiar with the
-Unicode convensions.
+Unicode conventions.
 
 NOTE: Since Rust does not support aliases for `enum` variants, only the *long names* are
 supported in UNIC components. Property abbreviation names are provided in the documentation (to

docs/Unicode_and_Rust.md

@@ -27,7 +27,7 @@ following *assignment* statuses:
 -   **assigned character**, code points that are marked to be an *Encoded Character*,
 
 
-    Chatacter*, or
+    Character*, or
 
 -   **unassigned** or **reserved**, code points that can become an *Encoded Character* in the
     future.
@@ -86,24 +86,24 @@ because of any limitations with upgrading its code to a newer version of the com
 
 And a peculiar case for keeping the Unicode version of the data separate from the code is when
 it gets to *Private-Use Code Points*. These code points (like any other code point) receive
-*default* character properties, which are specified by the Unicode Stanard. However, they *can*
+*default* character properties, which are specified by the Unicode Standard. However, they *can*
 be assigned non-default property values, as deemed by the application. This is something that
 should never affect how source code is being compiled, or a compiler being deployed, but only
-the data being processed an application with clear boundries for the Private-Use code points.
+the data being processed an application with clear boundaries for the Private-Use code points.
 
-## Tehnical Challenges
+## Technical Challenges
 
 A big technical challenge with having more than one library (a language core library and some
 third-party libraries) for basic character/string functionalities and text processing for
-handling text is the *possiblity* of them getting mixed up. This is where every programmer need
+handling text is the *possibility* of them getting mixed up. This is where every programmer need
 to pay attention to which library to use in every situation.
 
 That is why having **one** library that provides majority of functionalities and enforces
 consistency between its components is important in this area. UNIC has a goal to enforce this
 consistency during its own development time (via integration tests), as well as in application
 runtime (assertion in debug mode).
 
-Still, there is one sutation that is not aviodable by third-parties: mixing core library and
+Still, there is one situation that is not avoidable by third-parties: mixing core library and
 third-party library in one process.  Here, the burden is on the application developer to avoid
 any mixing, or ensure and verify that it is safe to do so.
 

docs/Versioning.md

@@ -26,7 +26,7 @@ policies are followed with respect to new Unicode versions.
 
 This allows applications to *intentionally* opt-in for Unicode version upgrades, if needed, by
 fixating on UNIC minor versions. This can be useful and important for some applications, like
-search indices, as there as Unicode text processing algorithms that are not promissed to be
+search indices, as there as Unicode text processing algorithms that are not promised to be
 stable between Unicode versions. See [Unicode Character Encoding Stability
 Policies](http://unicode.org/policies/stability_policy.html) for more details.