diff --git a/lib/elixir/lib/code.ex b/lib/elixir/lib/code.ex
index f71e75366d3..0f0d0b8fe00 100644
--- a/lib/elixir/lib/code.ex
+++ b/lib/elixir/lib/code.ex
@@ -3,14 +3,14 @@ defmodule Code do
   Utilities for managing code compilation, code evaluation, and code loading.
 
   This module complements Erlang's [`:code` module](`:code`)
-  to add behaviour which is specific to Elixir. For functions to
+  to add behavior which is specific to Elixir. For functions to
   manipulate Elixir's AST (rather than evaluating it), see the
   `Macro` module.
 
   ## Working with files
 
   This module contains three functions for compiling and evaluating files.
-  Here is a summary of them and their behaviour:
+  Here is a summary of them and their behavior:
 
     * `require_file/2` - compiles a file and tracks its name. It does not
       compile the file again if it has been previously required.
@@ -710,8 +710,8 @@ defmodule Code do
   specially because a function is named `defmodule`, `def`, or the like. This
   principle mirrors Elixir's goal of being an extensible language where
   developers can extend the language with new constructs as if they were
-  part of the language. When it is absolutely necessary to change behaviour
-  based on the name, this behaviour should be configurable, such as the
+  part of the language. When it is absolutely necessary to change behavior
+  based on the name, this behavior should be configurable, such as the
   `:locals_without_parens` option.
 
   ## Running the formatter
@@ -855,7 +855,7 @@ defmodule Code do
     * Newlines before certain operators (such as the pipeline operators)
       and before other operators (such as comparison operators)
 
-  The behaviours above are not guaranteed. We may remove or add new
+  The behaviors above are not guaranteed. We may remove or add new
   rules in the future. The goal of documenting them is to provide better
   understanding on what to expect from the formatter.
 
@@ -1145,7 +1145,7 @@ defmodule Code do
 
     * `:static_atoms_encoder` - the static atom encoder function, see
       "The `:static_atoms_encoder` function" section below. Note this
-      option overrides the `:existing_atoms_only` behaviour for static
+      option overrides the `:existing_atoms_only` behavior for static
       atoms but `:existing_atoms_only` is still used for dynamic atoms,
       such as atoms with interpolations.
 
@@ -1627,7 +1627,7 @@ defmodule Code do
       error. You may be set it to `:warn` if you want undefined variables to
       emit a warning and expand as to a local call to the zero-arity function
       of the same name (for example, `node` would be expanded as `node()`).
-      This `:warn` behaviour only exists for compatibility reasons when working
+      This `:warn` behavior only exists for compatibility reasons when working
       with old dependencies.
 
   It always returns `:ok`. Raises an error for invalid options.
@@ -1961,7 +1961,7 @@ defmodule Code do
   @doc """
   Returns `true` if the module is loaded.
 
-  This function doesn't attempt to load the module. For such behaviour,
+  This function doesn't attempt to load the module. For such behavior,
   `ensure_loaded?/1` can be used.
 
   ## Examples
diff --git a/lib/elixir/lib/collectable.ex b/lib/elixir/lib/collectable.ex
index 2ee45f14eb1..782df766072 100644
--- a/lib/elixir/lib/collectable.ex
+++ b/lib/elixir/lib/collectable.ex
@@ -94,10 +94,10 @@ end
 
 defimpl Collectable, for: List do
   def into(list) do
-    # TODO: Change the behaviour so the into always comes last on Elixir v2.0
+    # TODO: Change the behavior so the into always comes last on Elixir v2.0
     if list != [] do
       IO.warn(
-        "the Collectable protocol is deprecated for non-empty lists. The behaviour of " <>
+        "the Collectable protocol is deprecated for non-empty lists. The behavior of " <>
           "Enum.into/2 and \"for\" comprehensions with an :into option is incorrect " <>
           "when collecting into non-empty lists. If you're collecting into a non-empty keyword " <>
           "list, consider using Keyword.merge/2 instead. If you're collecting into a non-empty " <>
diff --git a/lib/elixir/lib/config/provider.ex b/lib/elixir/lib/config/provider.ex
index 9cc52cf72b8..b8ead820566 100644
--- a/lib/elixir/lib/config/provider.ex
+++ b/lib/elixir/lib/config/provider.ex
@@ -312,7 +312,7 @@ defmodule Config.Provider do
            """
            the application #{inspect(app)} has a different value set #{path(key, path)} \
            during runtime compared to compile time. Since this application environment entry was \
-           marked as compile time, this difference can lead to different behaviour than expected:
+           marked as compile time, this difference can lead to different behavior than expected:
 
              * Compile time value #{return_to_text(compile_return)}
              * Runtime value #{return_to_text(runtime_return)}
diff --git a/lib/elixir/lib/enum.ex b/lib/elixir/lib/enum.ex
index 1a2dfe52b34..00d377d27e6 100644
--- a/lib/elixir/lib/enum.ex
+++ b/lib/elixir/lib/enum.ex
@@ -269,12 +269,12 @@ defmodule Enum do
   After all, if we want to traverse every element on a list, the longer the
   list, the more elements we need to traverse, and the longer it will take.
 
-  This linear behaviour should also be expected on operations like `count/1`,
+  This linear behavior should also be expected on operations like `count/1`,
   `member?/2`, `at/2` and similar. While Elixir does allow data types to
   provide performant variants for such operations, you should not expect it
   to always be available, since the `Enum` module is meant to work with a
   large variety of data types and not all data types can provide optimized
-  behaviour.
+  behavior.
 
   Finally, note the functions in the `Enum` module are eager: they will
   traverse the enumerable as soon as they are invoked. This is particularly
@@ -4020,7 +4020,7 @@ defmodule Enum do
   @doc """
   Reduces over two enumerables halting as soon as either enumerable is empty.
 
-  In practice, the behaviour provided by this function can be achieved with:
+  In practice, the behavior provided by this function can be achieved with:
 
       Enum.reduce(Stream.zip(left, right), acc, reducer)
 
@@ -4054,7 +4054,7 @@ defmodule Enum do
   The reducer will receive 2 args: a list of elements (one from each enum) and the
   accumulator.
 
-  In practice, the behaviour provided by this function can be achieved with:
+  In practice, the behavior provided by this function can be achieved with:
 
       Enum.reduce(Stream.zip(enums), acc, reducer)
 
diff --git a/lib/elixir/lib/file.ex b/lib/elixir/lib/file.ex
index ecf4b8550dd..1092899526d 100644
--- a/lib/elixir/lib/file.ex
+++ b/lib/elixir/lib/file.ex
@@ -758,7 +758,7 @@ defmodule File do
 
   Note: The command `mv` in Unix-like systems behaves differently depending on
   whether `source` is a file and the `destination` is an existing directory.
-  We have chosen to explicitly disallow this behaviour.
+  We have chosen to explicitly disallow this behavior.
 
   ## Examples
 
@@ -822,7 +822,7 @@ defmodule File do
       The function receives arguments for `source_file` and `destination_file`. It should
       return `true` if the existing file should be overwritten, `false` if otherwise.
       The default callback returns `true`. On earlier versions, this callback could be
-      given as third argument, but such behaviour is now deprecated.
+      given as third argument, but such behavior is now deprecated.
 
   """
   @spec cp(Path.t(), Path.t(), on_conflict: on_conflict_callback) :: :ok | {:error, posix}
