265871 - JavaScript Console should be renamed to Error Console

Status: VERIFIED FIXED

(Toolkit Graveyard :: Error Console, defect)

Description

[Hixie (not reading bugmail)]

The JS Console now does much more than just JS. We should rename it to something
like the Web Console or Error Console.

Comment 1

[Robert Kaiser]

Erm, shouldn't we do this for Seamonkey as well?

Comment 2

[Michael Tibben]

I agree... here are some alternative ideas:

Message Console
Developer Console
Scripting Console
Script Console
Debug Console
Firefox Console
Error Console

Comment 3

[Reed Loden [:reed]]

*** Bug 316149 has been marked as a duplicate of this bug. ***

Comment 4

[Frank]

i think Debug-Console is the best name...

Pls split the errors/warnings/hints into languages (html/js/css) and error-types (unknown tags/syntax error)

is it possible to define own texteditor (in my case scite) for displaying sourcecode? I know the main-problem is to set the line-number where the error is...but there can be a command-line with variables for displaying in another editor like this:

...\scite.exe %(filename) -goto:%(linenumber)

Comment 5

[Michael Tibben]

"Debug Console" could be confused with the Javascript Debugger. 
Personally I like "Scripting Console", as the word scripting can refer to javascript, css, html, or any other kind of web script collectively.

Comment 6

[Tom Chiverton]

I don't like 'scripting console' because it is geek-speak, and people don't normally talk of scripting CSS.
I agree 'debug console' is confusing.

Error console gets my vote.

Comment 7

[sasha]

Whatever it is called it should not have mixed JS and CSS messages. At this time firefox has no more JS Console. This thing that took its name and place is almost useless for any serious work. Just reloading Google page fills it up with so called "errors". There should be some mechanism in place that would let me see "JavaScript errors" in "JavaScript console" without all this CSS stuff. Well, uckily Opera still has JS console :)

Comment 8

[sasha]

Heh, I found extension called Console2. Very nice. It makes console even more usefull then before.

Comment 9

[Giovanni Glass]

I vote for calling it "error console". "Javascript Console" is just misleading now that it covers CSS as well.

