Version: 2.7 (using KDE 4.5.3) OS: Linux Pressing the keyboard 2only highlites the 2 on the kcalc field, but doesn't print a 2 in the window. I think it is because of the 2 showing up, when I press the CTRL key for showing the keyboard shortcuts. So the 2 is the number and the shortcut for the shift button. Reproducible: Always Steps to Reproduce: press 2 obn the keyboard Actual Results: nothing Expected Results: 2
I cannot reproduce. Both the normal "2" and the "Ctrl+2" work as expected.
I cannot reproduce either. Is it possible that this is an internationalization issue? What locale are you using?
I am using a german localized KDE, but changing the keyboard with goal6 - kaulich - /home/kaulich: 21 -> setxkbmap us goal6 - kaulich - /home/kaulich: 22 -> kcalc didn't change a thing.
Switching my KDE from german to english fixes this, so it is an translation error. Using CTRL to show the keyboard shortcuts, show 'CTRL-2' on the shift key for english and '2' on the shift key for german.
FYI, KDE_LANG can be used to work around or reproduce the bug: Workaround: KDE_LANG=en_US kcalc Reproducer: KDE_LANG=de kcalc (needs kde-l10n-de installed) The language can also be changed per app from the "Help" menu (not sure why it's under "Help", but that's where kdelibs puts that menu entry).
OK, I'll look into this. Strange thing though, the shortcuts are defined in kcalc.ui as just "2" and "Ctrl+2". So I'm not sure where it is going wrong yet. But to be honest I have not done much before regarding i18n. So I will have to look into it and ask around to figure it out.
I’ve got German translation installed and the 2 works just fine (4.5.3)
Kubuntu 10.10 in locale de works: kcalc --version Qt: 4.7.0 KDE: 4.5.1 (KDE 4.5.1) KCalc: 2.7 branch compiled from sources in locale de works: kcalc --version Qt: 4.7.0 KDE: 4.5.3 (KDE 4.5.3) KCalc: 2.7 trunk compiled from sources in locale x-test does NOT work: kcalc --version xxQt: 4.7.0 KDE Development Platform: 4.5.76 (4.6 >= 20101111) xxKCalcxx: 2.8 xx
Please check that you're also using kde-l10n-de from the 4.5 branch, not kde-l10n-de trunk or some Kubuntu langpack from Launchpad Rosetta.
I can reproduce this on: (output of: locale) LANG=de_AT.UTF-8 LC_CTYPE="de_AT.UTF-8" LC_NUMERIC="de_AT.UTF-8" LC_TIME="de_AT.UTF-8" LC_COLLATE="de_AT.UTF-8" LC_MONETARY="de_AT.UTF-8" LC_MESSAGES="de_AT.UTF-8" LC_PAPER="de_AT.UTF-8" LC_NAME="de_AT.UTF-8" LC_ADDRESS="de_AT.UTF-8" LC_TELEPHONE="de_AT.UTF-8" LC_MEASUREMENT="de_AT.UTF-8" LC_IDENTIFICATION="de_AT.UTF-8" LC_ALL= (output of: kcalc --version) Qt: 4.6.3 KDE: 4.5.2 (KDE 4.5.2) KCalc: 2.7 (output of: rpm -q qt qt-x11 kdelibs kde-l10n-German kdeutils-minimal) qt-4.6.3-8.fc13.i686 qt-x11-4.6.3-8.fc13.i686 kdelibs-4.5.2-8.fc13.i686 kde-l10n-German-4.5.2-1.fc13.noarch kdeutils-minimal-4.5.2-1.fc13.i686
Created attachment 60075 [details] correct the shortcut The patch resolves the problem, but if the key "Ctrl+2" is pressed, the button label is set to "Ctrl". I think it's okay, but don't know if this is wished. Best Regards Daniel Schulz
(In reply to comment #11) > Created an attachment (id=60075) [details] > correct the shortcut > > The patch resolves the problem, but if the key "Ctrl+2" is pressed, the button > label is set to "Ctrl". I think it's okay, but don't know if this is wished. > > Best Regards > Daniel Schulz I'm sorry, I confused in the sentence. The correct one is: > The patch resolves the problem, but if the key "Ctrl" is pressed, the button > label is set to "Ctrl+2". I think it's okay, but don't know if this is wished. I saw the same procedure in the English version. So the patch should be correct. Best Regards
Responding to the patch sent to the kde-utils-devel mailing list. I don't think this is the right solution -- have you regenerated the German translation files after this change to the .ui file? It looks like your patch worked because the corresponding translation was not found. For instance, using the x-test translations I'm still unable to press "2" and see the number 2 in KCalc. A quick look at http://websvn.kde.org/trunk/l10n-kde4/de/messages/kdeutils/kcalc.po?revision=1231486&view=markup shows me they have translated "Ctrl+2" into "Stgr+2". My knowledge of KDE's translation infrastructure is close to zero, but I think it will fail to associate this to Ctrl+2 -- in fact, the shortcut ends up being "2", which conflicts with the actual shortcut for the "2" button. The whole situation with x-test is worse than the one with de, as most shortcuts will not be valid, so when KCalc calls setShortcut(QString(shortcut())) the string will be empty. Translators, would it make sense to fix the de translations and/or mark these shortcuts as untranslatable?
I cannot reproduce the issue. I am running KDE in German. I changed the German translation file (Strg+2 -> something else) but still nor problem. I installed Japanese language files and ran KDE_LANG=ja kcalc and then I saw the problem. "2" was not added to the display. I then checked the MO file but in Japanese the Ctrl+2 string is left empty so it is not in the MO file. After trying the German (default) version again, another run of KDE_LANG=ja kcalc did not show the problem anymore. I did not change the MO file. After that I tried with several language but wans not alble to reproduce the problem anymore. My system: $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= KDE 4.6.2 including German translation files from Debian experimental-snapshots repo, set to German as default language.
I forgot this: kcalc --version Qt: 4.7.3 KDE: 4.6.2 (4.6.2) KCalc: 2.8
Weird. I'm using qt from the 4.7 git branch, KDE from trunk/master. I checked out l10n-kde4/{de,x-test}/messages/kdeutils. If I run `KDE_LANG=de kcalc', pressing "2" works like pressing the "Shift" toggle button, whereas pressing "Ctrl+2" does nothing. Doing the same with KDE_LANG=x-test does nothing in both cases. kcalc$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= kcalc$ Should these shortcuts be made untranslatable anyway?
Really strange that this is not reproducable by several people in locale de. Maybe this is somehow related to keyboard layout? Afaik the numbers 0-9 don't need to be translated, but the key "Ctrl" is labeled "Strg" on a german keyboard, so "Ctrl+2" should be translatable at least for locale de.
Looks like there are two duplicates of this BR: https://bugs.kde.org/show_bug.cgi?id=259739 https://bugs.kde.org/show_bug.cgi?id=274556 I have asked the reporters for the locale they are using when these bugs happen.
*** Bug 274556 has been marked as a duplicate of this bug. ***
Do we all at least agree that neither of the shortcuts ("2" and "Ctrl+2") work when KDE_LANG=x-test?
With x-test, none of the numbers work.
*** Bug 259739 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > With x-test, none of the numbers work. Of course the numbers in x-test do not work, your keyboard emits "2" pressing this button, and not "xx2xx" as in x-test.
Yes, that is what I wanted to point out but failes due to "on my way to bed" syndrom. :) So, x-test is not a good test case here.
How does this "Strg" translation work? When the de locale is used, a QKeySequence objects are created with "Strg+2" as the string. Qt then calls QShortcut::tr("Ctrl") in QKeySequencePrivate::assign(), but the call returns "Ctrl" here, and the shortcut is registered as "2". Does it work differently for you?
OK, this might be the problem here: I only have l10n-kde4/de/messages/kdeutils here; as soon as I checked out l10n-kde4/de/messages/qt and installed kde-qt.mo, the tr call worked as expected, and so did the shortcuts.
@ Raphael: Just to clarify, with kde-qt.mo and kcalc.mo from l10n-kde4/de/messages you can not reproduce this bug, right?
Exactly.
It'd be nice if Christoph, Markus and/or M. Wagner could confirm that they are missing kde-qt.mo (actually, the package which provides it). Furthermore, I propose at least making the 0...9 buttons untranslatable. Is there anything else we could do besides that in order to close the bug?
(In reply to comment #29) > It'd be nice if Christoph, Markus and/or M. Wagner could confirm that they are > missing kde-qt.mo (actually, the package which provides it). > Yes that indeed should be checke and confirmed. > Furthermore, I propose at least making the 0...9 buttons untranslatable. Yes. < Is > there anything else we could do besides that in order to close the bug? Not that I am aware of.
SVN commit 1235446 by rkcosta: Make the 0..9 buttons untranslatable. I don't think any language actually translates them, but it doesn't hurt, given the issues we faced in the related bug. CCBUG: 256591 M +10 -10 kcalc.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=1235446
SVN commit 1235447 by rkcosta: Make the 0..9 buttons untranslatable. I don't think any language actually translates them, but it doesn't hurt, given the issues we faced in the related bug. Backport of r1235446. CCBUG: 256591 M +10 -10 kcalc.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=1235447
Christoph, Markus or M. Wagner: could confirm that you have not installed the respective package for the kde-qt translations?
Hello, I can't find the package on my computer, and not in the fedora repos, where do I have to search it? goal6.bs.gns-mbh.com - kaulich - /home/kaulich: 21 -> locate kde-qt.mo goal6.bs.gns-mbh.com - kaulich - /home/kaulich: 22 -> su Passwort: [root@goal6 kaulich]# yum whatprovides */kde-qt.mo Geladene Plugins: presto, refresh-packagekit ... No Matches found Thanks for youre support, Christoph
The file is named kdeqt.mo on systems compiled from sources and in debian based distributions, sorry for the typo :(
Oh, I have /usr/share/locale/de/LC_MESSAGES/kdeqt.mo installed, but the 2 in my kcalc doesn't work. Anything else I can check?
(In reply to comment #36) > Oh, I have > > /usr/share/locale/de/LC_MESSAGES/kdeqt.mo > > installed, but the 2 in my kcalc doesn't work. > > Anything else I can check? Can you try running `KDE_LANG=de kcalc' and also getting the output of `locale'?
KDE_LANG=de kcalc doesn't fix anything, here is the output of locale: LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
(In reply to comment #29) > It'd be nice if Christoph, Markus and/or M. Wagner could confirm that they are > missing kde-qt.mo (actually, the package which provides it). > Sorry for being late. It still does not work for me: kcalc --version Qt: 4.7.2 KDE: 4.6.3 (4.6.3) KCalc: 2.8 find /usr/share/locale/ -name 'kdeqt.mo' /usr/share/locale/de/LC_MESSAGES/kdeqt.mo (kde-l10n-German-4.6.3-1.fc14.noarch) locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
Maybe it is related to this warning from the "Qt Linguist Manual" (although KDE is using gettext): 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.
I can always reproduce the bug on Fedora 14. kcalc --version Qt: 4.7.2 KDE: 4.6.3 (4.6.3) KCalc: 2.8 locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= The patch by Daniel did it. Is there a chance to pacth the official sources? Thanks
(In reply to comment #41) > > The patch by Daniel did it. > Is there a chance to pacth the official sources? No. Reason is that a lot of people don't need that 'patch', it works for them. And I can not reproduce this bug on at least five different systems (master + branch 4.6 compiled from sources, kubuntu 10.10 with 4.6.2, some VM's with Kubuntu + openSUSE). None understands so far why it works on some systems and why it does not work on e.g. your system, so it is impossible to 'fix' the issue. Please attach your kdeqt.mo + kcalc.mo. What is your keyboard layout / keyboard hardware?
Just a note, I recently had to rollback the following change, it broke key bindings entirely: ------------------------------------------------------------------------ r1235446 | rkcosta | 2011-06-05 14:25:18 -0400 (Sun, 05 Jun 2011) | 8 lines Make the 0..9 buttons untranslatable. I don't think any language actually translates them, but it doesn't hurt, given the issues we faced in the related bug. CCBUG: 256591
Created attachment 61654 [details] As requested my kcalc.mo kcalc.mo is located in /usr/share/locale/de/LC_MESSAGES/
Created attachment 61655 [details] As requested my kdeqt.mo kdeqt.mo is located in /usr/share/locale/de/LC_MESSAGES/
My keyboard layout is german. The keyboard hardware is: Logitech cordless keyboard
Kubuntu 10.10 system: $ kcalc --version Qt: 4.7.0 KDE: 4.6.2 (4.6.2) KCalc: 2.8 branch 4.7 compiled from sources: $ kcalc --version Qt: 4.7.0 KDE: 4.6.90 (4.7 RC1) KCalc: 2.9 @ Attila: Using your attached *mo files in both systems listed above I can not reproduce the bug, "2" + "Strg+2" works.
I have to mention, that i can always reproduce the bug on different PC, different hardware and also on a Laptop. Just tested today on Fedora 14, 15. Another strange thing is, if i change the language to english "2" + "Strg+2" works. If i switch the language to hungarian, then "2" + "Strg+2" doesn't work like german. Can i provide any other information or can i test?
(In reply to comment #43) > Just a note, I recently had to rollback the following change, it broke key > bindings entirely: > > ------------------------------------------------------------------------ > r1235446 | rkcosta | 2011-06-05 14:25:18 -0400 (Sun, 05 Jun 2011) | 8 lines > > Make the 0..9 buttons untranslatable. > > I don't think any language actually translates them, but it doesn't > hurt, given the issues we faced in the related bug. > > CCBUG: 256591 I can confirm that this commit broke the numpad 0-9 for me while surrounding keys ('.', 'enter', '+', '-', '*' and '/') kept working. No amount of changing LC / LANG / KDELANG (from nl_NL to en_US) on startup fixed it. Reversing this patch did. FreeBSD 8.2, Kcalc 2.8, KDE 4.6.5, Qt 4.7.3
+1 In KDE 4.6.4 it worked fine, in KDE 4.6.5 it is broken.
I can confirm the error. I've tested KCalc at several installations (FC15) but the "2" didn't work on any. Main system (at home): Linux 2.6.38.8-32.fc15.x86_64 x86_64 KDE: 4.6.5 (4.6.5) Keyboard: Logitech Y-R0012 KCalc: Version 2.8 nouveau, Gallium 0.4 on NV46,2.1 Mesa 7.11-devel Installed languages: DE, HU.
People, please do not mix bug reports. This one is about Shift+2 not working when running KCalc in German (or Hungarian, apparently) in some machines. The bug about KCalc not working with the keyboard at all is bug 277020, which has been fixed for 4.7.0 (you can contact your distribution for them to backport the fix to 4.6.5 as well).
(In reply to comment #48) > > If i switch the language to hungarian, then "2" + "Strg+2" doesn't work like > german. > Language hungarian does 'translate' the message "Ctrl+2" as "Ctrl+2" and "2" as "2". So from gettext/application there should be no difference to en_US. @ Attila: Are you shure that in hungarian "Ctrl+2" and "2" does not work for you? Does any other language than en_US work for you? Maybe this is an issue with any locale != en_US for you? I tested in branch with de, en_US, hu, nl, uk, ru, en_GB, fr, km, nds. I can enter "2" + "Ctrl+2" via keybord in any language except km, which has a strange translation here: msgid "Ctrl+2" msgstr "បញជា(Ctrl)+2" A calculator where I can not enter one number via keyboard is useless from my pov, whereas as a missing keybord shortcut is a minor issue. Maybe "Ctrl+2" should be made untranslatable so "2" via keyboard works for all reporters, if we do not find the reason/fix for this bug?
I can confirm again. In hungarian and german "Ctrl+2" and "2" does not work, but changing the language to Finnish it works. That means English and Finnish is OK.
I can reproduce this bug now in locale ja, but in a really strange way. System branch compiled from sources: $ kcalc --version Qt: 4.7.0 KDE: 4.6.95 (4.7 RC2) KCalc: 2.9 Using 'KDE_LANG=ja kcalc' "2" + "Crtl+2" only works if "Ctrl+2" is translated as "Ctrl+2", but not if "Ctrl+2" is *un*translated as "". Afaik gettext() returns either the translated string or the english string in case of an untranslated message, so it should not make any difference if "Crtl+2" is untranslated or translated as "Crtl+2". CC'ing the i18n coordinator because apparently not only locale de is affected.
@Burkhard: Can not repro your problem, having "Ctrl+2" untranslated in japanase (like it is in the repos at the moment) still makes 2 and Ctrl+2 work About the bug in general, can not reproduce the problem either without "breaking the translations", that is, translating "Ctrl+2" as "LALAL+2". You guys having the original bug can you please run msgunfmt /usr/share/locale/de/LC_MESSAGES/kcalc.mo | grep Ctrl | grep -A 1 msgid and msgunfmt /usr/share/locale/de/LC_MESSAGES/kdeqt.mo | grep \"Ctrl\" | grep -A 1 msgid And paste the results? Also it'd be good to know your kdelibs and Qt versions
-> msgunfmt /usr/share/locale/de/LC_MESSAGES/kcalc.mo | grep \"Ctrl\" | grep -A 1 msgid -> msgunfmt /usr/share/locale/de/LC_MESSAGES/kcalc.mo | grep Ctrl | grep -A 1 msgid msgid "Ctrl+2" -> rpm -qa | grep kdelibs kdelibs-common-4.6.95-1.fc15.x86_64 kdelibs-4.6.95-1.fc15.x86_64 kdelibs-devel-4.6.95-1.fc15.x86_64 -> rpm -qa | grep qt ibus-qt-1.3.1-4.fc15.x86_64 qt-webkit-4.7.3-6.fc15.x86_64 qt-mysql-4.7.3-6.fc15.x86_64 qt-4.7.3-6.fc15.i686 dbusmenu-qt-0.8.2-0.2.fc15.x86_64 qtcurve-kde4-1.8.4-2.fc15.x86_64 dbusmenu-qt-0.8.2-0.2.fc15.i686 qt-x11-4.7.3-6.fc15.i686 imsettings-qt-1.2.3-1.fc15.x86_64 qt-config-4.7.3-6.fc15.x86_64 qtscriptbindings-0.1.0-14.fc15.x86_64 qt-assistant-adp-4.6.3-2.fc15.x86_64 qt-4.7.3-6.fc15.x86_64 PackageKit-qt-0.6.16-1.fc15.x86_64 qtcurve-gtk2-1.8.5-4.fc15.x86_64 pinentry-qt-0.8.1-3.fc15.x86_64 qt-config-4.7.3-6.fc15.i686 qt-mobility-1.2.0-2.fc15.i686 qt-devel-4.7.3-6.fc15.x86_64 polkit-qt-0.99.0-2.fc15.x86_64 qt-x11-4.7.3-6.fc15.x86_64 qt-recordmydesktop-0.3.8-4.fc15.noarch polkit-qt-0.99.0-2.fc15.i686 qt3-3.3.8b-35.fc15.i686 qt3-3.3.8b-35.fc15.x86_64 qt-mobility-1.2.0-2.fc15.x86_64 poppler-qt-0.16.7-1.fc15.x86_64 qt-webkit-devel-4.7.3-6.fc15.x86_64
Christoph, the first command has to be over kdeqt.mo not over kcalc.mo and the second command output are two lines, not just one
(In reply to comment #56) > @Burkhard: Can not repro your problem, having "Ctrl+2" untranslated in japanase > (like it is in the repos at the moment) still makes 2 and Ctrl+2 work > Updated and rebuild kdelibs, kdeutils, l10n-kde4/ja(unpatched) in master + 4.7rc. master with $ KDE_LANG=ja kcalc --version Qt: 4.7.0 KDE Development Platform: 4.7.40 (4.7.40 (KDE 4.8 >= 200110623) KCalc: 2.10 KDE_LANG=ja kcalc -> "2" works (but I am pretty sure it did not work when I first tested kcalc in locale ja, "Ctrl+2" does not work. When I press "Ctrl" the text on the Shift button is empty- diiferent behavior to 4.7! branch with $ KDE_LANG=ja kcalc --version Qt: 4.7.0 KDE Development Platform: 4.7.00 (4.7.0) KCalc: 2.9 KDE_LANG=ja kcalc -> "2" + "Ctrl+2" both do not work, but after pressing the "Ctrl" button the Shift button is labelled "2" - different from master "" and from locale en_US "Ctrl+2" or de "Shift+2". In both cases I see on konsole "KTranscript: Loaded module: /home/kde42/kde47/share/locale/ja/LC_SCRIPTS/kdelibs4/kdelibs4.js" > > You guys having the original bug can you please run > msgunfmt /usr/share/locale/de/LC_MESSAGES/kcalc.mo | grep Ctrl | grep -A 1 > msgid > and > msgunfmt /usr/share/locale/de/LC_MESSAGES/kdeqt.mo | grep \"Ctrl\" | grep -A 1 > msgid > > And paste the results? Also it'd be good to know your kdelibs and Qt versions @ Albert: Please look at my Comment #47. I could not reproduce the bug with the german kdeqt.mo+kcalc.mo provided by Attila, so there must be another issue. PS reminds me of https://bugs.kde.org/show_bug.cgi?id=232918
I hope I understood your last comment, I had to change the commands to get 2 lines of output: msgunfmt /usr/share/locale/de/LC_MESSAGES/kdeqt.mo | grep -A 1 \"Ctrl\" msgid "Ctrl" msgstr "Strg" msgunfmt /usr/share/locale/de/LC_MESSAGES/kcalc.mo | grep -A 1 Ctrl msgid "Ctrl+2" msgstr "Strg+2" Christoph
I have just tested kcalc on openSUSE 11.4 Live-CD running KDE 4.6.0 kcalc 2.8 on the same hardware. The language was german. 2 and Ctrl+2 is OK. Could this be a bug by Fedora?
I had the same problem. Some days ago there was an update for gettext in the fedora Repos. And now I am not able to reproduce the bug anymore. So it seems fixed, isn't it? Ah … I updadet to KDE 4.7.2 too. So, don't know which update has resolved the bug. But for me it is fixed.
Afaik all people having this bug are on a fedora system. In cannot reproduce the bug on many systems (master, branch 4.7 compiled from sources, Kubuntu 11.04, many VM's debian/suse/mageia with kde 4.5.x/4.6.x/4.7.x) except a VM with fedora 15, bug is with kde 4.6.5 and kde 4.7. my conclusion: fedora downstream bug
No, same bug exists on pardus too: http://forum.pardususer.de/index.php?topic=1956.msg22800#msg22800 (german)
Actually it seems to be a kde-qt-problem. Fedora (15, not 16) applies the patch with the name 0012-Add-context-to-tr-calls-in-QShortcut.patch, taken from kde-qt (look into the SRPM). If qt is compiled with this patch, kcalc shows the misbehaviour described here. If compiled without, everything is working correctly. Slackware - which I use with self-compiled KDE - has the same problem, because it uses kde-qt. Qt compiled with this patch reverted, it's all OK on Slackware, too. So it seems it is no really gettext-related, nor a translation-issue. Peter
Arg, ok, this is it: http://pkgs.fedoraproject.org/gitweb/?p=qt.git;a=blob;f=0012-Add-context-to-tr-calls-in-QShortcut.patch;h=2b552d39795de3ab2eba8ee6ae0ab9a81d0837aa;hb=f15 CC'ing Albert, original author of said patch. Do you think this still a good idea for distros to carry or not?
The patch is good BUT only if shipped with translations that were made with this patch taken into account, since kde-qt is no more, the translations KDE ship no longer match the code Fedora ships, so you are shipping inconsistent translations thus the translation for "Ctrl" -> "Strg" is not correctly loaded and bad stuff is bound to happen (basically because probably Qt drops the Strg it does not understand and ends up with colliding shorcuts, the weird thing is why this only happens with 2 and not with 3, 4, etc. (ahh, just checked the code and there is no action with shortcut being Ctrl+number other than Ctrl+2))
So looks like we can close this as a downstream issue, though this is ultimately KDE's fault for discontinuing kde-qt!
This is in no way KDE's fault. KDE has always shipped tarballs that were consistent. When this patch was in kde-qt, our translations took it into account, when we stopped distributing kde-qt, our translations were changed and continued being correct. The problem is that fedora decided to apply this patch without knowing what it did and without taking into account you were using incosistent translations once KDE decided to stop distributing kde-qt. Next time you apply a patch it would be cool if you thought about the consequences of doing so and what must happen for it to work. This slip you had in fedora made us all lose lots of time trying to debug a problem none of us (except Fedora) were responsible of and most of us could never reproduce because we do not use fedora. I was expecting nothing after my comment but if anything I expected a thank you for explaining what the problem was and a commitment from your side to be more careful with patches in the future, but instead i find nothing else than an attempt to put the blame were it does not belong. And this makes me sad, because you always say you want to be a team player, but being a team player means accepting your own responsabilities, not trying to put them under the carpet.
> This is in no way KDE's fault. KDE has always shipped tarballs that were > consistent. When this patch was in kde-qt, our translations took it into > account, when we stopped distributing kde-qt, our translations were changed and > continued being correct. But nobody alerted us distributors of that change. The change affects not just our forward-ported kde-qt patches (which, incidentally, we had already dropped with 4.8 / Fedora 16, by the way), but also mixing existing kde-qt releases which you did ship with newer kde-l10n, or shipping newer Qt releases without your no longer supported kde-qt patches with older kde-l10n. This is exactly the kind of change which needs to be announced on kde-packager. > The problem is that fedora decided to apply this patch without knowing what it > did and without taking into account you were using incosistent translations > once KDE decided to stop distributing kde-qt. [paragraph snipped and quoted / replied to separately below] > This slip you had in fedora made us all lose lots of time trying to debug a > problem none of us (except Fedora) were responsible of and most of us could > never reproduce because we do not use fedora. As per comment #64 and comment #65, this also affects (or affected) at least Pardus and Slackware, which, to me, is also an indicator of a serious communication breakdown. I don't think it's fair to put all the blame on Fedora. [the paragraph snipped from the above quote:] > Next time you apply a patch it would be cool if you thought about the > consequences of doing so and what must happen for it to work. Our intention was the best, to continue to apply existing BUG FIXES to our Qt packages rather than restoring the bugs they fixed. The fact that this i18n patch slipped through was an unfortunate oversight. And yes, that was our fault. But I still consider it KDE's fault that they stopped supporting their bug fixes. > I was expecting nothing after my comment but if anything I expected a thank you > for explaining what the problem was and a commitment from your side to be more > careful with patches in the future, but instead i find nothing else than an > attempt to put the blame were it does not belong. And this makes me sad, > because you always say you want to be a team player, but being a team player > means accepting your own responsabilities, not trying to put them under the > carpet. Well, thank you for your help in debugging this! But ultimately, if kde-qt hadn't been discontinued (I still think that was a mistake; I'm also unhappy about those qt-copy patches in SVN which weren't migrated to kde-qt in git for some reason; every dropped patch is likely to be a bug coming back), or if the implications on translations had been discussed on kde-packager, we wouldn't have had this problem in the first place.
> > This is in no way KDE's fault. KDE has always shipped tarballs that were > > consistent. When this patch was in kde-qt, our translations took it into > > account, when we stopped distributing kde-qt, our translations were changed > > and continued being correct. > But nobody alerted us distributors of that change. The change affects not just > our forward-ported kde-qt patches (which, incidentally, we had already dropped > with 4.8 / Fedora 16, by the way), but also mixing existing kde-qt releases > which you did ship with newer kde-l10n, or shipping newer Qt releases without > your no longer supported kde-qt patches with older kde-l10n. This is exactly > the kind of change which needs to be announced on kde-packager. I don't think what you are asking is fair. I (as a programmer) am responsible to ensure the tarballs I ship are correct, that's the end of my responsability. You can not ask me to think of all the possible patches or not people may have or may have not applied over my code and go saying, remember if you applied patch A now you will have this problem. Enough problems I have as a programmer to make sure my stuff is the most correct I can to have to care about every possible patching combination people has done over my code. I think that it is the people adding patches on top of my code that are responsible for checking each time that I release a new version if those patches still apply. And yes, I agree this is a very cumbersome and boring process, and that is why i think there should not be any kind of distribution patching other than backporting and security fixes (when it makes sense). > I don't think it's fair to put all the blame on Fedora. Right, my fault, the problem was not Fedora, the problem was the distributions that were shipping the patch without knowing its consequences. I agree it would have been awesome if I as the actual creator of the patch would have thought on the issue an warned kde-packager. Would that would have been a plus, not something you can demand from us, since if what you had done was ship the tarballs we ship, there would have never been any problem.
> You can not ask me to think of all the possible patches or not people may have > or may have not applied over my code But these are patches KDE shipped. The lesson to take here is that patches cannot be "unpublished". Deleting the git repository with the patches won't magically make them disappear instantly everywhere. And retracting bugfixes is a very bad idea. Whenever you retract a patch, it needs to be explained somewhere (e.g. in a commit message) why it got retracted. Mass-retracting all patches by deleting the repository, without giving any convincing reason why they're no longer needed, is extremely unhelpful. (FWIW, there has been more than one mass drop event: move from SVN (qt-copy) to git (kde-qt), moves from one Qt version to the next, deletion of kde-qt in git. Each of them dropped bugfixes without giving any reason.) The default assumption is that if the patch still applies, as in "patch doesn't complain about fuzz or rejects", it's probably still needed. > if what you had done was ship the tarballs we ship, there would have never been > any problem. There would have been a problem for a while, because we cannot reasonably be expected to upgrade Qt and kde-l10n at exactly the same time.
> There would have been a problem for a while, because we cannot reasonably be > expected to upgrade Qt and kde-l10n at exactly the same time. That is true, I sincerely thought that we did ship kde-qt tarballs together with KDE releases, but it seems we never did. So you are right that the patch was flawed in assuming that a Qt with the patch would be used along with our translations built against the patched Qt. I am sorry about that. Good stuff that we decided to drop kde-qt patches and now with Qt-project.org merging our patches upstream should be hopefully (let's dream) easier.
I just want to say thank you for fixing this bug. Fedora 16 is out and "2" + "Strg+2" is working again.