Revert unnecessary changes

Author: DerEchtePilz

docs/en/annotations/annotations.md

@@ -52,17 +52,17 @@ To use annotations on methods, **methods must be static**.
 
 ### `@Default`
 
-The `@Default` annotation indicates that the method is _not_ a subcommand. This acts similarly to regular Bukkit commands. Commands with the `@Default` annotation can be used to run the main code when the command named with the `@Command` annotation is stated, such as the following:
+The `@Default` annotation indicates that the method is _not_ a subcommand. This acts in a similar way to regular Bukkit commands. Commands with the `@Default` annotation can be used to run the main code when the command named with the `@Command` annotation is stated, such as the following:
 
 <<< @/../reference-code/src/main/java/annotations/DefaultMethodExample.java#defaultMethodExample
 
-The `@Default` annotation doesn’t mean that the command can't have arguments! Arguments can still be used and declared as shown:
+The `@Default` annotation does not mean that the command can't have arguments! Arguments can still be used and declared as shown:
 
 <<< @/../reference-code/src/main/java/annotations/DefaultMethodExample.java#defaultWithArgsMethodExample
 
 ### `@Subcommand`
 
-The `@Subcommand` simply tells the CommandAPI that the declared method is a subcommand. This acts similarly to the regular CommandAPI's `.withSubcommand()` method. The subcommand annotation can take in a single string which is the name of the subcommand:
+The `@Subcommand` simply tells the CommandAPI that the declared method is a subcommand. This acts in a similar way to the regular CommandAPI's `.withSubcommand()` method. The subcommand annotation can take in a single string which is the name of the subcommand:
 
 <<< @/../reference-code/src/main/java/annotations/SubcommandMethodExample.java#subcommandMethodExample
 
@@ -119,6 +119,6 @@ For the `@ALiteralArgument` annotation, the parameter is the literal to be used
 
 #### Other arguments
 
-The `LocationArgument`, `Location2DArgument`, `EntitySelectorArgument` and `ScoreHolderArgument` can all take an extra parameter in their constructors. As a result, the annotation-equivalent of these arguments also allows you to provide the parameter in the annotation:
+The `LocationArgument`, `Location2DArgument`, `EntitySelectorArgument` and `ScoreHolderArgument` can all take an extra parameter in their constructors. As a result, the annotation-equivalent of these arguments also allow you to provide the parameter in the annotation:
 
 <<< @/../reference-code/src/main/java/annotations/ParameterExample.java#otherParameterExample

docs/en/annotations/intro.md

@@ -6,14 +6,14 @@ authors:
 
 # Annotation-based commands
 
-The CommandAPI also includes a tiny lightweight annotation-based command framework. This works very differently compared to previous commands shown in this documentation, and **it is less feature-rich than registering commands using the other methods.**
+The CommandAPI also includes a very small lightweight annotation-based command framework. This works very differently compared to previous commands shown in this documentation, and **it is less feature-rich than registering commands using the other methods.**
 
 In short, the CommandAPI's annotation-based system:
 
