Config and Lang Text

Config and Lang Text

This guide exists to make one thing crystal clear:

You do not need keys for normal DaisyCore messages.

The intended order

Use DaisyCore text in this order:

1. direct MiniMessage strings
2. Component values when you want explicit control
3. shared config-backed keys when the plugin already stores text that way

Default path: direct MiniMessage strings

reply("<gradient:#7dd3fc:#c4b5fd>Ready.</gradient>")

player.openMenu("Profile", rows = 3) {
    slot(13) {
        item(Material.PLAYER_HEAD) {
            name("<gradient:#7dd3fc:#c4b5fd>${player.name}</gradient>")
            lore("<gray>Coins: <white>1,250</white>")
        }
    }
}

sidebar {
    title("<gradient:#7dd3fc:#c4b5fd>Profile</gradient>")
}

tablist {
    header("<gradient:#7dd3fc:#c4b5fd>Welcome back</gradient>")
}

That is already the intended modern path.

When config-backed text becomes worth it

Install a shared text source when you want:

• reloadable wording
• one shared source across commands, menus, sidebars, and tablists
• localization
• admin-editable text
• a config-heavy plugin workflow

Preferred ecosystem path: DaisyConfig

The cleanest path now is to let DaisyConfig load text and hand it into DaisyCore, whether that text came from a simple lang.yml or a managed module bundle:

val langHandle = yamlTextConfigHandle(this, "lang.yml")

val daisy =
    DaisyPlatform.create(this) {
        messages(langHandle.current.asDaisyTextSource())
        commands()
        menus()
        scoreboards()
        tablists()
    }

That keeps the product boundaries clean:

• DaisyConfig stores and loads text
• DaisyCore renders it

You do not need the whole suite at once.

• stay in DaisyCore only when local strings are enough
• add DaisyConfig when text becomes shared and reloadable
• add DaisySeries too when config-backed values need canonical parsing

What shared keys look like

replyLang("profile.ready", "player" to player.name)

titleLang("profile.sidebar.title", viewer = player)

headerLang("profile.tablist.header", viewer = player, "player" to player.name)

Those keys are your plugin’s config paths.

They are useful when the plugin is already text-by-config.

They are not required for:

• a hello-world command
• a small menu
• a local sidebar
• a simple tablist

Placeholder-aware rendering stays in DaisyCore

If config-backed text is used in:

• commands
• menus
• sidebars
• tablists

then DaisyCore still owns:

• MiniMessage parsing
• viewer-aware rendering
• PlaceholderAPI integration
• fallback behavior when PlaceholderAPI is absent

That safety boundary does not change just because the text came from config.

Current default

Use direct MiniMessage strings first. Use config-backed text when the plugin wants shared, reloadable, or translatable wording.

Next steps

• Learn the DaisyConfig side of the bridge: Use DaisyConfig with DaisyCore
• See the full intended stack: Build the Normal Stack
• See the full stack together: Full Ecosystem Example
• Jump to runtime text details: Text Bridge