- Jul 23, 2021
- 42
- 106
I did the same, just translated with Google Translate and then Figma. Takes so much time, we need to think about some automatization
- Jun 26, 2020
- 23
- 4
- Dec 29, 2017
- 3,181
- 5,505
I'm sorry, but I can't help you with that.
Sugoi is only trained for Japanese to English and my dictionary system also only includes that.
I have no information about Indonesian translation models.
- Dec 29, 2017
- 3,181
- 5,505
I'm not sure I understand.May I ask if it's more accurate to exclude variable scripts？
What specifically do you want to exclude and why?
Is something being translated that shouldn't?
Last edited:
Is it possible to detect that some authors include variable scripts in the dialog text?
Many authors prefer to put variable scripts in text instead of JS plugins
- Dec 29, 2017
- 3,181
- 5,505
What exactly do you want SLR Translator to do differently? Is something breaking?Is it possible to detect that some authors include variable scripts in the dialog text?
Many authors prefer to put variable scripts in text instead of JS plugins
Currently if a script is included in the dialogue it should automatically be escaped during batch translation and stay intact.
Last edited:
- Dec 29, 2017
- 3,181
- 5,505
https://f95zone.to/threads/slr-tran...aker-vx-vx-ace-mv-and-mz.208393/post-14155064
You can also find explanations for them if you press F1 inside the tool.
- Dec 29, 2017
- 3,181
- 5,505
I've released v1.071.
There were some cases of speech bubble characters getting eaten during batch translation.
I still don't know what's causing it because it's rare and inconsistent, but I've simply added another check at the end that looks at the original Japanese text and if it sees a speech bubble character in there that is not present in the Initial translation it will place it in there.
I've also changed the potential file name error to only report if it doesn't see Japanese, because why report a potential file name, if it wasn't even translated and doesn't break anything.
There were some cases of speech bubble characters getting eaten during batch translation.
I still don't know what's causing it because it's rare and inconsistent, but I've simply added another check at the end that looks at the original Japanese text and if it sees a speech bubble character in there that is not present in the Initial translation it will place it in there.
I've also changed the potential file name error to only report if it doesn't see Japanese, because why report a potential file name, if it wasn't even translated and doesn't break anything.
- Dec 29, 2017
- 3,181
- 5,505
I've released v1.072.
This update is going to really annoy some people who don't care about translation accuracy, but I care and this is my tool. >:C
I've introduced a new error check that compares the size of the original text with the translation.
Japanese almost always uses less characters to convey the same information as English.
So for example if the input is 2 lines with a total of 30 characters, and the output is 1 line of 10 characters, that translation cannot be accurate, and it will report it as such.
If you absolutely do not care and you just want to use this for a quick MTL, then you can open up the "transredbatch.js" in the "www/addons/transRedBatch" folder, and delete the two blocks named "Report Sugoi Errors" and "Report potentially eaten lines".
This update is going to really annoy some people who don't care about translation accuracy, but I care and this is my tool. >:C
I've introduced a new error check that compares the size of the original text with the translation.
Japanese almost always uses less characters to convey the same information as English.
So for example if the input is 2 lines with a total of 30 characters, and the output is 1 line of 10 characters, that translation cannot be accurate, and it will report it as such.
If you absolutely do not care and you just want to use this for a quick MTL, then you can open up the "transredbatch.js" in the "www/addons/transRedBatch" folder, and delete the two blocks named "Report Sugoi Errors" and "Report potentially eaten lines".
Last edited:
- Dec 29, 2017
- 3,181
- 5,505
Some clarification on what is going on when lines are being eaten.
Usually that is caused by some kind of short noise and then some type of unicode emoji at the start of a cell.
For some reason that can cause Sugoi to get stuck.
I've tried to always escape special unicode characters to never send them to Sugoi in the first place, but that had pretty terrible effects on translation quality. For example a situation becomes very different depending on whether or not something is followed by a heart and the lack of context means just re-inserting them in post makes some text really silly.
To still fix Sugoi getting stuck you can add the noise with the emoji to the escaper and a translation to the dictionary. It will then no longer send it to Sugoi and the entire text will be correctly translated.
Now obviously I don't actually expect people to do that themselves, but I need to know it's happening in the first place.
So if you notice a SHISAYE.UNUSUALLYSHORT error please post the contents of the Original Texts and the Initial Translations cell of that row here so I can prevent that instance from happening in the future.
I've been already collecting those obviously, but now with that error check it's much easier to actually notice them.
In general please report problematic cells that are not obvious false positives.
Usually that is caused by some kind of short noise and then some type of unicode emoji at the start of a cell.
For some reason that can cause Sugoi to get stuck.
I've tried to always escape special unicode characters to never send them to Sugoi in the first place, but that had pretty terrible effects on translation quality. For example a situation becomes very different depending on whether or not something is followed by a heart and the lack of context means just re-inserting them in post makes some text really silly.
To still fix Sugoi getting stuck you can add the noise with the emoji to the escaper and a translation to the dictionary. It will then no longer send it to Sugoi and the entire text will be correctly translated.
Now obviously I don't actually expect people to do that themselves, but I need to know it's happening in the first place.
So if you notice a SHISAYE.UNUSUALLYSHORT error please post the contents of the Original Texts and the Initial Translations cell of that row here so I can prevent that instance from happening in the future.
I've been already collecting those obviously, but now with that error check it's much easier to actually notice them.
In general please report problematic cells that are not obvious false positives.
Last edited:
- Nov 3, 2021
- 391
- 934
I just realized I was still on v1.070 so this might not be relevant anymore but:
I got a weird thing where the SLR replaced seemingly random words with "Booth".
I was editing RJ01108188 (MV). There were 8 affected cells, but it's a rather small game. I checked transredbatch and TranslationEngineWrapper for a smoking gun, but it's possible those weren't even the right places.
Though it's not a big deal and will likely be quickly caught by anyone who actually tests their patches.
I got a weird thing where the SLR replaced seemingly random words with "Booth".
You don't have permission to view the spoiler content.
Log in or register now.
Though it's not a big deal and will likely be quickly caught by anyone who actually tests their patches.
- Dec 29, 2017
- 3,181
- 5,505
I guess one of my changes since v1.070 fixed it, although I really don't remember it.
It looks fine to me...
(I just pressed the prep button, did batch translation, pressed the post button, and wrapped it to stint.)
(The first translation is obviously still terrible, but at least no weird booth character...)
- Dec 29, 2017
- 3,181
- 5,505
I've released v1.074.
A bunch of stuff, but the most notable is that my patterns for improving consistency in character usage (Restrict output to !?., instead of bouncing between special characters) is now active for all cell types instead of just dialogue.
I didn't use it for non dialogue because I can come up with a way to construct a plugin that would break from it.
But ultimately in all the games I've worked on I've never actually seen a dev do it, and it seems dumb to make certain parts of the translation worse just because I can "imagine" a plugin that "could" break from it.
Edit: To explain what I mean in case someone ever comes across it.
If someone would for some god forsaken reason format a plugin like a csv and then include "、"in one of the entries, then that would be replaced with ",", which would cause everything afterwards to be put in the wrong place, or just crash it entirely.
While I have seen cells in the plugins.js that separate stuff with "," , I have never seen such an entry with a "、" before.
Edit2:
I just realized I can fairly easily fix that.
I will just make a check whether or not the original text includes both ","and "、", and if it does the "、" will not be replaced.
Because why on earth would they use 2 different comma types in the same cell unless it's for a specific purpose, and then it would definitely not break csv stuff.
I will include that in v1.075.
I will also do checks for the other characters. So that if "!" and "！" exist in the same cell it will not replace the "！", and so on, just in case there's some really weird shit.
A bunch of stuff, but the most notable is that my patterns for improving consistency in character usage (Restrict output to !?., instead of bouncing between special characters) is now active for all cell types instead of just dialogue.
I didn't use it for non dialogue because I can come up with a way to construct a plugin that would break from it.
But ultimately in all the games I've worked on I've never actually seen a dev do it, and it seems dumb to make certain parts of the translation worse just because I can "imagine" a plugin that "could" break from it.
Edit: To explain what I mean in case someone ever comes across it.
If someone would for some god forsaken reason format a plugin like a csv and then include "、"in one of the entries, then that would be replaced with ",", which would cause everything afterwards to be put in the wrong place, or just crash it entirely.
While I have seen cells in the plugins.js that separate stuff with "," , I have never seen such an entry with a "、" before.
Edit2:
I just realized I can fairly easily fix that.
I will just make a check whether or not the original text includes both ","and "、", and if it does the "、" will not be replaced.
Because why on earth would they use 2 different comma types in the same cell unless it's for a specific purpose, and then it would definitely not break csv stuff.
I will include that in v1.075.
I will also do checks for the other characters. So that if "!" and "！" exist in the same cell it will not replace the "！", and so on, just in case there's some really weird shit.
Last edited:
- Dec 29, 2017
- 3,181
- 5,505
On an odd note.
I've noticed that sometimes the nw.js process get's stuck and even if you close SLR Translator it's still running in the background and eating resources.
I have no idea why that's happening.
It's super inconsistent, it seems really random.
If someone has an idea, please tell me.
I've noticed that sometimes the nw.js process get's stuck and even if you close SLR Translator it's still running in the background and eating resources.
I have no idea why that's happening.
It's super inconsistent, it seems really random.
If someone has an idea, please tell me.
- Nov 3, 2021
- 391
- 934
Shisaye, would you be willing to add support for TyranoScript games into the SLR? I've been messing around with Tyrano games recently, and while the whole process is a bit scuffed (extract using external tools, make the project, shift over to slr, prep/translate/error-correct, shift back to T++, export as folder, further edit the files in N++, repack with external tools) it does work in the end and things would be a little more convenient if I could just stay in the SLR translator the whole time.
Oh, also,
Oh, also,
I had this happen to me... uh... sometime last week? I figured it was because rpgm had crashed, which I attributed to something in plugins.js getting translated which souldn't have since the game worked fine after I substituted in the original plugins.js. Though since you brought it up, it's possible nw.js was already spinning out of control and that's why rpgm crashed. I'll try to pay more attention if it happens again.