Almost everything in Fzzy Config is automatically translatable. Translation is not strictly required, but strongly recommended for better user experience.

Concept

Translation in Fzzy Config is driven by the Translatable 🗗 interface or the @Translation annotation.

Translatable

Translatable objects accept a matched triad of keys:

The below image showcases all three translations. The Prefix is the text at the top, the title is on the left, and the description is shown in the tooltip.

The following support these keys:

• Config Entries (including automatic validation of "plain" values)
• Config Classes 🗗
• Config Sections 🗗
• Config Actions 🗗
• Config Groups 🗗

So almost every piece of your config will automatically support translation, tooltips, and inline descriptions! If there is something that isn't captured, implement Translatable or use @Translation on that escapee.

Notes regarding translations:

• Prefixes often won't be rendered outside the normal config GUI list.
• Both prefixes and descriptions will be narrated, prefix and then description.
• If you prefix a config, the prefix will appear both in the config landing page (if applicable) and at the top of the settings list as a "header".

@Translation

If you want to override default translations, or provide translations without implementing Translatable, you can use the @Translation annotation.

This annotation is useful for repeating parts. If you have a config object that repeats, normally you would have to provide a translation for every setting. @Translation allows you to define one common lang key for all instances of the annotated field.

Fallbacks

If not provided with translations, Fzzy Config will do it's best to provide fallbacks where possible.

• Fields will use the capitalized and split-by-word field name: myValidatedField to My Validated Field
• Sections will be named by the field the section is stored in.
• Configs will use the simple class name split by words: ItemsConfig to Items Config.
• Descriptions and prefixes are blank by default.
• If a field is annotated with @Comment or @TomlComment, it will be used as the fallback tooltip description.

Example

//fields and sections have lang keys based on their "location" in the Config class graph.
//Lang key composition is as follows
//1. the namespace of the config id: (my_mod)
//2. the path of the config id: (my_mod.my_config)
//3. any parent ConfigSection field names as declared in-code: (my_mod.my_config.subSection)
//4. the setting field name as declared in-code: (my_mod.my_config.subSection.fieldName)
{
  "_comment1": "the lang for an example 'fieldName' setting in a config inside section 'subSection'",
  "my_mod.my_config.subSection.fieldName": "Very Important Setting",
  "my_mod.my_config.subSection.fieldName.desc": "This very important setting is used in this very important way."
  "my_mod.my_config.subSection.fieldName.prefix": "Here is some introductory information about this very important setting that you can see in the GUI above the setting itself."
}

EnumTranslatable

Enums can implement a sub-interface of Translatable, EnumTranslatable 🗗. This interface provides translation methods for each enum constant.

Prefix

The primary method to override in EnumTranslatable is prefix(). Per the documentation, enum translations are in the form <prefix>.CONSTANT, <prefix>.CONSTANT.desc, <prefix>.CONSTANT.prefix.

// this enum will have a translation key like "my_mod.test_enum.ANNIE" etc.
public enum TestEnum implements EnumTranslatable {
    ANNIE, // "my_mod.test_enum.ANNIE": "Annie"
    BILBO, // "my_mod.test_enum.BILBO": "Mr. Baggins"
    CODY; // "my_mod.test_enum.CODY": "Cody"

    @NotNull
    @Override
    public String prefix() {
        return "my_mod.test_enum";
    }
}