Configuring

Languages

Spanish ships with the plugin. messages_es.yml is written out on the first start.

# config.yml
language:
  default: es

/chorus reload, and the whole server speaks Spanish.

How it works#

A language is a file called messages_<code>.yml next to messages.yml. The code is whatever you want to call it, and it is the same code you put in the config.

plugins/ChorusCore/
├── messages.yml       English, and the fallback for everything
├── messages_es.yml    Spanish, shipped
├── messages_fr.yml    French, if you write one
└── messages_pt.yml    Portuguese, if you write one

A translation only writes down what it translates#

This is the part worth understanding, because it is what makes translations survive updates.

# messages_fr.yml — a perfectly valid translation
prefix: '<gradient:#a06bff:#e0c3fc><bold>Chorus</bold></gradient> <dark_gray>|</dark_gray> '

home:
  created: '%prefix%<gray>Maison <white>%home%</white> enregistrée.'
  deleted: '%prefix%<gray>Maison <white>%home%</white> supprimée.'

Every line it leaves out comes from messages.yml. A file with forty lines in it is a server that speaks forty lines of French and English for the rest — never a server with forty holes in it.

That is also what lets a translation survive an update that adds twenty new messages: the new ones are English until somebody gets round to them, and nothing breaks in the meantime.

A translation may also leave out prefix, and then it borrows the English one. A line it writes as '' is silenced in that language only.

Per-player languages#

language:
  default: es
  per-player: true

Each player is sent the file matching their own Minecraft language, falling back to default when there is no file for it. A player with their client in French gets messages_fr.yml if it exists; everybody else gets Spanish.

The console always reads default.

A broadcast is rendered once per language rather than once per player, so a server with a hundred players and three languages costs three parses, not a hundred.

Writing one#

Copy messages.yml to messages_<code>.yml.
Translate the lines you care about.
Delete the rest. A line you did not translate is better absent than left in English inside the translation, because absent means it follows the English file when that file changes.
/chorus reload.

The startup banner says which languages were found.

What not to bother translating#

Lines that are pure decoration — separators, a header that is nothing but a %placeholder%, a line of ▪ characters. There is nothing in them to translate, and leaving them out keeps the file to the part that matters. The shipped Spanish file does exactly that: 892 of the 947 keys.

Rules for the values#

Keep every %placeholder%. A renamed one leaves a gap where the number should be.
Keep the colour tags, or change them deliberately. They are not part of the translation but they are part of the line.
Both MiniMessage and &-codes work, the same as in English.

What the build checks#

A translation that ships inside the jar is checked when the plugin is built: every key it uses has to be a real one, every line has to be valid MiniMessage, and every %placeholder% in it has to exist in the English line it replaces.

Your own files are not checked that way — they are read at runtime. A key that is not real is ignored, and a line with a broken tag is sent as written.

Spanish#

messages_es.yml is complete for everything a player sees — 892 of the 947 keys, the missing ones being the decoration described above. It was written as a translation rather than a machine pass: /sethome says casa and not hogar, and the tone matches the English.

Money is written the same way in every language. The symbol, which side it goes on and how many decimals are in the currency block of config.yml; the separators themselves are always 1,000.00 and are not configurable. A translation cannot change that, and should not try to by writing the amount into the message itself.

If you want it different, edit it. The file is yours once it is written out — the plugin never overwrites it.