Apply suggestions from code review

Co-authored-by: Cem Aksoylar <[email protected]>

docs/docs/development/new-shield.mdx

@@ -20,7 +20,7 @@ The high level steps are:
 - Add the base Kconfig files.
 - Add the shield overlay file to define the KSCAN driver for detecting key press/release.
 - Add the matrix transform for mapping KSCAN row/column values to key positions in the keymap.
-- Add a physical layout definition to select the matrix transform and kscan instance.
+- Add a physical layout definition to select the matrix transform and KSCAN instance.
 - Add a default keymap, which users can override in their own configs as needed.
 - Add a `<my_shield>.zmk.yml` metadata file to document the high level details of your shield, and the features it supports.
 - Update the `build.yaml` file from the repository template to have some sample builds of the firmware to test.
@@ -329,7 +329,7 @@ Internally ZMK translates all row/column events into "key position" events to ma
 A "key position" is the numeric index (zero-based) of a given key, which identifies
 the logical key location as perceived by the end user. All _keymap_ mappings actually bind behaviors to _key positions_, not to row/column values.
 
-The `<shield_name>.overlay` must include a matrix transform that defines this mapping from row/colum to key position.
+The `<shield_name>.overlay` must include a matrix transform that defines this mapping from row/column values to key positions.
 
 Here is an example for the [nice60](https://github.com/Nicell/nice60), which uses an efficient 8x8 GPIO matrix, and uses a transform:
 
@@ -365,14 +365,14 @@ Some important things to note:
 
 - The `#include <dt-bindings/zmk/matrix_transform.h>` is critical. The `RC` macro is used to generate the internal storage in the matrix transform, and is actually replaced by a C preprocessor before the final devicetree is compiled into ZMK.
 - `RC(row, column)` is placed sequentially to define what row and column values that position corresponds to.
-- If you have a keyboard with options for `2u` keys in certain positions, ANSI vs ISO layouts, or break away portions, the define one matrix transform for each possible arrangement, and they will be used in the physical layouts to let users select a given layout in they keymap file.
+- If you have a keyboard with options for `2u` keys in certain positions, ANSI vs ISO layouts, or break away portions, define one matrix transform for each possible arrangement to be used in the physical layouts. This will allow the users to select the right layout in their keymap files.
 
 See the [matrix transform section](../config/kscan.md#matrix-transform) in the Keyboard Scan configuration documentation for details and more examples of matrix transforms.
 
 ## Physical Layout
 
-The physical layout is the top level entity that aggregates all details about a certain possibly layout for a keyboard: the matrix transform that defines the set of key positions, and what row/column they correspond to, what kscan driver is used for that layout, etc.
-For keyboards that support multiple layouts, setting a `chosen` node to a given physical layout in your keymap will allow selecting the given layout you've built.
+The physical layout is the top level entity that aggregates all details about a certain possible layout for a keyboard: the matrix transform that defines the set of key positions and what row/column they correspond to, what kscan driver is used for that layout, etc.
+For keyboards that support multiple layouts, setting a `chosen` node to a defined physical layout in your keymap will allow selecting the specific layout that you've built.
 
 A physical layout is very basic, e.g.: