@Feyn-Man, @GortiZ6, the Italian case might have a problem too. Ctrl+C has been used for "Saving changes" but in a lot of context menus Copy is still mapped to Ctrl+C. Unless other Qt versions remap that, Ctrl+C would not be obeyed in those contexts as Copy because the general "Save changes" would eclipse it. My Qt version (5.9.5) does not remap Copy shortcut. Is that an error?

Should we mention all the other translators? Most of them cannot be referenced as reviewers.

This seems like a Qt bug to me. In the Portuguese translation, for instance, I think Return should be shown as Enter and Space as Espaço. Is there a way to translate the name of the keys but not change the shortcut?

Yes, this might a Qt bug or a bug in how we distribute Qt for some platforms, but don't worry about the keys being untranslated. They should be, anyway. The "translation" here is intended for remapping keys in the language (some software makers like to do that). For example, in Microsoft programs in Spanish, you use Ctrl+E for Select All because you have to use Ctrl+A for Open (Abrir). If you are not making this, there is no reason to translate the keys. Qt will translate them for you, unless there aren't any translation in Qt for that language (then the standard buttons wouldn't be translated either). In this latter case, the translation of the shortcut would break it (or so I think).

I checked that in Spanish and German in my system the keys are translated (I'd need to install other language packages in my system to test the others) but the most important part is that the shortcuts work in all languages. See the analysis made by @horst-p-w-neubauer in #2178 (comment) Portuguese did not work for him. Maybe it works in some other platforms, but it is better if they work in all, and then, if correctly provided by Qt and distributed by us, the keys will be translated in the GUI.

I wanted all of you to review this, mainly to confirm that I haven't erased any remapping that you were doing. Sorry for not making that explicit.

I'm not sure about the reset of the type="vanished" attribute in many files. I'd vote for remove the vanished items completely as I think, they are only necessary when they show up for the first time, because they are often a pattern for a lite changed version of the text so it helps to translate the new version. But one might regrett, losing the type="vanished" information itself. If tested it and it doesn't reapear, when you have linguist update the .ts files. I think this should be solved before commiting. Are you using a xsl-transformation to fix this?

We should not worry about the missing vanished attribute. Yes, that should not change, but I used a simple awk script to fix them and it had this side effect. This can be fixed if lupdate is rerun, but I didn't want to do it for this pull request, because then, it would be more difficult to bring that change to the 3.12.x branch, because a lot of conflicts would appear. We can do it in another commit.

But nevertheless, I'm thinking that there might be conflicts nevertheless and I should rerun the script in the other branch. I save it here for the future, so we don't have to rethink it again.

for i in *.ts; do
   awk '
/source>Ctrl\+|source>Alt\+|source>Shift\+/ {print; v_key=1}
!/source>Ctrl\+|source>Alt\+|source>Shift\+/ {if(!v_key) {print} else {print "        <translation></translation>"; v_key=0}}
' $i > $i.new;
   mv $i.new $i; 
done

Looking at the script I see that I forgot Function keys. In any case, the translations never changes those, so might be unnecessary. Should I include them?

No, they simply disappear, which is better. In fact, lupdate should have an option for that, but I looked at it, and it doesn't. After a release all the vanished strings should be removed.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

	<!-- 
	
	  finds translations with preceding sources that includes Short-Keys
	  and removes the translations value but not the items attributes
	  	
	-->
	<!--  XPath 2.0 version - you may use this instead of the template using 'starts-with()' if you run XPath 2.0 or higher 	 -->
	<!-- 	<xsl:template match="translation[preceding-sibling::source[matches(node(),'Ctrl\+|Shift\+|Alt\+|F\d+')]]"> -->
	<!--  XPath 1.0 version - replace this with the template using 'matches()' that's only working with XPath 2.0 or higher 	 -->
	<xsl:template match="translation[preceding-sibling::source[starts-with(node(),'Ctrl+') or starts-with(node(),'Shift+') or starts-with(node(),'Alt+')
	  or (starts-with(node(),'F') and number(substring(node(),2,1)) and (number(substring(node(),3,1)) or  not(substring(node(),3,1))) )]]"> 
		<xsl:copy>
			<xsl:apply-templates select="@*"/>
			<!-- remove all translations of Short-Keys - they are probably wrong  -->
			<!-- <xsl:apply-templates/> -->
		</xsl:copy>
	</xsl:template>
	
	<!-- standard copy template -->
	<xsl:template match="@*|node()">
		<xsl:copy>
			<xsl:apply-templates select="@*"/>
			<xsl:apply-templates/>
		</xsl:copy>
	</xsl:template>	

	<!-- manually insert Doctype line - dirty but working ;-) -->
	<xsl:template match="/">
		<xsl:value-of disable-output-escaping="yes" select="'&#13;&#10;&lt;!DOCTYPE_TS&gt;&#13;&#10;'"/>
        <xsl:apply-templates/>
    </xsl:template> 
 </xsl:stylesheet>

Thanks, @horst-p-w-neubauer. It could be useful for other more complex transformations. I've used XSL before, but the syntax is so convoluted, that it's impossible to keep in my memory for quick XML processing. The good thing about AWK is that it's simple and it's applicable to any text format. Of course, for XML is less specialized and complex processing would be more difficult.

For example, we could use it after the release to remove vanished strings from up-to-date ts files.

For example, we could use it after the release to remove vanished strings from up-to-date ts files.

Forget about this, I've just discovered that you can remove vanished entries using the -noobsolete argument to lupdate. My impression looking at the man page was that it was only to not convert current strings in vanished strings, not to remove vanished strings. So after a release, we could run lupdate -noobsolete to clean up-to-date files. It can be added to the wiki, as well.

Would you please check my explanation on the wiki if it is what we found out and if it is easy enough to understand?
dont-translate-keyboard-shortcuts

I've tried to clarify and complete the explanation. I hope I haven't added too much detail about the rationale.

@mgrojo yes, the CTRL+C was a mistake, have you already fixed it or should I do something?

I can do that in this branch. The problem is: if Ctrl+S isn't remapped to Ctrl+C, Ctrl+W cannot be remapped to Ctrl+S. Should we leave both of them unchanged?

These are the current remappings:

sqlb_it.ts:        <source>Ctrl+O</source>
sqlb_it.ts:        <translation>Ctrl+A</translation>

sqlb_it.ts:        <source>Ctrl+W</source>
sqlb_it.ts:        <translation>Ctrl+S</translation>

sqlb_it.ts:        <source>Ctrl+S</source>
sqlb_it.ts:        <translation>Ctrl+C</translation>

sqlb_it.ts:        <source>Ctrl+Q</source>
sqlb_it.ts:        <translation>Ctrl+E</translation>

So..
Ctrl+O -> Ctrl+A wrong -> should be revert to Ctrl+O
Ctrl+W -> Ctrl+S -> I changed this to 'S' as i changed the translatio "Write Changes" to "Salva le modifiche" so if the 'W' was to "write changes" I think that the 'S' here is right since we use the 'S' shortcut to save changes.
Ctrl+S -> Ctrl+C wrong -> if what i wrote up here is wrong... then I need to know what the "W" shortcut was meant to :/
Ctrl+Q -> Ctrl+E currently I don't know what the Ctrl+Q should do if it's to quit from an app maybe this should reverted to Ctrl+Q as well

@GortiZ6

As far as I can see, software like "Firefox" and "Edge" tend to leave the shortcuts in english also with the italian translation, as you can see from this picture:

But if you take other products as example, like those by Microsoft, a lot of shortcuts are translated. For Spanish, Ctrl+O is remapped to Ctrl+A (abrir), Ctrl+A to Ctrl+E (¿entero=all?), Ctrl+S to Ctrl+G (guardar), etc. I suppose that they don't want to be regarded as English-centric products, but at the end, most people don't like that, because not all the programs we use are translated, or even when they are, don't follow those remappings and stick with the English standard.

The English "New Tab" with Ctrl+T goes to "Nuova Scheda" but the shortcut remain "Ctrl+T", so all shortcuts should be reverted to the english ones. Sorry to create much trouble, I'll avoid it in next time.

It made sense to remap some if one likes to follow the Microsoft way, but the problem is that all the shortcuts have to be regarded as a whole, so there aren't any clashes.

Ok, I will reset also Italian if you confirm that you think it's the preferred solution.

Agreed. I've updated the branch removing all translations of shortcuts, including function keys and remapped keys in Italian. When Travis confirms that everything is OK, I will merge the branch.

- Removed translation of Function keys for all languages
- Removed also remapped shortcuts for Italian

See issue #2178 and discussion in PR #2235.

- Removed translation of Function keys for all languages
- Removed also remapped shortcuts for Italian

See issue #2178 and discussion in PR #2235.

# Conflicts:
#	src/translations/sqlb_cs.ts
#	src/translations/sqlb_de.ts
#	src/translations/sqlb_es_ES.ts
#	src/translations/sqlb_fr.ts
#	src/translations/sqlb_ja.ts
#	src/translations/sqlb_ko_KR.ts
#	src/translations/sqlb_pl.ts
#	src/translations/sqlb_pt_BR.ts
#	src/translations/sqlb_ru.ts
#	src/translations/sqlb_tr.ts
#	src/translations/sqlb_uk_UA.ts
#	src/translations/sqlb_zh.ts
#	src/translations/sqlb_zh_TW.ts