With the addition of Desktop Mode, GameTranslate now seems to work for many of the RPG-style games I've wanted to play, so I've done the purchasing thing.

But there are two (or ideally three, depending on how the code and key-hooking is structured, since it may be way too much work) things that would really make it amazing, at least in my case:

1. Allow both Japanese-to-English translations and the Romaji feature to be used concurrently
   1. This would be very helpful for people with intermediate language skills who can mostly read native text, but need help with unfamiliar characters
2. Polling of a text-area to automatically update a panel showing the translation
   1. For RPGs and visual novels and the like, which tend to have a very static text-area, being able to set the text-region once with a hotkey, like we can do now, then either having that region polled on a timer or in response to another hotkey, would remove a lot of usability friction
      1. The logic here would be pretty simple:
         1. If the OCR-result string changed since the last scan, re-run translation
            
         2. If the OCR-result string did not change, do nothing
         3. If the region is blank, clear the panel
            1. Do not report that there was nothing to translate
            2. Ideally, do not resize it, either, so that it doesn't draw too much attention
      2. The panel showing the translation should be reused so that its position on the screen doesn't change
   2. I think this might be what another user requested as "real-time translation"
3. If it is possible to implement the automatic polling feature (2), being able to set multiple regions to be monitored simultaneously would be outstanding
   1. For an RPG, it can be helpful to not only translate the dialogue region, but also something like the speaker's name or an in-game system like a weather indicator
      1. This might be a reasonably easy workaround to the problem of OCR string concatenation, where the speaker's name is too close to the dialogue itself, so there isn't a good way of hinting to the translation engine that it should be evaluating things separately
      2. If implementing multiple translation panels doesn't feel right, I'd imagine most users would be happy to see everything in the same panel, just separated by linebreaks or as part of a bullet-point list

I maintain enough projects myself that I know how fatiguing feature-requests can be, but I'm certain that there are other people who would be sold immediately with at least one of these.

Hi fl0rm and thank you for the much welcome feedback and suggestions!

Interestingly enough, I have actually been working on some of the things that you are suggesting, which are;

A tiny config window that shows above the translation window (when hovered), which contains

• A button to switch between translated and captured text
• A button that copies the currently displayed text to your clipboard, aka Ctrl + C
• A pause button for the automatic window
• A one-shot capture button for the automatic window

All these buttons will have a corresponding hotkey that the users can set if they'd like.

With your suggestion, I will add another button for when the user has Romaji activated, so they can swap between the two :)

The automatic window is already polled on a timer, but without taking into account if the captured is changed or not. An option to change the poll timer will be added in the coming update.

I have previously considered adding a feature that would automatically request a new translation if the area that the user has selected changes, but it is a fairly complex thing to do just right. However, it will definitely be added at some point, but I can not say that this specific feature is prioritized at the moment.

Regarding not reporting when text can not be found, I will add it as an option so you can turn it off.

Being able to set multiple regions is a great idea, I will look into that as well!

Excuse the late reply, I had some hardware issues for the past few days so I spent all my time attempting to fix it. Finally made it through yesterday, so now it is back to work! :)

I agree with your last note, but I'd say that I am rather lacking in feature requests than drowning in them at the moment. Either way, I really do lack the time to work on this full-time, considering the very low price and the number of people buying it. But.. I can feel the momentum growing in many ways, hopefully it won't be long until I can give this application the love & dedication it deserves and requires.

Thank you once again for the feedback!

No problem at all for the delay, and those features as described sound like they'd provide pretty complete coverage of what I'd be hoping to see.

If it does already re-capture the selected area, I have not seen it automatically updating the translation as the text changes. It may be that the interval is longer than the time I have allowed (though I did leave it for over a minute).

My method has been to use Desktop mode and select a region using the default hotkey, L-CTRL. I believe the version I have installed is the latest, 0.3.5, and I do not have any other overlay systems in place that would be likely to interfere.

The system is, however, Windows 11, which I understand has not been thoroughly tested, but if there is a way to get lower-level debugging logs, I can experiment and share anything interesting with you, like if it seems to be the case that the capture-region drifts or that the operation fails for some reason. It's been a while since I last looked into Windows graphics calls, but I'm no stranger to unprocessed streams of verbose data.

Sorry, I just re-read your post and saw that you were clear that it does re-poll the area, but that it doesn't automatically act on the changes. And yeah, I can imagine why it would be tricky to make it smooth.

Keeping the panel where the translation appears in the exact same place that the user has positioned it should help (anchored to a top-left origin should be intuitive enough), but adjusting for width, height, and, depending on the game, the possibility of some background animation triggering a false-change in the OCR result might lead to unwanted flickering.

Maybe that could be mitigated by diffing the strings to see if the delta is more than one or two or some configurable number of characters, or a levenshtein edit-distance in languages where that makes sense.

UX isn't really my thing, unfortunately, but I can draft a parsing function or logical flowchart for something if that might be useful to work through an idea.

Hi again fl0rm :)

Good to hear.

I now see the issue. 'Desktop' mode does not currently allow to use the automatic mode. The reason for that is that I could not find a solution where it was possible to take a screenshot of the monitor without including the GameTranslate window in the screenshot as well. Which led to the just before captured/translated text being the text that was read in the next poll.. There are solutions to this, but none that could work with how our current window is created and used (afaik).

I believe the 'Desktop' button should have a tooltip that lets the user know the automatic capture mode is disabled. Let me know if you can't see it! :)

Have you had any success playing your game with 'Attached' mode? It should work just fine for your use case. Also make sure that you use the 'AutomaticWindow' keybinding, the 'FastKey' and other hotkeys do not work for that. 

Diffing strings or similar solutions could very well be a good enough workaround, but that would still require the text to constantly be OCR'd. I think I have a better solution in mind that only involves taking a screenshot and calculating if an update should be done or not, but I am yet to have time to put that into practice.

Thank you!

There is indeed a disabled button and I figured that might be trying to communicate that it was disabled, as I saw in your response to another user about two weeks ago.

I will experiment with the other modes, though the path that seemed most intuitive was to use Desktop mode and to just identify the part of the screen (in a non-fullscreen application, at least in this case) that to be translated. I am unsure whether a typical user would be confused if the GameTranslate window were to also be captured initially, since they would likely just readjust their settings to keep it away from the text to be translated.

I was referring to when you hover the 'Desktop' button;

If you are unable to see this, I need to take a look at it.

Regarding your last paragraph, try the automatic mode and you will understand why it is a problem. I do not at the moment plan to separate the actual capture area from the GameTranslate window's position as I doubt anyone at all would want to do that instead of just using the automatic mode which immerses itself into the background. At least not after adding the possibility to flip back and forth between captured and translated text. If this feature is requested by many in the future, I'll of course look at it, but again, I doubt anyone would when they see how the automatic mode works. It would of course have solved the Desktop issue for now, but I prefer not to divert effort to that since I do plan on solving this in a cleaner way in the future.