@@ -895,7 +895,7 @@ defmodule File do
 
   Note: The command `cp` in Unix-like systems behaves differently depending on
   whether `destination` is an existing directory or not. We have chosen to
-  explicitly disallow this behaviour. If `source` is a `file` and `destination`
+  explicitly disallow this behavior. If `source` is a `file` and `destination`
   is a directory, `{:error, :eisdir}` will be returned.
 
   ## Options
@@ -904,7 +904,7 @@ defmodule File do
       The function receives arguments for `source` and `destination`. It should return
       `true` if the existing file should be overwritten, `false` if otherwise. The default
       callback returns `true`. On earlier versions, this callback could be given as third
-      argument, but such behaviour is now deprecated.
+      argument, but such behavior is now deprecated.
 
     * `:dereference_symlinks` - (since v1.14.0) By default, this function will copy symlinks
       by creating symlinks that point to the same location. This option forces symlinks to be
diff --git a/lib/elixir/lib/float.ex b/lib/elixir/lib/float.ex
index 2c6c42eee0c..305395a38f2 100644
--- a/lib/elixir/lib/float.ex
+++ b/lib/elixir/lib/float.ex
@@ -210,7 +210,7 @@ defmodule Float do
 
   ## Known issues
 
-  The behaviour of `floor/2` for floats can be surprising. For example:
+  The behavior of `floor/2` for floats can be surprising. For example:
 
       iex> Float.floor(12.52, 2)
       12.51
@@ -218,7 +218,7 @@ defmodule Float do
   One may have expected it to floor to 12.52. This is not a bug.
   Most decimal fractions cannot be represented as a binary floating point
   and therefore the number above is internally represented as 12.51999999,
-  which explains the behaviour above.
+  which explains the behavior above.
 
   ## Examples
 
@@ -254,7 +254,7 @@ defmodule Float do
   The operation is performed on the binary floating point, without a
   conversion to decimal.
 
-  The behaviour of `ceil/2` for floats can be surprising. For example:
+  The behavior of `ceil/2` for floats can be surprising. For example:
 
       iex> Float.ceil(-12.52, 2)
       -12.51
@@ -262,7 +262,7 @@ defmodule Float do
   One may have expected it to ceil to -12.52. This is not a bug.
   Most decimal fractions cannot be represented as a binary floating point
   and therefore the number above is internally represented as -12.51999999,
-  which explains the behaviour above.
+  which explains the behavior above.
 
   This function always returns floats. `Kernel.trunc/1` may be used instead to
   truncate the result to an integer afterwards.
@@ -305,7 +305,7 @@ defmodule Float do
 
   ## Known issues
 
-  The behaviour of `round/2` for floats can be surprising. For example:
+  The behavior of `round/2` for floats can be surprising. For example:
 
       iex> Float.round(5.5675, 3)
       5.567
@@ -313,8 +313,8 @@ defmodule Float do
   One may have expected it to round to the half up 5.568. This is not a bug.
   Most decimal fractions cannot be represented as a binary floating point
   and therefore the number above is internally represented as 5.567499999,
-  which explains the behaviour above. If you want exact rounding for decimals,
-  you must use a decimal library. The behaviour above is also in accordance
+  which explains the behavior above. If you want exact rounding for decimals,
+  you must use a decimal library. The behavior above is also in accordance
   to reference implementations, such as "Correctly Rounded Binary-Decimal and
   Decimal-Binary Conversions" by David M. Gay.
 
diff --git a/lib/elixir/lib/io/ansi.ex b/lib/elixir/lib/io/ansi.ex
index 2932418c8fb..01af9d4bb28 100644
--- a/lib/elixir/lib/io/ansi.ex
+++ b/lib/elixir/lib/io/ansi.ex
@@ -268,7 +268,7 @@ defmodule IO.ANSI do
   The named sequences are represented by atoms.
 
   It will also append an `IO.ANSI.reset/0` to the chardata when a conversion is
-  performed. If you don't want this behaviour, use `format_fragment/2`.
+  performed. If you don't want this behavior, use `format_fragment/2`.
 
   An optional boolean parameter can be passed to enable or disable
   emitting actual ANSI codes. When `false`, no ANSI codes will be emitted.
diff --git a/lib/elixir/lib/kernel.ex b/lib/elixir/lib/kernel.ex
index 5c359c3c178..2fcb3d30970 100644
--- a/lib/elixir/lib/kernel.ex
+++ b/lib/elixir/lib/kernel.ex
@@ -125,7 +125,7 @@ defmodule Kernel do
   ### Supporting documents
 
   Under the "Pages" section in sidebar you will find tutorials, guides,
-  and reference documents that outline Elixir semantics and behaviours
+  and reference documents that outline Elixir semantics and behaviors
   in more detail. Those are:
 
     * [Compatibility and deprecations](compatibility-and-deprecations.md) - lists
@@ -548,10 +548,10 @@ defmodule Kernel do
     * `exit({:shutdown, term})`
 
   Exiting with any other reason is considered abnormal and treated
-  as a crash. This means the default supervisor behaviour kicks in,
+  as a crash. This means the default supervisor behavior kicks in,
   error reports are emitted, and so forth.
 
-  This behaviour is relied on in many different places. For example,
+  This behavior is relied on in many different places. For example,
   `ExUnit` uses `exit(:shutdown)` when exiting the test process to
   signal linked processes, supervision trees and so on to politely
   shut down too.
@@ -2362,7 +2362,7 @@ defmodule Kernel do
   Keys in the `Enumerable` that don't exist in the struct are automatically
   discarded. Note that keys must be atoms, as only atoms are allowed when
   defining a struct. If there are duplicate keys in the `Enumerable`, the last
