Studio gets text from at least two kinds of resource: messages contain strings, and fonts contain glyph shapes and metrics. A successful UTF-16LE decode does not determine which glyph resource the UI will use. Regional font inventories and layout geometry therefore need to be considered together. [1][2]
BMG and key tables
Japanese V1 stores Layout.bmg, Message.bmg and matching .tbl files in NitroFS. BMG files carry MESGbmg1 with INF1 and DAT1 sections and UTF-16LE message content. The companion tables associate keys and message indices; their pairing has been validated, while every table column's original application meaning is not fully established. Later builds put message pairs inside the ARM9 UI archive. [1]
NFTR fonts
Later releases keep localised .ZFTR files under LocalizeData. Their LZ11 payloads decode to RTFN NFTR data with glyph maps. Japanese V1 instead has seven font members in the embedded UI archive. The 79 later NitroFS fonts are spread as 10 in JP V2, 26 in US V2 and 43 in EU V2, reflecting their different language sets. [1][2]
Rendering consequences
Font metrics affect line breaks, button labels and hitbox relationships. To reproduce a screen, identify the selected message key, language, font resource and layout rather than substituting a visually similar system font. Unknown or missing glyph behaviour requires a fixture from the target build; it should not be guessed from a desktop renderer. [1][2]
Message keys and on-screen text
The wiki lists numbered layout IDs with text attributes, alongside separate message IDs for prompts. Drawing menus, save confirmations, keyboard keys and online errors each have their own named entries. A default can be blank because the application fills it at runtime. When replacing a language, keep each resource tied to the same key and check its displayed width: longer translations can overflow fixed layouts. The message catalogue guide lists all keys. [3]