Fix various typos

community/contributing/pr_workflow.rst

@@ -241,7 +241,7 @@ before staging it, while it is staged, and after it has been committed.
 - ``git show`` will show you the changes of the last commit. You can also
   specify a commit hash to see the changes for that commit.
 
-That's a lot to memorise! Don't worry, just check this cheat sheet when you
+That's a lot to memorize! Don't worry, just check this cheat sheet when you
 need to make changes, and learn by doing.
 
 Here's how the shell history could look like on our example:

getting_started/workflow/best_practices/data_preferences.rst

@@ -25,7 +25,7 @@ Y or Z? This article covers a variety of topics related to these dilemmas.
 
   Imagine if one had to process 3 million data points within a single frame. It
   would be impossible to craft the feature with a linear-time algorithm since
-  the sheer size of the data would increase the runtime far beyond the time alotted.
+  the sheer size of the data would increase the runtime far beyond the time allotted.
   In comparison, using a constant-time algorithm could handle the operation without
   issue.
 

getting_started/workflow/best_practices/logic_preferences.rst

@@ -30,7 +30,7 @@ either? Let's see an example:
     # my_buildings.gd
     extends Node
 
-    # (note how constant scripts/scenes have a diferent naming scheme than
+    # (note how constant scripts/scenes have a different naming scheme than
     # their property variants).
 
     # This value is a constant, so it spawns when the Script object loads.

getting_started/workflow/best_practices/scene_organization.rst

@@ -45,7 +45,7 @@ recommend the use of
 `Dependency Injection <https://en.wikipedia.org/wiki/Dependency_injection>`_.
 This technique involves having a high-level API provide the dependencies of the
 low-level API. Why do this? Because classes which rely on their external
-environment can inadvertantly trigger bugs and unexpected behavior.
+environment can inadvertently trigger bugs and unexpected behavior.
 
 To do this, one must expose data and then rely on a parent context to
 initialize it:
@@ -312,7 +312,7 @@ Each subsystem within one's game should have its own section within the
 SceneTree. One should use parent-child relationships only in cases where nodes
 are effectively elements of their parents. Does removing the parent reasonably
 mean that one should also remove the children? If not, then it should have its
-own place in the hierachy as a sibling or some other relation.
+own place in the hierarchy as a sibling or some other relation.
 
 .. note::
 

tutorials/3d/fps_tutorial/part_one.rst

@@ -126,7 +126,7 @@ The reason behind this is so we can rotate ``Player`` on the ``Y`` axis, and ``R
 the ``X`` axis.
 
 .. note:: Had we not used ``Rotation_helper``, we would've likely had cases of rotating on
-          both the ``X`` and ``Y`` axes simultaneously, potentially futher degenerating into a state of
+          both the ``X`` and ``Y`` axes simultaneously, potentially further degenerating into a state of
           rotation on all three axes in some cases.
 
           See :ref:`using transforms <doc_using_transforms>` for more information

tutorials/animation/animation_tree.rst

@@ -201,7 +201,7 @@ Controlling from code
 
 After building the tree and previewing it, the only question remaining is "How is all this controlled from code?".
 
-Keep in mind that the animaton nodes are just resources and, as such, they are shared between all the instances.
+Keep in mind that the animation nodes are just resources and, as such, they are shared between all the instances.
 Setting values in the nodes directly will affect all instances of the scene that uses this ``AnimationTree``.
 This has some cool use cases, though, e.g. you can copy and paste parts of your animation tree, or reuse nodes with a complex layout
 (such as a state machine or blend space) in different animation trees.

tutorials/animation/introduction_2d.rst

@@ -459,9 +459,9 @@ Timeline zoom level control
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. figure:: img/animation_reference_timeline_zoom_level.png
-   :alt: Timeline zoom level contro
+   :alt: Timeline zoom level control
 
-   Timeline zoom level contro
+   Timeline zoom level control
 
 Timeline control
 ^^^^^^^^^^^^^^^^

tutorials/io/saving_games.rst