-  entry will be taken (same behaviour as `Map.new/1`).
+  entry will be taken (same behavior as `Map.new/1`).
 
   This function is useful for dynamically creating and updating structs, as
   well as for converting maps to structs; in the latter case, just inserting
@@ -2410,7 +2410,7 @@ defmodule Kernel do
   @doc """
   Similar to `struct/2` but checks for key validity.
 
-  The function `struct!/2` emulates the compile time behaviour
+  The function `struct!/2` emulates the compile time behavior
   of structs. This means that:
 
     * when building a struct, as in `struct!(SomeStruct, key: :value)`,
@@ -3389,7 +3389,7 @@ defmodule Kernel do
 
   The pin operator will check if the values are equal, using `===/2`, while
   patterns have their own rules when matching maps, lists, and so forth.
-  Such behaviour is not specific to `match?/2`. The following code also
+  Such behavior is not specific to `match?/2`. The following code also
   throws an exception:
 
       attrs = %{x: 1}
@@ -3928,7 +3928,7 @@ defmodule Kernel do
   one element, which is the number itself.
 
   If first is more than last, the range will be decreasing from first
-  to last, albeit this behaviour is deprecated. Instead prefer to
+  to last, albeit this behavior is deprecated. Instead prefer to
   explicitly list the step with `first..last//-1`.
 
   See the `Range` module for more information.
diff --git a/lib/elixir/lib/kernel/special_forms.ex b/lib/elixir/lib/kernel/special_forms.ex
index b307cc5970a..47d4dca75f0 100644
--- a/lib/elixir/lib/kernel/special_forms.ex
+++ b/lib/elixir/lib/kernel/special_forms.ex
@@ -550,7 +550,7 @@ defmodule Kernel.SpecialForms do
   Elixir won't emit any warnings though, since the alias
   was not explicitly defined.
 
-  Both warning behaviours could be changed by explicitly
+  Both warning behaviors could be changed by explicitly
   setting the `:warn` option to `true` or `false`.
 
   """
@@ -674,7 +674,7 @@ defmodule Kernel.SpecialForms do
   Elixir won't emit any warnings though, since the import
   was not explicitly defined.
 
-  Both warning behaviours could be changed by explicitly
+  Both warning behaviors could be changed by explicitly
   setting the `:warn` option to `true` or `false`.
 
   ## Ambiguous function/macro names
@@ -888,7 +888,7 @@ defmodule Kernel.SpecialForms do
   At first, there is nothing in this example that actually reveals it is a
   macro. But what is happening is that, at compilation time, `squared(5)`
   becomes `5 * 5`. The argument `5` is duplicated in the produced code, we
-  can see this behaviour in practice though because our macro actually has
+  can see this behavior in practice though because our macro actually has
   a bug:
 
       import Math
@@ -915,7 +915,7 @@ defmodule Kernel.SpecialForms do
       my_number.() * my_number.()
 
   Which invokes the function twice, explaining why we get the printed value
-  twice! In the majority of the cases, this is actually unexpected behaviour,
+  twice! In the majority of the cases, this is actually unexpected behavior,
   and that's why one of the first things you need to keep in mind when it
   comes to macros is to **not unquote the same value more than once**.
 
@@ -1444,7 +1444,7 @@ defmodule Kernel.SpecialForms do
       [elixir: :prolog]
 
   Given the grandparents of Erlang and Prolog were nil, those values were
-  filtered out. If you don't want this behaviour, a simple option is to
+  filtered out. If you don't want this behavior, a simple option is to
   move the filter inside the do-block:
 
       iex> languages = [elixir: :erlang, erlang: :prolog, prolog: nil]
@@ -1496,7 +1496,7 @@ defmodule Kernel.SpecialForms do
 
   *Available since Elixir v1.8*.
 
-  While the `:into` option allows us to customize the comprehension behaviour
+  While the `:into` option allows us to customize the comprehension behavior
   to a given data type, such as putting all of the values inside a map or inside
   a binary, it is not always enough.
 
@@ -1624,7 +1624,7 @@ defmodule Kernel.SpecialForms do
       iex> width
       nil
 
-  The behaviour of any expression in a clause is the same as if it was
+  The behavior of any expression in a clause is the same as if it was
   written outside of `with`. For example, `=` will raise a `MatchError`
   instead of returning the non-matched value:
 
diff --git a/lib/elixir/lib/list.ex b/lib/elixir/lib/list.ex
index afd19d2e799..71f370b26e1 100644
--- a/lib/elixir/lib/list.ex
+++ b/lib/elixir/lib/list.ex
@@ -107,7 +107,7 @@ defmodule List do
   charlists in IEx when you encounter them, which shows you the type, description
   and also the raw representation in one single summary.
 
-  The rationale behind this behaviour is to better support
+  The rationale behind this behavior is to better support
   Erlang libraries which may return text as charlists
   instead of Elixir strings. In Erlang, charlists are the default
   way of handling strings, while in Elixir it's binaries. One
diff --git a/lib/elixir/lib/module/types/helpers.ex b/lib/elixir/lib/module/types/helpers.ex
index 776c83ac75c..ff4d6dbd4e2 100644
--- a/lib/elixir/lib/module/types/helpers.ex
+++ b/lib/elixir/lib/module/types/helpers.ex
@@ -27,7 +27,7 @@ defmodule Module.Types.Helpers do
         #{hint()} all expressions given to binaries are assumed to be of type \
         integer() unless said otherwise. For example, <<expr>> assumes "expr" \
         is an integer. Pass a modifier, such as <<expr::float>> or <<expr::binary>>, \
-        to change the default behaviour.
+        to change the default behavior.
         """
     end)
   end
diff --git a/lib/elixir/lib/path.ex b/lib/elixir/lib/path.ex
index 4cf3445cc9b..cba9d689890 100644
--- a/lib/elixir/lib/path.ex
+++ b/lib/elixir/lib/path.ex
@@ -261,7 +261,7 @@ defmodule Path do
       Path.relative("/bar/foo.ex")      #=> "bar/foo.ex"
 
   """
-  # Note this function does not expand paths because the behaviour
+  # Note this function does not expand paths because the behavior
   # is ambiguous. If we expand it before converting to relative, then
   # "/usr/../../foo" means "/foo". If we expand it after, it means "../foo".
   # We could expand only relative paths but it is best to say it never
