uk to us fixups (exercism#148)

* uk to us fixups * Update building/tracks/config-json.md Co-authored-by: ee7 <45465154+ee7@users.noreply.github.com> * aspell artefacts removed * dos2unix Co-authored-by: Bruce M. Axtens <bugmagnet@outlook.com> Co-authored-by: Jeremy Walker <jez.walker@gmail.com> Co-authored-by: ee7 <45465154+ee7@users.noreply.github.com>
kianmeng · Jun 18, 2021 · 318c8ad · 318c8ad
1 parent 72bee20
commit 318c8ad
Show file tree

Hide file tree

Showing 38 changed files with 66 additions and 66 deletions.
diff --git a/README.md b/README.md
@@ -6,7 +6,7 @@ These are the official docs for Exercism.
 We welcome all and any contributions.
 This repo is live-synced to the website.
 
-## How this repo is organised
+## How this repo is organized
 
 There are three top-level repositories:
 

diff --git a/building/tooling/analyzers/comments.md b/building/tooling/analyzers/comments.md
@@ -30,7 +30,7 @@ analyzer (those that can become output), are comments on the `main` branch, on
 the [`exercism/website-copy`][git-website-copy] repository.
 
 At the moment of writing, [this issue][issue-ci-comments] tracks the status of any
-generalisation of this CI, if any.
+generalization of this CI, if any.
 
 ## Wording
 

diff --git a/building/tooling/analyzers/creating-from-scratch.md b/building/tooling/analyzers/creating-from-scratch.md
@@ -6,7 +6,7 @@ These are the steps to get going:
 
 1. Check [our repository list for an existing `...-analyzer`](https://github.com/exercism?q=-analyzer) to ensure that one doesn't already exist.
 2. Scan the [contents of this directory](./) to ensure you are comfortable with the idea of creating an Analyzer.
-3. Open an issue at [exercism/exercism][exercism-repo] introducing yourself and telling us which language you'd like to create a Analayzer for.
+3. Open an issue at [exercism/exercism][exercism-repo] introducing yourself and telling us which language you'd like to create a Analyzer for.
 
 We have an incredibly friendly and supportive community who will be happy to help you as you work through this! If you get stuck, please speak to us on Slack or create new issues at [exercism/exercism][exercism-repo] as needed 🙂
 

diff --git a/building/tooling/analyzers/docker.md b/building/tooling/analyzers/docker.md
@@ -2,7 +2,7 @@
 
 Our Analyzers are deployed as Docker images.
 
-Please read the [general Tooling docker information](../docker.md) to familarise yourself with how these work.
+Please read the [general Tooling docker information](../docker.md) to familiarize yourself with how these work.
 
 When we run the Analyzer's container we execute a `run.sh` script.
 To ensure this works properly the following rules must be following:

diff --git a/building/tooling/analyzers/interface.md b/building/tooling/analyzers/interface.md
@@ -39,7 +39,7 @@ The `analysis.json` file should be structured as followed:
 
 ### `summary` (optional)
 
-The summary field is a text (not markdown) field that summarises the output.
+The summary field is a text (not markdown) field that summarizes the output.
 It might say something like "Your solution is nearly there - there's just two small changes you can make." or "The code works great, but there's a little bit of linting that needs doing.".
 This summary is rendered on the website above the comments.
 
@@ -58,7 +58,7 @@ The pointer-string to a file in `website-copy`.
 A JSON Object containing any params that should be interpolated during rendering.
 For example, in the markdown file, you could write `Try %{variable_name} += 1 instead`, and then set `params` to `{ "variable_name": "foo"}` in order to substitute `%{variable_name}` for the actual variable that the student used.
 
-When using parameterised files, ensure to escape all uses of `%` by placing anther `%` in front of it.
+When using parameterized files, ensure to escape all uses of `%` by placing anther `%` in front of it.
 e.g. `Try aim aim for 100%% of the tests passing`.
 
 #### `type` (optional)
@@ -107,7 +107,7 @@ more about the [goal of exercism here](https://github.com/exercism/docs/blob/mai
 
 In the following paragraphs, keywords such as **MUST**, **SHOULD**, **MAY**
 are to be interpreted as in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt);
-given that we recognise the following four output states and their restrictions:
+given that we recognize the following four output states and their restrictions:
 
 - `approve`: **MUST** be an approvable solution, **MAY** be with comment.
 - `disapprove`: **MUST** be with comment
@@ -119,7 +119,7 @@ Per [RFC2119](https://www.ietf.org/rfc/rfc2119.txt), if **MUST** is used, it is
 a guarantee that the rule is always so, and does not need to be guarded for. For
 example, **MUST** be without comment means that the website could crash if an
 analyzer sends a comment anyway. **SHOULD** indicates any consumer of the output
-must still guard against unwanted behaviour.
+must still guard against unwanted behavior.
 
 ### Approvability
 
@@ -148,8 +148,8 @@ language features are part of "idiomatic rules" and not stylistic choices.
 Example: **Ruby**'s MRI treats variables named `_` differently.
 
 Finally there are rules that are pure preferences, even though they might be
-adopted by large bodies such as organisations and corporations. These rules
-are usually part of _competing_ standards. Exercism does not favour one over
+adopted by large bodies such as organizations and corporations. These rules
+are usually part of _competing_ standards. Exercism does not favor one over
 another. Example: **TypeScript** has a linter `tslint` (or `eslint` + plugin)
 which is maintained by a company that is not Microsoft. It competes with other
 linters such as `xo`. Most of the rules are not language features or idiomatic
@@ -204,14 +204,14 @@ to the official rules.
 
 - **Ruby** has a language feature where `_` is treated differently,
   - :-1: if a student uses `_` for a variable name, but then uses it.
-- **Ruby** recognises `constants` only if they start with a **C**apital Letter,
+- **Ruby** recognizes `constants` only if they start with a **C**apital Letter,
   - :-1: if a student uses `snake_case` for a `class` name
 - **Ruby** has _de facto_ standards on `cAsInG` and `name-ing`,
   - :speech_balloon: you **SHOULD** guide students that `snake_case` is to be
     expected by most IDEs and highlighting on exercism in code blocks.
 - **JavaScript** IDEs highlight variables which are not used, except for those
   prefixed with an underscore (`_`).
-  - :speech*balloon: note that this behaviour exist so it might help them to use
+  - :speech*balloon: note that this behavior exist so it might help them to use
     a different naming strategy. They might think that prefixing with `*`means `private`, which is not the case in JavaScript.
 - **TypeScript** has a _de facto_ standard lint tool provided by Palantir,
   - :no_bell: If a student does not follow these rules as the lint tool is not

diff --git a/building/tooling/docker.md b/building/tooling/docker.md
@@ -7,7 +7,7 @@ It should live at the root directory of your repository and should be called `Do
 
 The Dockerfile should create the minimal image needed for the tooling to function correctly and speedily.
 
-The Dockerfile should produce an image with as a small a size as possible while maximising (and prioritising) performance.
+The Dockerfile should produce an image with as a small a size as possible while maximizing (and prioritizing) performance.
 Applying the official [Dockerfile best practices](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) can help to create a minimal image.
 
 ## Execution

diff --git a/building/tooling/representers/README.md b/building/tooling/representers/README.md
@@ -5,7 +5,7 @@
 One of the problems faced by the Exercism community is how to provide meaningful feedback to many people providing many solutions to many different exercises.
 To help reduce the scope of this potentially enormous task, solutions are normalized into "representations".
 For example, out of the most recent 500 submissions to the TwoFer exercise on the Ruby track, about 380 of them would be considered unique (if you normalize for trivial things like code formatting and comments).
-If you normalise them even further (by normalizing things like function or variable names), that number gets even smaller, so there might be only 250 unique approaches.
+If you normalize them even further (by normalizing things like function or variable names), that number gets even smaller, so there might be only 250 unique approaches.
 If the Exercism community can provide some feedback on those 250 approaches, then hope is that we will have valid feedback prepared for ~99% of all future submissions for TwoFer.
 With the Concept Exercises the solution space will be even smaller because Concepts Exercises will be deliberately designed to be solved in a specific way.
 
@@ -25,7 +25,7 @@ A notification will be sent for old solutions with a matching representation.
 Each language has it's own representer, written in that language.
 The website acts as the orchestrator between the representer and students' submissions.
 
-Each representer lives in the Exercism GitHub organisation in a repository named `$LANG-representer` (e.g. `ruby-representer`).
+Each representer lives in the Exercism GitHub organization in a repository named `$LANG-representer` (e.g. `ruby-representer`).
 You can explore the different representers [here](https://github.com/exercism?q=-representer).
 
 If you would like to get involved in helping with an existing Representer, please open an issue in its repository asking if there is somewhere you can help.

diff --git a/building/tooling/representers/docker.md b/building/tooling/representers/docker.md
@@ -2,7 +2,7 @@
 
 Our Representers are deployed as Docker images.
 
-Please read the [general Tooling docker information](../docker.md) to familarise yourself with how these work.
+Please read the [general Tooling docker information](../docker.md) to familiarize yourself with how these work.
 
 When we run the Representer's container we execute a `run.sh` script.
 To ensure this works properly the following rules must be following:

diff --git a/building/tooling/test-runners/README.md b/building/tooling/test-runners/README.md
@@ -12,7 +12,7 @@ Test Runners give us two advantages:
 Each language has it's own Test Runner, written in that language.
 The website acts as the orchestrator between the Test Runners and students' submissions.
 
-Each Test Runner lives in the Exercism GitHub organsation in a repository named `$LANG-test-runner` (e.g. `ruby-test-runner`).
+Each Test Runner lives in the Exercism GitHub organization in a repository named `$LANG-test-runner` (e.g. `ruby-test-runner`).
 You can explore the different Test Runners [here](https://github.com/exercism?q=-test-runner).
 
 If you would like to get involved in helping with an existing Test Runner, please open an issue in its repository asking if there is somewhere you can help.

diff --git a/building/tooling/test-runners/docker.md b/building/tooling/test-runners/docker.md
@@ -2,7 +2,7 @@
 
 Our Test Runners are deployed as Docker images.
 
-Please read the [general Tooling docker information](../docker.md) to familarise yourself with how these work.
+Please read the [general Tooling docker information](../docker.md) to familiarize yourself with how these work.
 
 When we run the Test Runner's container we execute a `run.sh` script.
 To ensure this works properly the following rules must be following:

diff --git a/building/tooling/test-runners/interface.md b/building/tooling/test-runners/interface.md
@@ -1,6 +1,6 @@
 # The Test Runner Interface
 
-Test Runners have the single responsibility of taking a solution, running all tests and returning a standardised output.
+Test Runners have the single responsibility of taking a solution, running all tests and returning a standardized output.
 All interactions with the Exercism website are handled automatically and are not part of this specification.
 
 ## Execution

diff --git a/building/tracks/README.md b/building/tracks/README.md
@@ -15,7 +15,7 @@ All concept and practices exercises of a track involve _concepts_. These concept
 Tracks have two types of exercises:
 
 - Concept exercises: they are designed to teach one or more concepts to a student. Check the [documentation](./concept-exercises.md) for more information.
-- Practice exercise: they are designed to practice learnt concepts. Check the [documentation](./practice-exercises.md) for more information.
+- Practice exercise: they are designed to practice learned concepts. Check the [documentation](./practice-exercises.md) for more information.
 
 ## Shared files
 

diff --git a/building/tracks/ci/migrating-from-travis.md b/building/tracks/ci/migrating-from-travis.md
@@ -58,7 +58,7 @@ bin/build.sh
 echo "No checks yet"
 ```
 
-Creating these as _separate_ binaries will allow for optimisation later. No need to in-line anything right now.
+Creating these as _separate_ binaries will allow for optimization later. No need to in-line anything right now.
 
 ## Fill in the templates
 
@@ -172,10 +172,10 @@ Here is the diff for [`workflows/ci.yml`][workflow-template-ci-yml].
 
 ## Now it should work
 
-This is enough to convert to GitHub Actions, with the possibility to optimise your scripts.
+This is enough to convert to GitHub Actions, with the possibility to optimize your scripts.
 
 1. From `build.sh`, remove steps that should run only once, and extract them to the `ci-check.sh` and `pre-check.sh` files (hint, you can create `lint.sh`, and call that from both "scripts")
-2. To `pr.sh` and `pr-check.sh`, add optimisations that use the input arguments to determine which files or exercises to check.
+2. To `pr.sh` and `pr-check.sh`, add optimizations that use the input arguments to determine which files or exercises to check.
 3. Add additional checks
 4. Add documentation how to run checks locally, and what each one tries to accomplish.
 

diff --git a/building/tracks/ci/workflow-templates.md b/building/tracks/ci/workflow-templates.md
@@ -23,7 +23,7 @@ The recommended actions for checking the content of your repository has integrit
 2. check for stubs
 3. check for documentation (`v3` requires new files; this might move to `configlet`)
 4. lint the exercises using a "maintainers" configuration
-5. test the exercises using the example/examplar files (can include build step)
+5. test the exercises using the example/exemplar files (can include build step)
 
 There can also be track-specific actions. For example:
 

diff --git a/building/tracks/concept-exercises.md b/building/tracks/concept-exercises.md
@@ -166,7 +166,7 @@ We place high value on making Exercism's content safe for everyone and so often
 
 - Try to make sure the story is welcoming and can be understood by everyone. If the story contains in-jokes or regional slang, try to think of alternative phrases.
 - Try to write examples that are inclusive to everyone. For example, consider using names from other cultures and mixed genders.
-- Ask yourself whether you know anyone personally who would take offence by the story. If that's the case, consider changing it to avoid it.
+- Ask yourself whether you know anyone personally who would take offense by the story. If that's the case, consider changing it to avoid it.
 
 #### Example
 

diff --git a/building/tracks/config-json.md b/building/tracks/config-json.md
@@ -238,7 +238,7 @@ Each concept is an entry in the top-level `concepts` array. The following fields
 ## Key features
 
 The language's key features succinctly describe what the most important features of the language are.
-They are intended to upsell the more interesting features of a language to potential students.
+They are intended to promote the more interesting features of a language to potential students.
 Titles should strive to use as little technical jargon as possible, bearing in mind that students might not be familiar with what language-specific jargon means before learning that language.
 
 The key features are specified in the top-level `key_features` field which is defined as an array of objects with the following fields:

diff --git a/building/tracks/deprecated-exercises.md b/building/tracks/deprecated-exercises.md
@@ -4,7 +4,7 @@ Deleting an exercise is a destructive action as it would delete all users' solut
 Therefore, exercises can **never** be deleted.
 Instead, we allow exercises to be deprecated.
 
-Deprecating an exercise has the following behaviours:
+Deprecating an exercise has the following behaviors:
 
 - Users who have downloaded or started the exercise can access their existing solution as normal
 - Users who have **not** downloaded or started the exercise, will not see or be able to start it.

diff --git a/building/tracks/practice-exercises.md b/building/tracks/practice-exercises.md
@@ -1,6 +1,6 @@
 # Practice Exercises
 
-[Practice Exercises](../../product/practice-exercises.md) are exercises designed to allow students to solve an arbitrary problem, with the aim of them making use of the concepts they have learnt so far.
+[Practice Exercises](../../product/practice-exercises.md) are exercises designed to allow students to solve an arbitrary problem, with the aim of them making use of the concepts they have learned so far.
 
 ## Metadata
 
@@ -108,7 +108,7 @@ We place high value on making Exercism's content safe for everyone and so often
 
 - Try to make sure the story is welcoming and can be understood by everyone. If the story contains in-jokes or regional slang, try to think of alternative phrases.
 - Try to write examples that are inclusive to everyone. For example, consider using names from other cultures and mixed genders.
-- Ask yourself whether you know anyone personally who would take offence by the story. If that's the case, consider changing it to avoid it.
+- Ask yourself whether you know anyone personally who would take offense by the story. If that's the case, consider changing it to avoid it.
 
 #### Example
 
@@ -150,7 +150,7 @@ We place high value on making Exercism's content safe for everyone and so often
 
 - Try to make sure the story is welcoming and can be understood by everyone. If the story contains in-jokes or regional slang, try to think of alternative phrases.
 - Try to write examples that are inclusive to everyone. For example, consider using names from other cultures and mixed genders.
-- Ask yourself whether you know anyone personally who would take offence by the story. If that's the case, consider changing it to avoid it.
+- Ask yourself whether you know anyone personally who would take offense by the story. If that's the case, consider changing it to avoid it.
 
 #### Example
 
@@ -319,7 +319,7 @@ public static class Isogram
 - The code should be as simple as possible.
 - Only use language features introduced by the exercise's prerequisites (and their prerequisites, and so on).
 - The tests file is shown to the student when doing in-browser coding and downloaded to the student's file system when using the CLI.
-- Exercism favours Practice Exercises being completed via Test Driven Development. To achieve this, all but the first test should be skipped by default. How this is done differs between languages.
+- Exercism favors Practice Exercises being completed via Test Driven Development. To achieve this, all but the first test should be skipped by default. How this is done differs between languages.
 - The relative paths to the test file(s) must be specified in the [`.meta/config.json` file's `"files.test"` key](./#filemetaconfigjson).
 
 #### Example

diff --git a/building/tracks/presentation.md b/building/tracks/presentation.md
@@ -95,7 +95,7 @@ The editor will show the above documentation files, except for the `cli.md` docu
 
 ### CLI
 
-The CLI will create a `README.md` and `HINTS.md` file that contain the above documentation files's contents, except for the `debug.md` document.
+The CLI will create a `README.md` and `HINTS.md` file that contain the above documentation files' contents, except for the `debug.md` document.
 
 #### README.md
 
@@ -166,7 +166,7 @@ The editor will show the above documentation files, except for the `cli.md` docu
 
 ### CLI
 
-The CLI will create a `README.md` and `HINTS.md` file that contain the above documentation files's contents, except for the `debug.md` document. The two append files will be appended.
+The CLI will create a `README.md` and `HINTS.md` file that contain the above documentation files' contents, except for the `debug.md` document. The two append files will be appended.
 
 #### README.md
 

diff --git a/building/tracks/stories/booleans.rpg-quest-logic.md b/building/tracks/stories/booleans.rpg-quest-logic.md
@@ -19,7 +19,7 @@ These are example tasks that fit the story of Annalyn rescuing her best friend:
 
 - Implement check for _Fast attack_: a fast attack can be made if the knight is sleeping, as it takes time for him to get his armor on, so he will be vulnerable.
 - Implement check for _Spy_: the group can be spied upon if at least one of them is awake. Otherwise, spying is a waste of time.
-- Implement check for _Signal prisoner_: the prisoner can be signalled using bird sounds if the prisoner is awake and the archer is sleeping, as archers are trained in bird signalling so they could intercept the message.
+- Implement check for _Signal prisoner_: the prisoner can be signaled using bird sounds if the prisoner is awake and the archer is sleeping, as archers are trained in bird signaling so they could intercept the message.
 - Implement check for _Free prisoner_: Annalyn can try sneaking into the camp to free the prisoner, but this tactic will only work if the prisoner is awake and the other two characters are sleeping. If the prisoner is sleeping, they'll be startled by Annalyn's sudden appearance and will awaken the other two characters. The prisoner can also be freed if the archer is sleeping and Annalyn has her pet dog with her, as the knight will be scared by the dog and will withdraw, and the archer can't equip his bow fast enough to prevent the prisoner from being freed.
 
 ## Terminology