Commonlib's `getConfig(key, translate?)` and `getConfName(key, translate?)`
default `translate` to `englishMessageTranslator`, and this plug-in never
passed the second argument. Every automatically wired setting therefore
rendered its name and description in English, whatever `displayLanguage` was
set to. Commonlib's own Config Doctor already threads a translator through
`getConfName`, so this only restores the argument which was missing here.
`src/modules/features/SettingDialogue/settingConstants.ts` now re-exports the
names it supplies explicitly and adds thin `getConfig` and `getConfName`
wrappers which default the translator to `translateLiveSyncMessage`. That
reaches all three existing call sites, and therefore the 102 `setAuto` and
`autoWire*` calls across the setting panes, the setup-wizard configuration
summaries, and the externally-modified-setting prompt. Of the 225 distinct
name and description strings in the two manifest tables, 160 are already
catalogue keys with translations; the remaining 65 are not catalogue keys and
pass through unchanged.
`ModuleResolveMismatchedTweaks` used `confName()`, which accepts no
translator, so it gains a local `localisedConfName()` instead. Swapping in
`getConfName()` there would have silently dropped the `statusDisplay()`
suffix, replaced the empty-string fallback for an unknown key with
`${key} (No info)`, and introduced `SettingInformation` as a second source.
English output is unchanged: every catalogue key which contains a space has a
value identical to the key itself, so translating under the default language
is idempotent.
Verified with `npm run check`, `npm run test:unit`, and `npm run build`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use typed Commonlib outcomes to guide Fetch and Rebuild without treating a new remote as a failed read. Preserve automatic synchronisation choices when scheduled initialisation is cancelled.
Why:
- Large downloaded batches can outlive the finite remote operation and be suspended before every document reaches the Vault.
- The v1.0 activity contract requires local application to remain distinct from remote-operation reporting.
Changes:
- Add an Obsidian-owned local application activity boundary which reuses Wake Lock policy without incrementing remote activity.
- Retain one boundary through queue processing and the final recovery snapshot, releasing and reacquiring it around suspension.
- Log final snapshot failures, preserve processing results, and cover the lifecycle with focused tests and documentation.
Continues the source-key migration inside the application boundary introduced
in 1.0.0, where LiveSync owns its catalogue and consumes Commonlib as a
published package.
- Replace hardcoded user-visible strings in the Obsidian UI (Setup Wizard
dialogues, P2P panes, Customisation Sync panes, Global History, the JSON
conflict pane and the remote-configuration menu) with `$msg` calls, keeping
the English source string as the key.
- Wire up strings whose translations already existed in the catalogue but were
still rendered as literals, for example the whole Intro dialogue.
- Add the new entries to `src/common/messagesYAML/en.yaml` and `es.yaml`, then
regenerate `messagesJson/` and `combinedMessages.prod.ts` through the
documented `i18n:bake` pipeline.
- No Commonlib gitlink or catalogue is involved; every change is
LiveSync-owned.
Regenerating the catalogue also normalises three pre-existing entries each in
`ko.json` and `zh.json`, where the committed JSON kept a trailing space before
a newline that YAML cannot represent.
Verified with tsc-check, tsc-check:apps, svelte-check and lint.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Use the preferred Obsidian element helper and preseed the real-Obsidian scenario before startup. Register the focused test and strengthen revision boundary coverage.
vorotamoroz