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 661194 - Reject seems a bit harsh for not wanting to pick up the call
Reject seems a bit harsh for not wanting to pick up the call
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: message-tray
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Jean-François Fortin Tam
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-07 15:44 UTC by William Jon McCann
Modified: 2012-11-06 20:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (12.50 KB, image/png)
2011-10-07 15:44 UTC, William Jon McCann
  Details
o hai, i fixed ur bug (1.58 KB, patch)
2012-11-01 14:18 UTC, Jean-François Fortin Tam
reviewed Details | Review
the ultimate patch (1006 bytes, patch)
2012-11-05 16:34 UTC, Jean-François Fortin Tam
committed Details | Review

Description William Jon McCann 2011-10-07 15:44:05 UTC
Created attachment 198545 [details]
screenshot

The incoming call notification offers me the option of "Answer" or "Reject". The latter sounds a bit harsh to me. I don't really want to reject anyone if I'm just busy at the moment.
Comment 1 Jean-François Fortin Tam 2012-10-30 20:57:32 UTC
Sure, but then please find a better synonym or this should be closed as "wontfix, no suggestion" :)

So far, any word among those would feel just as harsh:

object, oppose, protest, resist, combat, contest, fight, decline, deny, disallow, disapprove, refuse, spurn, turn down, veto

Yes, some of them sound funny, but I included them for the sake of completeness. "Refuse" is just as harsh as reject, and I don't see any other words that would fit without being harsh. It's not like you're actually _saying_ those words to the other person that's calling anyway.
Comment 2 William Jon McCann 2012-10-30 21:41:30 UTC
iOS seems to use "Decline". Android seems to use "Ignore" or "Decline". You could also do it symbolically. Ignore may be overloaded and imply persistence.

Decline seems fine and is symmetric with accept/answer.
Comment 3 Allan Day 2012-11-01 12:14:20 UTC
(In reply to comment #2)
...
> Decline seems fine and is symmetric with accept/answer.

I agree.
Comment 4 Jean-François Fortin Tam 2012-11-01 14:18:24 UTC
Created attachment 227801 [details] [review]
o hai, i fixed ur bug

Are these the droids you were looking for?
Comment 5 Giovanni Campagna 2012-11-01 16:25:07 UTC
Review of attachment 227801 [details] [review]:

I liked the other commit message! :)

::: js/ui/status/bluetooth.js
@@ +344,3 @@
         this.addButton('always-grant', _("Always grant access"));
         this.addButton('grant', _("Grant this time only"));
+        this.addButton('reject', _("Decline"));

Why this one too?

IMHO, in this case you want to "reject" someone/something, as generally you control pairing from both ends, so if you reject it means someone is attempting to hack you through bluetooth.
Comment 6 Jean-François Fortin Tam 2012-11-01 16:38:20 UTC
Just thought that I'd make it consistent (and save translators some work).
I'm fine if others decide to keep the original bluetooth wording though.
Comment 7 Stéphane Démurget 2012-11-05 00:58:39 UTC
Since the context is:

    Authorization request from %s
    Device %s wants access to the service '%s'

I agree with Giovanni that decline does not make sense in this context.
"Reject" seems fine, I think "Refuse" is even better, but makes an unuseful string change.

Let's fix this!
Comment 8 Allan Day 2012-11-05 15:47:33 UTC
(In reply to comment #6)
> Just thought that I'd make it consistent (and save translators some work).
> I'm fine if others decide to keep the original bluetooth wording though.

Yeah, let's keep the wording for the bluetooth notification. Could you update the patch just to change the call one, Jean-François?
Comment 9 Jean-François Fortin Tam 2012-11-05 16:34:26 UTC
Created attachment 228150 [details] [review]
the ultimate patch

Here it is then.
Comment 10 drago01 2012-11-05 19:58:13 UTC
Review of attachment 228150 [details] [review]:

OK.
Comment 11 Allan Day 2012-11-06 20:55:16 UTC
Pushed to master.