ConfigurationEngine

EliteMobs' translatable extension of MagmaCore's configuration engine.

Registering a translation must never mutate the configuration Between 10.0.1 and 10.7.x setString and setList ran fileConfiguration.set(key, null) on non-English servers, so translated text would only be served from translations/<language>.csv. The identical strip in CustomConfigFields.translatable caused real, permanent data loss once MagmaCore's CustomConfig#initialize(File) started calling ConfigurationEngine#fileSaverCustomValues after parsing (MagmaCore 2db8d8e, 2026-06-21): the in-memory deletion became a disk write, and the first boot on a translated server erased text out of every downloaded content package.

The strip here was assumed to be survivable because these callers pass a Java-side defaultValue that is recreated on every boot. That was true of 914 of the 916 translatable call sites and false of the two that matter:

• CustomBossesConfigFields#processConfigFields registers onKillMessage with a null default, and every content-package boss reaches it through CustomConfig#initialize(File) - the save path that writes back to the user's YAML. There is no Java-side source for that text, so the strip deleted it permanently; the next boot read null and returned null.
• setItemStack registers <key>.lore with a null default because its own addDefault calls used to be English-gated, leaving the lore of every menu button with no fallback outside the CSV.

Both are fixed by not mutating: registration is now identical on English and translated servers, and the source text stays in the YAML exactly as it does in English. Keeping the key cannot clobber a translation - reconciliation in TranslationsConfigFields only ever writes the en column, never the language column - and the value these methods return is still the translated one.

Do not reintroduce the strip. Anything that removes a key here is one MagmaCore save-path change away from deleting user content again.