mirror of
https://github.com/vrtmrz/obsidian-livesync.git
synced 2026-08-28 14:27:08 +00:00
f09b4c779e7ffb69eff077541dcd7dd16ec1fd2f
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 nimulaandClaude Opus 5
|
f8ee3c8662 |
i18n: wire the display-language translator into the settings manifest
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>
|
||
|
nimulaandClaude Sonnet 5
|
0a1e1f3625 |
i18n(zh-tw): polish translation naturalness and terminology consistency
- Unify 資料庫適配器 -> 資料庫轉接器 across 6 entries so the database adapter setting uses one term throughout the catalogue. - Drop the calqued "透過⋯⋯來⋯⋯" construction in 3 entries (Testing-only conflict resolution, the P2P replicator description, and the duplicated garbage-collection cleanup description); the sentences read the same without the borrowed English "by X to Y" shape. - Rename the Eden-chunk "Incubate" feature's label from 孵化 (hatch) to 暫存 (temporarily store) across 7 entries, matching the wording already used in the toggle's own description and avoiding a half-metaphor/half-literal split within the same feature. - Convert the ASCII ellipsis "..." to the full-width "⋯" in 22 in-progress/loading strings, per Taiwanese typography convention; the English source keys (which legitimately end in "...") are untouched. - Reword "Fetch database with previous behaviour" to avoid a 以前/以 + 前一種 parsing ambiguity, matching the 先前的行為 wording already used by the sibling 保留先前的行為 entry. - Drop the orphaned closing paren in errMaxDocumentSize/errMaxRequestSize, fixing a display defect inherited from the English source. - Add 同步 to beforeLiveSync for clarity. Regenerated messagesJson/zh-tw.json and combinedMessages.prod.ts via `npm run i18n:bake`; no other locale's entries changed. Verified with tsc-check, lint, lint:community, lint:community:tools, svelte-check, build, check:compatibility, and test:unit (630 tests, 88 files) — all pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
nimulaandClaude Opus 5
|
b939687cb3 |
i18n(zh-tw): complete the catalogue coverage
Continues the zh-tw work from commit 0f50f290, which only translated the
190 keys `$msg()` calls in `src/` resolved through the catalogue at the
time. This closes the remaining gap: 573 of 1450 keys (39.5%) to 1446 of
1450 (99.7%), matching es (99.9%) and comfortably ahead of every other
locale except it.
While re-scanning to find the next batch, the earlier "code-referenced"
count turned out to be wrong: the previous grep only matched single-line
`$msg("literal")` calls and missed multi-line calls and the `msg`, `_msg`,
and `translateMessage` aliases various Svelte components import (e.g.
`import { $msg as msg } from "@/common/translation"`). A corrected scan
found 624 referenced keys, not 309, of which 350 were still untranslated —
mostly the P2P Sync status panes and several SetupWizard dialogues. Since
this pass translates everything remaining regardless of reference status,
that gap closes as a side effect; it is called out here only because it
explains why some of the newly translated strings are already visible in
today's UI rather than being pure catalogue completeness.
- Translated by area: P2P Sync replicator panes and the `P2P.*` runtime
messages; ConfigSync's plugin/snippet/theme comparison UI; the
SetupWizard's remote-setup, rebuild/fetch, and outro dialogues (both the
legacy flat-key strings and the newer `Ui.SetupWizard.*` Svelte
component keys); the Svelte-based `Ui.Settings.*` settings panels
(Maintenance, Patches, Hatch, Remote, Common, Selector, PowerUsers,
CustomisationSync, Advanced, Setup, SyncSettings); Setting Doctor
(`Doctor.*`); the remote-size warning flow (`moduleCheckRemoteSize.*`);
the redflag3 fetch-method chooser (`RedFlag.*`); the remaining
`moduleMigration.*`, `liveSyncReplicator.*`, `Replicator.*`, and
`TweakMismatchResolve.*` entries; and the rest of the plain
English-sentence keys, including the language-picker's native-script
entries (added `lang-he: עברית`, matching how `lang-de`/`lang-ja`/etc.
already show each language's own name rather than a Chinese gloss).
- Wording follows docs/terms.md and the register already established in
this file: `Setup URI`, `Vault`, `chunk(s)`, `Peer`, `Peer-to-Peer`,
`Hatch`, and `CouchDB` stay untranslated as proper nouns; `resolved`
(device/database state) is consistently 已處理, matching the existing
Scram-dialogue usage.
- `${...}` placeholders and `%{...}` keyword references are kept
byte-identical to the English source, including the multi-paragraph
`RedFlag.Fetch.Method.Desc` and `moduleCheckRemoteSize.msgDatabaseGrowing`
callout blocks; verified programmatically against all 1446 zh-tw
entries.
- 4 keys are still deliberately left untranslated, unchanged from the
previous commit: `moduleMigration.docUri` and
`obsidianLiveSyncSettingTab.linkTroubleshooting` are a URL and a doc
path, `obsidianLiveSyncSettingTab.logServerConfigurationCheck`'s English
value is the key name itself, and `moduleLiveSyncMain.logPluginVersion`
is a version-number template.
- Regenerated `messagesJson/zh-tw.json` and `combinedMessages.prod.ts`
through the documented `i18n:bake` pipeline; no other language's
entries changed.
Verified with tsc-check, tsc-check:apps, lint, lint:community,
lint:community:tools, svelte-check, check:compatibility, and test:unit
(604 tests, 86 files) — all pass.
Not in scope, unchanged from the previous commit: the ~137 Commonlib-owned
setting labels/descriptions never reach any translator because
`getConfig()` call sites in SettingDialogue omit the `translate` argument;
German is staged in the catalogue but never imported by
`combinedMessages.dev.ts`; Hebrew keyword references are never expanded by
`expandKeywords()`. None of these are specific to zh-tw and none are
touched here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
nimulaandClaude Opus 5
|
df8c79538e |
i18n(zh-tw): translate the keys the application actually renders
The zh-tw catalogue was the weakest of the ten supported locales at 380 of
1450 keys (26%), well behind zh (75%) and ja (57%). Users who select
繁體中文 saw English for most of the interface.
This does not attempt full parity. It closes the gap for the 190 keys that
`$msg()` calls in `src/` actually resolve through the catalogue (zh-tw had
no entry for any of them), plus the 7 `K.*` keyword fragments that
`expandKeywords()` substitutes into `%{...}` references at build time
(zh-tw had none of these either, so any zh-tw message referencing `%{Peer}`
etc. would have shown the raw token on screen — the same defect currently
affecting `he`).
- 186 of the 190 code-referenced keys are translated. The remaining 4 are
left as-is because their English value is not translatable prose:
`moduleMigration.docUri` and `obsidianLiveSyncSettingTab.linkTroubleshooting`
are a URL and a doc path, `obsidianLiveSyncSettingTab.logServerConfigurationCheck`'s
English value is the key name itself, and `moduleLiveSyncMain.logPluginVersion`
is a version-number template.
- Two pre-existing entries are corrected for internal consistency: `Bucket
Name` (儲存桶→儲存庫) and `Peer-to-Peer Synchronisation` (點對點同步→
Peer-to-Peer 同步), the latter matching the other three occurrences of
"Peer-to-Peer" already left untranslated in this same file.
- Wording follows docs/terms.md and the existing zh-tw register: `Setup
URI`, `Vault`, `chunk(s)`, `Hatch`, and `Peer-to-Peer` stay untranslated
as proper nouns, matching how the rest of the file already treats them.
- `${...}` placeholders and `%{...}` keyword references are kept
byte-identical to the English source; verified programmatically against
all 573 zh-tw entries, not just the new ones.
- Regenerated `messagesJson/zh-tw.json` and `combinedMessages.prod.ts`
through the documented `i18n:bake` pipeline; no other language's entries
changed.
Coverage: 380/1450 (26.2%) -> 573/1450 (39.5%).
Verified with tsc-check, tsc-check:apps, lint, lint:community,
lint:community:tools, svelte-check, check:compatibility, and test:unit
(604 tests, 86 files) — all pass.
Not in scope, left for follow-up: the ~137 Commonlib-owned setting
labels/descriptions never reach any translator because `getConfig()` call
sites in SettingDialogue omit the `translate` argument; German is staged
in the catalogue but never imported by `combinedMessages.dev.ts`; Hebrew
keyword references are never expanded by `expandKeywords()`. None of these
are specific to zh-tw and none are touched here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|