Almost everything related to Fzzy Config is automatically translatable or otherwise able to be notated. Translation is not strictly required, but strongly recommended for a better user experience.
Concept
Translation in Fzzy Config is driven by the Translatable interface or the @Translation annotation.
Translatable
Translation in most places in Fzzy Config is a matched triad of keys:
- Translation:
my_mod.my_config.my_section.myField
(Name of the element) - Description:
my_mod.my_config.my_section.myField.desc
(tooltip of the element) - Prefix:
my_mod.my_config.my_section.myField.prefix
(Inline introduction of the element, typically presented above it in a GUI, hence the name. This is particularly useful above sections, groups, and other organizational elements to briefly explain what the user will find within)
The below image showcases all three translations in action. The Prefix is the text at the top, the title is on the left, and the description is shown in the tooltip.
The following pieces and parts automatically support these:
- Validation (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 in your config that isn't getting captured, simply implement Translatable
on that escapee.
Some notes regarding translations in practice:
- Prefixes often won't be rendered in popups or other situations outside the normal config GUI.
- Both prefixes and descriptions will be narrated, prefix and then description.
- If you prefix a config, the prefix text will both appear in the config landing page (if applicable) and at the top of the config settings list as a "header".
@Translation
If you want to override the default translation, or provide a translation and description without implementing Translatable
, you can use the @Translation
annotation. This annotation provides a prefix that the annotated field name is appended to. See the Annotations article for details.
This annotation can be very useful for repeating parts. If you have a config object, lets say an entity attributes "chunk", that repeats many times in a config. Normally you would have to provide a translation for every individual setting based on the total classpath. That would get annoying fast. @Translation allows you to define one lang prefix that is common for all instances of the annotated field.
Fallbacks
If not provided with fallbacks, Fzzy Config will do it's best to provide stand-ins where possible.
- Fields will use the Capitalized and split-by-word version of the field name:
myValidatedField
toMy Validated Field
- Sections will similarly fall back to the field the section is stored in.
- Configs will fall back to their simple Class name split by words:
ItemsConfig
toItems Config
- Descriptions and Prefixes are blank by default, to prevent meaningless tooltips
- If a field is annotated with
@Comment
or@TomlComment
, it will be used as the tooltip description if no translation is found
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 special sub-interface of Translatable, EnumTranslatable. This interface provides default methods for creating translations of each enum constant.
Heads up!
This translates the enum constants themselves. The field holding the enum gets its own translation following the rules above
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,BILBO,CODY;@NotNull@Overridepublic String prefix() {return "my_mod.test_enum";}}