Messages and colours

Every line the plugin sends lives in messages.yml. There are no hardcoded strings in the code, which is what makes a full translation possible.

The file#

prefix: '<gradient:#a06bff:#e0c3fc><bold>Chorus</bold></gradient> <dark_gray>|</dark_gray> '

error:
  no-permission: '%prefix%<red>You are not allowed to do that.'
  player-not-found: '%prefix%<red>%player% is not online.'

home:
  created: '%prefix%<gray>Home <white>%home%</white> saved.'
  deleted: '%prefix%<gray>Home <white>%home%</white> deleted.'

The sections, in the order they appear:

The rule for finding a key: anything starting with menu. is in menus.yml, everything else in messages.yml.

Silencing a line#

A message set to '' is not sent at all.

cooldown:
  waiting: ''

That is the way to take a line out — deleting the key gives you the shipped English one back, since a missing key falls through to the default.

Colours#

Every line the plugin writes takes MiniMessage tags and the old &-codes, in the same line if you like. That includes kit names, item lore, warp descriptions, motd.txt and info.txt.

'&c&lRed Bold'
'<red><bold>Red Bold'
'&6Gold and <gradient:#1f8f8c:#3fb8b4>a gradient'

Both hex spellings work as well: &#a1b2c3, and &x&a&1&b&2&c&3 the way the old proxies wrote it.

A colour code clears the formatting before it, exactly as it does in vanilla, so &l&cText comes out red and not bold. A doubled && writes the character itself, for a line that needs to talk about a code without becoming one.

The full tag list is in the MiniMessage documentation. The ones that come up:

Placeholders#

Each message has its own, written %like_this%. The shipped file shows which ones a line takes; a placeholder that does not belong to that message is left as written.

home:
  created: '%prefix%<gray>Home <white>%home%</white> saved.'
  limit: '%prefix%<red>You already have <white>%count%</white> of <white>%limit%</white> homes.'

Values are put in as text, never as formatting. A player whose home is called <red> sees those five characters, not a colour — and the same goes for &-codes. Nobody can write their way into looking like somebody else, or into a clickable link.

Item names and lore#

Item names and lore are not quietly italicised the way the game does it by default, and a line of lore that names no colour is drawn grey rather than the purple the game falls back to.

Neither is written into your file. What you type is stored exactly as you typed it, the styling happens when the line is drawn, and an editor screen shows you the plain text back.

This applies to /itemname and /lore too, which take either format from anyone holding chorus.items.format.

A note on bold#

Bold is for a heading, not for a value. A name that comes out of the data — a player, a home, a warp, an item — is written in white against grey rather than in bold, because a bold word in the middle of a sentence reads as shouting. The shipped messages follow that; yours do not have to.

Changing a message#

1. Edit messages.yml.
2. /chorus reload.

Keep the key. Change the value. A key that is not one the plugin knows is ignored, and a key you delete comes back as the shipped English line on the next read — which is a safe way to undo a change you no longer like.

Translating rather than editing? See Languages: a translation is a separate file, so an update never overwrites your work.