Tool RPGM SLR/DSLR/SEP - Translation Engines for RPG Maker VX, VX Ace, MV, MZ, and Pictures

[CodedGamer]

That Commonevents has to be one of the weirdest I've ever seen.
I don't think that was made with the official MZ editor.

I've changed the core MZ plugin parsing for Commonevents to make it no longer crash, which I'm definitely not going to regret, and I'm not even sure if it exports correctly now, because I'm not sure what those bits are even supposed to do.

Please try again with v2.040.

It works now.
Thank you and sorry for the trouble.

 

[derakino999]

hi, requesting halp
can you check why does prisoner soldier mahou shoujo nonaka karen RJ01366739 always get stuck at 20% in the trying to check for errors in translated cells part?
the part where it checks wrong translations and then tells you to search shisaye and purple tag
idk if it's an issue on my end but it always happens at 20% i've tried many times
also worth noting i translated the game with google because sugoi gives poor results with certain games, and i believe it is the case here as well
though i doubt translating with sugoi would fix the problem

magical girls ftw btw

https://f95zone.to/threads/translat...naka-karen-yamaimoyamamomo-rj01366739.279905/

 

[Shisaye]

hi, requesting halp
can you check why does prisoner soldier mahou shoujo nonaka karen RJ01366739 always get stuck at 20% in the trying to check for errors in translated cells part?
the part where it checks wrong translations and then tells you to search shisaye and purple tag
idk if it's an issue on my end but it always happens at 20% i've tried many times
also worth noting i translated the game with google because sugoi gives poor results with certain games, and i believe it is the case here as well
though i doubt translating with sugoi would fix the problem

magical girls ftw btw

https://f95zone.to/threads/translat...naka-karen-yamaimoyamamomo-rj01366739.279905/

Tested on v2.040 with the latest version of the game, full game translated on standard settings with SLR.
Error checking took less than a minute on an old i7-6800 CPU @ 3.40GHz, no errors detected, just 1 purple cell with a bad translation.

 

[derakino999]

Tested on v2.040 with the latest version of the game, full game translated on standard settings with SLR.
Error checking took less than a minute on an old i7-6800 CPU @ 3.40GHz, no errors detected, just 1 purple cell with a bad translation.

yeah, just checked, it does work if you translate it with sugoi, but not with google

 

[Shisaye]

yeah, just checked, it does work if you translate it with sugoi, but not with google

...then don't?
I assume you mean batch translating with normal "Google" not "SLR Google", because otherwise the translation quality would be basically the same because it would escape all the scripts and cut the sentences in tiny snippets.
And using normal Google is something the manual explicitly tells you not to do.

Not that anyone would actually read the manual.

 

[derakino999]

...then don't?
I assume you mean batch translating with normal "Google" not "SLR Google", because otherwise the translation quality would be basically the same

the same as what? i don't understand
the same quality as sugoi? because no,

sugoi gives poor results with certain games, and i believe it is the case here as well

and yea i'm using normal google, what is SLR google?

and i did read the manual long ago but maybe i forgot that part
EDIT: oh hold on, i misunderstood, SLR google is like google but made to work with the tool setings?

 

[Shisaye]

the same as what? i don't understand
the same quality as sugoi? because no,

and yea i'm using normal google, what is SLR google?

and i did read the manual long ago but maybe i forgot that part

"Uses Google, it crashes and doesn't work."
"Admits to never even having used SLR Google (the second Google entry in the translator list that actually makes it no longer crash, but like sugoi based SLR significantly decreases translation quality for text command heavy games)."
"Still states that Google is obviously better than SLR"

 

[derakino999]

"Uses Google, it crashes and doesn't work."
"Admits to never even having used SLR Google (the second Google entry in the translator list that actually makes it no longer crash, but like sugoi based SLR significantly decreases translation quality for text command heavy games)."
"Still states that Google is obviously better than SLR"
View attachment 5514658

