initialisation -> initialization

Author: lilasta

text/1440-drop-types-in-const.md

@@ -15,7 +15,7 @@ Some of the collection types do not allocate any memory when constructed empty (
 is no longer required to be a hard error (as it is safe and accepted that these destructors may never run).
 
 Allowing types with destructors to be directly used in `const` functions and stored in `static`s or `const`s will remove the need to have
-runtime-initialisation for global variables.
+runtime-initialization for global variables.
 
 # Detailed design
 [design]: #detailed-design
@@ -62,9 +62,9 @@ A `const` item's destructor _will_ run at each point where the `const` item is u
 # Alternatives
 [alternatives]: #alternatives
 
-- Runtime initialisation of a raw pointer can be used instead (as the `lazy_static` crate currently does on stable)
+- Runtime initialization of a raw pointer can be used instead (as the `lazy_static` crate currently does on stable).
 - On nightly, a bug related to `static` and `UnsafeCell<Option<T>>` can be used to remove the dynamic allocation.
-  - Both of these alternatives require runtime initialisation, and incur a checking overhead on subsequent accesses.
+  - Both of these alternatives require runtime initialization, and incur a checking overhead on subsequent accesses.
 - Leaking of objects could be addressed by using C++-style `.dtors` support
   - This is undesirable, as it introduces confusion around destructor execution order.