# Translations

# Introduction

So what is a translation?
A translation in Triton can be either text or a sign group. It represents a single message that can be sent in different languages.

If you're using local storage, translations live in the translations folder. Otherwise, they'll live in the translations table/collection in your database.

Each translation must be placed inside a collection, which is a group of translations. Collections provide a better way to organize translations and to apply settings in bulk.

When adding, removing or editing translations, you can manually edit the JSON files or use TWIN (recommended).

# Managing Collections

Before you can add translations, you must have, at least, one collection.
Triton generates the default collection for you automatically, but you can rename it or create other collections.

# Deleting a collection

Deleting a collection is also very easy to do, just follow the instructions for your preferred method:

# Managing translations

All translations must have a key field.
For text translations, this field is used in placeholders.
For sign translations, this field is used in the sign command.

# Text Translations

All text translations are required to have the following fields: type, key and languages. The type field is automatically set on TWIN by selecting the text type.
Meanwhile, the languages field is where you'll define the actual translations for each language.

# Using variables

Using variables might be useful, for example, if you need to translate a message like "Player1 has killed Player2" and you want replace Player1 and Player2 with the actual player names. To use variables, you must place %1, %2, %3, etc where you want variables to be inserted. You can also repeat a variable various times if it appears in the message more than once (e.g. %1 has killed %2. %1 is awesome!).

These variables will later be replaced by their actual value passed through the Triton Placeholder's arg tag.

Example:

# Using JSON chat components

REQUIREMENTS

This feature requires Triton v3.1.0 or newer.
Understanding of the Minecraft JSON Text Format (opens new window) is also required.

Since Minecraft 1.7, the game has supported rich text through JSON chat components. This allows you to add custom click and hover actions as well as natively translated text using Minecraft's own locales.

Because of this, it might be useful to output JSON text in some situations. To to that, simply prepend [triton_json] to the translation text. You can also place variables in the JSON text, but keep in mind they aren't escaped.

Example:

[triton_json]{"translate":"gameMode.changed","color":"gold","bold":true,"with":[{"text":"%1"}]}

Right now, there is no TWIN support for this feature, so you have to write the above in the respective language. In the future, a button to switch between text and JSON modes will be added, which will insert [triton_json] automatically.

# Using Kyori's MiniMessage

REQUIREMENTS

This feature requires Triton v3.5.1 or newer and PaperMC (or a fork).
Understanding of the MiniMessage Format (opens new window) is also required.

Kyori's MiniMessage library allows to easily add click and hover actions as well as HEX colors codes (along with legacy colors). This makes it much easier to use HEX Colors, which would be complicated using md5's chat library.

Because of this, it might be useful to output parsed MiniMessages in some situations. To to that, simply prepend [minimsg] to the translation text. You can also place variables in the MiniMessage text.

Example:

[minimsg]<#006fff>PVP: <gold>%1</gold> has been killed by <#6100e9>%2

# Using PlaceholderAPI

REQUIREMENTS

This feature requires Triton v3.7.0 or newer.

You can simply use any PlaceholderAPI placeholder inside the translation and it will be replaced accordingly.

Example:

Welcome, %player_name%!

# Sign Translations

Also known as Sign Groups, these can be used to translate signs.

# Available Fields for Translatable Items

TWIN abstracts this complexity, but if you want to edit the JSON files manually, you might need know what each field does. Here is a full list of supported fields:

# type

required
Type: String Enum
Possible Values: text, sign
This parameter defines the remaining structure of the item.

# key

required
Type: String
If type is text, this will be used to match the in-game placeholders.
If type is sign, this will be used to match this Sign Group when using /triton sign.

# languages

required for text
Type: JSON Object (contains strings)
Example:

{
  "en_GB": "Your text in English here.",
  "pt_PT": "Your text in Portuguese here."
}

Holds the text in each language.

# lines

required for sign
Type: JSON Object (contains string arrays)
Example:

{
  "en_GB": ["line1_EN", "line2_EN", "line3_EN", "line4_EN"],
  "pt_PT": ["line1_PT", "line2_PT", "line3_PT", "line4_PT"]
}

Holds the sign lines in each language.

# locations

required for sign
Type: JSON Array of Locations
Example:

[
  {
    "world": "world",
    "x": 33,
    "y": 68,
    "z": 291
  },
  {
    "world": "world",
    "x": 33,
    "y": 67,
    "z": 291
  }
]

Represents which signs are in this Sign Group.

If you're using BungeeCord, you must also include a server parameter in each location, like this:

{
  "server": "lobby",
  "world": "world",
  "x": 33,
  "y": 68,
  "z": 291
}

# patterns

optional | text only
Type: String (regex) array
Default: []
If any of the regex strings in this array matches a message (everywhere except scoreboards), it will be replaced with the translation.

# servers

optional | text only | BungeeCord only
Type: String list
Default: empty list
Example: ["lobby-1", "lobby-2", "lobby-3"]
If blacklist is false, represents the servers where this item is available.
Otherwise, this represents the servers where this item is not available.

# blacklist

optional | text only | BungeeCord only
Type: Boolean (true or false)
Default: true
If enabled, turns servers into a blacklist instead of a whitelist.