[Tools] SLR/DSLR/SEP - Translation Engines 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.

 

[Shisaye]

Some clarification regarding the latest update.

The "Prepare for Batch Translation" button only needs to be pressed once after creating a new project. You do not need to press it again, it wont do anything negative, but nothing positive either.

The new system determines whether or not you ever pressed the button by a small addition to the cache files and will press the button for you if you try to start a batch translation without it.
That means on old projects it will assume that you've never pressed it until it placed the new information, which is a bit annoying, but wont actually do anything negative to your project (but waste your time).
You can turn this whole deal off in the options menu.

Was this really necessary? Apparently so. Some people will rather take the effort of writing a long message shitting on a project, than read some basic instructions.

 

[Shisaye]

I've made a translation for RJ281598 using DeepSeekV3.2EXP as a test because that's weirdly enough currently the cheapest model, but I can't really recommend it.
When it worked it worked good, but in less than 200k characters it shit the bed 6 times and just replied with "A" or "/" when asked for a full batch.
Not a horrible error to get since obviously it wont really bill you a lot of output tokens for that, but DeepSeekV3-0324 never did that.

I did not test the proper 3.2, yet. (Came out today.)
I also never tried 3.1 Terminus, yet. The normal 3.1 is pretty bad.

 

[Shisaye]

Finished tests with basically all DeepSeek versions now.
My Impressions are as follows:

DeepSeekV3 - Decent - Not great not terrible.

DeepSeekV3-0324: Good - Follows instructions very well.

DeepSeekV3.1: Bad - Does not follow instructions, constantly screws up

DeepSeekV3.1-Terminus: Good - Basically the same as V3-0324

DeepSeekV3.2-EXP: Bad - Hangs up spamming the same letter quite often

DeepSeekV3.2: Not great - Hangs up less than 3.2EXP, but it still happens

I did not test 3.1-Exacto or 3.2-Special because they are reasoning models with really weird output, that is currently not supported by DSLR.

Translation quality for all of them is pretty bland/sterile and it prefers to take things in a non lewd way, but the tests were done on 0.1 temperature to give it the best chance to follow instructions, so that's not particularly surprising.


TLDR:
I still only really recommend V3-0324, which is also the model I've tested the most, but if you have a better provider for V3.1-Terminus then go with that, since there doesn't seem to be a whole lot of difference.

 

[Renderhentai]

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.

yeah, i don't know exaclty how Gemini Nano was placed in Translator++, but with the new chrome versions it works very well for translations, like a Local AI tranlation

 

[Shisaye]

yeah, i don't know exaclty how Gemini Nano was placed in Translator++, but with the new chrome versions it works very well for translations, like a Local AI tranlation

If it's a free addon for T++ I might be able to integrate it, but SLR Translator's UI is based on a really old version of T++ so I doubt it's a simple drop in, and if it's one of the premium addons it's probably riddled with DRM. Dreamsavior really loves DRM in his supposedly GPLv3 licensed project.

For local AI translations I'm currently using Qwen3 VL 32B abliterated v1, and there's also 8B and 4B versions that still work fairly well. (As long as you use Q6 or higher)
I just run them with LM Studio. DSLR can then talk to that like any other openai endpoint.

I couldn't tell you how they actually compare with Gemini Nano though, because I still have basically no data from that thing.

 

[Shisaye]

Bad news. Seems like OpenRouter no longer offers free requests to premium models. You can now only get free requests for stuff you could host yourself or is pretty shit.
No DeepSeekV3.X at all anymore either.

As a result OpenRouter is now basically worthless for DSLR, unless you're planning to pay money.
And even that is a bit "meh" because paying a provider directly is probably cheaper, and OpenRouter credits expire after a year, which is a bit bullshit.

 

[Renderhentai]

