konstant61
Member
- May 3, 2017
- 226
- 85
- 291
- Thread starter LordGamer00
- Start date
- Aug 27, 2022
- 135
- 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
- 135
- 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
- 135
- 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
- 135
- 202
- 217
denadm
Member
- Apr 7, 2023
- 172
- 206
- 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
- 135
- 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.