-- It Has no runtime overhead compared to using the regular command registration system (unlike other annotation-based frameworks such as [ACF](https://github.com/aikar/commands)).
+- Has no runtime overhead compared to using the regular command registration system (unlike other annotation-based frameworks such as [ACF](https://github.com/aikar/commands)).
 - Reduces code bloat (to an extent).
 - Improves readability since commands are declared declaratively instead of imperatively.
-- It Is not as powerful as the regular command registration system.
+- Is not as powerful as the regular command registration system.
 
 :::info
 
@@ -49,7 +49,7 @@ Seems fairly straightforward, given everything else covered in this documentatio
 
 ### Warp command (with annotations)
 
-I think it's best to show the example and explain it afterward:
+I think it's best to show the example and explain it afterwards:
 
 <<< @/../reference-code/src/main/java/annotations/WarpCommand.java#annotationsExample
 
@@ -68,9 +68,9 @@ The annotation framework is designed in such a way that an entire command is rep
 #### Default command
 <<< @/../reference-code/src/main/java/annotations/WarpCommand.java#defaultExample
 
-Here, declare the main command implementation using the `@Default` annotation. The `@Default` annotation informs the CommandAPI that the method it is attached to doesn’t have any subcommands. This is effectively the same as registering a regular command without using `.withSubcommand()`.
+Here, declare the main command implementation using the `@Default` annotation. The `@Default` annotation informs the CommandAPI that the method it is attached to does not have any subcommands. This is effectively the same as registering a regular command without using `.withSubcommand()`.
 
-Here, we simply write what happens when no arguments are run (i.e., the user just runs `/warp` on its own). As such, we don't include any parameters to our method.
+Here, we simply write what happens when no arguments are run (i.e. the user just runs `/warp` on its own). As such, we don't include any parameters to our method.
 
 #### Default command (again!)
 
@@ -82,15 +82,15 @@ We also have a second `@Default` annotated method, which handles our `/warp <war
 new StringArgument("warp")
 ```
 
-It's also crucial to note the parameters for this method. The first parameter is a `Player` object, which represents our command sender. The CommandAPI's annotation system uses the fact that the command sender is a `Player` object and automatically ensures that anyone using the command must be a `Player`. In other words, non-players (such as the console or command blocks), would be unable to execute this command.
+It's also very important to note the parameters for this method. The first parameter is a `Player` object, which represents our command sender. The CommandAPI's annotation system uses the fact that the command sender is a `Player` object and automatically ensures that anyone using the command must be a `Player`. In other words, non-players (such as the console or command blocks), would be unable to execute this command.
 
 The second argument is a `String` object, which represents the result of our argument "warp". The CommandAPI's annotation system can also infer the return type of the argument that is provided to it (in this case, a `StringArgument` will produce a `String`) and will automatically cast and provide the result to that parameter.
 
 #### Subcommand
 
 <<< @/../reference-code/src/main/java/annotations/WarpCommand.java#subcommandExample
 
-Lastly, we declare a subcommand to allow us to run `/warp create <name>`. To do this, we simply use the `@Subcommand` annotation. In this example, we also apply a permission node required to run the command by using the `@Permission` annotation. The rest is fairly straight forward – we declare an argument, in this case it's another `StringArgument` , so we use `@AStringArgument` and then declare everything else in a similar fashion to the default command executor.
+Lastly, we declare a subcommand to allow us to run `/warp create <name>`. To do this, we simply use the `@Subcommand` annotation. In this example, we also apply a permission node that is required to run the command by using the `@Permission` annotation. The rest is fairly straight forward - we declare an argument, in this case it's another `StringArgument` , so we use `@AStringArgument` and then declare everything else in a similar fashion to the default command executor.
 
 #### Registering the command
 

docs/en/contribution/project-structure.md

@@ -10,17 +10,17 @@ The CommandAPI is a relatively large project (especially from the standpoint of
 
 ## CommandAPI submodule folders
 
-This is where all the code is for the CommandAPI. The CommandAPI is a Maven project with multiple modules which each serves a different purpose:
+This is where all of the code is for the CommandAPI. The CommandAPI is a Maven project with multiple modules which each serves a different purpose:
 
-- `commandapi-preprocessor` - The CommandAPI uses a bit of reflection to perform things which couldn’t normally be done (for example, allowing custom commands in datapacks). Reflection is inherently unsafe and can lead to runtime errors if specific fields or methods aren’t present. The CommandAPI preprocessor project is a source annotation processor that checks all declared reflection calls and looks up at compile-time whether those calls are possible - if not, it prevents the CommandAPI from building. In short, it's a compile-time reflection checker.
+- `commandapi-preprocessor` - The CommandAPI uses a bit of reflection to perform things which could not normally be done (for example, allowing custom commands in datapacks). Reflection is inherently unsafe and can lead to runtime errors if specific fields or methods are not present. The CommandAPI preprocessor project is a source annotation processor that checks all declared reflection calls and looks up at compile-time whether those calls are possible - if not, it prevents the CommandAPI from building. In short, it's a compile-time reflection checker.
 
-- `commandapi-x.x.x` - The CommandAPI needs to access various NMS methods to operate. These are implemented for the specific version given by `x.x.x`. For example, to support Minecraft `1.16.5`, the project is `commandapi-1.16.5`. The `NMS` class implementation is done in these version-specific files.
+- `commandapi-x.x.x` - The CommandAPI needs to access various NMS methods in order to operate. These are implemented for the specific version given by `x.x.x`. For example, to support Minecraft `1.16.5`, the project is `commandapi-1.16.5`. The `NMS` class implementation is done in these version-specific files.
 
-- `commandapi-core` - The main brains of the CommandAPI. This includes both the code that makes the CommandAPI run, and the API which developers can use.
+- `commandapi-core` - The main brains of the CommandAPI. This includes both the code that makes the CommandAPI run, as well as the API which developers can use.
 
-- `commandapi-vh` - The CommandAPI version handler. This is a super tiny project that simply links up all the NMS version-specific files into the CommandAPI. This is only used for the actual running of the CommandAPI (e.g., the CommandAPI plugin or shading the CommandAPI). This ensures proper compile-time safety of NMS implementations.
+- `commandapi-vh` - The CommandAPI version handler. This is a super tiny project which simply links up all of the NMS version-specific files into the CommandAPI. This is only used for the actual running of the CommandAPI (e.g., the CommandAPI plugin or shading the CommandAPI). This ensures proper compile-time safety of NMS implementations.
 
-- `commandapi-plugin` - It's the CommandAPI plugin! This is the project used for releases to both GitHub and Spigot. It's the CommandAPI all in one neat package, with a few extra features such as config-based command conversion for server owners (or other non-developers)
+- `commandapi-plugin` - It's the CommandAPI plugin! This is the project which is used for releases to both GitHub and Spigot. It's the CommandAPI all in one neat package, with a few extra features such as config-based command conversion for server owners (or other non-developers)
 
 - `commandapi-shade` - It's the CommandAPI, but in shade-able format. It has none of the features of the CommandAPI plugin variant and can be shaded into your own plugins. Effectively, it's `commandapi-core` + `commandapi-vh` with all of the `commandapi-x.x.x` NMS implementations included.
 

docs/en/create-commands/arguments/arguments.md

@@ -26,7 +26,7 @@ List<Argument> arguments = new ArrayList<>();
 arguments.add(new PlayerArgument("target"));
 ```
 
-The String value is the node registered into Minecraft's internal command graph. This name is also used as a prompt that is shown to a player when they are entering the command.
+The String value is the node that is registered into Minecraft's internal command graph. This name is also used as a prompt that is shown to a player when they are entering the command.
 
 The CommandAPI is very flexible when it comes to registering arguments, and lets you use a number of different methods to suit your preference:
 
@@ -59,7 +59,7 @@ The CommandAPI is very flexible when it comes to registering arguments, and lets
 
 ## Argument Casting
 
-To access arguments, they have to be cast to the type that the argument represents. The order of the arguments in the [`CommandArguments args`](./command-arguments) is the same as the order in which the arguments were declared.
+To access arguments, they have to be casted to the type that the argument represents. The order of the arguments in the [`CommandArguments args`](./command-arguments) is the same as the order in which the arguments were declared.
 
 :::tabs
 ===Java

docs/en/create-commands/arguments/types/command-arguments.md

@@ -12,8 +12,8 @@ authors:
 
 Command arguments allow users to provide an executable server command. The `CommandArgument` class lets you specify:
 
-- Arbitrary commands – any command that the user has permissions to run can be provided.
-- Restricted commands – only specific commands can be provided.
+- Arbitrary commands - any command that the user has permissions to run can be provided.
+- Restricted commands - only specific commands can be provided.
 
 Using the `CommandArgument` will return a `CommandResult`, which contains a Bukkit `Command` instance representing the command to be executed, and a `String[]` of command arguments.
 
@@ -186,7 +186,7 @@ SuggestionsBranch.suggest(
 
 #### Empty suggestions
 
-Empty suggestions that are provided using `ArgumentSuggestions.empty()` tell the `CommandArgument` to stop accepting further suggestions. This "ends" the command. Using the following example, this allows the user to enter `/give diamond` and only `/give diamond` - users can’t enter any other commands.
+Empty suggestions that are provided using `ArgumentSuggestions.empty()` tell the `CommandArgument` to stop accepting further suggestions. This "ends" the command. Using the following example, this allows the user to enter `/give diamond` and only `/give diamond` - users cannot enter any other commands.
 
 ```java
 SuggestionsBranch.suggest(
@@ -203,7 +203,7 @@ These commands are valid:
 /give minecraft:diamond
 ```
 
-These commands aren't valid:
+These commands are not valid:
 
 ```mccmd
 /give

docs/en/create-commands/arguments/types/custom-arguments.md

@@ -8,7 +8,7 @@ authors:
 
 # Custom arguments
 
-Custom arguments are a quality-of-life feature that the CommandAPI offers which allows you to perform pre-processing on an argument in the argument instance rather than in your `executes()` method for a command. They are designed to be used for multiple commands – you can define the argument once and can use it wherever you want when declaring commands.
+Custom arguments are a quality-of-life feature that the CommandAPI offers which allows you to perform pre-processing on an argument in the argument instance rather than in your `executes()` method for a command. They are designed to be used for multiple commands - you can define the argument once and can use it wherever you want when declaring commands.
 
 The `CustomArgument<T, B>` has the following constructor:
 
@@ -18,7 +18,7 @@ public CustomArgument(Argument<B> base, CustomArgumentInfoParser<T, B> parser);
 
 This constructor takes in two parameters:
 
-- A "base argument", which is the argument that it'll use as the underlying parser. For example, if this is a `StringArgument`, it'll use the StringArgument's parsing rules (alphanumeric characters (A-Z, a-z and 0–9), and the underscore character) and if this is a `LocationArgument`, it'll take three numerical values.
+- A "base argument", which is the argument that it'll use as the underlying parser. For example, if this is a `StringArgument`, it'll use the StringArgument's parsing rules (alphanumeric characters (A-Z, a-z and 0-9), and the underscore character) and if this is a `LocationArgument`, it'll take three numerical values.
 
 - A "parser", which lets you process the argument based on its input. This is described in more detail below.
 
@@ -60,7 +60,7 @@ These fields are as follows:
   CommandSender sender();
   ```
 
-  `sender()` represents the command sender typing the command. This is normally a `Player`, but can also be a console command sender if using a Paper server.
+  `sender()` represents the command sender that is typing the command. This is normally a `Player`, but can also be a console command sender if using a Paper server.
 
 - ```java
   CommandArguments previousArgs();
@@ -106,7 +106,7 @@ We can use our custom argument like any other argument. Say we wanted to write a
 /tpworld <world>
 ```
 
-Since we’ve defined the method `worldArgument()` which automatically generates our argument, we can use it as follows:
+Since we have defined the method `worldArgument()` which automatically generates our argument, we can use it as follows:
 
 :::tabs
 ===Java
@@ -117,13 +117,13 @@ Since we’ve defined the method `worldArgument()` which automatically generates
 <<< @/../reference-code/src/main/kotlin/createcommands/arguments/types/CustomArguments.kt#useCustomArgumentsExampleDSL
 :::
 
-By using a `CustomArgument` (as opposed to a simple `StringArgument` and replacing its suggestions), we’re able to provide a much more powerful form of error handling (automatically handled inside the argument), and we can reuse this argument for other commands.
+By using a `CustomArgument` (as opposed to a simple `StringArgument` and replacing its suggestions), we are able to provide a much more powerful form of error handling (automatically handled inside the argument), and we can reuse this argument for other commands.
 
 ::::
 
 ## Message Builders
 
-The `MessageBuilder` class is a class to easily create messages to describe errors when a sender sends a command which doesn’t meet the expected syntax for an argument. It acts similarly to a `StringBuilder`, where you can append content to the end of a String.
+The `MessageBuilder` class is a class to easily create messages to describe errors when a sender sends a command which does not meet the expected syntax for an argument. It acts in a similar way to a `StringBuilder`, where you can append content to the end of a String.
 
 The following methods are as follows: