Editing pass (#1874)

* Update faq.rst

* Update c_sharp_basics.rst

* Update external_editor.rst

* Update unity_to_godot.rst

* Update unity_to_godot.rst

about/faq.rst

@@ -25,7 +25,7 @@ For full details, look at the `COPYRIGHT.txt <https://github.com/godotengine/god
 as the `LICENSE.txt <https://github.com/godotengine/godot/blob/master/LICENSE.txt>`_ and `LOGO_LICENSE.txt <https://github.com/godotengine/godot/blob/master/LOGO_LICENSE.md>`_ files
 in the Godot repository.
 
-Also see `the license page on the Godot website <https://godotengine.org/license>`_.
+Also, see `the license page on the Godot website <https://godotengine.org/license>`_.
 
 Which platforms are supported by Godot?
 ---------------------------------------
@@ -80,7 +80,7 @@ discussions on `open issues <https://github.com/godotengine/godot/issues>`_ is a
 great way to start your troubleshooting.
 
 As for new languages, support is possible via third parties using the GDNative /
-NativeScript / PluginScript facilities. (See question about plugins below.)
+NativeScript / PluginScript facilities. (See the question about plugins below.)
 Work is currently underway, for example, on unofficial bindings for Godot
 to `Python <https://github.com/touilleMan/godot-python>`_ and `Nim <https://github.com/pragmagic/godot-nim>`_.
 
@@ -110,7 +110,7 @@ Since Godot is an open-source project, it was imperative from the start to prior
 more integrated and seamless experience over attracting additional users by supporting
 more familiar programming languages--especially when supporting those more familiar
 languages would result in a worse experience. We understand if you would rather use
-another language in Godot (see list of supported options above). That being said, if
+another language in Godot (see the list of supported options above). That being said, if
 you haven't given GDScript a try, try it for **three days**. Just like Godot,
 once you see how powerful it is and rapid your development becomes, we think GDScript
 will grow on you.
@@ -225,7 +225,7 @@ For extending Godot, like creating Godot Editor plugins or adding support
 for additional languages, take a look at :ref:`EditorPlugins <doc_making_plugins>`
 and tool scripts.
 
-Also see the official blog posts on these topics:
+Also, see the official blog posts on these topics:
 
 * `A look at the GDNative architecture <https://godotengine.org/article/look-gdnative-architecture>`_
 * `GDNative is here! <https://godotengine.org/article/dlscript-here>`_

getting_started/editor/external_editor.rst

@@ -3,7 +3,7 @@
 Using an external text editor
 ==============================
 
-While godot has an inbuilt text editor, some developers have a tendency to
+While Godot has an inbuilt text editor, some developers have a tendency to
 want to use a text editor they are familiar with. Godot provides this
 option via the options under 
 ``Editor -> Editor Settings -> Text Editor -> External``

getting_started/editor/unity_to_godot.rst

@@ -93,7 +93,7 @@ Unity's scene system consists of embedding all the required assets in a scene
 and linking them together by setting components and scripts to them.
 
 Godot's scene system is different: it actually consists in a tree made of nodes.
-Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this is similar to Unity scene system.
+Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this is similar to the Unity scene system.
 However, each node can have multiple children, which makes each a subscene of the main scene.
 This means you can compose a whole scene with different scenes stored in different files.
 
@@ -145,7 +145,7 @@ new specific node that has collision properties. Godot features various collisio
 - Question: What are the advantages of this system? Wouldn't this system potentially increase the depth of the scene tree? Besides, Unity allows organizing GameObjects by putting them in empty GameObjects.
 
     - First, this system is closer to the well-known object-oriented paradigm: Godot provides a number of nodes which are not clearly "Game Objects", but they provide their children with their own capabilities: this is inheritance.
-    - Second, it allows the extraction a subtree of scene to make it a scene of its own, which answers the second and third questions: even if a scene tree gets too deep, it can be split into smaller subtrees. This also allows a better solution for reusability, as you can include any subtree as a child of any node. Putting multiple nodes in an empty GameObject in Unity does not provide the same possibility, apart from a visual organization.
+    - Second, it allows the extraction a subtree of the scene to make it a scene of its own, which answers the second and third questions: even if a scene tree gets too deep, it can be split into smaller subtrees. This also allows a better solution for reusability, as you can include any subtree as a child of any node. Putting multiple nodes in an empty GameObject in Unity does not provide the same possibility, apart from a visual organization.
 
 
 These are the most important concepts you need to remember: "node", "parent node", and "child node".
@@ -222,7 +222,7 @@ or include the script directly in the node. If you need to attach more scripts t
 depending on your scene and on what you want to achieve:
 
 - either add a new node between your target node and its current parent, then add a script to this new node.
-- or, your can split your target node into multiple children and attach one script to each of them.
+- or, you can split your target node into multiple children and attach one script to each of them.
 
 As you can see, it can be easy to turn a scene tree to a mess. This is why it is important to have a real reflection
 and consider splitting a complicated scene into multiple, smaller branches.

getting_started/scripting/c_sharp/c_sharp_basics.rst

@@ -13,7 +13,7 @@ Afterwards, you may want to look at :ref:`how to use specific features <doc_c_sh
 read about the :ref:`differences between the C# and the GDScript API <doc_c_sharp_differences>`
 and (re)visit the :ref:`Scripting section <doc_scripting>` of the step-by-step tutorial.
 
-C# is a high-level programming language developed by Microsoft. In Godot it is implemented with the Mono 5.x .NET framework including full support for C# 7.0.
+C# is a high-level programming language developed by Microsoft. In Godot, it is implemented with the Mono 5.x .NET framework including full support for C# 7.0.
 Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime.
 A good starting point for checking its capabilities is the `Compatibility <http://www.mono-project.com/docs/about-mono/compatibility/>`_ page in the Mono documentation.
 
@@ -78,7 +78,7 @@ When troubleshooting, it sometimes can help to delete the ``.mono`` folder and l
 Note that currently there are some issues where the Godot and the C# project don't stay in sync; if you delete, rename or move things like scripts or nodes, they may no longer match up.
 In this case, it can help to edit the solution files manually.
 
-Example: If you created a script (e.g. ``Test.cs``) and delete it in Godot, compilation will fail because the now missing file is still expected to be there by the CS project.
+Example: If you created a script (e.g. ``Test.cs``) and delete it in Godot, the compilation will fail because now the missing file is still expected to be there by the CS project.
 You can for now simply open up the ``.csproj`` and look for the ``ItemGroup``, there should be a line included like the following:
 
 .. code-block:: xml
@@ -116,7 +116,7 @@ Here's a blank C# script with some comments to demonstrate how it works.
 
         public override void _Process(float delta)
         {
-            // Called every frame. Delta is time since last frame.
+            // Called every frame. Delta is time since the last frame.
             // Update game logic here.
         }
     }
