Recover the stranded Translation Bridge work, and measure whether it is worth finishing

[rouges78]

Five commits on claude/bold-banach never merged after PR #19 took the first half of that branch. By the time they were reviewed, Injekt — the consumer of much of that code — had been archived (#83). This recovers the parts that survive Injekt's removal, then measures the question that recovery raised: is the shared memory bridge worth finishing at all?

What came back

Nothing here references Injekt; the recoverable slice turned out to be self-contained.

Dictionary engine — a single hash-indexed store replaces two parallel maps, so a duplicate key updates in place and the entry count stops drifting. Plus a 500k-entry cap, a CSV parser that honours quoted fields and "" escapes, batch lookup, mtime-based hot reload, and save/load of a dictionary directory.

Shared memory — Response Data becomes a real circular buffer with a tail the client advances. A full buffer now marks the slot Error instead of overwriting replies the plugin has not read yet. The Shmem moves behind an Arc<SharedShmem> co-owned by the server thread, replacing the raw-pointer-as-usize handoff and the unsound Send/Sync on TranslationBridge. Header counters are written once per batch from the Rust stats, removing the read-modify-write race against the plugin.

AI fallback — cache misses feed an mpsc queue drained by translation_bridge_drain_misses. Its non-Windows stub already shipped with e3262e58; main had an orphan command, defined only for Linux and never registered. This adds the Windows implementation and the missing main.rs line.

PROTOCOL_VERSION goes to 2: the new response_data_tail field changes the layout every client must agree on, and the branch left the constant at 1.

The measurement

Recovering this raised a fair question — is a Named Pipe fast enough, or does the shared memory path need finishing? Measured rather than guessed. Same workload on both, 3000 iterations after warmup, release build, reproducible via cargo test --release --lib ipc_bench:

transport	p50	p95	p99
Named Pipe	9.2us	18.9us	30.4us
shared memory	0.4us	0.5us	0.8us

The pipe is ~20x slower per string, and it does not matter. GSTranslator::Translate() checks a process-local cache first and only calls IPC on a miss, and that cache is persisted across sessions. The ~88 strings/frame the pipe affords at p95 is not a rendering budget — it is a budget of strings never seen before, which decays to zero within seconds of play.

ipc_bench.rs compiles only under cfg(test), so it stays reproducible without entering the binary.

What the measurement turned up

No request/response path is complete on both sides. The overlay pipe is one-way by design; GameStringerTranslator has a real client in gs-hook but no Rust server; ue_translator/ipc_bridge.rs has a server that is a loop calling sleep; and the shared memory plugin's QueryBackend still returns null.

One correction is folded in: an earlier draft of the log claimed the DLL looks for a pipe name Rust never declares. Reading the UTF-16 strings out of the prebuilt DLLs shows otherwise — gs-hook.dll carries GameStringerTranslator, unity_auto_translator.dll carries GameStringerUETranslator. Two separate channels with two separate clients, each correctly named. Renaming either into the other would disconnect a prebuilt binary. The real defect is the missing server, not the name.

All of it is in docs/METODI-DI-TRADUZIONE.md with the commands to re-check.

Verification

cargo check (8 warnings, all pre-existing in process_utils.rs — the 3 in translation_bridge are gone), cargo test translation_bridge (22 passed, two of them new), cargo clippy (no new warnings), tsc --noEmit, eslint, i18n:check (802 = baseline), tauri:check-cmds (no invoke into the void), dead:check (no new dead modules).

Worth knowing before merging

This is maintenance on a dormant subsystem, not a feature. The bugs it fixes are real and sitting in main today, but nothing consumes the Translation Bridge yet. Given the numbers above, finishing the pipe server looks like the better investment than finishing the C# QueryBackend — the hard half of the pipe is already written in hook-dll/src/ipc.cpp.

🤖 Generated with Claude Code