Create an initial test for British English

This commit adds and begins populating a substitution list for
words that vary between British and American English.

doc/.vale/gitlab/British.yml

+---
+# Checks for use of some of the top misused terms at GitLab.
+#
+# For a list of all options, see https://errata-ai.github.io/vale/styles/
+extends: substitution
+message: 'Use the American spelling "%s" instead of the British "%s".'
+link: https://about.gitlab.com/handbook/communication/#top-misused-terms
+level: error
+ignorecase: true
+swap:
+  aeon: eon
+  aeroplane: airplane
+  ageing: aging
+  aluminium: aluminum
+  anaemia: anemia
+  anaesthesia: anesthesia
+  analyse: analyze
+  annexe: annex
+  apologise: apologize
+  behaviour: behavior
+  busses: buses
+  calibre: caliber
+  centre: center
+  cheque: check
+  civilisation: civilization
+  civilise: civilize
+  colour: color
+  cosy: cozy
+  cypher: cipher
+  dependant: dependent
+  defence: defense
+  distil: distill
+  draught: draft
+  encyclopaedia: encyclopedia
+  enquiry: inquiry
+  enrol: enroll
+  enrolment: enrollment
+  enthral: enthrall
+  # equalled: equaled // Under discussion
+  # equalling: equaling // Under discussion
+  favourite: favorite
+  fibre: fiber
+  fillet: filet
+  flavour: flavor
+  furore: furor
+  fulfil: fulfill
+  gaol: jail
+  grey: gray
+  humour: humor
+  honour: honor
+  initialled: initialed
+  initialling: initialing
+  instil: instill
+  jewellery: jewelry
+  labelling: labeling
+  labelled: labeled
+  labour: labor
+  libellous: libelous
+  licence: license
+  likeable: likable
+  liveable: livable
+  lustre: luster
+  manoeuvre: maneuver
+  marvellous: marvelous
+  matt: matte
+  meagre: meager
+  metre: meter
+  mitre: miter
+  modelling: modeling
+  moustache: mustache
+  neighbour: neighbor
+  normalise: normalize
+  offence: offense
+  organise: organize
+  orientated: oriented
+  paralyse: paralyze
+  plough: plow
+  pretence: pretense
+  programme: program
+  pyjamas: pajamas
+  rateable: ratable
+  realise: realize
+  recognise: recognize
+  reconnoitre: reconnoiter
+  rumour: rumor
+  sabre: saber
+  saleable: salable
+  saltpetre: saltpeter
+  sceptic: skeptic
+  sepulchre: sepulcher
+  signalling: signaling
+  sizeable: sizable
+  skilful: skillful
+  sombre: somber
+  smoulder: smolder
+  speciality: specialty
+  spectre: specter
+  splendour: splendor
+  sulphur: sulfur
+  theatre: theater
+  travelled: traveled
+  traveller: traveler
+  travelling: traveling
+  unshakeable: unshakable
+  wilful: willful
+  yoghurt: yogurt

doc/administration/database_load_balancing.md

@@ -246,7 +246,7 @@ is in sync with the primary. If the data is determined to be recent enough the
 secondary can be used, otherwise it will be ignored. To reduce the overhead of
 these checks we only perform these checks at certain intervals.
 
-There are three configuration options that influence this behaviour:
+There are three configuration options that influence this behavior:
 
 | Option                       | Description                                                                                                    | Default    |
 |------------------------------|----------------------------------------------------------------------------------------------------------------|------------|

doc/administration/geo/disaster_recovery/background_verification.md

@@ -54,14 +54,14 @@ Feature.enable('geo_repository_verification')
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
 the **Verification information** tab for that node to view automatic checksumming
 status for repositories and wikis. Successes are shown in green, pending work
-in grey, and failures in red.
+in gray, and failures in red.
 
 ![Verification status](img/verification-status-primary.png)
 
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
 the **Verification information** tab for that node to view automatic verification
 status for repositories and wikis. As with checksumming, successes are shown in
-green, pending work in grey, and failures in red.
+green, pending work in gray, and failures in red.
 
 ![Verification status](img/verification-status-secondary.png)
 

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -95,7 +95,7 @@ ensure these processes are close to 100% as possible during active use.
 Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
 review status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
-objects aren't yet replicated (shown in grey), consider giving the node more
+objects aren't yet replicated (shown in gray), consider giving the node more
 time to complete
 
 ![Replication status](img/replication-status.png)

doc/administration/high_availability/nfs.md