i thought the translation was poor because of ming's sugoi offline translator itself not liking the format of text in certain rpgm games, not because of your tool, also i didn't know what SLR google was and now that i opened the manual again it doesn't say
i suppose it's googletranslate but then the text is post processed by your tool scripts?
when i first saw it long ago i thought it was like an autofix for wrong translations that used google on each one of them after translating everything with sugoi, but it should be obvious now what it actually is
but yea like i also remember a red google option here or in translator++ not sure and i have no clue what that was either
anyway thank you for your help, it worked

 

[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]

Since the current implementation of user written context prompts just dumped at the end of the system prompt isn't great I thought about using

You must be registered to see the links

to give the LLM more context.
Since it has support for .trans files and is open source I could "technically" even fork it and integrate it directly into DSLR.

The issue is that I have no clue how someone is supposed to use it and how to actually properly prompt with its output.

If someone has experience with it please tell me about it.

 

[Shisaye]

Another question:
How aggressive should DSLR be in rejecting translations?

Let's say for example the original text includes the number "1", but the offered translation does not include "1", "１", "one", or "first".
Should that translation always be rejected?

Or what if the original includes the punctuation "！", but the translation does not include "!", or "！". Should that be an automatic rejection?


Or should it just accept stuff like that and tag the cell purple?


Edit: I could obviously just make that a toggle in the options menu, but what should be the default setting?

 

[RTS23]

Another question:
How aggressive should DSLR be in rejecting translations?

Why not make it a slider and/or multiple options? These kind of questions are heavily dependent on the translator judgement, which also may differ depending on the game (puzzles require more precision than pure VNs). Thus, I believe they should be somewhat customizable.

Also, I wanted to ask because I forgot/it's have been a while ever since I used SLR translator last, is there an easy way to customize text codes? In the sense, I wanna replace line break text command "\n" with "<lf>" (and force a maximum number of line breaks or otherwise log an error), instead of preserving "\V[x]" and other "\x[x]", preserve "<cf>" and whatever may fit "<x>".

I am asking this because I'm trying to translate a chinese Unreal Engine 4 game. I know it's completely unsupported, but just wanted to know the viability before rulling out the tool. What I got is just a 2M lines file with english engine and chinese text with those codes, which I yet have to find out what they really do.

As always, I'm getting into places I've never been before. I don't have any idea on how LLMs good do in chinese to english translation, don't have tooling, and the work seems way too big, but still I have to give it a go or otherwise wouldn't be me.

EDIT: After reviewing what RPGMaker encoding was, I realize SLR is way too advanced for what this game needs. The only part I would use is the image OCR, which I haven't used yet, so great.

 

[Shisaye]

Why not make it a slider and/or multiple options? These kind of questions are heavily dependent on the translator judgement, which also may differ depending on the game (puzzles require more precision than pure VNs). Thus, I believe they should be somewhat customizable.

The question is about the default setting though.

Also, I wanted to ask because I forgot/it's have been a while ever since I used SLR translator last, is there an easy way to customize text codes? In the sense, I wanna replace line break text command "\n" with "<lf>" (and force a maximum number of line breaks or otherwise log an error), instead of preserving "\V[x]" and other "\x[x]", preserve "<cf>" and whatever may fit "<x>".

I am asking this because I'm trying to translate a chinese Unreal Engine 4 game. I know it's completely unsupported, but just wanted to know the viability before rulling out the tool. What I got is just a 2M lines file with english engine and chinese text with those codes, which I yet have to find out what they really do.

Short answer: No.

Long Answer: Fuck No.



Fine...
Actual answer: If you want something not sent to the LLM, or sent as a different placeholder you need to change the entries in the DSLRTranslationEngineWrapper.js (Technically you can do that from the options menu, but it's honestly easier to edit in the file). If you want to add a new rejection reason you need to add that to the second part of the DSLREngine.js when it says "//Single Translation Request Processing". You could also add a check to the Full Batch Processing like the checkCommandPreservation function, but I honestly kinda regret that one already. (It re-doing an entire batch for some lost placeholders really isn't much more token efficient than just sending single requests for the screwed up lines.)
Additionally you would obviously need to change all the prompts to actually tell the LLM to preserve the new stuff and that it's working with Chinese now. (And turn off the "Japanese Source" setting.)
As for the linebreak stuff you could just fix that in post using regex.

