konstant61
Member
- May 3, 2017
- 226
- 85
- 291
- Thread starter LordGamer00
- Start date
- Aug 27, 2022
- 136
- 202
- 217
I understand the struggle completely. Since we are in the same boat, I hope you can understand the limitations better.
When I started developing this project, there were no free automatic Ren'Py translation tools available (or the existing ones were very limited). My goal from day one was to create a free tool accessible to everyone. However, financial constraints have followed me my whole life, and I have only managed to bring the project to this point despite these impossibilities.
For the last few updates, I have been trying to fix non-Google engines blindly. I will take one last look at them in the next update. However, after that, I will mark all non-Google engines as 'Experimental'. To be honest, working blindly without the hardware/budget to test them is just wasting time and is mentally exhausting for me.
I wish you the best of luck in finding a new opportunity soon. Let's hope things get better for both of us.
konstant61
Member
- May 3, 2017
- 226
- 85
- 291
This is the Unicode error that I meant...when I corrected some translation errors in strings.rpy...
- Aug 27, 2022
- 136
- 202
- 217
This error is not caused by RenLocalizer itself, but by how you edited the file afterward.
The Problem: When you edited strings.rpy and saved it, your text editor (likely Windows Notepad) saved the file in a different encoding (Windows-1252 or Windows-1251). Ren'Py only accepts UTF-8 encoding, so it crashes when trying to read the file.
The Fix:
Download and install Notepad++ (free)
Open the problematic file: game/tl/russian/strings.rpy
Go to menu: Encoding → Convert to UTF-8 (or "UTF-8-BOM")
Save the file (Ctrl+S)
Try launching the game again.
Pro Tip for the Future: Always use Notepad++ or VS Code when editing .rpy files. Windows Notepad can corrupt non-English characters.
Let me know if it works!
konstant61
Member
- May 3, 2017
- 226
- 85
- 291
I just wanted to check this...we'll see...
P.S. But first I need to have lunch...)))))))))so to speak, to gain strength...
P.S. But first I need to have lunch...)))))))))so to speak, to gain strength...
konstant61
Member
- May 3, 2017
- 226
- 85
- 291
As far as I know, the standard Unicode encoding is simply UTF-8. I don't know why you installed UTF-8 BOM...
- Aug 27, 2022
- 136
- 202
- 217
You are right, standard UTF-8 is usually sufficient and is the industry standard. I only suggested BOM as an alternative because some specific text editors on Windows sometimes handle it better.
However, based on the error log you shared, the file is currently saved as neither. It is saved as Windows-1251 (ANSI). That is why it crashed. So, you can simply save it as Standard UTF-8 (without BOM) as you prefer, and it will work perfectly.
konstant61
Member
- May 3, 2017
- 226
- 85
- 291
I saved the files in standard UTF-8 mode...without any additions...
P.S. UTF-8 BOM works...Game is running...
P.S. UTF-8 BOM works...Game is running...
- Aug 27, 2022
- 136
- 202
- 217
denadm
Member
- Apr 7, 2023
- 173
- 207
- 227
Hello. I'm facing a dilemma. I use a script bat UnRen or renpy-sdk for language parsing, but in some cases, depending on the quirks of the novel's developer, they don't extract the files to the tl folder. What if I add a separate parser to this program, with an input field for the desired language, but a more in-depth analysis is required. Is that possible? I would be grateful.
- Aug 27, 2022
- 136
- 202
- 217
I faced the same issue myself: sometimes relying on standard decompilers (like UnRen) or parsing only .rpy files isn't enough.
I discovered that many text strings actually remain trapped inside the compiled .rpyc files and never make it into the decompiled .rpy. Even if you successfully decompile the game, some critical strings (especially dynamic ones in screens or init blocks) are simply missing from the source code. That's why I spent so much time implementing a native RPYC Reader directly into RenLocalizer.
So, yes! Extending the parser is definitely possible and recommended. Here are a few areas you might find helpful based on my experience:
- RPYC & RPYMC Reading: Instead of relying on an external unrpyc tool, writing a direct AST reader (using Python's pickle mechanics) allows you to extract all of the game's data, including those tricky hidden strings. My project does this in `src/core/rpyc_reader.py`. It reads both script bytecode and screen caches (.rpymc).
- Screen Language (SL2) Parsing: A lot of 'missing' text lives in complex screen definitions (buttons, tooltips, frames). A standard line-by-line parser misses these. You need an approach that understands Ren'Py's Screen Language structures.
- Technical Filtering: Parsing everything also means getting a lot of garbage code (like file paths or variable names). You'd need a robust filter (I use a symbol density heuristic) to distinguish between 'Dialogue' and 'Code'.
If you want to create a custom parser module, check out `src/core/parser.py` in the repo. It's designed to be modular, so you could easily plug in a 'Deep Analysis' logic there. You can use, adapt, or develop the current RPYC reading logic (`src/core/rpyc_reader.py`) as you see fit. I recommend using it as a basis for your in-depth analyses because writing something from scratch is really headache-inducing. Building on top of something open source is less of a headache. Also, once you're done, I'd love to take a look at your code—if you don't mind, of course. Maybe I'll discover a few tips that I can add to my program.
denadm
Member
- Apr 7, 2023
- 173
- 207
- 227
I would gladly use it, but I'm not a programmer. I use AI, but I've used up my two-week limit in the VS Code program, and the alternative AI there isn't as advanced, and I can't afford to pay, given the situation in Ukraine.
It's one thing to pay a couple of bucks for the OpenRouter API and translate a dozen novels, but it's another thing to pay these corporations many times more.
Browser-based Gemini or Copilot can give useful advice, but it's difficult to shuffle code when you don't understand it, and the result is some kind of bullshit.
Therefore, all hope rests on you, if you understand this or have the means to do so.
I noticed an important bug, used deepl. The program does not distinguish between [] and possibly {}.
Example: [RYD] translates as XRPYXVAR0XRPYX and writes an error message: PLACEHOLDER DAMAGED.
But when I added {} and [] to the glossary, the translation was successful.
It's one thing to pay a couple of bucks for the OpenRouter API and translate a dozen novels, but it's another thing to pay these corporations many times more.
Browser-based Gemini or Copilot can give useful advice, but it's difficult to shuffle code when you don't understand it, and the result is some kind of bullshit.
Therefore, all hope rests on you, if you understand this or have the means to do so.
I noticed an important bug, used deepl. The program does not distinguish between [] and possibly {}.
Example: [RYD] translates as XRPYXVAR0XRPYX and writes an error message: PLACEHOLDER DAMAGED.
You don't have permission to view the spoiler content.
Log in or register now.
But when I added {} and [] to the glossary, the translation was successful.
Last edited:
- Aug 27, 2022
- 136
- 202
- 217
Honestly, I'm not a programmer either. I’d describe myself as a "vibecoder" since I build everything 100% using AI too. I know exactly how painful it is to be stuck with dumb or limited models when the credits run out—it really kills the workflow.
Just a friendly tip: check out "Google Antigravity". It's a new IDE from Google and since it's in preview, it's currently free with much higher limits than standard chat or VS Code trials. It might save you some headache.
Regarding the parser, I'm not sure how much I can improve the filtering right now because I'm currently focused on a more annoying issue specifically with Google Translate. I added an "Aggressive Translation" mode, but it's still not perfect. The tool successfully detects the text and sends it to the API, but for some reason, Google simply returns it untranslated. It’s not a detection failure—the request goes out, but it comes back raw. This happens to about 1-5% of the lines depending on the game.
So, for the next update, I'll likely review the non-Google engines one last time and mark them as "Experimental". Trying to fix or configure them blindly without proper testing is a massive headache.
Spending money on APIs is really tough when the budget is tight. I'm in a similar boat—I managed to snag my current AI subscription at a 1/3 discount, but I have no idea what I'll do once that runs out
. This lack of funds really ties my hands; I can't properly test other translation engines because they require paid credits. So, honestly, I don't know if the non-Google engines are working correctly right now. My impression is that it's hit-or-miss; they work for some users and fail for others.