diff --git a/lib/elixir/lib/process.ex b/lib/elixir/lib/process.ex
index abb69426a84..0129d726e85 100644
--- a/lib/elixir/lib/process.ex
+++ b/lib/elixir/lib/process.ex
@@ -195,7 +195,7 @@ defmodule Process do
   @doc """
   Sends an exit signal with the given `reason` to `pid`.
 
-  The following behaviour applies if `reason` is any term except `:normal`
+  The following behavior applies if `reason` is any term except `:normal`
   or `:kill`:
 
     1. If `pid` is not trapping exits, `pid` will exit with the given
@@ -624,7 +624,7 @@ defmodule Process do
   exits with a reason other than `:normal` (which is also the exit reason used
   when a process finishes its job) and `pid1` is not trapping exits (see
   `flag/2`), then `pid1` will exit with the same reason as `pid2` and in turn
-  emit an exit signal to all its other linked processes. The behaviour when
+  emit an exit signal to all its other linked processes. The behavior when
   `pid1` is trapping exits is described in `exit/2`.
 
   See `:erlang.link/1` for more information.
diff --git a/lib/elixir/lib/protocol.ex b/lib/elixir/lib/protocol.ex
index b1bc957a1b9..591d25354a0 100644
--- a/lib/elixir/lib/protocol.ex
+++ b/lib/elixir/lib/protocol.ex
@@ -126,8 +126,8 @@ defmodule Protocol do
   Although the implementation above is arguably not a reasonable
   one. For example, it makes no sense to say a PID or an integer
   have a size of `0`. That's one of the reasons why `@fallback_to_any`
-  is an opt-in behaviour. For the majority of protocols, raising
-  an error when a protocol is not implemented is the proper behaviour.
+  is an opt-in behavior. For the majority of protocols, raising
+  an error when a protocol is not implemented is the proper behavior.
 
   ## Multiple implementations
 
diff --git a/lib/elixir/lib/range.ex b/lib/elixir/lib/range.ex
index c59a28a93a8..475021626c4 100644
--- a/lib/elixir/lib/range.ex
+++ b/lib/elixir/lib/range.ex
@@ -172,7 +172,7 @@ defmodule Range do
   one element, which is the number itself.
 
   If `first` is greater than `last`, the range will be decreasing from `first`
-  to `last`, albeit this behaviour is deprecated. Therefore, it is advised to
+  to `last`, albeit this behavior is deprecated. Therefore, it is advised to
   explicitly list the step with `new/3`.
 
   ## Examples
diff --git a/lib/elixir/lib/regex.ex b/lib/elixir/lib/regex.ex
index 7b7f1b83321..ee9f658f6b9 100644
--- a/lib/elixir/lib/regex.ex
+++ b/lib/elixir/lib/regex.ex
@@ -152,10 +152,10 @@ defmodule Regex do
 
   There is another character class, `ascii`, that erroneously matches
   Latin-1 characters instead of the 0-127 range specified by POSIX. This
-  cannot be fixed without altering the behaviour of other classes, so we
+  cannot be fixed without altering the behavior of other classes, so we
   recommend matching the range with `[\\0-\x7f]` instead.
 
-  Note the behaviour of those classes may change according to the Unicode
+  Note the behavior of those classes may change according to the Unicode
   and other modifiers:
 
       iex> String.match?("josé", ~r/^[[:lower:]]+$/)
diff --git a/lib/elixir/lib/registry.ex b/lib/elixir/lib/registry.ex
index 4177e35bae7..42e963210a6 100644
--- a/lib/elixir/lib/registry.ex
+++ b/lib/elixir/lib/registry.ex
@@ -18,7 +18,7 @@ defmodule Registry do
   implementation. We explore some of those use cases below.
 
   The registry may also be transparently partitioned, which provides
-  more scalable behaviour for running registries on highly concurrent
+  more scalable behavior for running registries on highly concurrent
   environments with thousands or millions of entries.
 
   ## Using in `:via`
diff --git a/lib/elixir/lib/string.ex b/lib/elixir/lib/string.ex
index 1966c533409..a547cbd42b3 100644
--- a/lib/elixir/lib/string.ex
+++ b/lib/elixir/lib/string.ex
@@ -167,7 +167,7 @@ defmodule String do
   the locale, it is not taken into account by this module.
 
   In general, the functions in this module rely on the Unicode
-  Standard, but do not contain any of the locale specific behaviour.
+  Standard, but do not contain any of the locale specific behavior.
   More information about graphemes can be found in the [Unicode
   Standard Annex #29](https://www.unicode.org/reports/tr29/).
 
@@ -227,7 +227,7 @@ defmodule String do
   to the definition of the encoding) is encountered, only one
   code point needs to be rejected.
 
-  This module relies on this behaviour to ignore such invalid
+  This module relies on this behavior to ignore such invalid
   characters. For example, `length/1` will return
   a correct result even if an invalid code point is fed into it.
 
@@ -1472,7 +1472,7 @@ defmodule String do
   The `replacement` may be a string or a function that receives the matched
   pattern and must return the replacement as a string or iodata.
 
-  By default it replaces all occurrences but this behaviour can be controlled
+  By default it replaces all occurrences but this behavior can be controlled
   through the `:global` option; see the "Options" section below.
 
   ## Options
diff --git a/lib/elixir/lib/system.ex b/lib/elixir/lib/system.ex
index 7f67495e31c..9b958b00866 100644
--- a/lib/elixir/lib/system.ex
+++ b/lib/elixir/lib/system.ex
@@ -42,7 +42,7 @@ defmodule System do
     * `system_time/0` - the VM view of the `os_time/0`. The system time and operating
       system time may not match in case of time warps although the VM works towards
       aligning them. This time is not monotonic (i.e., it may decrease)
-      as its behaviour is configured [by the VM time warp
+      as its behavior is configured [by the VM time warp
       mode](https://www.erlang.org/doc/apps/erts/time_correction.html#Time_Warp_Modes);
 
     * `monotonic_time/0` - a monotonically increasing time provided
@@ -522,7 +522,7 @@ defmodule System do
   in case trapping exists is not supported by the current OS.
 
   The first time a signal is trapped, it will override the
-  default behaviour from the operating system. If the same
+  default behavior from the operating system. If the same
   signal is trapped multiple times, subsequent functions
   given to `trap_signal` will execute *first*. In other
   words, you can consider each function is prepended to
@@ -536,7 +536,7 @@ defmodule System do
     * `:sigusr1` - halts the VM via status code of 1
 
   Therefore, if you add traps to the signals above, the
-  default behaviour above will be executed after all user
+  default behavior above will be executed after all user
   signals.
 
   ## Implementation notes
diff --git a/lib/elixir/lib/task.ex b/lib/elixir/lib/task.ex
index 1b221050faa..56bd80e8928 100644
--- a/lib/elixir/lib/task.ex
+++ b/lib/elixir/lib/task.ex
@@ -1181,7 +1181,7 @@ defmodule Task do
   given time. All other tasks will have been shut down using
   the `Task.shutdown/2` call.
 
-  As a convenience, you can achieve a similar behaviour to above
+  As a convenience, you can achieve a similar behavior to above
   by specifying the `:on_timeout` option to be `:kill_task` (or
   `:ignore`). See `Task.await_many/2` if you would rather exit
   the caller process on timeout.
diff --git a/lib/elixir/pages/anti-patterns/code-anti-patterns.md b/lib/elixir/pages/anti-patterns/code-anti-patterns.md
index 9bc9e9e1d2f..0264c63590b 100644
--- a/lib/elixir/pages/anti-patterns/code-anti-patterns.md
+++ b/lib/elixir/pages/anti-patterns/code-anti-patterns.md
@@ -141,7 +141,7 @@ end
 
 An `Atom` is an Elixir basic type whose value is its own name. Atoms are often useful to identify resources or express the state, or result, of an operation. Creating atoms dynamically is not an anti-pattern by itself; however, atoms are not garbage collected by the Erlang Virtual Machine, so values of this type live in memory during a software's entire execution lifetime. The Erlang VM limits the number of atoms that can exist in an application by default to *1_048_576*, which is more than enough to cover all atoms defined in a program, but attempts to serve as an early limit for applications which are "leaking atoms" through dynamic creation.
 
-For these reason, creating atoms dynamically can be considered an anti-pattern when the developer has no control over how many atoms will be created during the software execution. This unpredictable scenario can expose the software to unexpected behaviour caused by excessive memory usage, or even by reaching the maximum number of *atoms* possible.
+For these reason, creating atoms dynamically can be considered an anti-pattern when the developer has no control over how many atoms will be created during the software execution. This unpredictable scenario can expose the software to unexpected behavior caused by excessive memory usage, or even by reaching the maximum number of *atoms* possible.
 
 #### Example
 
@@ -343,7 +343,7 @@ iex> Graphics.plot(point_3d)
 {5, 6, 7}
 ```
 
-Given we want to plot both 2D and 3D points, the behaviour above is expected. But what happens if we forget to pass a point with either `:x` or `:y`?
+Given we want to plot both 2D and 3D points, the behavior above is expected. But what happens if we forget to pass a point with either `:x` or `:y`?
 
 ```elixir
 iex> bad_point = %{y: 3, z: 4}
@@ -352,7 +352,7 @@ iex> Graphics.plot(bad_point)
 {nil, 3, 4}
 ```
 
-The behaviour above is unexpected because our function should not work with points without a `:x` key. This leads to subtle bugs, as we may now pass `nil` to another function, instead of raising early on.
+The behavior above is unexpected because our function should not work with points without a `:x` key. This leads to subtle bugs, as we may now pass `nil` to another function, instead of raising early on.
 
 #### Refactoring
 
@@ -448,7 +448,7 @@ iex> Extract.get_value("name=Lucas&university=institution=UFMG&lab=ASERG", "univ
 
 #### Refactoring
 
-To remove this anti-pattern, `get_value/2` can be refactored through the use of pattern matching. So, if an unexpected URL query string format is used, the function will crash instead of returning an invalid value. This behaviour, shown below, allows clients to decide how to handle these errors and doesn't give a false impression that the code is working correctly when unexpected values are extracted:
+To remove this anti-pattern, `get_value/2` can be refactored through the use of pattern matching. So, if an unexpected URL query string format is used, the function will crash instead of returning an invalid value. This behavior, shown below, allows clients to decide how to handle these errors and doesn't give a false impression that the code is working correctly when unexpected values are extracted:
 
 ```elixir
 defmodule Extract do
diff --git a/lib/elixir/pages/anti-patterns/design-anti-patterns.md b/lib/elixir/pages/anti-patterns/design-anti-patterns.md
index fb83e97a41d..f4c2457a33a 100644
--- a/lib/elixir/pages/anti-patterns/design-anti-patterns.md
+++ b/lib/elixir/pages/anti-patterns/design-anti-patterns.md
@@ -75,7 +75,7 @@ This is a special case of [*Primitive obsession*](#primitive-obsession), specifi
 
 #### Example
 
-An example of this anti-pattern is a function that receives two or more options, such as `editor: true` and `admin: true`, to configure its behaviour in overlapping ways. In the code below, the `:editor` option has no effect if `:admin` is set, meaning that the `:admin` option has higher priority than `:editor`, and they are ultimately related.
+An example of this anti-pattern is a function that receives two or more options, such as `editor: true` and `admin: true`, to configure its behavior in overlapping ways. In the code below, the `:editor` option has no effect if `:admin` is set, meaning that the `:admin` option has higher priority than `:editor`, and they are ultimately related.
 
 ```elixir
 defmodule MyApp do
@@ -249,7 +249,7 @@ Using multi-clause functions is a powerful Elixir feature. However, some develop
 
 #### Example
 
-A frequent example of this usage of multi-clause functions occurs when developers mix unrelated business logic into the same function definition, in a way that the behaviour of each clause becomes completely distinct from the others. Such functions often have too broad specifications, making it difficult for other developers to understand and maintain them.
+A frequent example of this usage of multi-clause functions occurs when developers mix unrelated business logic into the same function definition, in a way that the behavior of each clause becomes completely distinct from the others. Such functions often have too broad specifications, making it difficult for other developers to understand and maintain them.
 
 Some developers may use documentation mechanisms such as `@doc` annotations to compensate for poor code readability, however the documentation itself may end-up full of conditionals to describe how the function behaves for each different argument combination. This is a good indicator that the clauses are ultimately unrelated.
 
@@ -331,7 +331,7 @@ iex> struct(URI.parse("/foo/bar"), path: "/bar/baz")
 }
 ```
 
-The difference here is that the `struct/2` function behaves precisely the same for any struct given, therefore there is no question of how the function handles different inputs. If the behaviour is clear and consistent for all inputs, then the anti-pattern does not take place.
+The difference here is that the `struct/2` function behaves precisely the same for any struct given, therefore there is no question of how the function handles different inputs. If the behavior is clear and consistent for all inputs, then the anti-pattern does not take place.
 
 ## Using application configuration for libraries
 
diff --git a/lib/elixir/pages/getting-started/anonymous-functions.md b/lib/elixir/pages/getting-started/anonymous-functions.md
index 8c12cf242a6..501329405da 100644
--- a/lib/elixir/pages/getting-started/anonymous-functions.md
+++ b/lib/elixir/pages/getting-started/anonymous-functions.md
@@ -17,7 +17,7 @@ true
 
 In the example above, we defined an anonymous function that receives two arguments, `a` and `b`, and returns the result of `a + b`. The arguments are always on the left-hand side of `->` and the code to be executed on the right-hand side. The anonymous function is stored in the variable `add`.
 
-We can invoke anonymous functions by passing arguments to it. Note that a dot (`.`) between the variable and parentheses is required to invoke an anonymous function. The dot makes it clear when you are calling an anonymous function, stored in the variable `add`, opposed to a function named `add/2`. For example, if you have an anonymous function stored in the variable `is_atom`, there is no ambiguity between `is_atom.(:foo)` and `is_atom(:foo)`. If both used the same `is_atom(:foo)` syntax, the only way to know the actual behaviour of `is_atom(:foo)` would be by scanning all code thus far for a possible definition of the `is_atom` variable. This scanning hurts maintainability as it requires developers to track additional context in their head when reading and writing code.
+We can invoke anonymous functions by passing arguments to it. Note that a dot (`.`) between the variable and parentheses is required to invoke an anonymous function. The dot makes it clear when you are calling an anonymous function, stored in the variable `add`, opposed to a function named `add/2`. For example, if you have an anonymous function stored in the variable `is_atom`, there is no ambiguity between `is_atom.(:foo)` and `is_atom(:foo)`. If both used the same `is_atom(:foo)` syntax, the only way to know the actual behavior of `is_atom(:foo)` would be by scanning all code thus far for a possible definition of the `is_atom` variable. This scanning hurts maintainability as it requires developers to track additional context in their head when reading and writing code.
 
 Anonymous functions in Elixir are also identified by the number of arguments they receive. We can check if a function is of any given arity by using `is_function/2`:
 
diff --git a/lib/elixir/pages/getting-started/binaries-strings-and-charlists.md b/lib/elixir/pages/getting-started/binaries-strings-and-charlists.md
index abc59774bfc..2cbdc5c55c9 100644
--- a/lib/elixir/pages/getting-started/binaries-strings-and-charlists.md
+++ b/lib/elixir/pages/getting-started/binaries-strings-and-charlists.md
@@ -250,7 +250,7 @@ iex> is_list(~c"hełło")
 true
 ```
 
-This is done to ease interoperability with Erlang, even though it may lead to some surprising behaviour. For example, if you are storing a list of integers that happen to range between 0 and 127, by default IEx will interpret this as a charlist and it will display the corresponding ASCII characters.
+This is done to ease interoperability with Erlang, even though it may lead to some surprising behavior. For example, if you are storing a list of integers that happen to range between 0 and 127, by default IEx will interpret this as a charlist and it will display the corresponding ASCII characters.
 
 ```elixir
 iex> heartbeats_per_minute = [99, 97, 116]
diff --git a/lib/elixir/pages/getting-started/modules-and-functions.md b/lib/elixir/pages/getting-started/modules-and-functions.md
index 8849f1db3ea..31a3cba5fd2 100644
--- a/lib/elixir/pages/getting-started/modules-and-functions.md
+++ b/lib/elixir/pages/getting-started/modules-and-functions.md
@@ -130,7 +130,7 @@ defmodule Math do
 end
 ```
 
-And it will provide the same behaviour. You may use `do:` for one-liners but always use `do`-blocks for functions spanning multiple lines. If you prefer to be consistent, you can use `do`-blocks throughout your codebase.
+And it will provide the same behavior. You may use `do:` for one-liners but always use `do`-blocks for functions spanning multiple lines. If you prefer to be consistent, you can use `do`-blocks throughout your codebase.
 
 ## Default arguments
 
diff --git a/lib/elixir/pages/getting-started/protocols.md b/lib/elixir/pages/getting-started/protocols.md
index ba06b0eb0e9..30993322419 100644
--- a/lib/elixir/pages/getting-started/protocols.md
+++ b/lib/elixir/pages/getting-started/protocols.md
@@ -1,6 +1,6 @@
 # Protocols
 
-Protocols are a mechanism to achieve polymorphism in Elixir where you want the behaviour to vary depending on the data type. We are already familiar with one way of solving this type of problem: via pattern matching and guard clauses. Consider a simple utility module that would tell us the type of input variable:
+Protocols are a mechanism to achieve polymorphism in Elixir where you want the behavior to vary depending on the data type. We are already familiar with one way of solving this type of problem: via pattern matching and guard clauses. Consider a simple utility module that would tell us the type of input variable:
 
 ```elixir
 defmodule Utility do
@@ -12,7 +12,7 @@ end
 
 If the use of this module were confined to your own project, you would be able to keep defining new `type/1` functions for each new data type. However, this code could be problematic if it was shared as a dependency by multiple apps because there would be no easy way to extend its functionality.
 
-This is where protocols can help us: protocols allow us to extend the original behaviour for as many data types as we need. That's because **dispatching on a protocol is available to any data type that has implemented the protocol** and a protocol can be implemented by anyone, at any time.
+This is where protocols can help us: protocols allow us to extend the original behavior for as many data types as we need. That's because **dispatching on a protocol is available to any data type that has implemented the protocol** and a protocol can be implemented by anyone, at any time.
 
 Here's how we could write the same `Utility.type/1` functionality as a protocol:
 
@@ -184,7 +184,7 @@ defprotocol Size do
 end
 ```
 
-As we said in the previous section, the implementation of `Size` for `Any` is not one that can apply to any data type. That's one of the reasons why `@fallback_to_any` is an opt-in behaviour. For the majority of protocols, raising an error when a protocol is not implemented is the proper behaviour. That said, assuming we have implemented `Any` as in the previous section:
+As we said in the previous section, the implementation of `Size` for `Any` is not one that can apply to any data type. That's one of the reasons why `@fallback_to_any` is an opt-in behavior. For the majority of protocols, raising an error when a protocol is not implemented is the proper behavior. That said, assuming we have implemented `Any` as in the previous section:
 
 ```elixir
 defimpl Size, for: Any do
diff --git a/lib/elixir/pages/getting-started/writing-documentation.md b/lib/elixir/pages/getting-started/writing-documentation.md
index bb061f4fd26..8ed897bc36b 100644
--- a/lib/elixir/pages/getting-started/writing-documentation.md
+++ b/lib/elixir/pages/getting-started/writing-documentation.md
@@ -106,7 +106,7 @@ We recommend that developers include examples in their documentation, often unde
 
 Elixir treats documentation and code comments as different concepts. Documentation is an explicit contract between you and users of your Application Programming Interface (API), be them third-party developers, co-workers, or your future self. Modules and functions must always be documented if they are part of your API.
 
-Code comments are aimed at developers reading the code. They are useful for marking improvements, leaving notes (for example, why you had to resort to a workaround due to a bug in a library), and so forth. They are tied to the source code: you can completely rewrite a function and remove all existing code comments, and it will continue to behave the same, with no change to either its behaviour or its documentation.
+Code comments are aimed at developers reading the code. They are useful for marking improvements, leaving notes (for example, why you had to resort to a workaround due to a bug in a library), and so forth. They are tied to the source code: you can completely rewrite a function and remove all existing code comments, and it will continue to behave the same, with no change to either its behavior or its documentation.
 
 Because private functions cannot be accessed externally, Elixir will warn if a private function has a `@doc` attribute and will discard its content. However, you can add code comments to private functions, as with any other piece of code, and we recommend developers to do so whenever they believe it will add relevant information to the readers and maintainers of such code.
 
diff --git a/lib/elixir/pages/mix-and-otp/docs-tests-and-with.md b/lib/elixir/pages/mix-and-otp/docs-tests-and-with.md
index 03716bd8bf3..729f3ef52e8 100644
--- a/lib/elixir/pages/mix-and-otp/docs-tests-and-with.md
+++ b/lib/elixir/pages/mix-and-otp/docs-tests-and-with.md
@@ -88,7 +88,7 @@ def parse(line) do
 end
 ```
 
-Our implementation splits the line on whitespace and then matches the command against a list. Using `String.split/1` means our commands will be whitespace-insensitive. Leading and trailing whitespace won't matter, nor will consecutive spaces between words. Let's add some new doctests to test this behaviour along with the other commands:
+Our implementation splits the line on whitespace and then matches the command against a list. Using `String.split/1` means our commands will be whitespace-insensitive. Leading and trailing whitespace won't matter, nor will consecutive spaces between words. Let's add some new doctests to test this behavior along with the other commands:
 
 ```elixir
 @doc ~S"""
