diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 90d7d7404a..ea5f5bd2eb 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,7 +24,7 @@ In any case, be sure to describe the feature in enough detail, to consider its i
## Submitting a Patch
* Ideally, start with something small to get familiar with the review process and work up from there.
-* Make an effort to follow the overal coding style, which is roughly based on the [Qt Creator coding style](https://doc.qt.io/qtcreator-extending/coding-style.html).
+* Make an effort to follow the overall coding style, which is roughly based on the [Qt Creator coding style](https://doc.qt.io/qtcreator-extending/coding-style.html).
* Be prepared for detailed feedback on your patch and to make several revisions.
* Each pull request will be built automatically for Windows, Linux and macOS. If the build fails anywhere, please check if it may be a problem with your patch.
diff --git a/docs/manual/automapping.rst b/docs/manual/automapping.rst
index 55b9a521af..59bc6b0143 100644
--- a/docs/manual/automapping.rst
+++ b/docs/manual/automapping.rst
@@ -33,7 +33,7 @@ a map:
Since Tiled 1.4
-* Open *Project > Project Propecties* and set the "Automapping rules" property
+* Open *Project > Project Properties* and set the "Automapping rules" property
to the ``rules.txt`` file that you created in your project. If you have only a
single rule map, you can also refer to that map file directly.
@@ -73,7 +73,7 @@ At a minimum, a rule map contains:
when an input pattern is found.
In addition, custom properties on the rule map, its layers and on objects can
-be used to fine-tune the overal behavior or the behavior of specific rules.
+be used to fine-tune the overall behavior or the behavior of specific rules.
Finally, you may need some :ref:`special tiles ` to
set up certain rules. Tiled provides a built-in "Automapping Rules Tileset",
@@ -196,7 +196,7 @@ special cases as well!
Definition of Outputs
---------------------
-Outputs are generally defined by layers whichs name follows this scheme:
+Outputs are generally defined by layers whose name follows this scheme:
**output[index]\_name**
@@ -502,7 +502,7 @@ northern direction.
So basically the meaning we will define in the input region is: *All
tiles which are south of a water tile and are not water tiles themselves,
-will be replaced by a shoreline tile*
+will be replaced by a shoreline tile.*
+-----------------------------------------------------------+------------------+
| Tile layer | Name |
@@ -539,7 +539,7 @@ Corners on a Shore Line
This example is a continuation of the previous example. Now the corners
of the given shoreline should be implemented automatically. Within this
-article we will just examine the bent in corner shoreline in the topleft
+article we will just examine the bent in corner shoreline in the top left
corner. The other shoreline corners are constructed the same way. So
after the example is applied, we would like to have the corners of the
shoreline get suitable tiles. Since we rely on the other example being
@@ -572,9 +572,9 @@ Input and Output Regions
^^^^^^^^^^^^^^^^^^^^^^^^
So with this rule we want to put the bent in shore line tile in the top
-left corner, we don't care which tile was there before. Also
-we don't care about the tile in the lower right corner. (probably water,
-but can be any decorative watertile, so just ignore it).
+left corner; we don't care which tile was there before. We also don't
+care about the tile in the lower right corner (probably water, but can
+be any decorative water tile, so just ignore it).
+-----------------------------------------------------------------+------------------------------------------------------------------+-------------------------------------------------------------------+
| .. image:: images/automapping/TheManaWorld/2/regions_input.png | .. image:: images/automapping/TheManaWorld/2/regions_output.png | .. image:: images/automapping/TheManaWorld/2/regions_united.png |
@@ -598,15 +598,15 @@ Input Layers
Now we want to put all the nine possible patterns we observed as
possible input for this rule. We could of course define nine different
-layers *input1\_Ground* up to *input9\_Ground*
+layers *input1\_Ground* up to *input9\_Ground*.
-Nine TileLayers?! What a mess, we'll do it a better way.
+Nine TileLayers?! What a mess; we'll do it a better way.
Also, consider having not just 3 possible tiles at the 2 locations but 4.
Then we would need 4\*4=16 tilelayers to get all conditions. Another
downside of this comes with more needed locations: Think of more than 2
-locations needed to construct a ruleinput. So for 3 locations, then each
-location could have the 3 possibilites, hence you need 3\*3\*3 = 27
+locations needed to construct a rule input. So for 3 locations, each
+location could have the 3 possibilities, hence you need 3\*3\*3 = 27
tilelayers. It's not getting better...
So let's try a smart way: All input layers have the same name, so at
@@ -625,7 +625,7 @@ each position any of the three different tiles is valid.
Output Layer
^^^^^^^^^^^^
-The output is straight forward, since only one tile is needed. No
+The output is straightforward, since only one tile is needed. No
randomness is needed, hence the index is not needed to be varied, so
it's kept empty. The desired output layer is called Ground, so the over
all name of the single output layer will be output\_Ground. The correct
@@ -750,7 +750,7 @@ An Alternating Wall
-------------------
This example will demonstrate how a wall as a transition between a
-walkable area and the non-walkable black void can easily be setup. As
+walkable area and the unwalkable black void can easily be setup. As
input a dedicated set layer will be used.
+-------------------------------------------------------+--------------------------------------------------------+
diff --git a/docs/manual/export-yy.rst b/docs/manual/export-yy.rst
index b06ccad957..4760348b36 100644
--- a/docs/manual/export-yy.rst
+++ b/docs/manual/export-yy.rst
@@ -151,7 +151,7 @@ object.
.. note::
- As of now only variable definitions of the object itself can be overriden.
+ As of now only variable definitions of the object itself can be overridden.
Overriding variable definitions of parent objects is not supported. As a
workaround you can use the creation code to override variables of a parent
object.
diff --git a/docs/manual/projects.rst b/docs/manual/projects.rst
index 47600548e1..bbad39dfbe 100644
--- a/docs/manual/projects.rst
+++ b/docs/manual/projects.rst
@@ -25,7 +25,7 @@ Compatibility Version
Extensions Directory
A project-specific directory where you can put :doc:`Tiled extensions
`. It defaults to simply ``extensions``, so when you
- have a directory called "extensions" alonside your project file it will be
+ have a directory called "extensions" alongside your project file it will be
picked up automatically.
The directory is loaded in addition to the global extensions.
diff --git a/docs/manual/worlds.rst b/docs/manual/worlds.rst
index a3408ab68d..c3e1929241 100644
--- a/docs/manual/worlds.rst
+++ b/docs/manual/worlds.rst
@@ -78,11 +78,11 @@ Adding Maps
from the dropdown menu select the world you want to add it to. To add a
different map to the current world, you can use the 'Add another map to
the current world' button from the toolbar. Alternatively, both actions
- can be accessed by rightclicking in the map editor.
+ can be accessed by right-clicking in the map editor.
Removing Maps
Hit the 'Remove the current map from the current world' button on the
- toolbar. Alternatively, rightclick a map in the map editor and select the
+ toolbar. Alternatively, right-click a map in the map editor and select the
'Remove ... from World ...' action from the context menu.
Moving Maps