#1241 Issue with ń letter (Polish)

[Damian Stankiewicz]

Hi,

starting from 6.0 version of OmegaT (in 6.1 it's the same, checked), there's an issue when trying to type "ń" letter, while translating to Polish.
It's normally achieved by pressing AltGr+n. It worked fine until the new version of program. Now, when I press the combination, I am sent to the beginning of the segment instead of getting proper letter. Thus, it is impossible to comfortably translate text to Polish (workaround is pasting "ń", but it's obviously inconvenient).

So:
Steps to reproduce:

• Press AltGr+n

What I expected to see:

ń

What I saw instead:

Getting the cursor to the beginning of a segment.

I'm here to answer any questions. Meanwhile, I'm reinstalling 4.33 version of OmegaT to be able to translate efficiently.

[Jean-Christophe Helary]

Do you find the same behaior with the 5.7 series?

[Jean-Christophe Helary]

Which physical keyboard do you use? And which keyboard layout?
Is it a Windows machine? And Linux machine? Which version?

[Damian Stankiewicz]

The problem is absent with version 5.70 downloaded from https://sourceforge.net/projects/omegat/files/OmegaT%20-%20Latest/OmegaT%205.7.0/ (OmegaT_5.7.0_Beta_Without_JRE.zip), ń works just fine. It appeared in 6.0 and continues in 6.1 beta.

Keyboards - various physical keyboards, currently it's a standard one mounted in Asus K56C, but checked with 2 or 3 other keyboards, with the same result (using different computers). Layout - QWERTY. Attaching photo of the keyboard.

System is Windows 10 Home, 10.0.19045. All other devices with Windows, as well.

Apparently, I'm not the only one struggling with this issue. https://sourceforge.net/p/omegat/bugs/1227/ it has been reported in November by another user. It's safe to assume that the issue appears for all (or: a lot of) translators intending to produce text in Polish language on devices with Windows.

[Jean-Christophe Helary]

Thank you for the information. The main difference between 6.0 and the 5.7 series is the use of Java 11 instead of Java 8.

We have a Java 8 equivalent to OmegaT 6.0, it is OmegaT 5.8 which has not been released as an application (yet) but is available as code here:
https://github.com/omegat-org/omegat/releases/tag/v5.8.0

I understand that building OmegaT may not be something that you are familiar with, but if you could try this version and do not find any faulty behavior, that would tell us with more certainty that the culprit is probably Java 11.

If the issue is reproduced in 5.8, it means that we messed something between 5.7.1 and 5.8/6.0 and that's easier to investigate.

[Damian Stankiewicz]

I have an issue while trying to compile OmegaT 5.8.
Attached images: ss of result of compilation in cmd, ss of test results, ss of installed Java.
Attached rar archive: Gradle test results.

Please provide some suggestion what could be done with it.

[Jean-Christophe Helary]

Could it be that you're building it with Java 17 and that it errors ?

I just ran ./gradlew clean run and everything worked nicely.

[Seji]

I've encountered the same issue after upgrading to v6.0.
The problem is with default keyboard shortcuts in v6.0, namely the ones listed below (next note interferes with Alt+n; search dictionary was also interfering with something, I don't remember now what it was).

editSearchDictionaryMenuItem=
gotoNextNoteMenuItem=

My solution was to modify them as follows in MainMenuShortcuts.properties file

editSearchDictionaryMenuItem=ctrl shift E
gotoNextNoteMenuItem=ctrl alt M

Now everything works as intended.

[Hiroshi Miura]

A default is

gotoNextNoteMenuItem=ctrl alt N

[Jean-Christophe Helary]

On macOS, adding cmd to alt modifies alt, but adding ctrl to alt does not modify alt. So, basically, all our alt shortcuts are potentially problematic when using ctrl, i.e. on Windows and Linux...

I guess it would be nice to provide a mechanism that offers locale-based shortcuts. In the meanwhile we can ask the translation teams to check with standard locale keyboards if we have problems with the various shortcuts.

Also, with the Polish keyboard, Shift Alt D interfers with Ž.

[iks koks]

I can confirm that this workaround works fine:
1. Open OmegaT
2. Go to Options > Access Configuration folder
3. Create a file called "MainMenuShortcuts.properties" in this directory
4. Paste this line there:
gotoNextNoteMenuItem=ctrl alt M
5. Save the file.
6. Restart OmegaT

Thanks @Seji.

[Jean-Christophe Helary]

Thank you for checking.
I think that in the long run, we need to have a locale based shortcuts selection process to avoid conflicts.

In the meanwhile, changing the shortcuts is the best option.

[Hiroshi Miura]

We can detect right-alt down event using KeyEvnet#getKeyLocation method.
It can be used to skip ctrl + right-alt + key combination but accept ctrl + left-alt + key.
When the getKeyLocation method returns KeyEvent.KEY_LOCATION_RIGHT we can skip it.
It should be configurable to check a right-alt and not launch a shortcut command.

[Jean-Christophe Helary]

A lot of keyboards do not have R-alt (or even R-Ctrl). I don't think it is a good idea to use R/L as a modifier diferenciator.

[Hiroshi Miura]

No problem when there is no right alt key on your hardware, because I explain a addition of a user preference option and an optional behavior when user HIT right-Alt hardware key.
Who can hit a R-alt when there is no hardware?
I don't think user want to change his/her preference to ignore right-alt as shortcut when user don't have R-alt key, There is no-sense.

We CAN use a R/L key location detection feature, when user CONFIGURE to ignore R-alt in preference, and OmegaT got R located Alt key.
It should be configurable to ignore a right-alt hit event as shortcut event.
When the getKeyLocation method returns KeyEvent.KEY_LOCATION_RIGHT we can skip it. Because we can detect right-alt down event using KeyEvnet#getKeyLocation method.