@@ -144,14 +144,14 @@ As C# support is quite new to Godot, there are some growing pains and things tha
 Below is a list of the most important issues you should be aware of when diving into C# in Godot, but if in doubt also take a look over the official `issue tracker for Mono issues <https://github.com/godotengine/godot/labels/topic%3Amono>`_.
 
 - As explained above, the C# project isn't always kept in sync automatically when things are deleted, renamed or moved in Godot (`#12917 <https://github.com/godotengine/godot/issues/12917>`_)
-- Writing editor plugins and tool scripts in C# is not yet supported
+- Writing editor plugins and tool scripts in C# are not yet supported
 - Exporting Mono projects is only supported for desktop platforms (Linux, Windows and macOS). HTML5, Android, iOS and UWP are not currently supported (`#18364 comment <https://github.com/godotengine/godot/issues/18364#issuecomment-406222102>`_)
 - Attached C# scripts should refer to a class that has a class name that matches the file name and is unique within the project assembly (`#7402 comment <https://github.com/godotengine/godot/issues/7402#issuecomment-269910926>`_)
 
 Performance of C# in Godot
 --------------------------
 
-According to some preliminary `benchmarks <https://github.com/cart/godot3-bunnymark>`_, performance of C# in Godot - while generally in the same order of magnitude - is roughly **~4x** that of GDScript in some naive cases.
+According to some preliminary `benchmarks <https://github.com/cart/godot3-bunnymark>`_, the performance of C# in Godot - while generally in the same order of magnitude - is roughly **~4x** that of GDScript in some naive cases.
 For full performance, C++ is still a little faster; the specifics are going to vary according to your use case. GDScript is likely fast enough for most general scripting workloads.
 C# is faster, but requires some expensive marshalling when talking to Godot.