(In reply to comment #0)
> The JS Console now does much more than just JS. We should rename it to
> something
> like the Web Console or Error Console.
> 

Comment 10

[Magnus Melin [:mkmelin]]

"Developer Console" would get my vote, followed by "Debug Console". 

Comment 11

[Willem Jeffery]

(In reply to comment #7)
> Whatever it is called it should not have mixed JS and CSS messages. At this
> time firefox has no more JS Console. This thing that took its name and place is
> almost useless for any serious work. Just reloading Google page fills it up
> with so called "errors". There should be some mechanism in place that would let
> me see "JavaScript errors" in "JavaScript console" without all this CSS stuff.

I second that.
I can't hear my javascript anymore because all the CSS is shouting at me.

I propose the CSS errors are lowered to 'warning', their rightful place, like bug 316200 also proposes. A CSS parse error does not require immediate attention -- if any at all. JS errors are less obvious from the code and the coder often requires help from the browser.

As for the name, I'd prefer 'Error Console', of if you're exact, 'Error Log'.

Comment 12

[richardtallent]

- I vote for anything that doesn't have the word "Console" in it. Suggest: "Page Debug Log" or similar.

- CSS properties that are valid CSS2/CSS3 but that Firefox has no support for yet (box-sizing, border-radius, background-size, etc.) should not be reported as errors or even warnings. If we really must report them, they should be at the "message" level.

- CSS properties that are valid in form but that custom properties for other browsers (filter, behavior, text-overflow, etc.) should be reported as "Warnings." If they are commonly found "in the wild", I would argue that they, too, should be moved to Messages. Cross-browser support demands some custom properties, the user agent should ignore what it doesn't understand as long as the syntax is valid, not throw errors.

- Suggest adding messages/warnings/errors relating to parsing of XHTML when Transitional or Strict DOCTYPE is in effect.

- There should be a way to both toggle-filter messages by source (JS, CSS, SVG, XHTML, etc.) and by severity (Error, Warning, Message). The "Clear" button should clear only the currently-filtered messages.

Comment 13

[u88484]

Question: When creating a patch for this do we have to rename every instance of javascript console in the tree? like including extensions and inside jar files?

btw I propose 'Developer Console' and almost have a complete patch...just need to know if I need to add the above stuff or take out some other things. Easy to rename it if need be once I create the patch incase developer console is not wanted.

Comment 14

[u88484]

Attachment: everything -mail/xpfe/calendar

Patch includes changes for everything except calendar, xpfe, and mail. Mail and xpfe coming up...caldendar I will get to in a few days.

Comment 15

[u88484]

Attachment: Mail patch

Comment 16

[Daniel C]

What about just 'Console'?

Tools -> Console

Makes sense to me. Although Developer Console is probably the best of the rest. Error Console is technically incorrect, for the same reason as this bug was filed to start with.

Comment 17

[Simon Bünzli]

I'd rather go with "Error Console" or "Message Console". While technically both of them are incorrect, IMHO they're the least confusing for non-developing users. Just imagine: you're having an extension or a website tested and you want all errors to be reported by any user...

> Developer Console
Implies that it's mainly for developers. Why would it then be installed everywhere? And would this make the reporting user to an assistant developer?

> Scripting Console
> Script Console
> Debug Console
These are all mainly geek-speak (as mentioned above). No need to confuse the users here. (Although I quite like Debug Console - since that's what it's used for)

> Firefox Console
Rather "Toolkit Console", but "Toolkit" won't mean anything to Joe User, either.

> Console
I'd vote for that one, if there weren't any other consoles to be mentioned with which that one could be confused (Java Console, System Console).

So unless the "Console" part shouldn't be dropped completely, I'd vote for the remaining two - so that you can ask your users to report the errors from the ... Error Console (or any messages from the Message Console) - which will make the most sense for them.

As for "Error Log", "Web Debug Log" et al., it sounds somewhat funny to evaluate some JavaScript code in a log (removing the JavaScript evaluation part would help - has that already been suggested?)...

Comment 18

[Daniel C]

(In reply to comment #17)
> > Firefox Console
> Rather "Toolkit Console", but "Toolkit" won't mean anything to Joe User,
> either.

Firefox Console is quite good I think, and a possibility (Thunderbird could have Thunderbird Console), it doesn't have to be Toolkit Console (which is indeed a rubbish name). However, there is no other menuitem (on Linux/Windows anyway, I know Mac is different) that has the brand name in it, with the exception of About... There is no 'Quit Firefox', or 'Firefox Help', which is why that may not be an option. I had thought that Console could be confusing (command console, Java Console etc.)

Comment 19

[Magnus Melin [:mkmelin]]

*** Bug 330845 has been marked as a duplicate of this bug. ***

Comment 20

[:deanis74]

Comment on attachment 208757 [details] [diff] [review]
everything -mail/xpfe/calendar

I think the safest way of doing this is not to change the menuitem id or the label and accesskey variable names.  Just change the strings in the .dtd files and be done with it.  This will break the fewest things in FF, and also any existing extensions that look for the menus by id will not have to be updated.

Comment 21

[Mike Connor [:mconnor]]

Comment on attachment 208759 [details] [diff] [review]
Mail patch

Dean, when we're changing strings, we change the entity names so that localizers will see the change and follow up.  The menuitem ids shouldn't change though, so extensions targeting bits are less likely to change.

Developer Console isn't really the right string, since that will be out of place for a default UI piece.

Comment 22

[Mike Connor [:mconnor]]

Beltzner and I went through the possibilities a while back and decided Error Console was the right choice.

Comment 23

[Jez McKean]

(In reply to comment #16)
> What about just 'Console'?

Agreed.

Comment 24

[u88484]

(In reply to comment #22)
> Beltzner and I went through the possibilities a while back and decided Error
> Console was the right choice.
> 

Mike, with it being renamed to error console, I forsee dozens/hundreds of bugs/threads with users pasting every single error that shows in the console. They will think everysite with hundreds of css errors is a firefox bug and they will post away. Right now javascript console tends to keep the "noobs" away from that area since they don't technically understand what it is and how to use it. And developer console would do the same. 

Comment 25

[Tom Chiverton]

All the more reason to have filtering in the core, if every last little CSS glitch is going to be spat out to normal users.

Comment 26

[Simon Bünzli]

(In reply to comment #24)
> Mike, with it being renamed to error console, I forsee dozens/hundreds of
> bugs/threads with users pasting every single error that shows in the console.

First, CSS errors aren't errors anymore but only warnings (see bug 264162). And second, bug 312962 might even get as far as make the difference between CSS and JS errors (more) obvious (e.g. but not necessarily as Console² does). Third, we might even hide the CSS errors by default (see also below). And fourth, if we have to educate users about who is responsible for what, we'll lose only a little time (duping ain't that hard) and have (hopefully) more educated users as reward.

(In reply to comment #25)
> All the more reason to have filtering in the core, if every last little CSS
> glitch is going to be spat out to normal users.

Filtering should not go to the core but to the console itself (at least not more than we've got by mentioned bug 264162) - see bug 275265 for the work on this. I'd just vote for disabling to show CSS errors by default.

Comment 27

[Magnus Melin [:mkmelin]]

Any chance you could reconsider the name? IMO, Error console is almost as bad as  JavaSript console. If not "Developer Console" than simply "Console"?

I do see the point about dev console not being "out of
place for a default UI piece", but I think it makes sence to target it to developers. Developers are an important/the target audience for this feature and normal users will be confused to think the problem is with firefox - see comment 24.

Comment 28

[Mike Connor [:mconnor]]

I think you guys aren't giving users enough credit, in general.  There's always going to be some users who won't get it, but console on its own doesn't tell people a lot, and if its just a developer tool, it shouldn't be in the core.

Part of the goal with the UI rethink pegged for b1 is to allow better filtering/display.  If users don't get what something is, we should have a way for them to figure it out, not name it something scary so they won't touch it.

Comment 29

[u88484]

Mike, are we just changing the ui or even all of the commands that are called? Like the following (specifically the omcommand line)?

-              <menuitem id="javascriptConsole" 
-                        label="&javaScriptConsoleCmd.label;" accesskey="&javaScriptConsoleCmd.accesskey;"
+              <menuitem id="errorConsole" 
+                        label="&errorConsoleCmd.label;" accesskey="&errorConsoleCmd.accesskey;" 
                         oncommand="errorConsole();"/>

Comment 30

[Eyal Rozenberg]

Indeed, it is certainly not an 'error' console. I agree with comment #27.

Comment 31

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I'm with mconnor on this one -- "Error Console" is the name that makes the most sense, esp. if the default settings are to show errors but not warnings.  Note that "Script Console" would be quite a lie, since we show all sorts of other errors (XML parsing errors come to mind) there.

Comment 32

[u88484]

So do we just want the UI/labels changed to say Error Console or also all of the commands and stuff like 'toJavaScriptConsole()' or just leave those be so that only the UI is changed?

Comment 33

[:Gavin Sharp [email: [e-mail]]]

At least for now, there's no reason to change the function names.

Comment 34

[Eyal Rozenberg]

(In reply to comment #31)
> Note that "Script Console" would be quite a lie,

Ok, so we rule out 'script console'. But why not 'developer console' or just 'console' or 'message console'?

Comment 35

[Simon Bünzli]

(In reply to comment #34)
> Ok, so we rule out 'script console'. But why not 'developer console' or just
> 'console' or 'message console'?

As already said in comment #17:
"Developer Console" raises the question why developer tools are included in the default distribution (which AFAIK is because we want users being able to report errors - so rather "Debugger Console" which however sounds too geeky).

"Console" doesn't further allow to make a distinction to the system console (invoked through the -console command line parameter) or the rarely used Java console.

And "Message Console" is IMO only second choice since "message" is ambivalent (for one all errors/warnings/messages and for the other just the harmless/uninteresting messages) - and the default is and will continue to be to only show errors at first.

Comment 36

[u88484]

Attachment: Rename to error console

Comment 37

[:deanis74]

(In reply to comment #36)
> Created an attachment (id=221502) [edit]

From comment 21, "The menuitem ids shouldn't change though, so extensions targeting bits are less likely to change."

Comment 38

[u88484]

Attachment: Updated patch

Thanks dean, forgot about that.

Doesn't change menuitem id's

Comment 39

[BoffinBrain]

I vote for Error Console.

I understand that in programming terms, errors are usually fatal, but I prefer the human semantics of the word, where anything showing in this console signifies an 'error' on the part of the web designer or indeed the browser itself when coming across unrecognised attributes etc.  I think the majority here like this term the most.

I also agree with the default view settings to show only JavaScript and Errors.

Comment 40

[Mike Connor [:mconnor]]

Comment on attachment 221505 [details] [diff] [review]
Updated patch

r=me on the browser/toolkit bits

bz, this changes a bunch of stuff in core-ish areas, can you double-check these are ok?

Comment 41

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 221505 [details] [diff] [review]
Updated patch

sr=bzbarsky.  Gotta love the different accesskeys in different overlays...

Comment 42

[Boris Zbarsky [:bzbarsky]]

Neil, we might want similar changes to Seamonkey.

Comment 43

[[e-mail]]

(In reply to comment #42)
>Neil, we might want similar changes to Seamonkey.
Hmm, the patch already changes suite help; incorrectly as it happens...

Comment 44

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, is the chatzilla change correct?

Comment 45

[James Ross]

Most certainly not.

Comment 46

[u88484]

(In reply to comment #43)
> (In reply to comment #42)
> >Neil, we might want similar changes to Seamonkey.
> Hmm, the patch already changes suite help; incorrectly as it happens...
>

(In reply to comment #44)
> hm, is the chatzilla change correct?
>
Can you guys please elaborate? (In reply to comment #45)
> Most certainly not.
> 
 

Can you guys please elaborate?

Comment 47

[James Ross]

The ChatZilla change is changing something that does NOT reference the JavaScript Console.

-msg.client.opened     = JavaScript console for ``*client*'' opened.
+msg.client.opened     = Error Console for ``*client*'' opened.

Note that the 'c' is not capitalised. The message is used in reference to a specific view you can open in ChatZilla that allows (among other things) arbitrary execution of JavaScript. It is *a* JavaScript console, not *the* JavaScript Console. Subtle, perhaps, but very definately an incorrect change.

Comment 48

[Steffen Wilberg]

Comment on attachment 221505 [details] [diff] [review]
Updated patch

>Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
>-  <h3 id="javascript_console">JavaScript Console</h3>
>-  <p>Opens the JavaScript Console, which tracks problems with JavaScript code.
>+  <h3 id="javascript_console">Error Console</h3>
>+  <p>Opens the Error Console, which tracks problems with JavaScript code.
Please also change the corresponding toc entry (just the nc:name):
http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331

Firefox Help is indeed in browser/locales.
Seamonkey (Suite) Help is in extensions/help. Those changes are incorrect since you didn't change the console for Seamonkey. See
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd#16
http://lxr.mozilla.org/seamonkey/source/xpfe/components/console/resources/locale/en-US/console.dtd#38

Comment 49

[u88484]

(In reply to comment #47)
> The ChatZilla change is changing something that does NOT reference the
> JavaScript Console.
> 
> -msg.client.opened     = JavaScript console for ``*client*'' opened.
> +msg.client.opened     = Error Console for ``*client*'' opened.
> 
> Note that the 'c' is not capitalised. The message is used in reference to a
> specific view you can open in ChatZilla that allows (among other things)
> arbitrary execution of JavaScript. It is *a* JavaScript console, not *the*
> JavaScript Console. Subtle, perhaps, but very definately an incorrect change.
> 

ok will submit a new patch to remove the chatzilla specific changes.

(In reply to comment #48)
> (From update of attachment 221505 [details] [diff] [review] [edit])
> >Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
> >-  <h3 id="javascript_console">JavaScript Console</h3>
> >-  <p>Opens the JavaScript Console, which tracks problems with JavaScript code.
> >+  <h3 id="javascript_console">Error Console</h3>
> >+  <p>Opens the Error Console, which tracks problems with JavaScript code.
> Please also change the corresponding toc entry (just the nc:name):
> http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
> 
> Firefox Help is indeed in browser/locales.
> Seamonkey (Suite) Help is in extensions/help. Those changes are incorrect since
> you didn't change the console for Seamonkey. See
> http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd#16
> http://lxr.mozilla.org/seamonkey/source/xpfe/components/console/resources/locale/en-US/console.dtd#38
> 

Are the Seamonkey changes wanted?

Comment 50

[[e-mail]]

The error I spotted was that "Error Console" should be indexed under "E".

Comment 51

[u88484]

(In reply to comment #50)
> The error I spotted was that "Error Console" should be indexed under "E".
> 

What do you mean by that? Are the help docs indexed alphabetically?

Comment 52

[[e-mail]]

(In reply to comment #49)
>Are the Seamonkey changes wanted?
Yes please, particularly as we'll be switching to the toolkit error console anyway. Note that I wouldn't bother changing any entity names, just values.

Comment 53

[u88484]

Attachment: this should do it

(In reply to comment #52)
> (In reply to comment #49)
> >Are the Seamonkey changes wanted?
> Yes please, particularly as we'll be switching to the toolkit error console
> anyway. Note that I wouldn't bother changing any entity names, just values.
> 
done

(In reply to comment #47)
> The ChatZilla change is changing something that does NOT reference the
> JavaScript Console.
> 
> -msg.client.opened     = JavaScript console for ``*client*'' opened.
> +msg.client.opened     = Error Console for ``*client*'' opened.
> 
> Note that the 'c' is not capitalised. The message is used in reference to a
> specific view you can open in ChatZilla that allows (among other things)
> arbitrary execution of JavaScript. It is *a* JavaScript console, not *the*
> JavaScript Console. Subtle, perhaps, but very definately an incorrect change.
> 
chatzilla changes removed

Comment 54

[Steffen Wilberg]

Comment on attachment 222408 [details] [diff] [review]
this should do it

You still haven't fixed the Table of Contents of Firefox Help:
http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
That is displayed in the sidebar of the Help Viewer. Just expand Menu Reference->Tools and note that there's still a "JavaScript Console" entry.

You also didn't address Neil's comment about this file being sorted alphabetically, so "Error Console" should be listed under "#e", not "#j":
http://lxr.mozilla.org/mozilla/source/extensions/help/resources/locale/en-US/help-index1.rdf

Comment 55

[[e-mail]]

Comment on attachment 222408 [details] [diff] [review]
this should do it

It would be nice if you could change xpfe's access key to 'C' too, thanks.

Comment 56

[u88484]

Attachment: Again

(In reply to comment #55)
> (From update of attachment 222408 [details] [diff] [review] [edit])
> It would be nice if you could change xpfe's access key to 'C' too, thanks.
> 

Done

(In reply to comment #54)
> (From update of attachment 222408 [details] [diff] [review] [edit])
> You still haven't fixed the Table of Contents of Firefox Help:
> http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
> That is displayed in the sidebar of the Help Viewer. Just expand Menu
> Reference->Tools and note that there's still a "JavaScript Console" entry.
> 
> You also didn't address Neil's comment about this file being sorted
> alphabetically, so "Error Console" should be listed under "#e", not "#j":
> http://lxr.mozilla.org/mozilla/source/extensions/help/resources/locale/en-US/help-index1.rdf
> 

Both done

Comment 57

[Steffen Wilberg]

Comment on attachment 222555 [details] [diff] [review]
Again

The Firefox Help changes are fine, thanks. But I can't review the other changes, so requesting review from mconnor again.

Comment 58

[[e-mail]]

Comment on attachment 222555 [details] [diff] [review]
Again

Note: malformed patch at line 27 [patch stops at this error so there may be more].

Should we rename -jsconsole too? Should we rename jsConsoleHandler to errorConsoleHandler?

If you're not going to patch suite help index then please volunteer someone else to do all of the help changes.

Comment 59

[u88484]

(In reply to comment #58)
> (From update of attachment 222555 [details] [diff] [review] [edit])
> Note: malformed patch at line 27 [patch stops at this error so there may be
> more].
> 

Looks like that part of the patch bittrotted because of the change to Add-ons, will fix that tonight

> Should we rename -jsconsole too? Should we rename jsConsoleHandler to
> errorConsoleHandler?
> 

I donno. From what I understood, only change things like entity values and help docs. Not change functions, menuid's and all the other stuff.

> If you're not going to patch suite help index then please volunteer someone
> else to do all of the help changes.
> 
Did I not include the help changes for suite? becuase I can't find what your talking about. I donno if I missed checking those out or I forgot to patch the index. I know I changed the index in help-index1.rdf

If I missed it altogether I'm sorry, not intentionally not including suite stuff.

Going to post an updated patch tonight after a reply to this comment from you. 

Comment 60

[[e-mail]]

I see it now; I had expecting the files to be in alphabetical order...

Comment 61

[[e-mail]]

oops; indecision between "had expected" and "was expecting"

Comment 62

[u88484]

(In reply to comment #61)
> oops; indecision between "had expected" and "was expecting"
> 

oh, I've just been adding to the original patch since I deleted all of the checked out files I had when I first created the patch. Didn't feel like re checking them out and creating an all new patch...a lot of checking out and editing. I don't download the whole source, just which ever files I need at the time for a patch.

So if everything is good then I will fix the bitrotted part tonight and resubmit tonight.

Comment 63

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #59)
> Looks like that part of the patch bittrotted because of the change to Add-ons,
> will fix that tonight

No, bitrotting doesn't explain "malformed patch" errors.

Comment 64

[Steffen Wilberg]

You should use "cvs co <files>" to checkout the files you need, then "patch -p0 < patchfile" to apply the patch, then "cvs diff -up8 <files>" to generate the patch.

Use "cvs co <files>" again to merge the latest changes from the server. CVS doesn't remove your modifications, but tries to merge them. If cvs can't resolve conflicts, you need to fix them by hand with an editor. And don't delete your local files again!

Comment 65

[u88484]

(In reply to comment #64)
> You should use "cvs co <files>" to checkout the files you need, then "patch -p0
> < patchfile" to apply the patch, then "cvs diff -up8 <files>" to generate the
> patch.
> 
> Use "cvs co <files>" again to merge the latest changes from the server. CVS
> doesn't remove your modifications, but tries to merge them. If cvs can't
> resolve conflicts, you need to fix them by hand with an editor. And don't
> delete your local files again!
> 

ahhh I never knew I could locally apply a patch. I always thought I was to build myself with the patch attached to see the changes. Thanks and I will play around with that tonight and hope to have a final working patch tonight.

Comment 66

[[e-mail]]

(In reply to comment #65)
>I always thought I was to build myself with the patch attached to see the changes.
That's still correct, but this technique can be useful e.g. when fixing bitrot.

Comment 67

[u88484]

Attachment: Next attempt

ok I re checkedout every file and created a new fresh patch. Got rid of some bitrot like no more webshell stuff and qute is gone in the toolkit now (those changes were in previous patch). Also, I talked to biesi on IRC and he said this patch applied fine with no errors

Hopefully this is it, thanks guys for putting up with me...still learning here.

Comment 68

[[e-mail]]

Comment on attachment 222690 [details] [diff] [review]
Next attempt

Almost there, however I did find two issues which will need to be addressed before check in:

>Index: mozilla/extensions/help/resources/locale/en-US/help-index1.rdf
>      </rdf:li></rdf:Seq>
>+     <rdf:li>
>+       <rdf:Description ID="JSConsole"
>+         nc:name="error console"
>+         nc:link="developer_tools.xhtml#js_console"/>
>+     </rdf:li>
>    </nc:subheadings>
You have to be careful here: the </rdf:Seq> denotes the end of the section. Instead, your patch needs to look like this:
+     </rdf:li>
+     <rdf:li>
+       <rdf:Description ID="JSConsole"
+         nc:name="error console"
+         nc:link="developer_tools.xhtml#js_console"/>
      </rdf:li></rdf:Seq>
    </nc:subheadings>

>Index: mozilla/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd
>-<!ENTITY javaScriptConsoleCmd.label                             "JavaScript Console">
>-<!ENTITY javaScriptConsoleCmd.accesskey				"S">
>+<!ENTITY errorConsoleCmd.label                                  "Error Console">
>+<!ENTITY errorConsoleCmd.accesskey				"C">
>Index: mozilla/xpfe/components/console/resources/locale/en-US/console.dtd
>-<!ENTITY console.title "JavaScript Console">
>+<!ENTITY errorConsole.title "Error Console">
I did ask you not to change the names, only the values...

Comment 69

[Simon Bünzli]

(In reply to comment #68)
> I did ask you not to change the names, only the values...

I suppose you're only talking about the console.title bit and not about the javaScriptConsoleCmd.label one (which probably should be changed according to http://developer.mozilla.org/en/docs/Writing_localizable_code#Guidelines ).

Comment 70

[[e-mail]]

OK, I guess you can change javascriptConsoleCmd to errorConsoleCmd, but in that case don't forget to patch the XUL file too!

Comment 71

[u88484]

Attachment: Another

(In reply to comment #68)
> (From update of attachment 222690 [details] [diff] [review] [edit])
> Almost there, however I did find two issues which will need to be addressed
> before check in:
> 
> >Index: mozilla/extensions/help/resources/locale/en-US/help-index1.rdf
> >      </rdf:li></rdf:Seq>
> >+     <rdf:li>
> >+       <rdf:Description ID="JSConsole"
> >+         nc:name="error console"
> >+         nc:link="developer_tools.xhtml#js_console"/>
> >+     </rdf:li>
> >    </nc:subheadings>
> You have to be careful here: the </rdf:Seq> denotes the end of the section.
> Instead, your patch needs to look like this:
> +     </rdf:li>
> +     <rdf:li>
> +       <rdf:Description ID="JSConsole"
> +         nc:name="error console"
> +         nc:link="developer_tools.xhtml#js_console"/>
>       </rdf:li></rdf:Seq>
>     </nc:subheadings>

Fixed

> 
> >Index: mozilla/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd
> >-<!ENTITY javaScriptConsoleCmd.label                             "JavaScript Console">
> >-<!ENTITY javaScriptConsoleCmd.accesskey				"S">
> >+<!ENTITY errorConsoleCmd.label                                  "Error Console">
> >+<!ENTITY errorConsoleCmd.accesskey				"C">
> >Index: mozilla/xpfe/components/console/resources/locale/en-US/console.dtd
> >-<!ENTITY console.title "JavaScript Console">
> >+<!ENTITY errorConsole.title "Error Console">
> I did ask you not to change the names, only the values...
> 

Oops, forgot about that when I started over; Reverted it back to console.title

(In reply to comment #70)
> OK, I guess you can change javascriptConsoleCmd to errorConsoleCmd, but in that
> case don't forget to patch the XUL file too!
> 

Fixed...Left it as errorConsoleCmd and also changed that in the xul file.

Donno if I was supposed to carry forward the superreview or not so I requested superreview again.

Comment 72

[u88484]

Comment on attachment 222783 [details] [diff] [review]
Another

Can someone check this in on the trunk? Thanks

I don't have a clue on who to ask branch approval for so leaving a blank request.

Comment 73

[:Gavin Sharp [email: [e-mail]]]

Attachment 222783 [details] [diff] checked in on the trunk.

Comment 74

[:Gavin Sharp [email: [e-mail]]]

Attachment 222783 [details] [diff] checked in on the branch.