DOCS: Fix typo in using-playerinput-workflow.md (DOCATT-11242)

Packages/com.unity.inputsystem/Documentation~/using-playerinput-workflow.md

@@ -7,9 +7,9 @@ uid: input-system-workflow-player-input
 
 The highest level of abstraction provided by the Input System is when you use [Actions](actions.md) and the **Player Input component** together.
 
- The Player Input provides a way to make connections between your configured Actions and the C# methods in your own MonoBehaviour scripts, so that your desired C# methods are called when the user performs an input action.
+The Player Input provides a way to make connections between your configured Actions and the C# methods in your own MonoBehaviour scripts, so that your desired C# methods are called when the user performs an input action.
 
-It allows you to set up these connections using a UI in the inspector using an event-driven model, instead writing code to poll the values of your Actions as described in the [previous workflow example](using-actions-workflow.md)).
+It allows you to set up these connections using a UI in the inspector using an event-driven model, instead of writing code to poll the values of your Actions as described in the [previous workflow example](using-actions-workflow.md).
 
 The PlayerInput component also helps with local multi-player scenarios. You can use the PlayerInput component along with the PlayerInputManager component to handle automatic instantiation of new players when input occurs on new devices. For example, if you were making a four-player local cooperative game, PlayerInput with PlayerInputManager can handle allowing new players to join when they press start on their respective controller.
 
@@ -62,7 +62,7 @@ This workflow has pros and cons when compared to using [Actions without a Player
 
 This workflow also allows you to set up callbacks in the Editor using an interface in the Inspector, which can sometimes reduce code complexity but can also make debugging more difficult, because the connections between your actions and code are not themselves defined in your code.
 
-It also provides ready-made handling of the [assignment of devices](device-assignments.md) and [screen-splitting](set-up-split-screen-local-multiplayer.md) in local multiplayer scenarios. While these are things you can implement yourself, having a simple solution ready to go can be beneficial. However if you choose this option, the implementation is somewhat of a "black box", meaning you are less able to customise how it works.
+It also provides ready-made handling of the [assignment of devices](device-assignments.md) and [screen-splitting](set-up-split-screen-local-multiplayer.md) in local multiplayer scenarios. While these are things you can implement yourself, having a simple solution ready to go can be beneficial. However, if you choose this option, the implementation is somewhat of a "black box", meaning you are less able to customize how it works.
 
 As with the other workflows described in this section, there is a trade-off between flexibility, simplicity, and speed of implementation.