Language Keys
How EssentialsC's MiniMessage-based localization system works, and how to customize it.
Overview
Every player-facing message in EssentialsC is stored as a language key - a dotted identifier like heal.success or error.no_permission - mapped to a MiniMessage formatted string. Instead of building text in code, commands ask the LanguageManager for a key, and it resolves the right wording, color, and locale for whoever is reading it.
Resolution happens per message, per sender. Two players running the same command at the same time can each see their own language without either one configuring anything.
Key Format & Placeholders
Keys are grouped by the feature they belong to, using the module or command name as a prefix - heal.*, kit.*, home.*, error.*, tpa.*, and so on. A command usually owns a small cluster of keys covering its success, failure, and usage messages.
Values can contain two kinds of tags:
- MiniMessage formatting - things like
<color:#FFF200>,<b>, or<reset>, which control how the text looks. - Placeholders - plain
<name>tokens that get swapped for real data, like<player>or<amount>.
Placeholders are filled in with a literal text substitution, not a full MiniMessage parse - so a placeholder only gets replaced if its name matches exactly what the command passed in, including case. A typo like <Player> instead of <player> will print as-is instead of being replaced.
Example
"heal.success.by": "<prefix> <color:#FFF200>You have been healed by <color:#FFFFFF><healer></color></color>"
That key is requested in code with a placeholder map, and the result is what the player sees:
<prefix> is a special tag, not a placeholder you pass in. After every other placeholder is filled, EssentialsC automatically swaps <prefix> for the value of the file's own prefix key, so it's available in every message for free.
Supported Languages
EssentialsC ships a complete translation for each of these locales. en_US is the default and acts as the final fallback if a key or an entire locale is missing.
Switching Language
Players choose their own language with /language. It needs no permission and can only be run by players, since console always uses the server default.
| Subcommand | Description |
|---|---|
| /language | Shows your current language and lists every available code |
| /language set <code> | Switches your language to the given locale code |
| /language reset | Clears your override and returns to your client's auto-detected locale |
| /language list | Lists every bundled language code |
| /language help | Shows language command help |
/language set, EssentialsC reads the locale Minecraft reports for that player's client and uses it automatically - no setup required for players who already have their game in their own language.
Customizing Translations
Each locale lives at plugins/EssentialsC/lang/<code>.json, extracted from the plugin jar the first time that locale is needed. Open the file for the language you want to change, and edit the text - just leave the key names and any <placeholder> tokens exactly as shipped, since code looks them up by that exact name.
Apply changes with /essc reload (requires essentialsc.admin). It reloads every language file along with the rest of the config, no restart needed.
Fallback Order
If a key can't be found, EssentialsC steps down through a fallback chain before giving up:
The player's chosen language (/language set), or their client's detected locale if they haven't set one
The fallback-language set in config.yml
The default-language set in config.yml
A built-in "missing key" message, so a typo never crashes a command
Both default-language and fallback-language default to en_US and accept any of the codes listed above.