@@ -184,7 +184,7 @@ The NFS man page states:
 Read the [Linux man page](https://linux.die.net/man/5/nfs) to understand the difference,
 and if you do use `soft`, ensure that you've taken steps to mitigate the risks.
 
-If you experience behaviour that might have been caused by
+If you experience behavior that might have been caused by
 writes to disk on the NFS server not occurring, such as commits going missing,
 use the `hard` option, because (from the man page):
 

doc/administration/object_storage.md

@@ -98,9 +98,9 @@ object storage back end, like when Git clients request large files via LFS or wh
 downloading CI artifacts and logs.
 
 When the files are stored on local block storage or NFS, GitLab has to act as a proxy.
-This is not the default behaviour with object storage.
+This is not the default behavior with object storage.
 
-The `proxy_download` setting controls this behaviour: the default is generally `false`.
+The `proxy_download` setting controls this behavior: the default is generally `false`.
 Verify this in the documentation for each use case. Set it to `true` so that GitLab proxies
 the files.
 

doc/administration/packages/container_registry.md

@@ -427,7 +427,7 @@ NOTE: **Note:**
 
 By default, users accessing a registry configured with a remote backend are redirected to the default backend for the storage driver. For example, registries can be configured using the `s3` storage driver, which redirects requests to a remote S3 bucket to alleviate load on the GitLab server.
 
-However, this behaviour is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
+However, this behavior is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
 
 **Omnibus GitLab installations**
 

doc/ci/yaml/README.md

@@ -2607,7 +2607,7 @@ rspec:
 
 > Introduced in GitLab 9.4.
 
-The default behaviour of a caching job is to download the files at the start of
+The default behavior of a caching job is to download the files at the start of
 execution, and to re-upload them at the end. This allows any changes made by the
 job to be persisted for future runs, and is known as the `pull-push` cache
 policy.
@@ -3198,7 +3198,7 @@ job1:
 ### `retry`
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909) in GitLab 9.5.
-> - [Behaviour expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
+> - [Behavior expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
 
 `retry` allows you to configure how many times a job is going to be retried in
 case of a failure.

doc/development/api_graphql_styleguide.md

@@ -110,7 +110,7 @@ When exposing an `ID` field on a type, we will by default try to
 expose a global ID by calling `to_global_id` on the resource being
 rendered.
 
-To override this behaviour, you can implement an `id` method on the
+To override this behavior, you can implement an `id` method on the
 type for which you are exposing an ID. Please make sure that when
 exposing a `GraphQL::ID_TYPE` using a custom method that it is
 globally unique.
@@ -598,7 +598,7 @@ ID. Otherwise use a [globally unique ID](#exposing-global-ids).
 
 We already have a `FullPathLoader` that can be included in other
 resolvers to quickly find Projects and Namespaces which will have a
-lot of dependant objects.
+lot of dependent objects.
 
 To limit the amount of queries performed, we can use `BatchLoader`.
 

doc/development/api_styleguide.md

@@ -100,7 +100,7 @@ Model.create(foo: params[:foo])
 
 ## Using HTTP status helpers
 
-For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behaviour (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
+For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
 
 For `DELETE` requests, you should also generally use the `destroy_conditionally!` helper which by default returns a `204 No Content` response on success, or a `412 Precondition Failed` response if the given `If-Unmodified-Since` header is out of range. This helper calls `#destroy` on the passed resource, but you can also implement a custom deletion method by passing a block.
 

doc/development/contributing/issue_workflow.md

@@ -36,7 +36,7 @@ project.
 
 To allow for asynchronous issue handling, we use [milestones](https://gitlab.com/groups/gitlab-org/-/milestones)
 and [labels](https://gitlab.com/gitlab-org/gitlab/-/labels). Leads and product managers handle most of the
-scheduling into milestones. Labelling is a task for everyone.
+scheduling into milestones. Labeling is a task for everyone.
 
 Most issues will have labels for at least one of the following:
 
@@ -156,9 +156,9 @@ As a team needs some way to collect the work their members are planning to be as
 Normally there is a 1:1 relationship between Stage labels and Group labels. In
 the spirit of "Everyone can contribute", any issue can be picked up by any group,
 depending on current priorities. When picking up an issue belonging to a different
-group, it should be relabelled. For example, if an issue labelled `~"devops::create"`
+group, it should be relabeled. For example, if an issue labeled `~"devops::create"`
 and `~"group::knowledge"` is picked up by someone in the Access group of the Plan stage,
-the issue should be relabelled as `~"group::access"` while keeping the original
+the issue should be relabeled as `~"group::access"` while keeping the original
 `~"devops::create"` unchanged.
 
 We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
@@ -347,7 +347,7 @@ there is the ~"stewardship" label.
 
 This label is to be used for issues in which the stewardship of GitLab
 is a topic of discussion. For instance if GitLab Inc. is planning to add
-features from GitLab EE to GitLab CE, related issues would be labelled with
+features from GitLab EE to GitLab CE, related issues would be labeled with
 ~"stewardship".
 
 A recent example of this was the issue for
@@ -461,7 +461,7 @@ fixing in the same MR, but not worth creating a follow-up issue for. Renaming a
 method that is used in many places to make its intent slightly clearer may be
 worth fixing, but it should not happen in the same MR, and is generally not
 worth the overhead of having an issue of its own. These issues would invariably
-be labelled `~P4 ~S4` if we were to create them.
+be labeled `~P4 ~S4` if we were to create them.
 
 More severe technical debt can have implications for development velocity. If
 it isn't addressed in a timely manner, the codebase becomes needlessly difficult

doc/development/dangerbot.md

@@ -65,7 +65,7 @@ First, be aware of GitLab's [commitment to dogfooding](https://about.gitlab.com/
 The code we write for Danger is GitLab-specific, and it **may not** be most
 appropriate place to implement functionality that addresses a need we encounter.
 Our users, customers, and even our own satellite projects, such as [Gitaly](https://gitlab.com/gitlab-org/gitaly),
-often face similar challenges, after all. Think about how you could fulfil the
+often face similar challenges, after all. Think about how you could fulfill the
 same need while ensuring everyone can benefit from the work, and do that instead
 if you can.
 

doc/development/ee_features.md

@@ -111,7 +111,7 @@ There are a few gotchas with it:
   smaller methods. Or create a "hook" method that is empty in CE,
   and with the EE-specific implementation in EE.
 - when the original implementation contains a guard clause (e.g.
-  `return unless condition`), we cannot easily extend the behaviour by
+  `return unless condition`), we cannot easily extend the behavior by
   overriding the method, because we can't know when the overridden method
   (i.e. calling `super` in the overriding method) would want to stop early.
   In this case, we shouldn't just override it, but update the original method
@@ -131,7 +131,7 @@ There are a few gotchas with it:
   ```
 
   Instead of just overriding `Base#execute`, we should update it and extract
-  the behaviour into another method:
+  the behavior into another method:
 
   ```ruby
     class Base
@@ -613,9 +613,9 @@ module EE
 end
 ```
 
-#### EE-specific behaviour
+#### EE-specific behavior
 
-Sometimes we need EE-specific behaviour in some of the APIs. Normally we could
+Sometimes we need EE-specific behavior in some of the APIs. Normally we could
 use EE methods to override CE methods, however API routes are not methods and
 therefore can't be simply overridden. We need to extract them into a standalone
 method, or introduce some "hooks" where we could inject behavior in the CE

doc/development/fe_guide/frontend_faq.md

@@ -39,7 +39,7 @@ bundle exec rake routes | grep "issues"
 
 ### 2. `modal_copy_button` vs `clipboard_button`
 
-The `clipboard_button` uses the `copy_to_clipboard.js` behaviour, which is
+The `clipboard_button` uses the `copy_to_clipboard.js` behavior, which is
 initialized on page load, so if there are vue-based clipboard buttons that
 don't exist at page load (such as ones in a `GlModal`), they do not have the
 click handlers associated with the clipboard package.

doc/development/fe_guide/style/javascript.md

@@ -192,7 +192,7 @@ if (isThingNull) {
 
 ## ESLint
 
-ESLint behaviour can be found in our [tooling guide](../tooling.md).
+ESLint behavior can be found in our [tooling guide](../tooling.md).
 
 ## IIFEs
 

doc/development/hash_indexes.md

@@ -14,7 +14,7 @@ documentation:
 > answers to queries that subsequently use them. For these reasons, hash index
 > use is presently discouraged.
 
-RuboCop is configured to register an offence when it detects the use of a hash
+RuboCop is configured to register an offense when it detects the use of a hash
 index.
 
 Instead of using hash indexes you should use regular btree indexes.

doc/development/merge_request_performance_guidelines.md

@@ -24,7 +24,7 @@ The term `SHOULD` per the [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) means
 > carefully weighed before choosing a different course.
 
 Ideally, each of these tradeoffs should be documented
-in the separate issues, labelled accordingly and linked
+in the separate issues, labeled accordingly and linked
 to original issue and epic.
 
 ## Impact Analysis

doc/development/packages.md

@@ -139,7 +139,7 @@ During this phase, the idea is to collect as much information as possible about
 - **Requests**: Which requests are needed to have a working MVC. Ideally, produce
   a list of all the requests needed for the MVC (including required actions). Further
   investigation could provide an example for each request with the request and the response bodies.
-- **Upload**: Carefully analyse how the upload process works. This will probably be the most
+- **Upload**: Carefully analyze how the upload process works. This will probably be the most
   complex request to implement. A detailed analysis is desired here as uploads can be
   encoded in different ways (body or multipart) and can even be in a totally different
   format (for example, a JSON structure where the package file is a Base64 value of

doc/development/performance.md

@@ -109,7 +109,7 @@ In short:
 By collecting snapshots of process state at regular intervals, profiling allows
 you to see where time is spent in a process. The [StackProf](https://github.com/tmm1/stackprof)
 gem is included in GitLab's development environment, allowing you to investigate
-the behaviour of suspect code in detail.
+the behavior of suspect code in detail.
 
 It's important to note that profiling an application *alters its performance*,
 and will generally be done *in an unrepresentative environment*. In particular,

doc/development/reactive_caching.md

@@ -256,7 +256,7 @@ which `calculate_reactive_cache` can be called.
   end
   ```
 
-- The default behaviour can be overridden by defining a custom `reactive_cache_worker_finder`.
+- The default behavior can be overridden by defining a custom `reactive_cache_worker_finder`.
 
   ```ruby
   class Foo < ApplicationRecord

doc/development/secure_coding_guidelines.md

@@ -78,7 +78,7 @@ The output of this example is `#<MatchData "bar">`, as Ruby treats the input `te
 
 #### Impact
 
-This Ruby Regex speciality can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
+This Ruby Regex specialty can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
 
 #### Examples
 

doc/development/testing_guide/best_practices.md

@@ -337,7 +337,7 @@ Feature.enabled?(:ci_live_trace, project2) # => true
 
 The code exercised by a single GitLab test may access and modify many items of
 data. Without careful preparation before a test runs, and cleanup afterward,
-data can be changed by a test in such a way that it affects the behaviour of
+data can be changed by a test in such a way that it affects the behavior of
 following tests. This should be avoided at all costs! Fortunately, the existing
 test framework handles most cases already.
 

doc/development/testing_guide/testing_levels.md

@@ -540,7 +540,7 @@ and the basic idea is that the cost of a test includes:
 
 ### Frontend-related tests
 
-There are cases where the behaviour you are testing is not worth the time spent
+There are cases where the behavior you are testing is not worth the time spent
 running the full application, for example, if you are testing styling, animation,
 edge cases or small actions that don't involve the backend,
 you should write an integration test using Jasmine.

doc/development/value_stream_analytics.md

@@ -185,7 +185,7 @@ Currently supported parents:
 
 The [original implementation](https://gitlab.com/gitlab-org/gitlab/issues/847) of value stream analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
 ​
-To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behaviour is implemented in the value stream analytics service objects.
+To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behavior is implemented in the value stream analytics service objects.
 ​
 The reason for this was that we'd like to add the abilities to hide and order stages later on.
 

doc/development/verifying_database_capabilities.md

@@ -2,7 +2,7 @@
 
 Sometimes certain bits of code may only work on a certain database
 version. While we try to avoid such code as much as possible sometimes it is
-necessary to add database (version) specific behaviour.
+necessary to add database (version) specific behavior.
 
 To facilitate this we have the following methods that you can use:
 

doc/topics/git/lfs/index.md

@@ -217,7 +217,7 @@ If you push a LFS object to a project and you receive an error similar to:
 the LFS client is trying to reach GitLab through HTTPS. However, your GitLab
 instance is being served on HTTP.
 
-This behaviour is caused by Git LFS using HTTPS connections by default when a
+This behavior is caused by Git LFS using HTTPS connections by default when a
 `lfsurl` is not set in the Git config.
 
 To prevent this from happening, set the lfs url in project Git config:

doc/university/support/README.md

@@ -103,7 +103,7 @@ Our integrations add great value to GitLab. User questions often relate to integ
 
 ### Learn about the Support process
 
-Zendesk is our Support Centre and our main communication line with our Customers. We communicate with customers through several other channels too
+Zendesk is our Support Center and our main communication line with our Customers. We communicate with customers through several other channels too
 
 - Familiarize yourself with ZenDesk:
   - [UI Overview](https://support.zendesk.com/hc/en-us/articles/203661806-Introduction-to-the-Zendesk-agent-interface)

doc/user/project/integrations/bamboo.md

@@ -27,7 +27,7 @@ need to be configured in a Bamboo build plan before GitLab can integrate.
 1. In the left pane, select a build stage. If you have multiple build stages
    you want to select the last stage that contains the Git checkout task.
 1. Select the 'Miscellaneous' tab.
-1. Under 'Pattern Match Labelling' put `${bamboo.repository.revision.number}`
+1. Under 'Pattern Match Labeling' put `${bamboo.repository.revision.number}`
    in the 'Labels' box.
 1. Save
 

doc/user/project/repository/index.md

@@ -215,7 +215,7 @@ minutes.
 ![Repository Languages bar](img/repository_languages_v12_2.gif)
 
 Not all files are detected, among others; documentation,
-vendored code, and most markup languages are excluded. This behaviour can be
+vendored code, and most markup languages are excluded. This behavior can be
 adjusted by overriding the default. For example, to enable `.proto` files to be
 detected, add the following to `.gitattributes` in the root of your repository.