itch.io

No problem, makes sense.

About the model URL thing—I meant that I have presets like Gemini 2.5 Flash that are made for that specific model, so you're good to go. But I also have presets where I just made a general template instead of making a million versions for every model, like with OpenRouter. The OpenRouter preset has a model in it, but if users want to change it, they gotta go find another one on their site. Since models change all the time and I was too lazy to make one for every single variation :(, I just went with a basic template.

Yeah, sorry about that—it’s so tiny and the color is so close to the app's theme that I totally missed it. Or maybe it just slipped my mind. Happens to me sometimes! :)

Nope, I think that’s it for what we have right now, but I’ll let you know if I find more. :)

Thank you! This app is just getting better and better. :)

*Edit

Since uploading is working again, I got as much up there as I could. I added Gemini 2.5 Flash and that OpenRouter one I mentioned. Azure is also included, where we'd need the language code in the API URL and the region in the headers.

Sorry, I don't remember. :)

Yeah, it wouldn’t let me edit it for some reason, so I just deleted it. I probably just missed something :) so I took it down, but I’ll upload it again gradually. Sorry about that! :)

Yeah, the API registration URL is a solid idea. 

The Description box has a character limit, so I couldn't put in all the info I wanted for some APIs. Plus, I hit a limit while uploading, so I couldn't finish adding everything. 

I'm not sure if this is the way to go, but it would be awesome if every important thing had its own URL and Description for the setup. Like, we need it for the API Key, Models, and Pricing/Limits. The model section would be for when a preset is just for the site in general—like my Cloudflare one—instead of a specific model. If it's already for a specific model like Gemini 2.5 Flash-lite, then we don't need that section. This might even keep the info more up-to-date so people don't always have to dig through the guide. Or would that be overcomplicating it? Just an idea! :)

*Edit

I totally blew it. I wasn't looking and missed the %api_key% part and the %source%, %target%, so I just put "YOUR API KEY" instead. Sorry, I'll get those fixed.

*Edit 2

Maybe we could add %region% to the Request header and something like %country_code% to the API URL? Some presets like Azure Translate actually require it. 

URL: "https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=hu" 
H: "Ocp-Apim-Subscription-Region": "westeurope"

Hey,

that’s awesome! :) Will check it soon.

You're welcome. :)

Yes, I can confirm the keybinding problem is fixed now. (੭˃ᴗ˂)੭

Thanks! 

Thanks.

Nope :) I mostly just use "One Shot" when I need it, but sometimes I accidentally hit the "Pause" button and then quickly press it again to keep the translation going. I guess that habit stuck, and that's why I occasionally try that quick-press thing I mentioned, which is how I noticed this. It's not a big problem for me at all because I hardly ever use it; I just saw it and figured I'd let you know.

Hi,

The new 0.5.9-alpha 1 update has a weird little keybinding bug. My "Toggle Gametranslate" key was set to "Slash" in the app, but it stopped working with that key. If I go into the Dashboard and set it to the same key, it shows up as "Minus" instead, and then it works perfectly. All the other keys are fine.

Also, with the Stream friendly API, I noticed that hitting the "Pause" key (I use the "Period" button for "Pause") makes the translation reaction time super slow in Automatic mode. Before, when it was paused and new text showed up, quickly double-tapping Period would translate the text instantly. Now, with the Stream friendly API, the double-tap doesn't work. This seems to work fine if I use DXGI.

Just take it easy; no need to rush :) It's not that annoying.

My last comment was about the third bug. That one's fixed now. The second bug is still popping up sometimes, but not as often.

Yeah, the centering is fine now. The text hasn't been pushed to the right at all. Thanks! :) 

Okay. Thanks for the explanation. (I just saw the first picture again, and those colored words are more orange than yellow, but whatever, I fixed those lol) Keep up the good work :)

Okay, I figured out what's causing the third bug (and maybe the second one too? The line breaks were actually fine in my quick check, but who knows :) ) It's the combo of Automatic font size and Attempt text centering, but this only happens in the very latest version. If I turn on Comic mode with those, it gets a little better because it doesn't shove it so far to the right. I switched back to alpha 3, and those same settings worked fine there. So, this bug is only in the newest release.

Hey,

I noticed a few bugs in the new GameTranslate_0.5.8-alpha.4 update. They all showed up when I used Automatic mode.

