Step 7 Localization

Step 7: Localization

Every player-visible string in OptiKit is an FText, so the standard Localization Dashboard flow picks all of it up.

Where the texts live

• Setting names, descriptions, category names, option labels - on the catalog Data Assets (/OptiKit/Catalog/, or your own).
• Widget texts (footer captions, search hint, example labels) - in the WBPs.
• Dialog and apply-error texts - in one Data Asset: /OptiKit/DA_OkTexts (UOkTextLibrary, 35 fields). Edit it directly, or duplicate it and point Project Settings → Plugins → OptiKit → Text Library at your copy. Untouched fields keep the localized C++ defaults; the catalog check warns about emptied fields.
• Remaining C++ strings (capture prompts like "Press a key...") - LOCTEXT in the plugin source.

Gather setup (Localization Dashboard)

1. Tools → Localization Dashboard → select the Game target.
2. Cultures: add your languages (native culture stays e.g. English).
3. Gather from Packages → Include Path Wildcards: keep the default Content/* and add the filesystem wildcard Plugins/OptiKit/Content/* (the field matches file paths, not /OptiKit-style package paths).
4. Gather from Text Files: add Plugins/OptiKit/Source for the remaining C++ strings.
5. Gather Text → translate (built-in editor or PO export/import) → Compile Text.

The Language row

UI.Language fills its options from the cultures that have compiled localization data - after Compile Text, new languages appear automatically with native-name labels ("Türkçe", "Deutsch"). Switching is live, no restart; the choice persists and is restored at boot. In PIE the switch drives the game localization preview only - the editor's own language is never touched.

For packaged builds, also tick your cultures under Project Settings → Packaging → Localizations to Package.

The example/preview texts ("V-Sync", "80", "F") are replaced by real content at runtime and never reach players - translating them is optional.

Next: Step 8: Blueprint API