fix: keep the same with original docs

MC-XiaoHei · MC-XiaoHei · commit c62a2f0bb89b · 2024-12-08T19:34:14.000+08:00
diff --git a/docs/en/create-commands/arguments/command-arguments.md b/docs/en/create-commands/arguments/command-arguments.md
@@ -238,7 +238,7 @@ Here, we don't actually want to cast the argument, so we use unsafe arguments to
 
 ## Access safe arguments
 
-:::warning **Developer's Note:**
+:::danger **Developer's Note:**
 
 The following methods can’t be used to access a value returned by a `CustomArgument` as its return type depends on the base argument for it.
 
diff --git a/docs/en/create-commands/arguments/suggestions/string-suggestions.md b/docs/en/create-commands/arguments/suggestions/string-suggestions.md
@@ -69,7 +69,7 @@ We can then use this to generate our suggested list of friends:
 
 The `strings(Function<SuggestionInfo, String[]>)` method can also suggest arguments based on the values of previously inputted arguments, using the `previousArgs()` method in `SuggestionInfo`. This `previousArgs()` method returns a **list of previous arguments** which are parsed exactly like any regular CommandAPI command argument.
 
-:::warning
+:::danger
 
 The ability to use previously declared arguments _does not work via redirects_. This means that any command that comes before it that leads into a command that uses suggestions depending on previous arguments will not work. For example, if we had a command `/mycommand <arg1> <arg2> <arg3>` and ran it as normal, it would work as normal:
 
diff --git a/docs/en/create-commands/arguments/types/literal/literal-arguments.md b/docs/en/create-commands/arguments/types/literal/literal-arguments.md
@@ -26,7 +26,7 @@ It consists of a gamemode, followed by an optional player argument. The list of
 
 Unlike regular commands (as those implemented by Bukkit for example), these four options are "hardcoded" - they're not "suggestions". The user can _only_ enter one of these four examples, no other values are allowed.
 
-:::warning Developer's Note:
+:::danger Developer's Note:
 
 There is a simpler alternative to the `LiteralArgument` class! Instead of having to deal with arguments not being present in the array of arguments, consider using the much more intuitive `MultiLiteralArgument`, which is described in more detail [here](./multiliteral-arguments)!
 
diff --git a/docs/en/create-commands/arguments/types/literal/multiliteral-arguments.md b/docs/en/create-commands/arguments/types/literal/multiliteral-arguments.md
@@ -14,7 +14,7 @@ Now forget all of that. Multi literal arguments are the same as literal argument
 
 The multi literal argument has all of the same benefits of a regular literal argument - they are hardcoded options that the user must enter – they don't allow other values.
 
-:::warning Developer's Note:
+:::danger Developer's Note:
 
 For 9.1.0, all previously existing `MultiLiteralArgument` constructors have been deprecated! They will be removed in a future version.
 
diff --git a/docs/en/create-commands/arguments/types/misc/biome-arguments.md b/docs/en/create-commands/arguments/types/misc/biome-arguments.md
@@ -12,7 +12,7 @@ authors:
 
 In Minecraft 1.16, they added the ability to refer to in-game biomes. The CommandAPI implements this using the `BiomeArgument`. As expected, this returns Bukkit's `Biome` enum when used.
 
-:::warning
+:::danger
 
 When using the `Biome` object, the CommandAPI will return `null` if the specified `Biome` could not be found, for example if a player submitted a biome from a client-side resourcepack. The CommandAPI does **not** return `Biome.CUSTOM` from the `BiomeArgument`.
 
diff --git a/docs/en/create-commands/arguments/types/misc/particle-arguments.md b/docs/en/create-commands/arguments/types/misc/particle-arguments.md
@@ -207,7 +207,7 @@ The particle argument requires additional data for a particle depending on what
 
 Because certain particles (in the table above) require additional data, it is not recommended to spawn a particle without its corresponding data. This can result in particles not showing due to missing requirements.
 
-::::warning Example - Show particles at a player's location (without data)
+::::danger Example - Show particles at a player's location (without data)
 
 Say we wanted to have a command that displayed particles at a player's location. We will use the following command syntax:
 
diff --git a/docs/en/create-commands/arguments/types/misc/sound-arguments.md b/docs/en/create-commands/arguments/types/misc/sound-arguments.md
@@ -22,13 +22,13 @@ new SoundArgument("sound");
 new SoundArgument.NamespacedKey("sound");
 ```
 
-:::warning
+:::danger
 
 When using the `Sound` object, the CommandAPI will return `null` if the specified `Sound` could not be found. For this reason, it's recommended to use the `NamespacedKey` object for optimal compatibility with client-side resourcepacks.
 
 :::
 
-::::tip Example - Playing sound to yourself
+::::tip Example – Playing sound to yourself
 
 Say we want a simple command that plays a specific sound at your location. To do this, we will make the following command:
 
diff --git a/docs/en/create-commands/unregistration.md b/docs/en/create-commands/unregistration.md
@@ -207,7 +207,7 @@ Finally, `unregisterNamespaces` should be `false`, and since that's the default
 
 With this code, `/gamemode` will execute as normal, but `/minecraft:gamemode` will give the unknown command message.
 
-::::warning Developer's Note:
+::::danger Developer's Note:
 
 Doing the opposite action here -- only unregistering `/gamemode` but keeping `/minecraft:gamemode` -- is not recommended. That would be the following code, where `commandName` is `"gamemode"` (or any command in the Vanilla CommandDispatcher), and `unregisterNamespaces` is `false`:
 
diff --git a/docs/en/user-setup/config.md b/docs/en/user-setup/config.md
@@ -163,7 +163,7 @@ Controls whether the CommandAPI should use the latest NMS implementation for com
 
 This setting can be used to run the CommandAPI on Minecraft versions higher than it can support. For example, if the CommandAPI supports Minecraft 1.18 and Minecraft 1.18.1 comes out, you can use this to enable support for 1.18.1 before an official CommandAPI release comes out that supports 1.18.1.
 
-::: warning
+:::danger
 
 This feature is very experimental and should only be used if you know what you’re doing. In almost every case, it is better to wait for an official CommandAPI release that supports the latest version of Minecraft. Using `use-latest-nms-version` is _not_ guaranteed to work and can cause unexpected side effects!
 
@@ -187,7 +187,7 @@ Controls whether the CommandAPI should be more lenient when updating to a new Mi
 
 Similar to the [`use-latest-nms-version`](#use-latest-nms-version) setting, this can allow the CommandAPI to run on a version higher than it officially supports. As an example, this setting can allow updating to 1.21.2 from 1.21.1 but doesn't allow updating to 1.22 from 1.21.2.
 
-::: warning
+:::danger
 
 Take the warning from the [`use-latest-nms-version`](#use-latest-nms-version) and apply it here too. This is _not_ guaranteed to work either and also may cause unexpected side effects.
 