1: If some words in the text are a different color—like orange or red—the app often fails to mask or hide them properly. The picture only shows the orange-word issue (I forgot to screenshot the red ones). It sometimes successfully hides the orange words, but sometimes it doesn't. It never hides the red words. You can see the successful and unsuccessful orange word masking in the images for the third bug down below too.



I'm not sure if this particular bug is new to this update, because I've never tested sentences that have different colored words before, or at least I don't remember doing it.

2: The translation text isn't wrapping right compared to the original text; it just outputs the translated sentences in one long line. The area selected for the translation is wide, but I don't think this was a problem before. It doesn't happen a lot yet, but it does show up sometimes.

3: This is the most annoying one. Very often, the translation just slides way off to the right. Sometimes it moves so far off the screen that I can't even read it. It's okay when the text is short, but it's a huge pain when the text is long.

I don't remember if the second and third bugs ever happened before. (Or maybe I just forgot :) )

Thanks.

Nope. Everything's good; I didn't encounter any issue related to caching. Thanks :)

This update turned out pretty great. I'm especially thankful for this part: "Added a 'Show automatic border' checkbox to General config, letting users control whether they want the Automatic translation window to have a border or not." That's a super useful little feature for me—the border used to get in the way of my screen, and now I don't have to keep closing the window just to hide it. A huge thanks for this update! :)

That's weird. The offline translator works well for me, too. I downloaded the en-fi language pack, and that’s also working perfectly for me. But hey, at least you got it working with Deepl.

I'm running Windows 10, and it works fine on my machine. The issue might be on your side. Have you tried switching to a different Screenshot capture API, like DXGI?

Alright, thank you. •ᴗ•

No worries at all. It will be ready when it's ready, and I'll patiently wait. Hang in there and keep up the great effort :)

I understand now :) and yes, your assumption is right. Thanks.

It's completely identical to a previous translation, but the "previous" I'm referring to isn't the one right before; it's showing the text from one that was captured, say, 10 or 20 minutes ago.
:)

Hi,

Lately, I've been using the Manual capture mode for games, and I've noticed a recurring issue: occasionally, when I select a new block of text, the app displays an old translation that was captured previously, instead of translating the new text. When this happens, re-selecting the text repeatedly still brings up the incorrect, old translation. My workaround has been to deliberately exclude about half of the first letter when making the selection, which then forces a correct translation. It's not a frequent problem, but it does pop up from time to time. For now, it's not a major inconvenience.

Just wanted to give you a heads-up about this.

I have tested it, and it's working properly now. I think this is a great start and will definitely be a useful feature down the line.

Unfortunately, the application is crashing upon launch. I initially suspected the Dictionary feature because the app crashed immediately after I enabled it, but after testing, I found it continues to crash even when the Dictionary is disabled.

Edit: I have sent the crash reports for both scenarios. I generated the first report with Dictionary mode on (since that was my initial attempt to launch), and the second report with Dictionary mode off.

Oh, thank you for providing that information. I'm quite curious to see how it turns out :)

I have tested it and can confirm that there are absolutely no issues with Stream friendly mode anymore. It's working perfectly now. (੭˃ᴗ˂)੭

That's awesome. I'll be sure to test it out as soon as it's available (•̀ᴗ•́ )و

Hey there. 

Everything's working good now. The two bugs I mentioned are fixed. 

Thanks :)

Okay, so Stream friendly mode is finally working with Still background for both manga and games. I'm happy with this fix. While there's a small bit of extra processing time, it's not too bad and doesn't bother me, and it now translates the text when the image changes. It may be that Stream friendly mode only avoids misalignment when I use the Still Background feature, but even so, this is a great solution. I'm totally fine with this for now.

Unfortunately, this new update has introduced two bugs:
1. Manual capture mode only functions when Still background is active. If Still background is off, selecting text does nothing and no translation occurs.
2. In Automatic capture, if I hit Pause and try to select something new, the selection box is invisible, and it won't translate until I unpause. Also, the whole "translate while paused" thing only works if Still background is active, too. If it's off, no selection box, no translation. It didn't do this before; you could always select and translate while paused.

"If I'm not missing something else, you should be able to see the background being a few pixels misaligned." - Yes, that is correct.