TLDR: It's not a good idea, there's not much benefit to it, couldn't you just use LinguaGacha, or something like that?

 

[RTS23]

The question is about the default setting though.

Oh, sorry. I did not get the edit because I was writting the post. I take a long time writting anything.
Maybe I would change my mind if I were to see many other situations, but I believe the default should be "No reject" to give some sway in the translation process.
I suppose that the times "reject" would help do not compensate the quantity of repeat translations for something it's usually fine in most cases. The feature is great, tough.

TLDR: It's not a good idea, there's not much benefit to it, couldn't you just use LinguaGacha, or something like that?

Yeah, I relized after checking out RPGMaker encoding. Way too complex for what I really need.
The thing is that SLR Translator is the first "create a translation" tool that I've ever used, everything else was automatic translator hooks and whatnot crap from a long time ago. So I'm a bit lost on what tools are available that support LLMs.
Thanks for the evaluation, though.

 

[Shisaye]

Yeah, I relized after checking out RPGMaker encoding. Way too complex for what I really need.
The thing is that SLR Translator is the first "create a translation" tool that I've ever used, everything else was automatic translator hooks and whatnot crap from a long time ago. So I'm a bit lost on what tools are available that support LLMs.
Thanks for the evaluation, though.

I'm trying to keep SLR Translator focused to not just end up with a second Translator++.
(A tool that claims to do everything, but can't do anything correctly.)

I'm not super against trying to branch out to something not RPG Maker at some point, but you have to remember that this is just an unpaid hobby, I already invest way too much of my life to translate random smut.

Another issue is that a lot of the time there isn't really a "bulk" of games to translate.
It doesn't really make sense for me to make a new parser and translation engine for a single game.
RPG Maker is kinda special in being so streamlined and popular. With other game engines devs always feel the need to re-invent the wheel. Except maybe generic visual novels, but they have enough translators already.

 

[Shisaye]

To better rephrase my question with a bigger example. (But I actually mean a lot more stuff.)
Should stuff like this be grounds for a translation retry during single line checking? (By default, but can be turned off.)

if ((origstuff.match(/[0０]/gi) != null && shistuff.match(/0|０|zero|null|nothing/gi) == null) || (origstuff.match(/[1１]/gi) != null && shistuff.match(/1|１|one|first|single/gi) == null) || (origstuff.match(/[2２]/gi) != null && shistuff.match(/2|２|two|second|double|pair/gi) == null) || (origstuff.match(/[3３]/gi) != null && shistuff.match(/3|３|three|third|triple|trouple/gi) == null) || (origstuff.match(/[4４]/gi) != null && shistuff.match(/4|４|four|quadrouple/gi) == null) || (origstuff.match(/[5５]/gi) != null && shistuff.match(/5|５|five|fifth|penta/gi) == null) || (origstuff.match(/[6６]/gi) != null && shistuff.match(/6|６|six/gi) == null) || (origstuff.match(/[7７]/gi) != null && shistuff.match(/7|７|seven/gi) == null) || (origstuff.match(/[8８]/gi) != null && shistuff.match(/8|８|eight/gi) == null) || (origstuff.match(/[9９]/gi) != null && shistuff.match(/9|９|nine/gi) == null) || (origstuff.match(/[!！]/gi) != null && shistuff.match(/!|！/gi) == null) || (origstuff.match(/[\?？]/gi) != null && shistuff.match(/\?|？/gi) == null) || (origstuff.match(/[\$＄]/gi) != null && shistuff.match(/\$|＄|dollar|yen|money|gold|currency/gi) == null) || (origstuff.match(/[\%％]/gi) != null && shistuff.match(/\%|％|percent/gi) == null)) {
    retry() || tagPurple() || lewdTheLolis();
}

Or should it just paint a cell purple to notify the user that there is potentially something fucky, but ultimately do nothing about it?

(And yes I love writing incredibly inefficient long code.)

Edit:
Another option would be to only have that active during the first line by line checking of an accepted Full Batch, and not actually when receiving a single translation from the LLM.
Meaning it would cause a single translation request for a line that was part of an accepted Full Batch, but it would not reject the response if the LLM still doesn't include it.

 

[RTS23]

Oh, you are also considering interrogation and exclamation marks. I assumed that you would treat them differently, but it makes sense to group them with the numbers. The only case I don't really feel it is with "currency", as I cannot think of any phrase translating cost value to currency (e.g. "5$" to "5 of the currency"), though consider also adding the yen, (maybe euro?) symbols to the origstuff and coins, silver to shistuff.

Translating only the line with the infraction instead of the whole batch I believe is better in the long run, as that way you don't spent too much in retries. Then maybe I would consider the default to be "reject the line" if the cost of retry is low (only that line).

To be honest, I haven't used much the colors but neither did I produce a serious translation, so I'm not the best to talk about colors. I don't know, if there were a way to hide the other colored cells and files, that would make it easier to find out what lines are wrong. Now that I'm saying it, I believe it may actually have this feature and I just didn't use it because I'm dumb.
I was more busy on finding out what translated cells produced over 4 lines, requiring an additional window that I didn't like.

(There is no inefficient code, everything is solved by the compiler, and it doesn't feel wrong as all the line is for the same purpose)

 

[Shisaye]

I was more busy on finding out what translated cells produced over 4 lines, requiring an additional window that I didn't like.

If you just want to know which cells have more than 4 lines, why not just mark them with regex?
You wouldn't even need to make a custom script for it you could just do something like this in the search>replace menu after activating regex:

You must be registered to see the links

And then search for <HASMORETHAN4LINES>

 

[Shisaye]

Oh, you are also considering interrogation and exclamation marks. I assumed that you would treat them differently, but it makes sense to group them with the numbers. The only case I don't really feel it is with "currency", as I cannot think of any phrase translating cost value to currency (e.g. "5$" to "5 of the currency"), though consider also adding the yen, (maybe euro?) symbols to the origstuff and coins, silver to shistuff.

I guess I still didn't fully get across what I mean.
I'm even considering just adding words. So that if the original has one of the words ペニス, 陰茎, ディック, or チンポ , it does not accept a translation that does not include penis, cock, dick, phallus, prick, stick, rod, member, tool, thing, wand, sword, weapon, finger, spear, lance, or meat.

And I made that example list in like 2 minutes I didn't seriously think about it, yet.

The main goal would be to identify when the LLM put a translation in the wrong line, or when the LLM didn't faithfully translate, but just decided to leave stuff out.

Edit: But the more I think about it, that should just trigger a single line correction attempt of an accepted full batch, because if a LLM refuses to include that in a direct single line request, it's also not going to do it on a retry.
And if it doesn't change it if asked about it specifically, then tag it purple.

Edit2: Maybe I should actually just stick to obvious stuff like numbers though considering how much of a mess Japanese is...

 

[fantasmic]

Another question:
How aggressive should DSLR be in rejecting translations?

Let's say for example the original text includes the number "1", but the offered translation does not include "1", "１", "one", or "first".
Should that translation always be rejected?

Or what if the original includes the punctuation "！", but the translation does not include "!", or "！". Should that be an automatic rejection?


Or should it just accept stuff like that and tag the cell purple?


Edit: I could obviously just make that a toggle in the options menu, but what should be the default setting?

I think the default setting should be to just tag it purple. Automatically rejecting things like that could lead to DLSR being a bit too aggressive, when it'll probably take me just as long as the AI to come up with a good-enough tweak to the translation. I never mind doing a little manual work, and the purples can also clue me in to something weird the dev decided to do.
Purples have always been quite manageable until now, with most of the ones I find being either obviously weird (so I would've ended up editing them anyway once I encountered them in-game) or easy to write off as a style choice.

If you just want to know which cells have more than 4 lines, why not just mark them with regex?
You wouldn't even need to make a custom script for it you could just do something like this in the search>replace menu after activating regex:

You must be registered to see the links

And then search for <HASMORETHAN4LINES>

Man, every few months I think "I should figure out a script for this" then end up just scanning the project manually (which isn't as much work as it sounds), when it turns out the the answer this whole time was -- as I really should be expecting by now -- "just learn regex."