Minor textual changes

website/docs/chapter-02/01_suitefile.md

@@ -166,7 +166,7 @@ This section is used to define suite variables that are used in the suite or its
 The most common use case is to define these variables as constants that contain a static value during execution.
 This can either be a default value, that may be overwritten by globally defined variables via the Command Line Interface (CLI) or a constant value that is used in multiple places in the suite.
 
-In some cases, these variables are also dynamically reassigned during the execution of the suite, but this is not recommended and should be avoided if possible, because this may lead to test|task runtime dependancies and errors caused by these side-effects that are hard to debug and find.
+In some cases, these variables are also dynamically reassigned during the execution of the suite, but this is not recommended and should be avoided if possible, because this may lead to test|task runtime dependencies and errors caused by these side-effects that are hard to debug and find.
 
 See [3.2.2 `*** Variables ***` Section](chapter-03/02_variables.md#322--variables--section) for more information about the `*** Variables ***` section.
 

website/docs/chapter-02/03_executing.md

@@ -94,7 +94,7 @@ After executing a suite, Robot Framework, by default, generates three output fil
 `log.html` and `report.html` are generated based on the information stored in `output.xml`.
 
 A unique feature of Robot Framework is, that it logs each keyword call and its arguments with its log outputs and timestamps, so that it is possible to have a very detailed view of the execution flow and the data that was used during the execution.
-In case of a failure it is possible to see the exact keyword call that failed and the arguments that were used, which can be very helpful for debugging or reporting. Furthermore you also get all passed keywords and even the non-executed keywords to protocol the whole execution flow.
+In case of a failure it is possible to see the exact keyword call that failed and the arguments that were used, which can be very helpful for debugging or reporting. Furthermore, you also get all passed keywords and even the non‑executed keywords, allowing you to trace the whole execution flow.
 
 
 

website/docs/chapter-02/04_keyword_imports.md

@@ -128,8 +128,8 @@ This *module search path* is defined by the Python interpreter that executes Rob
 For **path separators**, it is strongly recommended to always use forward slashes (`/`), and even on Windows, not to use backslashes (`\`).
 This is because backslashes are used as escape characters in Robot Framework, which can cause issues when used in paths. Forward slashes are supported on all operating systems when used in Robot Framework.
 
-When choosing the location of resource files or libraries, it should be taken into that consideration that absolute paths are typically not portable and therefore should be avoided.
-Relative paths are portable as long as they are related to the data file that is importing using them, as long as that relative path is part of the project structure.
+When choosing the location of resource files or libraries, it should be taken into consideration that absolute paths are typically not portable and therefore should be avoided.
+Relative paths are portable as long as they are defined relative to the importing data file and point to locations within the project structure.
 
 However the most stable and recommended way is to use the **Python Path/module search path** to import them.
 That path needs to be defined when executing Robot Framework but can lead to more uniform and stable imports, because each suite or resource file can use the same path to import the same resource file or library, independent of the location of the importing suite or resource file.

website/docs/chapter-03/03_user_keyword.md

@@ -157,7 +157,7 @@ Understand the purpose and syntax of the [Arguments] setting in User Keywords.
 User Keywords can accept arguments, which make them more dynamic and reusable in various contexts.
 The `[Arguments]` setting is used to define the arguments a user keyword expects.
 
-See also Chapter 2 [2.5.2 Keyword Arguments](chapter-02/05_keyword_interface.md#252-keyword-arguments) for an introduction to argument kinds.
+See also [2.5.2 Keyword Arguments](chapter-02/05_keyword_interface.md#252-keyword-arguments) for an introduction to argument kinds.
 
 Arguments are defined by `[Arguments]` followed by the argument names separated by multiple spaces in the syntax of scalar variables.
 
@@ -400,7 +400,7 @@ However, this behavior can be used to conditionally end a keyword execution earl
 
 The `RETURN` statement of a keyword cannot return the returned value from a called keyword directly like in other programming languages.
 The return value must be stored in a variable first and then be returned by the `RETURN` statement.
-So the first keyword is **invalid** while the second **valid** is!
+So the first keyword is **invalid** while the second is **valid**!
 
 ```robot title="invalid"
 *** Keywords ***