Init translation cache from a local file

[eadmaster]

Advantages of having such an option:

• can display human-revised translations
• lower delay for the overlay to appear
• save CPU/GPU resources (only need to perform the OCR)

The local file could be a very simple csv with only 2 fields: jap_text,eng_text, which is also very easy to generate from existing translations.

EDIT: implemented here as described, i can send a PR after a few extra fixes.

[bquenin]

Thanks for the idea and for working on an implementation!

I like the concept - pre-loading curated translations would give better quality and faster response times. However, I see one main challenge that needs to be addressed: OCR variability.

The problem:
The OCR is good but not deterministic. The same on-screen text often produces slightly different OCR outputs across frames - character substitutions, added/missing punctuation, spacing differences, etc. This means we can't fully trust the OCR string as a reliable key for lookups.

If a translation pack is built on exact string matching, it would likely fail to match because the OCR output varies. How would the pack account for this?

Does fuzzy matching help?
The current translation cache uses fuzzy matching with a 0.9 (90%) similarity threshold. This helps with minor variations, but may not be enough:

• Short strings are sensitive - one character difference in 攻撃 drops similarity significantly
• Common OCR errors (similar-looking characters) can produce low similarity scores
• Added/missing punctuation like こんにちは vs こんにちは。 is ~83% similar → would miss at 0.9 threshold

Potential solutions:

1. Lower similarity threshold for packs - Use 0.75-0.8 for pack lookups, though this risks false positives on short strings

2. Normalization - Strip punctuation and normalize whitespace before matching, which would help with こんにちは vs こんにちは。

3. Multiple OCR variants per translation - Pack includes common OCR variations for the same line:

   こんにちは,Hello
   こんにちは。,Hello
   こんにちは!,Hello

4. Pack building mode - A mode that logs actual OCR outputs to a file, so pack creators can see what the OCR really produces for their game and build against that (rather than the original Japanese text)

Bottom line:
I think this could work well, but the OCR variability challenge needs a good solution. The integration itself (loading a pack from GUI, pre-populating the cache) is straightforward.

How does your implementation handle this? I'd be curious to hear your thoughts on making pack lookups robust against OCR variations.

[eadmaster]

I vote for 2: Normalization.

The idea is to strip all the small marks that could be missed by the OCR engine: symbols, dakuten ,etc

e.g. _normalize_for_hash("ｶﾞｯｺｳ 2024! (末)") # Output: カツコウ2024未

(See the normalization function here.)

Another issue i've found is when running with mode=inplace the text gets splitted into multiple pieces, which may also cause a cache miss.
I've added a workaround here, but it's not the best solution. If the bboxes are close, the text should be combined into a single string.

In the end there will always be edge cases, and we just fallback to live translation in these cases (maybe use a different text color to differentiate?)

If you want to experiment a bit, i've made this sample csv file.

[bquenin]

@eadmaster Thanks for sharing your implementation and the detailed discussion on normalization!

Before we move forward, I'd love to understand the use case better. A few questions:

1. What game(s) are you using this for? Is this for a specific game you're playing, or do you see it being useful across many titles?

2. Where does the translation data come from? Are you creating these CSV files yourself, extracting them from existing fan translations, or sourcing them from somewhere else?

3. What's the workflow look like? How do you go from "I want to play this game" to having a working translation pack?

4. What problem does this solve for you? Is it about translation quality, speed, consistency of terminology, or something else?

Understanding your actual use case will help us figure out if and how this feature could benefit other users as well.

[eadmaster]

1. multiple titles

2. and 3. the original script is extracted directly from the game data using tools like jstrings and stringsext. After that i get a rough automated translation and manually revise it. (I've made this python script to parse jstrings output and generate the CSV)

3. both translation quality and speed

With the current GUI it makes sense to have an extra button to load the CSV and init the cache. Then the curated translated lines should be fully-loaded into RAM, increasing the cache size if necessary. So this issue should be limited to the caching class without affecting other parts of the code (inplace text splitting is a separate issue).

[Antaniserse]

Personally I am mostly using the app for strategy RPG games, which have a fairly good mix of dialogue and static UI, with predictable text and positioning, so this would be a great approach, being able to load a curated script for the UI elements, faster and with less "flickering" of words, while leaving the normal OCR for the dynamic dialogues only

What I imagine is the Pack building mode you mentioned, tied to an hotkey, so that at any time I can dump the current screen list of words and sentences to a file, and then manually revise the content... this would make translating/fixing most of the game menus a fairly quick process, since you just need to open each individual screen once, dump, and edit

[eadmaster]

2. Could I please ask Eadmaster if he could write a brief tutorial on how to extract a script using jstrings and stringsext, and how to generate the CSV using the script? This would be really appreciated if possible!

hi, take a look here.
At step 3 use this script instead of the one suggested in the guide to generate the csv.

[eadmaster]

i've made some changes in my old fork so it can be installed alongside the current version:

$ uv tool install "git+https://github.com/eadmaster/interpreter.git"

In the examples folder you can find some scripts extracted by me.

cmdline usage :

$ interpreter-cli --cache-file="PopfulMail (PCECD).csv" -w RetroArch -m banner

Keep in mind the code is still quite experimental, some lines will hardly match without manual editing...