381648 - Add link to FAQ on connection error

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, enhancement)

Description

[:Mook]

It might be worthwhile to have a [help] link in the connection error messages, that links to the corresponding entry in the FAQ.  This would of course require the FAQ to have named anchors for each error with the link.

Apparently some people can be so lazy that they ask in #chatzilla instead of just reading the FAQ - so linking to the right place in the FAQ might help.

Comment 1

[:Gijs (he/him)]

We could change the error strings to include a button-mungeable thing, and enable the button munger from whatever displays these errors, and re-use the faq command. Give it an extra optional parameter for the anchor to use, add anchors to the subitems if necessary, and that should be it. Anyone up for writing this up?

Comment 2

[James Ross]

The anchors need to be unique, since all locales will get the same ones, so here are some options I've thought of:

  #con_reset, #con_nohost, #con_timeout, etc.
  #error_reset, #error_nohost, #error_timeout, etc.
  #con_error_reset, #con_error_nohost, #con_error_timeout, etc.

Comment 3

[:Mook]

Attachment: use inline buttons

initial implementation; questions:
- is there some way to implement this without making cmdFAQ a function?
- I'm unconditionally toggling inline-buttons on and off.  That might not be such a good thing...
- could use better tooltips :p
(Haven't touched the server-side stuff yet)

Comment 4

[James Ross]

What happens is:

1. /faq #foo
2. /goto-url faq #foo
3. /goto-url <url>
4. url = "faq", #foo dropped.

So the options are to change /goto-url to accept <url> [<anchor>], and then you'll get e.url and e.anchor in the code, or to change the argument to be a 'rest of input' consumer, i.e. one of the ones listed here: http://lxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/commands.js#267

I think making /goto-url take an optional extra argument, <anchor>, is the best way - it will help the code in cmdGotoURL too.

Comment 5

[James Ross]

Comment on attachment 266297 [details] [diff] [review]
use inline buttons

>-msg.connection.refused = Connection to %S (%S) refused.
>+msg.connection.refused = Connection to %S (%S) refused. [[help][Open the FAQ][faq connection.refused]]

The existing items with buttons currently follow this style:
  Some message here, ending a full sentence first. [[Button][Some description of what happens][%S]]

So, I suggest something like this for these errors:
  msg.connection.refused = Connection to %S (%S) refused. [[Help][Get more information about this error online][%S]]

The %S for the command is important, as we should not be exposing localisers to anything they should not be translating - although, in this case, it might be useful... I'm still open on this point.

Comment 6

[:Mook]

Attachment: make goto-url accept <anchor>

Per discussion on IRC, left the whole command to execute when clicking help localizable.

Comment 7

[James Ross]

Comment on attachment 266944 [details] [diff] [review]
make goto-url accept <anchor>

>+        // given "goto-url faq bar", expand to "http://.../faq/#bar"

Nit: Capital letter at the start, please.

>         var localeURLKey = "msg.localeurl." + e.url;
>+        var hash = ("anchor" in e && null != e.anchor) ? "#" + e.anchor : "";

Nit: Wrap the 'in' operands in parentheses and drop the "null !=".

r=silver with those nits fixed.

Comment 8

[:Mook]

Attachment: nits fixed

Comment 9

[James Ross]

Checked in --> FIXED.

Comment 10

[:Gijs (he/him)]

Uhhh... did FAQ changes also get checked in? The site is not showing them yet, afaict.

Comment 11

[James Ross]

The FAQ on the website was updated 30 minutes ago. There are no *visual* changes, only named anchors added to the HTML.