After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788409 - cosh and sinh button labels are swapped
cosh and sinh button labels are swapped
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
3.24.x
Other Linux
: Normal minor
: ---
Assigned To: gcalctool maintainers
gcalctool maintainers
Depends on:
Blocks:
 
 
Reported: 2017-10-01 23:03 UTC by rusins
Modified: 2017-10-02 06:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description rusins 2017-10-01 23:03:59 UTC 
In the "Advanced mode" of the calculator app, pressing the "cosh" button inputs "sinh" into the calculator expression field, and pressing the "sinh" button inputs "cosh" respectively. Seems like a simple mistake when labelling the buttons / actions.
Comment 1 Robert Roth 2017-10-01 23:15:14 UTC 
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
Comment 2 Daniel Boles 2017-10-02 06:40:48 UTC 
The IDs in the ui file are still swapped:

https://git.gnome.org/browse/gnome-calculator/commit/?id=2193ce3936f94489456872a68175e9f0303ee990
Comment 3 Robert Roth 2017-10-02 06:42:59 UTC 
(In reply to Daniel Boles from comment #2)
> The IDs in the ui file are still swapped:
> 
> https://git.gnome.org/browse/gnome-calculator/commit/
> ?id=2193ce3936f94489456872a68175e9f0303ee990

Indeed, thanks for pointing that out. After some thinking I'll probably revert the previous fix and change the action the buttons do, that way the labels and the id can stay the same, so no translation changes are required.
Comment 4 Daniel Boles 2017-10-02 06:47:11 UTC 
afaict, it wouldn't matter either way, as these labels don't have the translatable attribute, and gettext works on the basis of the original string anyway, so it wouldn't affect translation files if strings are moved/copied around.