If it's a free addon for T++ I might be able to integrate it, but SLR Translator's UI is based on a really old version of T++ so I doubt it's a simple drop in, and if it's one of the premium addons it's probably riddled with DRM. Dreamsavior really loves DRM in his supposedly GPLv3 licensed project.

For local AI translations I'm currently using Qwen3 VL 32B abliterated v1, and there's also 8B and 4B versions that still work fairly well. (As long as you use Q6 or higher)
I just run them with LM Studio. DSLR can then talk to that like any other openai endpoint.

I couldn't tell you how they actually compare with Gemini Nano though, because I still have basically no data from that thing.

I Actually have tried both Qwen AI with Lm Studio, they didn't translated for me, and tried with Gemini Nano.

A Simple RPGmaker game(without much text), can be in between 2-5 minutes. For a fairly large game, 25-40 minutes, and a huge game, one hour to more.

Gemini Nano was built to run even in a potato of a pc, but when more powerful your pc is, better response this engine has.


I don't know about plugins on your application, but if you want i can try to create a plugin to integrate for you

 

[Shisaye]

I Actually have tried both Qwen AI with Lm Studio, they didn't translated for me, and tried with Gemini Nano.

That's confusing. As far as my tests with "normal" LLMs went, the abliterated versions of qwen3vl are by far the best local models available.
How did you use them and at what quant?
They perform pretty bad if you use a quantization below Q6.
And of course running them on CPU is dreadfully slow, they need to be offloaded to VRAM to have reasonable speed. (But even the 4B versions aren't thaaat bad.)

If you want, give me an example project, I'll translate it with qwen3vl and then you can compare it with your nano results.

I don't know about plugins on your application, but if you want i can try to create a plugin to integrate for you

If you want to make something, go ahead.
But I'm not entirely sure if it's worth the effort, only do it if you would use it yourself.
Personally I'm translating stuff with DeepSeekV3.1-terminus, but of course that's not free.

It would need to be fed through the SLRtrans wrapper/escaper system or it will screw up scripts.
You can find examples of how that should look like in the www>addons>SLRtrans>lib>TranslationEngine folder.

 

[Shisaye]

I've released v2.042
Since looking up the different model variants can be annoying I've added a new bit to the manual that gives specific LM Studio recommendations based on hardware.
Even if you just have a GPU with 4GB VRAM, as long as it's CUDA/VULKAN capable using DSLR you can get significantly better results than SLR. (And it's still free and offline.)
But please don't waste your time if you would have to run the primary model on CPU. It would take so long that you would spend significantly more money on power than it would cost to use DeepSeek instead.


Changelog since last changelog post:

2.042
Changed some cell tagging for VX.
Fixed some DSLR log entries.
Added new section to the manual with model variant recommendations based on hardware.

2.041
Choice box entries with "|" in them will now be tagged yellow.
Fixed some typos.

2.040
Changed handling of MZ plugins in Commonevents to work with damaged or certain non standard code.

2.039
Adjusted descriptions, documentation, and presets to reflect the OpenRouter changes.

2.038
Fixed some wrong DSLR console logs.
Changed the agressive prompts for Full Batch to mention placeholders.
Updated the DSLR entry of the manual.

2.037
Added some new plugins.js tagging.
Added some patterns to add spaces behind variables if they are followed by stuff like "times".
Added new error check to DSLR Full Batch to reject batches if it completely failed to preserve placeholders or commands.

2.036
Added new repetition_penalty parameter option to DSLR and SEP.
Fixed some minor bugs.
Updated some descriptions.

2.035
Fixed bugs related to v2.034.
Changed some log messages.

2.034
Added new (default ON) option to SLRBatch that presses the "Prepare Project for Batch Translation" button when trying to run a batch translation, if the user has never pressed it before on this project.

2.033
TRANSLATIONFAIL error codes will now be removed when pressing the "Fix Cells and Check for Errors" button, instead the cells will be tagged purple.
Fixed it wrongly keeping the fallback model for all single requests of the batch instead of just the failed one.

 

