Translating your content

The localization system covers the plugin’s own messages. This page covers the other half: the content you author. Contract titles and descriptions, category names and descriptions, objective and reward text, and preset display names can all carry per-language translations, stored right in your data files.

Default content is English only

All default content is written in English and is not translated on purpose to reduce the file size and maintenance burden for newcomers. If you want to translate the default content without too much effort, you can do so by dumping the data files to an LLM of your choice and asking it to translate them. (point them to this page to explain the translation format and fallback behavior)

The Translations page

The web editor has a Translations page in the sidebar that collects the text you have written in one place, so you can see what is missing and fill the gaps without digging through your data files. The sections below explain the JSON it writes and how the fallback works, which you only need to read if you edit the files by hand or feed them to an LLM.

• Fields are grouped by content type (contracts, objectives, rewards, categories, presets, custom rewards), in the same order as the rest of the editor. Each group shows how many translations are missing.
• A field you left empty is not listed, because there is nothing to translate. Most rewards have no title or description of their own, so the rewards group is usually short. Write the title on the reward’s own page and it shows up here.
• Type in the Filter by name box to narrow the groups you have open. It matches item and field names, not the text itself.
• The Missing only switch is on by default, so the page only shows fields with a missing translation. Turn it off to see the ones you have already done. The list only updates when you change the filter or the switch, so a field you just finished does not jump away while you work.
• Each field shows its authored text next to one input per language. Type the translation and it saves when you leave the input. To change the authored text itself, click the item’s name, it links to the item’s own page.
• Add language starts a new language: type a code like ru and every field shows an empty input for it. The language becomes part of your config once you save the first translation in it.

On the Lite edition, custom item names on rewards show the usual premium badge. A custom reward’s unit label can only be translated when its command uses {amount}, and the page says so on rewards where it doesn’t.

How it works

Every content text field has a matching *Translations sibling: title has titleTranslations, description has descriptionTranslations, a category’s name has nameTranslations, and a preset’s displayName has displayNameTranslations. Each one maps a language code to the translated text, or is null when there are no translations:

{
  "title": "Big Game Hunter",
  "titleTranslations": {
    "fr": "Chasse au gros gibier",
    "es": "Cazador de caza mayor"
  },
  "description": "Take down the island's most dangerous predators.",
  "descriptionTranslations": null
}

When a player opens the menu, each field resolves independently:

1. Look up the player’s language in the field’s translations, matching the language code case-insensitively.
2. If there is no entry for that language, or the entry is blank, show the authored field instead.

There is no region fallback: a player on zh-CN gets the zh-CN entry or the authored text, never a zh entry. The player’s language is the one their framework tracks, the same one used for message localization.

The authored text has no language

The plain field (title, description, name, displayName) is not “the English text”. It is the fallback every player without a matching translation sees, in whatever language you wrote it. If you author your content in French, French is the fallback and an en entry is just another translation. Write the authored text in the language most of your players speak, then add translations for the rest.

Like message localization, partial coverage is fine. A missing or blank entry falls back per field, so you can translate the contracts that matter first and finish over time.

Preset display names

Presets carry a displayName that requirement chips show instead of the raw key, and it is the translatable part. The key stays the identifier that @ references resolve against, so renaming what players see never breaks your contracts. See Presets for the full shape.