[Tools] SLR - Offline JP to EN Translation for RPG Maker VX, VX Ace, MV, MZ, and Pictures

[Shisaye]

It's a new all-things model that google has created to implement on chrome, relying to be the substitute of the old tools of Chrome for things like summarization and translation.

Official Google doc here: https://developer.android.com/ai/gemini-nano

Also, I tried the chatgpt endpoint before, all I got was frustration trying to configure that

I'm just going to be honest, looking at this I'm pretty lost.
I have no idea how someone is supposed to use that.

 

[Shisaye]

Finally finished a serious offline DSLR test with the new models.
This is only for someone with bad hardware. If you have a high-end rig the tests and conclusion do not apply to you at all.

On a 9 year old PC that was expensive back then, but never received any hardware upgrade.
250000 characters of text, that has a lot of @1 placeholders \n[] commands and \c[] commands.

Test 1
Primary model Qwen3 VL 8B Instruct abliterated v2 I1 (Q5_K_S)
Fallback model Gemma3 27B abliterated dpo I1 (Q4_K_S)

The translation took ~8.5 hours. Not a single complete failure.

Test 2
Primary model Qwen3 VL 4B Instruct abliterated v1 (Q8_0)
Fallback model Qwen3 VL 8B Instruct abliterated v2 (Q8_0)

The translation took ~3.5 hours. 7 cells failed completely and need manual fixing.


Obervations:
Test 1 was a failure on this hardware.
The Primary model actually screwed up a lot constantly requiring the large fallback model to step in which is why it took so long.
8.5 hours for a mediocre translation of a medium sized game is not acceptable.
If you think about the monetary value of the power consumption, wear, and it simply blocking the PC, you could pay deepseek instead and have a faster better translation.

Test 2 was also a failure, although a less bad one.
3.5 hours is still really long considering it had complete failures.
The Primary model actually performed basically the same as the primary in the first test.
The fallback model was too big to offload into the old GPU and as a result pretty slow and did not have a particularly good rate at fixing stuff. Meaning on those 7 complete failures it just wasted a really long time failing.

Current Conclusion:
If you have outdated hardware I would use the biggest abliterated Qwen3 model you can fully fit in your GPU as a primary model and then use DeepSeekV3-0324 as fallback option with the free requests on OpenRouter.
That would be quite fast, free, you would not have a single complete failure, and if the game you are translating has a lot of \c[] commands and stuff like that you will likely still get a significantly better translation than with SugoiV4 based SLR.

If you absolutely want to keep it offline I would honestly just turn the fallback option off and once it finishes manually fix the cells with the TRANSLATIONFAILURE error code (Worst case just run normal SLR on them). That would be so much faster than trying to make a huge model do it for you.

If none of the models fit in your GPU, stick to SLR, it's not worth it.

 

[Shisaye]

I've released v2.030.
Most notable change: frequency_penalty, presence_penalty, stream, and chat_template_kwargs parameter options to DSLR and parameters are optional now.
(If you leave them blank or use 69 if they are a number, then they will not be sent to the endpoint at all.)


Changes since last changelog post:

2.030
Added frequency_penalty, presence_penalty, stream, and chat_template_kwargs options to DSLR.
Added prompt options for fallback model.
Parameters that are set to either be empty or 69 will no longer be sent to the endpoint.

2.029
When talking to the LLM about text commands DSLR will now use the correct capitalization of the original.
Changed DSLR default settings.
Changed DSLR documentation.
Changed DSLR FullBatch max_tokens calculation to be sustantially lower.
Added better error handling for '400 Bad Request' server errors.

2.028
Added more DSLR options for the fallback model. Fixed the existing ones.
Added adjustments to Temperature and Top K parameters during the last attempts.
If a batch would fail completely because even the fallback model ran out of tries, or it's not even enabled, then it will now accept the translation anyway, but add SHISAYE.FAILEDTRANSLATION into it.
Changed default max tokens to 4000.

2.027
Added FallBack LLM options to DSLR.
Removed outdated information from the documentation.

 

[Shisaye]

I've released v2.032.
To further address the weak hardware DSLR problem I've implemented a new option to limit the fallback attempts to 5 single requests.
Meaning instead of retrying the entire batch it will really only use the fallback model for the current failed translation.
That makes using large models with weak hardware much more viable because it will at worst only make 5 relatively quick attempts and not waste 2 hours.

But that new option would be a terrible idea for a fallback model using some kind of free limited requests/tokens, because it will spam small inefficient requests.
It's only a good idea for something unlimited and free. (If you host the model yourself.)


Changes since last changelog post:

2.032
Fixed it not sending the starter of the context prompt in DSLR.
Changed single request retries to 10 instead of 12.
Added new "Limit Fallback to Single Requests" option.
When enabled it will try 5 more times with the fallback model during single requests instead of the fallback model trying the entire batch again.
It will not retry the batch if those 5 attempts fail.

2.031
Implemented the DSLR endpoint parameter option changes for SEP.
Fixed some wrong text.