diff --git a/lib/elixir/pages/mix-and-otp/introduction-to-mix.md b/lib/elixir/pages/mix-and-otp/introduction-to-mix.md
index 9abd86bc57a..af1e5fa1714 100644
--- a/lib/elixir/pages/mix-and-otp/introduction-to-mix.md
+++ b/lib/elixir/pages/mix-and-otp/introduction-to-mix.md
@@ -295,7 +295,7 @@ def project do
 end
 ```
 
-When true, the `:start_permanent` option starts your application in permanent mode, which means the Erlang VM will crash if your application's supervision tree shuts down. Notice we don't want this behaviour in dev and test because it is useful to keep the VM instance running in those environments for troubleshooting purposes.
+When true, the `:start_permanent` option starts your application in permanent mode, which means the Erlang VM will crash if your application's supervision tree shuts down. Notice we don't want this behavior in dev and test because it is useful to keep the VM instance running in those environments for troubleshooting purposes.
 
 Mix will default to the `:dev` environment, except for the `test` task that will default to the `:test` environment. The environment can be changed via the `MIX_ENV` environment variable:
 
diff --git a/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md b/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md
index 9e32c1e4287..abb883f3a87 100644
--- a/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md
+++ b/lib/elixir/pages/mix-and-otp/task-and-gen-tcp.md
@@ -232,7 +232,7 @@ defp loop_acceptor(socket) do
 end
 ```
 