Now, the only remaining issue with Stream friendly mode on my end is that misalignment issue. Previously, the only way I could fix it was by using that "Windows scaling workaround" I mentioned, which was too cumbersome and time-consuming. Fortunately, thanks to the new feature, I can now use the Still background button to mitigate this selection issue (for manga, for instance), which makes it much less annoying. I'm really glad that feature is available! 

Thanks for all your help.

That's interesting 😂 

Ah, now I get it, and that makes perfect sense :) It's probably not confusing at all; I must have misinterpreted it. My bad. 😔🙏🙏🙏

I was using version 0.5.4-alpha.2. Since I saw two available versions, I just downloaded the newest one right away.

I double-checked, and the result was the same. The fix only works when that specific feature is active; when it's off, the problem persists.

I ended up running a quick test, lol. I tried out the Still background feature, but when I hit the New still background button, the text doesn't translate, and this happens with both manga and games. It successfully updates the background image, but it keeps showing the translation from the previous image instead of the new one.

I do want to point out a positive side effect: the Still background feature actually eliminated the text displacement problem I was having in Stream friendly mode. At least when the feature is active, the text displays correctly. It's just a pity that the new text doesn't get translated.
Obviously, this doesn't fully solve my Stream friendly mode issue since it only works with the Still background function for manga or vn, but I definitely see this as progress in the right direction :)

Well, I do play one game that's similar to that, but I think it has more animations than the average Visual Novel, so I'm curious if that will cause any interference. I'll test it out when I play next to see how it performs, but either way, I think this will be a very useful feature.

The Text removal expansion scale looks really promising. That sounds like an excellent feature that will be a big help.

Outside of that one VN-like game, I'm not playing any other Visual Novels right now, but I do read manga frequently. I will certainly test them out sometime :)

Thanks so much for adding these features!

Oh, I completely missed that one. I didn't notice it at all, but you're right, that looks bad too. 😅

I found two minor bugs. The text fields are oversized relative to the content.

Well, I'm not an expert, so I can't say for sure. I'm just playing around with this stuff for fun :)

That sounds interesting! I'm sure it will work out.

Yeah, it's definitely faster now. At least, it seems that way :) To be fair, I didn't really have a problem with the speed of the Custom APIs before; I was pretty happy with them, especially the ones where you can turn off or don't have the reasoning feature.

I'm all for any useful new features, so go for it!

Well, it works now, so that's what counts :)

I don't really use LLaMA because I haven't found a model that fits my needs or that my machine can handle. However, I just did a quick test and here's what I found: it's fast at translating single words or short sentences, but it gets a "Request timeout" when trying to translate longer, multi-sentence texts. This isn't a huge problem for me, though. If I really need to, I can run the same model through LM Studio on my machine. When I do that, it handles longer, multi-sentence texts just fine and even seems faster. I've never gotten a "Request timeout" with the smaller models I've tried there.

This is really useful, and if it wasn't fast enough before, it definitely is now. Thanks for that!

Keep up the great work (👍🏻ᴗ _ᴗ)👍🏻

Yes, I confirm that both Deepl configs have unique API keys and names.

I can no longer reproduce the bug, as the configurations now appear to be working independently. The issue only happened initially when I was switching exclusively between the two Deepl configs. However, after I switched to a Custom API config just once, it seems the problem resolved itself, and the presets are now "good" because they are functioning separately. Since the API key is no longer visible and only dots are shown, I'll only be able to verify which key is which in the future, when I check the character usage on my Deepl account.

Update: Right as I was about to finish writing this, I checked my two Deepl accounts real quick to see if the character counts had updated, and they did! So, fortunately, it looks like the issue has been resolved, as characters were charged separately to each account.

Well, I went ahead and named the key in the “API Key Name” field and pasted the key into the “API Key” field. Then I switched to another DeepL config, and surprisingly the same key showed up there, even though I had erased everything earlier. I kept jumping between the configs, and the pattern held: any change I made in one reflected in the other. If I deleted the key in one, the other one lost it too.

That persisted until I first switched from a DeepL config to a Custom API config, and then went to the other DeepL config. From that point on, they behaved separately. Now, if I delete the key in one and immediately jump to another DeepL config (without going via Custom API), the other one still keeps its key. I hope it’s really working independently now, and not secretly using the same key under the hood, but we’ll see over time.

By the way the UI request you did is spot on. It’s exactly what I was looking for. Thank you! :)