Track a game from the game database; one folder, one game

[ChakraFusion]

Item 13 from #21, rebuilt on dev-public without save versions or the rest of the draft stack (#35 depends on them).

Why. A folder tracked by hand only gets the name typed for it: no App ID, so no cover art and no launching. And nothing stopped a second entry for a folder inside one already tracked. Tracking Escape From Duckov from the game database put a second game on …\TeamSoda\Duckov\Saves, inside the folder an entry called "Duckov" already tracked. The same files were then watched, snapshotted and synced twice, under two games.

What changes:

• A "Track game" button beside "Track folder" on Home. It finds a game in the game database (the Ludusavi manifest index OpenSave already ships and downloads) in one of three ways:

  • by name;
  • by its program: the Steam install folder the program is in, or a folder above it named as the game's install folder, compared without spaces (the database writes "ProjectZomboid");
  • by a save folder: the game whose save location is that folder, holds it, or is held by it.

  The game is tracked with the database's name and App ID, its program, and a save location the database knows on this device.

• "Track folder" recognises the folder the same way and tracks it with the game's name and App ID ("Recognised as …").

• One folder, one game. TrackGame refuses a folder inside a tracked game's folder, or one holding it, and names that game. The exact same folder keeps its existing refusal, and moving a game's own folder is not affected.

• Already tracked under another entry. If the game picked is already tracked here, by App ID or by a folder that is, holds or is held by one of its save locations, the dialog says so. Instead of tracking it twice, it offers to link that entry: the existing PATCH /api/games/{id} gives it the database's name, App ID and program.

Backend:

• presets/gamedb.go:
  • a GameDB lookup over the manifest index, reusing the scanner's own template expansion, Proton prefixes, blocked roots and install-base candidates;
  • Search, IdentifyProgram and IdentifyFolder.
• daemon/gamedb.go and two read-only routes: GET /api/gamedb/search?q= and GET /api/gamedb/identify?path=.
• store.PathsNest: two folders one inside the other, but not the same folder. It sits beside PathsOverlap and compares paths the same way.

Left out on purpose, so this stands on dev-public alone. On my fork these build on other parts of the draft stack:

• Picking from the games running now: it needs the process memory measurement that comes with play sessions (Hold a game being played back from syncing until the session ends #34). It can follow with that.
• Linking an entry to the game database automatically in the background: it hangs off per-device settings detection (Keep each device's game settings out of sync #33).
• Ignoring Steam-only folders (a userdata/<id>/<appid> folder holding only remotecache.vdf is not a save): it needs delta.NeverSynced from Steam's remotecache.vdf is the launcher's file, not a save change #52.
• No migration is needed, so 0040 stays free for the next PR that adds a table.

Translations: all new text goes through $t. I added the zh-CN strings myself, since the catalog test requires every key; @Janlhin, please correct them if anything reads oddly.

Tests:

• TestGameDB_FindsGamesByNameFolderAndProgram: search, folder (same, inside, one level up), program by install-folder name, and no match for unrelated paths.
• TestTrackGame_RefusesAFolderInsideAnother:
  • a folder holding a tracked game's is refused, and so is one inside it, each naming the game;
  • the same folder keeps the usual refusal;
  • an unrelated folder is tracked.
  • With the check removed it fails on both nested cases.
• TestMarkTracked_NamesTheEntryAGameIsAlready: by folder, by App ID, and not for an unrelated game.
• Suites: the full Go unit and e2e suites pass locally. Frontend: 309 tests pass and the build is clean.
• Fork CI: green on the second attempt. The first failed one Windows shard on TestIgnored_ASaveFromTheCloudLeavesAnIgnoredFileAlone (failed twice before on branches without this change) and TestIgnore_AppliesToExtraLocationsToo (first time I've seen it; it tracks one plain folder per device and adds its extra location through /roots, which this PR doesn't touch, and both pass 10/10 locally with this branch). If the second shows up again, e2e: every failing test prints its daemons' logs #57's logs will say why.
• Not checked by hand: I haven't clicked through the new dialog in the app on dev-public. The fork's version of it (with the parts left out above) is in my test builds, which I run on four PCs.

🤖 Generated with Claude Code

[vercel]

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Janlhin]

Hi ChakraFusion— the full i18n extraction for OpenSave is done: three catalogs (en / zh-Hans / zh-Hant, 1328 keys), every window UI extracted to keys, including the lib-layer dynamic text (time formats, activity descriptions, notifications, sort names, appearance options). npm test 310/310, clean build, and the two runtime crashes introduced along the way (TransfersPanel alias leftovers, a timeline crash on missing timestamps) are fixed and verified.

Feel free to take anything you need from the feat/i18n-full-coverage branch — it's self-contained and builds standalone. I'll be pushing PRs to upstream (dev-public) view by view; if anything overlaps with your work, ping me and let's coordinate.

[ChakraFusion]

Thanks @Janlhin, that's a big piece of work, and good to know before more UI lands.

Where our work touches yours:

• This PR (Track a game from the game database; one folder, one game #73) adds the "Track game" dialog (views/home/TrackGameDialog.svelte) with new home.findGame.* keys in en.json and zh-CN.json. If your catalogs replace zh-CN with zh-Hans / zh-Hant, whichever of us merges second moves those keys across. If yours go in first, I'll do it on my side.
• Restore as many files at a time as the drive does best, with progress #55 adds restore-progress text in lib/restoreprogress.js ("Rebuilding the snapshot", "Checking the snapshot", "Writing the files"), and sync: closest devices first, by measured link speed #27 adds a tooltip in views/Devices.svelte. Both are plain strings today. I'll move them to keys so they don't add to your extraction work.
• My draft PRs sync: decide by save versions, not by guessing from files #30–A save put back is the other device's; emptying is no version until meant #36 change more of the UI (game view, settings, Home). When I rebuild them, all new text will go into keys, and I'll check your branch first so the names fit your scheme.

When your view-by-view PRs are up, I'll rebase onto them rather than ask you to adjust.

[ChakraFusion]

Following up on the two I mentioned: both are done.

• Restore as many files at a time as the drive does best, with progress #55: all of the restore progress text in lib/restoreprogress.js comes from restoreProgress.* keys now: the phase names, the "{done} of {total}" line and the time left (minutes as a plural). restoreProgressText(p, $t) takes the translate function from its call site, like your timeAgo/gameStatus approach.
• sync: closest devices first, by measured link speed #27: the link line and its tooltip in views/Devices.svelte use flat devices.link* keys (linkLan, linkVpn, linkRelay, linkInternet, linkUnmeasured, linkMeasured, linkTitle), to match your devices.* names.

Both PRs add the keys to en.json and zh-CN.json. When your zh-Hans / zh-Hant split lands, I'll move them across on my side.