Localization

Pretty much all significant messages in UnderscoreEnchants are configurable, and thus translatable. Locales are stored in the messages subfolder in the plugin's data folder as JSON files. By default, the English and Russian translations are bundled with the plugin. Here is a snippet of the en_US.json locale file:

{
  "identifier": "en_US",
  "messages": {
    "tokens": {
      "yes": "yes",
      "no": "no"
    },

    "start-messages": {
      "word-tokens": {
        "started": "Started <action>.",
        "finished": "Finished <action>. Took <ms>ms."
      },

      "process": {
        "populating-registry": "populating the registry",
        "initializing-connection": "initializing the connection data",
        "initializing-data": "initializing the data storage",
        "preparing-metrics": "preparing the bStats metrics",
        "checking-updates": "setting up the update checker",
        "creating-tasks": "creating the tasks",
        "registering-listeners": "registering the listeners",
        "initializing-commands": "initializing the commands",
        "initializing-economy": "initializing the economy handler",
        "registering-enchantments": "registering the enchantments",
        "adding-readme": "adding README if necessary",
        "implementing-api": "implementing the API",
        "starting-retrofit": "starting Retrofit for networking"
      },
      ...

The identifier part is used internally and in commands like /ue locale en_US. Everything inside of the messages section is simple messages.

Tip

The sections separating the messages inside the main messages node are purely for readability. The snippet above is functionally equivalent to the following snippet:

{
  "identifier": "en_US",
  "messages": {
    "yes": "yes",
    "no": "no",
    "started": "Started <action>.",
    "finished": "Finished <action>. Took <ms>ms.",
    "populating-registry": "populating the registry",
    "initializing-connection": "initializing the connection data",
    "initializing-data": "initializing the data storage",
    "preparing-metrics": "preparing the bStats metrics",
    "checking-updates": "setting up the update checker",
    "creating-tasks": "creating the tasks",
    "registering-listeners": "registering the listeners",
    "initializing-commands": "initializing the commands",
    "initializing-economy": "initializing the economy handler",
    "registering-enchantments": "registering the enchantments",
    "adding-readme": "adding README if necessary",
    "implementing-api": "implementing the API",
    "starting-retrofit": "starting Retrofit for networking"
    ...

If you want to fine-grain a localization file, just edit the messages inside of an existing one. However, if you want to create a new translation, either for yourself or for the whole world to use, you can copy en_US.json and translate it. (1)

1. Ideally you translate either en_US.json, because it is ultimately the source of truth when it comes to localisation. The English messages are the original messages, and everything else is a result of a translation, thus it is subject to losing or changing the original meaning to better express it in the target language. But this is just a guideline, and nothing stops you from translating based on another translation.

Note that some messages have placeholders, for example:

"finished": "Finished <action>. Took <ms>ms."

In this message, <action> and <ms> are placeholders. They will change their value depending on the context and will be replaced at runtime. Make sure to preserve each and every placeholder in all of your messages in order to not lose context and meaning.

Warning

Please note that this localization system is experimental. The format of the message files might be changed at any time. If that happens, the plugin will be able to convert your old files to the new format.