Skip to content
SheetForge

Localization

This page is about the languages of the product's own UI. Localizing your game's text — keys, translations, Unity Localization StringTables — is a different subject with its own page: Localization Sheets.

The product UI — menus, the authoring window, inspectors, dialogs, reports, tooltips — ships in 10 languages:

English (default) · 한국어 · 日本語 · 简体中文 · 繁體中文 · Español · Français · Deutsch · Português (Brasil) · Русский

The exact boundary, including which report fragments stay English, is under "The localization boundary" below.

Changing the language

  • On first run, the UI language is set automatically from your editor's OS language. Nine languages map directly; anything else stays English. A console line notes the choice. Change it any time as below — an explicit choice is never overwritten.
  • Edit ▸ Preferences ▸ SheetForge → language popup, or the "Editor language" field at the top of the import-settings inspector (both read/write the same value).
  • The language is a per-user setting (EditorPrefs) — every teammate uses their own language, and nothing about it touches version control (zero VCS churn).

[MenuItem] labels are static attributes and cannot change at runtime. So SheetForge regenerates a thin menu file (Assets/SheetForge/Editor/Generated/, gitignored) in the selected language. Changing the language triggers one short recompile — no loops, and identical content is never rewritten.

If the folder is missing or the language mismatches (e.g. right after cloning), it self-heals automatically. The Tools/SheetForge root is a fixed brand constant; leaf labels follow the language.

Language changes are locked while an Import/Export/Push is running — the menu-regeneration recompile must not disrupt a running pipeline. Change it afterward.

The localization boundary

Fully localized in all 10 languages:

  • Editor-drawn UI: menus, the authoring window, inspector, dialogs, buttons, tooltips.
  • The report skeleton and every error's "why"/"how" sentences.

Inline English (inside the localized skeleton):

  • Report detail fragments — the offending value, nearest-match suggestions, and other runtime-interpolated pieces, which cannot live as language-table keys.
  • Low-level exceptions and developer logs ([SheetForge]).

One pending gap, stated honestly: roughly 345–360 of the 1,043 keys still hold their English text in the eight languages other than English and Korean. Those keys are the Data Studio's 227 ui.studio.* keys plus the theme preference and the newest dialog and log lines.

Every key exists in every file, and parity is test-enforced, so nothing falls back to a raw key. This is a translation pass waiting to happen rather than a structural gap. See Capabilities & Limits ▸ Localization scope.

A guard test on both test harnesses enforces that the product source contains no hard-coded Korean strings — the development language never leaks into the UI. (The single data exception: each language's self-name, e.g. 한국어, in the language picker.)

Adding or fixing translations

Each language is exactly one file: Assets/SheetForge/Core/Tooling/Localization/Lang/Lang{Language}.cs. It is a pure static dictionary, so translators work in parallel without merge conflicts across languages.

  • English (LangEn) is the canonical key list. Every other language must cover the same keys.
  • A parity test immediately catches a missing key, an extra key, or a damaged placeholder ({name}) in any language.
  • To adjust a translation: edit the language's file, keep the placeholders intact, run the tests.