@@ -182,7 +182,7 @@ load function:
         # We need to revert the game state so we're not cloning objects 
         # during loading. This will vary wildly depending on the needs of a 
         # project, so take care with this step.
-        # For our example, we will accomplish this by deleting savable objects.
+        # For our example, we will accomplish this by deleting saveable objects.
         var save_nodes = get_tree().get_nodes_in_group("Persist")
         for i in save_nodes:
             i.queue_free()
@@ -216,7 +216,7 @@ load function:
         // We need to revert the game state so we're not cloning objects during loading. 
         // This will vary wildly depending on the needs of a project, so take care with 
         // this step.
-        // For our example, we will accomplish this by deleting savable objects.
+        // For our example, we will accomplish this by deleting saveable objects.
         var saveNodes = GetTree().GetNodesInGroup("Persist");
         foreach (Node saveNode in saveNodes)
             saveNode.QueueFree();

tutorials/platform/customizing_html5_shell.rst

@@ -20,7 +20,7 @@ Some simple use-cases where customizing the default page is useful include:
    the file system later
  - Passing custom "command line" arguments, e.g. ``-s`` to start a MainLoop script
 
-Another sample HTML page is avilable at `/misc/dist/html/fixed-size.html <https://github.com/godotengine/godot/blob/master/misc/dist/html/fixed-size.html>`__.
+Another sample HTML page is available at `/misc/dist/html/fixed-size.html <https://github.com/godotengine/godot/blob/master/misc/dist/html/fixed-size.html>`__.
 This page uses a fixed size canvas with an output widget below. However, the
 F12 browser console should be preferred as it can display additional
 information, such as WebGL errors.

tutorials/plugins/editor/making_main_screen_plugins.rst

@@ -9,7 +9,7 @@ What this tutorial covers
 As seen in the :ref:`doc_making_plugins` page, making a basic plugin that
 extends the editor is fairly easy. This plugin mechanism also allows you to
 create new UIs in the central part of the editor, similarly to the basic 2D, 3D,
-Script and AssetLib views. Such editor plugins are refered as "Main screen
+Script and AssetLib views. Such editor plugins are referred as "Main screen
 plugins".
 
 This tutorial leads you through the creation of a basic main screen plugin. With 
@@ -75,7 +75,7 @@ Scenes
 ------
 
 The ``main_screen_plugin.gd`` file will be responsible for each of our plugin's
-UI element instanciation, and it will also manage the communication between them.
+UI element instantiation, and it will also manage the communication between them.
 
 As a matter of fact, we wish to design each UI element in their own scene.
 Different scenes are not aware of each other unless they are both children of a
@@ -91,13 +91,13 @@ and scene #2 will be connected to that signal. Since all of our UI scenes will
 be instanced by ``main_screen_plugin.gd`` script, this one script will also
 connect each of them to the required signals.
 
-.. note:: If the ``main_screen_plugin.gd`` instanciates the UI scenes, won't
+.. note:: If the ``main_screen_plugin.gd`` instantiates the UI scenes, won't
           they be brothers nodes then?
 
 Not necessarily: this script may add all UI scenes as children of the same node
 of the editor's scene tree - but maybe it won't. And the ``main_screen_plugin.gd``
-script will *not* be the parent node of any instanciated scene because it is a
-script, not a node! This script will only hold references to instanciated
+script will *not* be the parent node of any instantiated scene because it is a
+script, not a node! This script will only hold references to instantiated
 scenes.
 
 Main screen scene

tutorials/plugins/gdnative/gdnative-cpp-example.rst

@@ -44,7 +44,7 @@ do the work for you.
 Note that these repositories now have different branches for different
 versions of Godot. GDNative modules written for an earlier version of
 Godot will work in newer versions (with the exception of one breaking
-change in ARVR interfaces between 3.0 and 3.1) but not vise versa so
+change in ARVR interfaces between 3.0 and 3.1) but not vice versa so
 make sure you download the correct branch.
 Also note that the version of Godot you use to generate the ``api.json``
 with becomes your minimum version.