Closed yuxi-liu-wired closed 4 months ago
I found the solution, I think. I just need to add the encoding='utf-8',
option every time I import logging
.
logging.basicConfig(
format='%(levelname)s: %(message)s',
encoding='utf-8',
level=logging_level
)
Thanks for the report, I'll take a look. Adding encoding to the logger config makes sense, but it should only be necessary to do it in the main scripts (gpt-subtrans.py, gui-subtrans.py) as they configure a global logger instance.
Actually now that I think about it I have vague memories of Windows causing problems when I tried to specify the encoding for the console logger, so I ended up leaving it with default encoding... it might be necessary to add a command line argument to set the encoding, or to write a test message in a try-catch block and fall back to default encoding if it fails.
Can you try this? It attempts to log as utf-8 and falls back to default encoding if it fails: https://github.com/machinewrapped/gpt-subtrans/commit/c60d8fb5ebdfae8251df00d7adf52f12f318b163
I haven't seen it fail yet so the fallback is untested, I'll see if I can remember under what conditions utf-8 wasn't supported.
I have tried this and it works as expected. There are no error messages in the command line or the GUI, and the translation works, and the savefile works.
First attempt:
.\gpt-subtrans test.srt --project True --scenethreshold 10 --target_language "Simplified Chinese"
Second attempt:
gui-subtrans
. It translated about 100 lines correctly, but then started throwing errors like this on the command line, and after throwing this error for a while, the GUI abruptly died.Third attempt:
test.subtrans
. Got errorLoading
test.srt
directly gives the same error. Deleting thetest.subtrans
would allow loadingtest.srt
again, but starting anew.