-You might notice that we added a line, `:ok = :gen_tcp.controlling_process(client, pid)`. This makes the child process the "controlling process" of the `client` socket. If we didn't do this, the acceptor would bring down all the clients if it crashed because sockets would be tied to the process that accepted them (which is the default behaviour).
+You might notice that we added a line, `:ok = :gen_tcp.controlling_process(client, pid)`. This makes the child process the "controlling process" of the `client` socket. If we didn't do this, the acceptor would bring down all the clients if it crashed because sockets would be tied to the process that accepted them (which is the default behavior).
 
 Start a new server with `PORT=4040 mix run --no-halt` and we can now open up many concurrent telnet clients. You will also notice that quitting a client does not bring the acceptor down. Excellent!
 
diff --git a/lib/elixir/pages/references/compatibility-and-deprecations.md b/lib/elixir/pages/references/compatibility-and-deprecations.md
index 9f6e4ee51d8..fceec9da953 100644
--- a/lib/elixir/pages/references/compatibility-and-deprecations.md
+++ b/lib/elixir/pages/references/compatibility-and-deprecations.md
@@ -21,13 +21,13 @@ There are currently no plans for a major v2 release.
 
 ## Between non-major Elixir versions
 
-Elixir minor and patch releases are backwards compatible: well-defined behaviours and documented APIs in a given version will continue working on future versions.
+Elixir minor and patch releases are backwards compatible: well-defined behaviors and documented APIs in a given version will continue working on future versions.
 
 Although we expect the vast majority of programs to remain compatible over time, it is impossible to guarantee that no future change will break any program. Under some unlikely circumstances, we may introduce changes that break existing code:
 
   * Security: a security issue in the implementation may arise whose resolution requires backwards incompatible changes. We reserve the right to address such security issues.
 
