Hi @lucydodo
I can't see how "just leave the translation empty and finished" will make Qt use the original shortcut.
I tried this locally and the shortcut won't work any more, and it's text disappeared.

Even if Qt for some reason or another used the orignal string (if the translation is empty), this must be reported as a bug.
If I say that this string is empty, then it must be empty. Translations overrides original.
Shortcut or not, that doesn't matter.

<source>Ctrl+N</source>
<translation></translation>

Interesting.. 🤔 Did you do the like as above when testing locally?
I just installed the Arabic version of Windows 10 on VM and installed the latest nightly build to test it out. (All shortcuts are not translated in current master branch) However as in the screenshot below, shortcuts are displayed, and they work fine.

@SafaAlfulaij

I can't see how "just leave the translation empty and finished" will make Qt use the original shortcut.

Yeah, I wasn't sure about that either but (apparently) it's a feature of Qt (?). eg when the translated string is empty, it automatically uses the original text instead

@mgrojo That's correct yeah?

@SafaAlfulaij

I can't see how "just leave the translation empty and finished" will make Qt use the original shortcut.

Yeah, I wasn't sure about that either but (apparently) it's a feature of Qt (?). eg when the translated string is empty, it automatically uses the original text instead

@mgrojo That's correct yeah?

Yes, this is what I know due to experience, but I haven't found any reference in the documentation. In the Qt Linguist Manual there are references to "accept the empty translation", but without clarifying what is then shown in the translation. Having said that, I don't have an explanation for @SafaAlfulaij's screenshot. For me, that Qt version is buggy, since it goes against all what we have seen till now. This is my case with an empty translation for "Ctrl+N":

Filed a bug upstream: #86774

@SafaAlfulaij But what about the nightly build? Even there, the shortcut doesn't appear and doesn't work?

It seems that the translation file was changed from the last time I updated it...

This is not the correct behaviour. If the translation is empty, and finished, then it must be empty in the application.

And as for the nightly build, yes the shortcuts are there and work, but if you take a closer look to the exe:

("ÿÿÿÿ" = "FF FF FF FF")

If you believe as I believe, that "-1" is an invalid string length, then let's please fix the wrong "standard" established within this project.
If not, I'm not sure what to say...

If this is a Qt bug, I don't know what they're doing about translation of keyboard shortcuts. Our recommendation to not translate them comes from various issues that we have received (see, for example, #2178). But I'm not sure if we have received some issue when the translation string is equal to the original. Maybe not and, in that case, we could merge this pull request without problem. But what about the other languages, are people building with Qt 5.15 going to have problems when the translation of shortcuts is empty? What Qt version are we using for the official builds?

What Qt version are we using for the official builds?

At the moment, it's Qt 5.12.8. We could update that to Qt 5.12.9, but I kind of figured... "why take the chance of possibly breaking something for our supposed-to-be-stable point release?". 😉

What Qt version are we using for the official builds?

At the moment, it's Qt 5.12.8. We could update that to Qt 5.12.9, but I kind of figured... "why take the chance of possibly breaking something for our supposed-to-be-stable point release?". wink

Perfect. I only wanted to confirm that it isn't 5.15, which is apparently the one causes problems.

First, sorry if I was rude in any way.
I'll explain in details:

• Empty approved translations should show empty in the app (my screenshot above).
• lrelease has a bug that if the translation is empty and approved, it will give it a length of -1 in the released QM file, which will (in some way or another) make QTranslator skips the translation as if it's not there and use the original.
• DB4S is recommending translators to use this bug (without knowing it's a bug in the first place), instead of letting them know about shortcuts and the proper way to translate them.

Regarding #2178, I'm not sure what the problem is, but perhaps it's because of keyboard layouts or something else. Did you try Ctrl+Enter and Ctrl+Return? These two are different keys (return is the normal, Enter is the keypad). Perhaps this was the problem?
Normally devs assign both as sequences for the same action (in code).

lrelease has a bug that if the translation is empty and approved, it will give it a length of -1 in the released QM file, which will (in some way or another) make QTranslator skips the translation as if it's not there and use the original.

Do we know for sure that it is a bug, and not something that's understood to work this way + just badly documented by Qt?

In fact, we never said that shortcuts must not be translated, but that key names should not be translated, because this is known not to work and is more or less documented.

Warning: Do not translate the "Alt", "Ctrl" or "Shift" parts of the accelerators. Qt relies on these strings being there. For supported languages, Qt automatically translates these strings.

(They should say that you are not supposed to translate key names in general, like Space or Return).

But I think we haven't actually have problems when the translation is equal to the original. Emptying the translation was just our quick way to avoid the problem in all languages. On the other hand, yes, I'm sure that leaving the translation empty and finished is, in general, not only for shortcuts, saying to Qt that there's no translation and the original text is to be kept. They have designed it that way, otherwise it's a so long-standing bug, that it has become a feature.

I think the pull request can be merged as is.

Based on the commit of @SafaAlfulaij, I tested it in Windows and macOS, and confirmed that it works.

This is because on macOS the Ctrl key sequence is replaced by the Command key sequence.

In fact, I think it's okay to merge in this case, but on the other hand, we have been doing like this until this time, and the official Qt IRC channel also confirmed that if the blank translation was approved, replaced by the original text
(but the person who gave the answer was not the official Qt developer),

if assuming that this is not a bug, I requested changes because of concerns about bugs that may occur in the stable version.

First of all, I approved the review based on the comments arising from this PR.
but I delegated choice to someone else about merge.

It is now merged to master. I'll try to cherry-pick it to the v3.12.x, which is the branch of the release. I hope it can be done without problems.

@SafaAlfulaij I had to solve some trivial conflicts and it looks good from a technical point of view. When compiling, it says that there are two pending messages, but I cannot find them. You can review it in 1dfa70c

@mgrojo Couldn't find it either...