[Shisaye]

I've released v2.045.
Significant changes to DSLR. If you use that, you should definitely update.


Changelog since last changelog post:

2.045
Introduced new "bad translation" purple tags for wrong line count and missing numbers.
Changed Batch size calculation to just be characters again.
DSLR Changes:
Changed Full Batch divider logic.
Changed wrapper so IDSP will no longer cause a sentence to split.
Added option (on by default) to remove all inner IDSP before sending the request to the LLM
Changed Full Batch calculation to never allow more than twice the maximum size even when it produces less than 40 entries.
Changed Full Batch calculation to be a lot less lenient in counting.
During Single requests wrong linecount is now only a reason for a rejection if it's also either significantly more characters or significantly less.
Changed how context is sent to the LLM, it will now also include the original text and not just successful translations.
It will now always send all error context even on the first try.
Changed log messages to be more accurate.
Changed some wrong descriptions.

2.044
Improved D_Text handling for DSLR, added some isolation patterns for DSLR.

2.043
For DSLR changed console log messages to actually show the entire request body including parameters and prompts instead of just the requested text.
Implemented new check for FullBatch that will now reject a batch if it failed to preserve more than 50% of text commands and placeholders. It wil also reject a batch if the LLM added 50% more than the original amount.
Implemented new detection for "response refusal" messages, but only a few variations so far. It will treat them as Server Errors.
Adjusted a bunch of descriptions.
Fixed some typos.

 

[Shisaye]

I've released v2.046.
I've added experimental support for translations other than Japanese to English to DSLR.
Refer to the manual as to how it works.
It's still kinda annoying to setup, and basically not tested, but at least trying to do that no longer outright crashes everything.

 

[Shisaye]

I've released v2.047.
Added support for v4 endpoints.
Tested it with a coding api running GLM-4.7.
It worked really well.

 

[Shisaye]

I've released v2.050 v2.051.
Biggest update in a while.
Loads of improvements and new options.

Happy New Year!

Changelog since last changelog post:

2.051
Fixed issues with some v1 endpoints.
Updated manual.

2.048-2050
Fixed placeholder recovery system.
Added v4 api support to SEP, including option to disable thinking.
SEP's api setting will now also automatically add v1/chat/completions/ if there is nothing similar.
Fixed tons of typos.
DSLR:
Added new options to specify how commands and placeholders are sent to the LLM.
Added automations to adjust placeholder mentions in prompts and error handling based on the currently chosen replacements.
Added option to replace all linebreaks with <br> before sending them to the LLM.
Added special automation for using html5 paragraph tags instead of dividers. (In theory, not tested)
The fallback model will now have its own batch calculation and options.
Added new Max Sent Placeholders option to limit batch size based on how many placeholders or commands are already in it.
Changed all prompts.
Adjusted descriptions.
Changed Options menu order.
Fixed \\i[] commands not making it to DSLR.
Fixed some typos.

2.047
Added DSLR support for v4 endpoints including its thinking parameter.
Cleaned up the old SLR code.

2.046
Added Experimental support for translations other than JP>EN.
Added new General Options called Japanese Language Source, and English Target Source.
They will attempt to skip all code parts that either expect the source to be Japanese or the Target to be English, that cannot be changed in the options menu.
Removed the obsolete character counting option.
To actually use DSLR for other translations the user still needs to adjust prompts and wrapper patterns. There is no automation for that.
Changed the sizes of the DSLR option menu entry fields.
Updated the manual and several descriptions to reflect the changes.

 

[Shisaye]

I need some opinions.
The Attached txt files are the contents of a Map001 file in original and 6 translation attempts.
Please rank them for me based on translation quality.
I purposely did not make them a single table, because this is not about nitpicking a single translation, but to compare the readability of the entire block.

If you view multiple as of identical quality just rank them the same.
If you view all of them the same, please still post about it.

This is actually really important going forward.