-  * Bugs: if an API has undesired behaviour, a program that depends on the buggy behaviour may break if the bug is fixed. We reserve the right to fix such bugs.
+  * Bugs: if an API has undesired behavior, a program that depends on the buggy behavior may break if the bug is fixed. We reserve the right to fix such bugs.
 
   * Compiler front-end: improvements may be done to the compiler, introducing new warnings for ambiguous modes and providing more detailed error messages. Those can lead to compilation errors (when running with `--warning-as-errors`) or tooling failures when asserting on specific error messages (although one should avoid such). We reserve the right to do such improvements.
 
diff --git a/lib/elixir/src/elixir_dispatch.erl b/lib/elixir/src/elixir_dispatch.erl
index 5e264a4f133..df9b04bdc5a 100644
--- a/lib/elixir/src/elixir_dispatch.erl
+++ b/lib/elixir/src/elixir_dispatch.erl
@@ -409,7 +409,7 @@ check_deprecated(Meta, Kind, ?application, Name, Arity, E) ->
       ok
   end;
 check_deprecated(Meta, Kind, Receiver, Name, Arity, E) ->
-  %% Any compile time behaviour cannot be verified by the runtime group pass.
+  %% Any compile time behavior cannot be verified by the runtime group pass.
   case ((?key(E, function) == nil) or (Kind == macro)) andalso get_deprecations(Receiver) of
     [_ | _] = Deprecations ->
       case lists:keyfind({Name, Arity}, 1, Deprecations) of
