Skip to content

Rename Dragonriding to Skyriding, with a settings migration - #1906

Open
mariusch wants to merge 1 commit into
EllesmereGaming:mainfrom
mariusch:fix/dragonriding-to-skyriding-rename
Open

Rename Dragonriding to Skyriding, with a settings migration#1906
mariusch wants to merge 1 commit into
EllesmereGaming:mainfrom
mariusch:fix/dragonriding-to-skyriding-rename

Conversation

@mariusch

@mariusch mariusch commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Renames Dragonriding to Skyriding across the options and locale files, and migrates
existing settings onto the new module id. Nothing changes but the wording.

History

Blizzard renamed the feature in 10.2.5 and made it evergreen, so the old name has been
wrong for a while rather than just dated.

It also hid the settings. Searching the options for "skyriding" found the module but none
of its controls, because every row read Enable Dragon Riding Bar or When Dragonriding.

The migration

Module data lives in EllesmereUIDB.profiles[*].addons[folder], so the subtree moves
with one re-key. The child SV globals are vestigial, NewDB wipes them each load.

Two stores hold that folder key, in different scopes:

Migration Scope Re-keys
skyriding_folder_rename_v1 profile addons.EllesmereUIDragonRiding
skyriding_synced_modules_rename_v1 global syncedModules.EllesmereUIDragonRiding

Sync group membership sits on EllesmereUIDB rather than in a profile, so profile scope
never reaches it. Without the second migration a synced HUD reads as unsynced and the old
key stays in SavedVariables.

Both run at parent ADDON_LOADED, before the HUD reads its DB, and both delete the old
key, so a re-run is a no-op. An optional legacySuffix on ADDON_DB_MAP keeps profile
strings exported under the old name importing.

Worth flagging:

  • koKR and ruRU still need a native speaker. deDE, frFR and zhCN rendered the old
    word in their own language under the renamed keys, so those values now follow the term
    each file already used elsewhere (Himmelsreiten, Vol draconique, 驭空术). koKR has
    six competing variants and ruRU none, so both fall back to English for now.
  • show_dragonriding and EDR_ keep the old spelling. Both are stored values, not
    labels: the visibility modes sit in already-shared profile strings import does not
    translate, and EDR_Cluster keys saved unlock anchors. Renaming either orphans data.

Eleven dead locale entries go too, and the module's searchTerms drops dragon riding
rather than keeping it as a synonym. frFR gains Hide when Skyriding Mounted, which it
was missing. No new keys.

How was it tested?

In game on live. Existing profiles keep their Skyriding HUD settings through the folder
re-key.

All 29 files parse, _keys.txt regenerates clean, every renamed key cross-checks against
live source with no orphans left, and addons and syncedModules are the only
folder-keyed stores.

Screenshots

Checklist

  • New settings default OFF -- N/A: a rename, no new settings and no appearance change
  • Zero cost while disabled -- N/A: no new events, hooks or frames
  • Cheap while enabled -- N/A: the two migrations run once at ADDON_LOADED
  • No writes onto Blizzard-owned frames -- N/A: no Blizzard frames touched
  • Tested in-game on live; no version gates or pre-Midnight APIs added

@mariusch
mariusch force-pushed the fix/dragonriding-to-skyriding-rename branch 2 times, most recently from 1a24bff to 950fdf4 Compare September 1, 2026 20:37
Blizzard renamed Dragonriding to Skyriding in patch 10.2.5 and made it an
evergreen feature. The addon still used the old name in option labels, page
names, tooltips, locale strings, and the Skyriding HUD's own module id.
User-facing text: renames the Blizz UI Enhanced page, its toggles and
tooltips, the visibility dropdown modes, the texture/font labels, and the
matching keys in all seven locale files that carried translations.
Locales: keys are renamed in place so existing translations survive. Where a
file's own live Skyriding entries already used the current term but the
renamed keys still carried the retired one, the values are aligned to that
same in-file term -- deDE to Himmelsreiten, frFR to Vol draconique, zhCN to
驭空术 -- so those languages no longer render the old name under a Skyriding
label. frFR also gains Hide when Skyriding Mounted, which it was missing,
phrased from its own Hide when Mounted entry. koKR and ruRU are left for a
native translator: koKR carries six competing variants and ruRU has no
established modern term, so there is nothing in-file to align to. Also drops
eleven entries that were dead or superseded, including a stale zhCN
L["Dragon Riding Bar"] that would have collided with L["Skyriding Bar"].
Module id: the HUD's folder key moves from EllesmereUIDragonRiding to
EllesmereUISkyriding, its file is renamed, and the vestigial
EllesmereUIDragonRidingDB saved variable is replaced by
EllesmereUISkyridingDB -- which also clears the old always-empty entry from
every user's SavedVariables file. Two migrations carry the settings over,
both running at parent ADDON_LOADED, well before the HUD reads its DB at
PLAYER_LOGIN: skyriding_folder_rename_v1 re-keys the per-profile settings
subtree under EllesmereUIDB.profiles[*].addons, and
skyriding_synced_modules_rename_v1 re-keys the sync group in the global
EllesmereUIDB.syncedModules, which is not reachable from profile scope.
Profile strings exported under the old name still import, via a new
per-entry legacySuffix that feeds the existing canon translation.
Visibility mode values (show_dragonriding et al) and the EDR_ prefix are
deliberately left alone: they are invisible to users, renaming them would
require rewriting stored values across every module plus permanent import
aliases for already-shared profile strings, and EDR_Cluster additionally
keys saved unlock anchors. Comments describing those identifiers keep the
old spelling so they still match the code they document.
@mariusch
mariusch force-pushed the fix/dragonriding-to-skyriding-rename branch from 950fdf4 to 72c9d4c Compare September 1, 2026 20:42
@mariusch
mariusch marked this pull request as ready for review September 1, 2026 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant