Multi Mod and Translation

Multi-Mod and Translation

How the toolkit handles more than one mod at once, dependency mods, translating someone else's mod, and the optional per-mod workspace files.

Working on many mods at once

Multi-mod workspaces just work. Every workspace folder that looks like a mod of the active game is treated as a mod being edited: definitions AND references are indexed across all of them, so completion, hover, go-to-definition and find-references span the whole workspace. tiger validates the mod that owns the file you save (with a per-mod baseline), and mod-targeted commands (new content, loc editing, translations) act on the mod of the active editor.

A workspace folder that merely contains mod folders also works: its direct children that look like mods are picked up, so you can keep one parent directory with 20 mods and open just that. There is no "primary mod" to configure.

The mod-scoped sidebar views (Mod Overview, Localization Coverage, Overrides & Conflicts, the event graph and the mod report) show one mod at a time: by default the mod of the file you are editing, or pin one with the focus dot in the Project view (also Paradox: Pick Focus Mod, with a button in the view headers). Switching mods is instant, because everything is indexed once at launch. See Sidebar Views.

Mods you are not working on can be skipped entirely, with the per-mod index switch in the Project view or Paradox: Exclude Workspace Mods from Indexing (setting: px.excludedMods). Excluded mods get no indexing, completion, diagnostics or views.

To keep 20 mods tellable apart, hovers and completion label definitions with the owning mod's launcher name (from its descriptor) instead of a generic "mod", for example trait group revealed_realm · Cultivation Expanded. Mods without a descriptor fall back to their folder name. The Overrides view also flags definitions that two of your mods declare (launcher load order decides those).

One caveat worth knowing before you open a total conversion plus a dozen mods: every VS Code window forks its own language server and builds its own full index, so ten windows on one workspace cost ten times the memory. docs/PERFORMANCE.md has the measured numbers and the settings that shrink them.

Working on submods and compatibility patches

Read-only parent / dependency mods can be indexed alongside your own. They come from any of three places, all merged, with the first match winning on duplicates:

1. Extra workspace folders. Open your submod plus its parent mods in a multi-root workspace (File → Add Folder to Workspace). These are treated as editable workspace mods (see above), which includes everything parents get.
2. The px.parentMods setting (absolute paths, load order, base first).
3. <mod>/.ck3modding/playset.json (below), which is the shareable, per-mod form.

Parent content gets full syntax highlighting and language features, is indexed between your mod and vanilla (so completion, hover, go-to-definition and find-references from your mod resolve into parents), shows up in the overrides view, and re-indexes live when a parent file changes.

Parents reach tiger too. When you validate, your parent mods and the other workspace mods are declared to tiger as load_mod entries, so a submod's references into its parents resolve instead of coming back "unknown". That happens automatically when your mod has no tiger conf of its own; when it has one, that conf stays in charge (tiger reads it directly), so regenerate it with Paradox Tiger: Generate ck3-tiger.conf, which writes the load_mod blocks for you, or add them yourself.

Translating another mod

Paradox Localization: New Translation Mod (translate another mod) scaffolds a standalone language compatibility mod for any indexed mod (a workspace mod or a read-only parent). Pick the source mod and target language, and it generates a complete mod folder:

• a descriptor.mod with a dependency on the source mod,
• every source loc file mirrored under localization/<lang>/replace/ with blanked values, keeping the original text as # english: ... comments so nothing wrong-language ever ships,
• a playset.json so the new mod resolves the source's symbols when opened alone,
• a TRANSLATE.md with the workflow, a per-file checklist, and a ready-made AI translation prompt (verbatim rules for preserving $variables$, [script], icons and formatting tags, and matching the official game translation's register and terminology).

Then work through the remaining keys with Translate Missing Keys (one by one), which walks the coverage view's missing list and reports what it wrote and what you skipped (leave a value empty to skip). The Localization Coverage view tracks the rest, since a blank value counts as untranslated.

Current limitation: the translation-mod scaffolder writes a launcher-style descriptor.mod. That is correct for CK3, but Victoria 3 and EU5 mods use the .metadata/metadata.json form, so on those two games you will need to write the descriptor yourself. Everything else the scaffolder produces is game-independent.

To add a language to your own mod instead, use Paradox Localization: Add Language (scaffold files).

Workspace files (optional, in <mod>/.ck3modding/)

The folder name follows the game: .ck3modding/ for CK3, .vic3modding/ for Victoria 3, .eu5modding/ for EU5.

• playset.json - { "parents": ["path/to/parent/mod", ...] }: index parent mods so total-conversion submods resolve names correctly. Shareable, unlike a machine-specific setting.
• schema.json - extend or override the bundled folder schema (folders → kinds → loc requirements) for frameworks the toolkit does not know. This is also the escape hatch for a wrong or missing EU5 folder mapping, since that table is community-sourced (see Supported Games); please file a Schema gap issue as well, so the fix reaches everyone.
• tiger-baseline.json - written by Paradox Tiger: Create Baseline (snapshot current problems).