diff --git a/lib/elixir/test/elixir/file_test.exs b/lib/elixir/test/elixir/file_test.exs
index 7d936ccdb5f..aa4a6b03f6c 100644
--- a/lib/elixir/test/elixir/file_test.exs
+++ b/lib/elixir/test/elixir/file_test.exs
@@ -14,7 +14,7 @@ defmodule FileTest do
     # Following Erlang's underlying implementation
     #
     # Renaming files
-    # :ok               -> rename file to existing file default behaviour
+    # :ok               -> rename file to existing file default behavior
     # {:error, :eisdir} -> rename file to existing empty dir
     # {:error, :eisdir} -> rename file to existing non-empty dir
     # :ok               -> rename file to non-existing location
@@ -26,7 +26,7 @@ defmodule FileTest do
     # :ok                -> rename dir to non-existing leaf location
     # {:error, ??}       -> rename dir to non-existing parent location
     # :ok                -> rename dir to itself
-    # :ok                -> rename dir to existing empty dir default behaviour
+    # :ok                -> rename dir to existing empty dir default behavior
     # {:error, :eexist}  -> rename dir to existing empty dir
     # {:error, :einval}  -> rename parent dir to existing sub dir
     # {:error, :einval}  -> rename parent dir to non-existing sub dir
@@ -35,7 +35,7 @@ defmodule FileTest do
     # other tests
     # {:error, :enoent} -> rename unknown source
     # :ok               -> rename preserves mode
-    test "rename file to existing file default behaviour" do
+    test "rename file to existing file default behavior" do
       src = tmp_fixture_path("file.txt")
       dest = tmp_path("tmp.file")
 
@@ -128,7 +128,7 @@ defmodule FileTest do
       end
     end
 
-    test "rename! file to existing file default behaviour" do
+    test "rename! file to existing file default behavior" do
       src = tmp_fixture_path("file.txt")
       dest = tmp_path("tmp.file")
 
@@ -256,7 +256,7 @@ defmodule FileTest do
       end
     end
 
-    test "rename dir to existing empty dir default behaviour" do
+    test "rename dir to existing empty dir default behavior" do
       src = tmp_fixture_path("cp_r")
       dest = tmp_path("tmp")
 
diff --git a/lib/iex/lib/iex.ex b/lib/iex/lib/iex.ex
index c6f2dcc430f..0b200a7ba59 100644
--- a/lib/iex/lib/iex.ex
+++ b/lib/iex/lib/iex.ex
@@ -115,7 +115,7 @@ defmodule IEx do
       iex(1)> [1, [2], 3]
       [1, [2], 3]
 
-  To prevent this behaviour breaking valid code where the subsequent line
+  To prevent this behavior breaking valid code where the subsequent line
   begins with a binary operator, such as `|>/2` or `++/2` , IEx automatically
   treats such lines as if they were prepended with `IEx.Helpers.v/0`, which
   returns the value of the previous expression, if available.
diff --git a/lib/mix/lib/mix.ex b/lib/mix/lib/mix.ex
index 8532964475f..3afe169049b 100644
--- a/lib/mix/lib/mix.ex
+++ b/lib/mix/lib/mix.ex
@@ -320,7 +320,7 @@ defmodule Mix do
 
   ## Environment variables
 
-  Several environment variables can be used to modify Mix's behaviour.
+  Several environment variables can be used to modify Mix's behavior.
 
   Mix responds to the following variables:
 
@@ -367,7 +367,7 @@ defmodule Mix do
     * `MIX_TARGET` - specifies which target should be used. See [Targets](#module-targets)
 
     * `MIX_XDG` - asks Mix to follow the [XDG Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)
-      for its home directory and configuration files. This behaviour needs to
+      for its home directory and configuration files. This behavior needs to
       be opt-in due to backwards compatibility. `MIX_HOME` has higher preference
       than `MIX_XDG`. If none of the variables are set, the default directory
       `~/.mix` will be used
@@ -749,7 +749,7 @@ defmodule Mix do
   ## Limitations
 
   There is one limitation to `Mix.install/2`, which is actually an Elixir
-  behaviour. If you are installing a dependency that defines a struct or
+  behavior. If you are installing a dependency that defines a struct or
   macro, you cannot use the struct or macro immediately after the install
   call. For example, this won't work:
 
diff --git a/lib/mix/lib/mix/dep/loader.ex b/lib/mix/lib/mix/dep/loader.ex
index f9b532c9fa5..5e988d8c07b 100644
--- a/lib/mix/lib/mix/dep/loader.ex
+++ b/lib/mix/lib/mix/dep/loader.ex
@@ -12,7 +12,7 @@ defmodule Mix.Dep.Loader do
   are included as children.
 
   By default, it will filter all dependencies that does not match
-  current environment, behaviour can be overridden via options.
+  current environment, behavior can be overridden via options.
   """
   def children(locked?) do
     mix_children(Mix.Project.config(), locked?, []) ++ Mix.Dep.Umbrella.unloaded()
diff --git a/lib/mix/lib/mix/release.ex b/lib/mix/lib/mix/release.ex
index ce3060a51f7..0e2659dfbfb 100644
--- a/lib/mix/lib/mix/release.ex
+++ b/lib/mix/lib/mix/release.ex
@@ -433,7 +433,7 @@ defmodule Mix.Release do
   the `:elixir` application configuration in `sys_config` to be
   read during boot and trigger the providers.
 
-  It uses the following release options to customize its behaviour:
+  It uses the following release options to customize its behavior:
 
     * `:reboot_system_after_config`
     * `:start_distribution_during_config`
diff --git a/man/mix.1 b/man/mix.1
index 44d3ed8c76b..e35a14a4ab6 100644
--- a/man/mix.1
+++ b/man/mix.1
@@ -31,7 +31,7 @@ All the
 .Nm
 functionality is represented by a set of tasks. A
 .Em task
-is a piece of code written in Elixir and intended for solving a particular problem. Like programs, many tasks accept input parameters and/or support options which slightly modify their behaviour, but others do not. There are two types of tasks: those that are available after installation this or that archive
+is a piece of code written in Elixir and intended for solving a particular problem. Like programs, many tasks accept input parameters and/or support options which slightly modify their behavior, but others do not. There are two types of tasks: those that are available after installation this or that archive
 .Pq local tasks
 and those that are offered by
 .Nm