Closed Bug 301208 Opened 19 years ago Closed 11 years ago

Improve the new netError.dtd

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bugs.caleb, Assigned: beltzner)

References

(
URL
)

Details

Attachments

(1 file, 9 obsolete files)

w/changes from dria (requires patch from 302729 to test)
14.22 KB, patch
Details | Diff | Splinter Review 
After the new error pages land (bug 280190), the error descriptions should be
analyzed once again and improved wherever possible before the localization freeze.

There are some parts which could be re-worded and made much more user friendly
and efficient. It's better to have the opinion of people who handle the help
system, becuase I'm sure that they can express themselves better :)

I'll CC a few people who might be of help.
Mention of configuring software/personal firewalls would be good, that's one of
the most common issues over at MozillaZine forums (especially after a user has
upgraded and their firewall decides to block the modified exe).
(In reply to comment #3)
> note also my comments in bug 280190 comment 153

William, could you take a look on that part?
Also see bug 280190 comment 170
This should block 1.8b4 since it has an l10n impact.
Flags: blocking1.8b4?
Blocks: branching1.8
Mike, can you take a look through these strings and see if we need to make
changes before 1.5? If so, it needs to happen before 1.8b4.
Flags: blocking1.8b4? → blocking1.8b4+
(In reply to comment #7)
> Mike, can you take a look through these strings and see if we need to make
> changes before 1.5? If so, it needs to happen before 1.8b4.

Reviewing now ...
(In reply to comment #8)
> (In reply to comment #7)
> > Mike, can you take a look through these strings and see if we need to make
> > changes before 1.5? If so, it needs to happen before 1.8b4.
> 
> Reviewing now ...

There is no point in doing this right now since the new error pages haven't been
checked in yet, so the strings you're currently looking at will all be replaced.

Bug 280190 attachment 189994 [details] [diff] [review] has the new strings at the bottom, but since it
hasn't landed yet it would be kinda difficult to post patches.

Maybe it would be best to set up a Wiki page with all the errors+descriptions
and handle the changes there, and once it's done to just create a patch?
OK, I set up a wiki to store the changes pending bug 280190. For now, we'll edit
these messages collaboratively at
http://wiki.mozilla.org/Firefox:1.5_Network_Error_Messages

Some notes about the changes I made:
 - used a more conversational voice
 - tried to simplify terminology
 - used sentence capitalization for text

Some things to consider:
 - should we be asking questions? why not just provide suggestions?
 - will we have access to things like the page the user tried to load?
Well done Mike.

One note though, it seems that we have a little problem with using "Firefox"
(the brand name) in the text, see bug 302309.
(In reply to comment #11)
> One note though, it seems that we have a little problem with using "Firefox"
> (the brand name) in the text, see bug 302309.

Do we need to nominate that one for blocking1.8b4? Or can we just use seperate
DTDs for each product? I'd really rather that we be able to use the product name
than "the browser" everywhere.

There are several comments in the wiki that I'm looking at, too:
 - changing some of the questions so that they're helpful, not interrogating
 - replacing "this address" with the address that caused the problem
 - should we use contractions? I'm for it for "can not" and "is not" for
friendliness
Made some more updates; tried removing all the questions (don't panic! we can go
back) and replaced them with suggestions of possible ways to fix the problem.
Please see "Open issues & questions" when reviewing.
Assignee: adamlock → mike
If we want to use &brandShortName; instead of "browser", bug 302309 has to be
fixed ASAP. Otherwise we aren't able to use this entity from within netError.dtd
for now.
Here's what's currently proposed in patch format.  The patch doesn't work as is
now because the entities have to be valid JS strings, and unescaped newlines
are invalid.

If anyone posts updated versions of the patch, please keep the formatting as is
(newlines, indentation, 80-character lines, etc.) to make reviewing easier.  We
can post a working patch when we have the wording finalized.  (In the meantime
I'm trying to fix this problem in bug 302729, although I don't know yet whether
I'll be able to do so or not.)

It'd be really good if we could have comments on the changes posted here
instead of in the wiki, because the wiki has to be manually checked whereas
bugmail is automated.
Depends on: 302729
Currently the areas covered when a website can't be found are :
* mistake typing
* expired domain
* local network connection settings
* firewall

I question the usefulness of mentioning "Has the domain's registration expired?"
as most users won't know one way or the other, and will not know how to check
such a thing.

I also wonder aloud if there should be some mention of high network traffic
perhaps being responsible (packet loss) or ISP-related problems, and/or some
mention that it might be the fault of the server the user is trying to contact
(high load, not online, experiencing problems, down for maintanance, etc).
(In reply to comment #10)
>  - used a more conversational voice

I think contractions such as "can't" and "isn't" seem out of place. I suggest
replacing "can't" with "cannot" and phrases such as "isn't available" with "is
unavailable".
The new version of Epiphany in the upcoming GNOME 2.12 uses Gecko 1.8, and they
have new user-friendly error messages, here's a screenshot:

http://www.gnome.org/~davyd/gnome-2-12/images/epiphany-errorpage.png

I like the concept of "If this page doesn't exist, you may find an archived
version..."
Updated with changes as suggested on the wiki (removed contractions from
headers; changed some of the suggested fixes)

I'm still not entirely happy with all of the headers, so please feel free to
propose changes. Contractions in the second-level text should be retained, IMO,
as they are a much friendlier read; I'll admit that they look kind of strange
in the headers.

Some notes & open questions for comment:

* Safari uses "Safari can't do this .." or "Safari wasn't able to do that" in
their headers. Do we want to do something similar? It's way friendlier, but
steps away from more familiar and to the point summaries of what went wrong.

* there are some cases where the "Try Again" button makes no sense. Is there a
way to remove it for some of the messages?
no longer a branch blocker since what we have is minimally sufficient (for
localizers) but if we're going to take further changes, we should get them in ASAP.
No longer blocks: branching1.8
Made a couple more small changes. I'd like for this to be wrapped up by Friday
EOD, so please throw in comments if you have any.

changes
 - removed "" around "offline mode" and added a ", and try again"
 - changed header for generic error (after a lot of internal debate) to "Oops",
since we can't really give any good diagnostic information, and might as well
be friendly (there are a lot of other programs that take this approach, and it
seems to work; see Gmail for an example)
Attachment #191448 - Attachment is obsolete: true
Whiteboard: [ETA 08/05]
- Changed protocolNotFound to be more technically accurate and easier to
understand
 - changed button label back to "Try Again" to be consistent with HIG (my bad)
Attachment #191019 - Attachment is obsolete: true
Attachment #191643 - Attachment is obsolete: true
Attached patch v5 with pretty printing (obsolete) — — Splinter Review 
Some final changes to protocolNotFound.
Attachment #191648 - Attachment is obsolete: true
Hm. Looking closer, I think what I actually want to do is strip out the first
line of each of these revised error mesages and put them into
mozilla/dom/locales/en-US/chrome/appstrings.properties.

That way the new error message for, say, conectionFailure would look like:
 __________________________________________________________________
/                                                                  \
|    .   Unable to connect                                         | <-- [1]
|   /!\  --------------------------------------------------------  |
|   ---  Firefox can't establish a connection with the server at   | <-- [2]
|        http://www.somebrokenserver.com                           |
|       --------------------------------------------------------   |
|        * The site could be temporarily unavailable or too busy.  | <-- [3]
|          Try again in a few moments.                             |
|                                                                  | 
|        * If you are unable to connect to any addresses, check    |
|          the computer's network connection.                      |
|                                                                  | 
|        * If your computer or network is protected by a firewall  |
|          or proxy, make sure that Firefox is permitted to access |
|          the Web.                                                |
|                                                                  | 
|        [Try Again]                                               |
\__________________________________________________________________/

where,
 [1] comes from the netError.dtd "<errorType>.title" attribute
 [2] comes from the appstrings.properties file
 [3] comes from the netError.dtd "<errorType>.longDesc" attribute
Attached file modified appstrings.properties file (obsolete) — 
So, once I learn how to make patches, I'll make this into a patch, but this is
what I think we'd need to change appstrings.properties to :)

(and then we'd have to take the equivalent strings *out* of netError.dtd)
some notes about appstrings.properties
the texts in that file are the ones that are shown in the error dialog when
error pages are disabled (some apps like camino (I think) disable them by default)

it's much easier to use the app name in appstrings.properties, because it is
actually possible to handle the case that the application doesn't specify its name.
Might it be better to use "ww.example.org" and "www.example.org" in place of
"ww.mozilla.org" and "www.mozilla.org"?
spec reserves example.com (not .org), so if you want to use something, that's 
usually the right thing.
(In reply to comment #28)
> spec reserves example.com (not .org), so if you want to use something, that's 
> usually the right thing.

.com, .org and .net are all reserved - http://rfc.net/rfc2606.html#s3.
Yeah, will update to (In reply to comment #27)
> Might it be better to use "ww.example.org" and "www.example.org" in place of
> "ww.mozilla.org" and "www.mozilla.org"?

Oops. Yes. It would. I'll update the patch when I find some hardware that's not
borrowed, or more accurately, some hardware that has the right software. I'll
also reformat non-pretty-printed for the DTD and post a patch of the appstrings
file in order to see if we can wrap this up.
Whiteboard: [ETA 08/05] → [ETA 08/09] [l10n impact]
Comment on attachment 191751 [details] [diff] [review]
v5 with pretty printing

>+<!ENTITY connectionFailure.title "Unable to connect">

>+  [li]If you are unable to connect to any addresses, check the computer's 
>+    network connection.[/li]

Why not "your computer's" instead of "the computer's"?	It's more personal, and
we're trying to make these errors user-friendly.  It also fits better with
"your computer" in the next bullet.

>+  [li]If your computer or network is protected by a firewall or proxy, make 
>+    sure that Firefox is permitted to access the Web.[/li]
>+[/ul]
>+">

Note also that because we're using this in a couple other entities
(netInterrupt, netReset, netTimeout), we need to make the fixes there too. 
Perhaps we should split it out into a new, internal entity that's used in the
creation of these so as to have less duplication.

>+<!ENTITY deniedPortAccess.title "This port is restricted">
>+<!ENTITY deniedPortAccess.longDesc "
>+[p]This address (%S) specifies a network port which is normally used for
>+  purposes other than Web browsing. Firefox has canceled the request for your
>+  protection.[/p]
>+">

Realistically, can we expect the average user to know what a network port is? 
I'm not sure what the fix is here, because we can't really obfuscate here
(which would prevent knowledgeable users from figuring out what the problem
is).

>+<!ENTITY fileNotFound.longDesc "

>+  [li]Check the file name for for capitalization or other typing errors.[/li]

s/for for/for/

>+  [li]Be sure that you have the required access to see the file at this
>+    address.[/li]

This sounds odd to me; what cause of the error does this describe?  If I knew
what this was describing I'd try to come up with something, but I'm at a loss
for how permissions can trigger this.  (My guess that trying to read, say,
~root/.bashrc as non-root would trigger this is wrong according to one response
from a user in #firefox.)

>+<!ENTITY generic.title "Oops">

Maybe add an exclamation mark at the end there?  It feels like the title's just
sort of "hanging" otherwise.  :-)

>+<!ENTITY generic.longDesc "
>+[p]Firefox has experienced a problem, and wasn't able to complete your request.
>+[/p]
>+">

If this is actually what's used (it feels very rough, but I don't have
suggestions at the moment), please remove the comma after "problem" -- you've
got a comma splice without the change.

>+<!ENTITY malformedURI.title "The address isn't valid">

>+  [li]Web addresses are usually written like [b]http://www.example.com[/b][/li]

This might be just me, but I'd prefer if you had an ending slash there after
<http://www.example.com>.

>+<!ENTITY netOffline.title "Offline mode">
>+<!ENTITY netOffline.longDesc "
>+[p]Firefox is currently in offline mode and is unable to browse the Web.[/p]

Perhaps use "can't" instead of "is unable to" to reduce unnecessary wordiness?

>+  [li]Uncheck "Work Offline" in the "File" menu to take the browser out of
>+    offline mode, then try again.[/li]

Please insert "and" before "then", and if we're making this Firefox-specific
change "the browser" to "Firefox".

>+<!ENTITY netTimeout.title "The connection has timed out">

>+[p]Firefox got tired of waiting to hear back from the server at %S.[/p]

How about:

"The server at %S is taking too long to respond to Firefox's request."

I don't really like having "request" in there, tho -- can anyone think of
something better to put in place of it?  This still feels sort of awkward, so
there's probably a better string to use here if someone can find it.

>+<!ENTITY proxyConnectFailure.title "The proxy server is refusing connections">

>+  [li]Contact the network administrator to make sure the proxy server
>+    is working.[/li]

I'd suggest changing "the network administrator" to "your network
administrator" to be more friendly.  Another possible option might be to say
"the person who runs your network" to use fewer geeky terms, but that's
probably just me underestimating the average user.  After all, I think
Microsoft uses it in their software.

>+<!ENTITY proxyResolveFailure.title "Unable to find the proxy server">

>+  [li]Check to make sure you computer has a working network connection.[/li]

s/you/your/

>+<!ENTITY unknownSocketType.title "Unexpected response from server">
>+<!ENTITY unknownSocketType.longDesc "
>+[p]The server at %S responded to the request in an unexpected way, and
>+  Firefox cannot continue.[/p]

"cannot continue" almost sounds like Firefox crashed, which clearly isn't
what's happened.  Would this be any better?  (I almost think it isn't, but I'm
really not all that sure.)

The server at %S responded to the request in an unexpected way, and Firefox
doesn't know how to respond to the server.

(I considered posting these changes as a patch, but it's probably better to
have one person do all the consolidation of suggestions to better keep things
under control.)
(In reply to comment #31; some portions removed)
> >+<!ENTITY deniedPortAccess.title "This port is restricted">
> >+<!ENTITY deniedPortAccess.longDesc "
> >+[p]This address (%S) specifies a network port which is normally used for
> >+  purposes other than Web browsing. Firefox has canceled the request for your
> >+  protection.[/p]
> >+">
> 
> Realistically, can we expect the average user to know what a network port is? 
> I'm not sure what the fix is here, because we can't really obfuscate here
> (which would prevent knowledgeable users from figuring out what the problem
> is).

I don't really know that we need to change this at all.  The facts are there and
as you said we can't get rid of any of the important information.  We've stated
that it's related to the address(1), isn't normal for Web browsing(2), and that
the action was canceled for security/"your protection"(3).  A normal user should
get the hint after #1-3.  If they want to learn what a port is, they can look it
up.  Aside from giving a tutorial on URLs, I don't know if there's much we can
do on an error page.  IMHO, it's fine as-is.

> >+<!ENTITY fileNotFound.longDesc "
> >+  [li]Be sure that you have the required access to see the file at this
> >+    address.[/li]
> 
> This sounds odd to me; what cause of the error does this describe?  If I knew
> what this was describing I'd try to come up with something, but I'm at a loss
> for how permissions can trigger this.  (My guess that trying to read, say,
> ~root/.bashrc as non-root would trigger this is wrong according to one response
> from a user in #firefox.)

FYI, the mention of permissions comes from the original netError.dtd that's been
going out with the 1.0.x builds.  I know I can force this event by trying to
access a drive/partition or network path that doesn't exist.  An
access-restricted network path might act the same way (haven't personally verified).


> >+<!ENTITY generic.title "Oops">
> 
> Maybe add an exclamation mark at the end there?  It feels like the title's just
> sort of "hanging" otherwise.  :-)

Agreed.


> >+<!ENTITY malformedURI.title "The address isn't valid">
> 
> >+  [li]Web addresses are usually written like [b]http://www.example.com[/b][/li]
> 
> This might be just me, but I'd prefer if you had an ending slash there after
> <http://www.example.com>.

What about changing the title to "This address isn't valid" as well?



> >+<!ENTITY netTimeout.title "The connection has timed out">
> 
> >+[p]Firefox got tired of waiting to hear back from the server at %S.[/p]
> 
> How about:
> 
> "The server at %S is taking too long to respond to Firefox's request."
> 
> I don't really like having "request" in there, tho -- can anyone think of
> something better to put in place of it?  This still feels sort of awkward, so
> there's probably a better string to use here if someone can find it.

Simple... make it shorter:
"The server at %S is taking too long to respond."


> >+<!ENTITY unknownSocketType.title "Unexpected response from server">
> >+<!ENTITY unknownSocketType.longDesc "
> >+[p]The server at %S responded to the request in an unexpected way, and
> >+  Firefox cannot continue.[/p]
> 
> "cannot continue" almost sounds like Firefox crashed, which clearly isn't
> what's happened.  Would this be any better?  (I almost think it isn't, but I'm
> really not all that sure.)
> 
> The server at %S responded to the request in an unexpected way, and Firefox
> doesn't know how to respond to the server.

Or:
"Firefox doesn't know how to communicate with the server at %S.  Its response
was not what Firefox expected."

No issues w/ the other suggestions; sounds good to me. :-)
Attaching a patch that makes the following changes, and has pretty-printing of
the DTD removed so that it's testable:

>Why not "your computer's" instead of "the computer's"?

Agreed.

> Perhaps we should split it out into a new, internal entity 
> that's used in the creation of these so as to have less duplication.

Good idea, but I'm not quite sure what's required to get that done, so I've
skipped that step for now. Feel free to modify as appropriate :)

> Realistically, can we expect the average user to know what a network port is?


I don't think so, no. We ran into this problem with protocol, as well, and it's
a nasty tradeoff between obfuscation and simplification as you point out. I
think the right answer here is to make the title simple ("This address is
restricted") and the follow up text informative ("%S uses a network port which
is normally used for purposes other than Web browsing. Firefox has canceled the
request for your protection.")

> s/for for/for/

Fixed, thanks.

> This sounds odd to me; what cause of the error does this describe?

To be honest, I'm not sure myself, and was just editing the error message that
came before :) I'm happy to remove it as a suggested thing to check.

> Maybe add an exclamation mark at the end there?

A period, I think. Don't want to seem to excited about it.

> If this is actually what's used (it feels very rough, but I don't have
> suggestions at the moment), please remove the comma after "problem" -- 
> you've got a comma splice without the change.

My least favourite error message, and I'm not even sure what error cases end up
leaving us in this state. Removed the comma splice, and tried changing the text
to: "Firefox can't load this page for some reason." I'd feel way more
comfortable about this if I knew how we got here, and what appstring would be
shown. Anyone know more about this error case?

> This might be just me, but I'd prefer if you had an ending slash there after
> <http://www.example.com>.

Both changes made. I'd also like to make the bold bits bold and red or
something, but am unsure if I can just shove in any ol' colour tags in these
entities.

> Perhaps use "can't" instead of "is unable to" to reduce unnecessary
wordiness?

Done. I need to grow a backbone about my decision to use contractions. :)

> Simple... make it shorter:
> "The server at %S is taking too long to respond."

Done.

> I'd suggest changing "the network administrator" to "your network 
> administrator" to be more friendly.

Done.

> s/you/your/

Done.

> The server at %S responded to the request in an unexpected way, and Firefox
> doesn't know how to respond to the server.

I asked darin, and he said that this error actually only occurs in a very small
percentage of cases, normally when a user doesn't have the PSM component
(https) installed. I've updated the DTD and appstrings to reflect that:

appstring = "Firefox doesn't know how to communicate with the server at %S."
longDesc = "[ul][li]Check to make sure your system has the Personal Security
Manager installed.[/li][li]This might be due to a non-standard configuration on
the server.[/li][/ul]"
Attachment #191751 - Attachment is obsolete: true
Attachment #191754 - Attachment is obsolete: true
Changed "unable to connect to any addresses" to "unable to load any pages" so
that it made sense in english :) 

Requesting a review, as I'd really like to land this in time to get it
translated and stuff.
Attachment #192403 - Attachment is obsolete: true
Attachment #192473 - Flags: review?(mconnor)
Comment on attachment 192473 [details] [diff] [review]
v7 changes to appstrings and neterror (for review)

Oops. Forgot that I'm hardcoding all the brandnames here. I knew it was too
good to be true!
Attachment #192473 - Flags: review?(mconnor) → review-
(In reply to comment #33)
> > Perhaps we should split it out into a new, internal entity 
> > that's used in the creation of these so as to have less duplication.
> 
> Good idea, but I'm not quite sure what's required to get that done, so I've
> skipped that step for now. Feel free to modify as appropriate :)

It's getting late and I'm running short on time, so I'll just describe the steps
to do this instead.  Say you have the following entities defined:

<!ENTITY foo "[p]That port's evil.[/p][ul][li]Generic info[/li][/ul]">
<!ENTITY bar "[p]What's that protocol?[/p][ul][li]Generic info[/li][/ul]">
<!ENTITY baz "[p]You don't have PSM.[/p][ul][li]Generic info[/li][/ul]">

What you want is to only have to define "[ul][li]Generic info[/li][/ul]" once. 
To do so, create a new entity like so:

<!ENTITY shared "[ul][li]Generic info[/li][/ul]">

You also probably want to add an explanatory localization note (formatted like
<http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/preferences/fonts.dtd#21>).
 Then use the entity inside the definitions for the other entities, like so:

<!ENTITY shared "[ul][li]Generic info[/li][/ul]">
<!ENTITY foo "[p]That port's evil.[/p]&shared;">
<!ENTITY bar "[p]What's that protocol?[/p]&shared;">
<!ENTITY baz "[p]You don't have PSM.[/p]&shared;">

I don't remember whether the entity must be defined before it's used (as shown
above) or not (the situation if the "shared" line could be legally moved below
the "baz" line), so you'll have to test this to see for yourself.  Personally,
I'd prefer the shared entity be added after all the other entity pairs in
netError.dtd so as to keep the organization the same, but it's not really a big
issue if you have to do it as demonstrated above.

> > This sounds odd to me; what cause of the error does this describe?
> 
> To be honest, I'm not sure myself, and was just editing the error message that
> came before :) I'm happy to remove it as a suggested thing to check.

Yeah, I think removing it's a good idea unless some necko gurus can tell us why
it's there; less is more.

> > Maybe add an exclamation mark at the end there?
> 
> A period, I think. Don't want to seem to excited about it.

It's not so much "excited" as that you don't hear people say "oops" in a level
voice; there's a guilty tone, some sort of emphasis, or some such thing beyond
just the sound of the word.  Using nothing and using a period both suggest a
level voice here, whereas an exclamation mark conveys a much more natural tone.
 It's one character, tho, so let it go if you must.

> I'd also like to make the bold bits bold and red or something, but am unsure
> if I can just shove in any ol' colour tags in these entities.

Theoretically you should be able to do so, although keep in mind how things
could look with an arbitrary user-selected theme with, say, a red background. 
(To take this into account you'd have to modify five additional skin files in
toolkit/ and themes/.)  Personally, I'd suggest just sticking with <strong/> and
leave its default style alone; don't overdo it.
-<!ENTITY deniedPortAccess.title "Port Restricted for Security Reasons">
-<!ENTITY deniedPortAccess.longDesc "[p]The requested address specified a port
(e.g. [q]mozilla.org:80[/q] for port 80 on mozilla.org) normally used for
purposes [em]other[/em] than Web browsing. The browser has canceled the request
for your protection and security.[/p]">
+<!ENTITY deniedPortAccess.title "This address is restricted">
+<!ENTITY deniedPortAccess.longDesc "">

Empty longDesc?
(In reply to comment #37)
 > Empty longDesc?

Yeah. There's not a long to say there in terms of suggesting alternatives. The appstring gives more detail 
about what went wrong (and echoes the URL), but after that, what can you say?
Comment on attachment 192473 [details] [diff] [review]
v7 changes to appstrings and neterror (for review)

>+<!ENTITY netOffline.title "Offline mode">
>+<!ENTITY netOffline.longDesc "[li]Uncheck Work Offline in the File menu to take the browser out of offline mode, then try again.[/li][/ul]">

Incidentally, it looks like netOffline wouldn't work because tags in
&netOffline.longDesc; aren't balanced.	I don't know exactly how it would fail
because of the current innerHTML hack being used.

Also of note is the fact that bug 302729 is reviewed and approved for checkin. 
This means that we should be able to use sane-looking entity values with
normal, unhackified HTML!  As soon as a patch for this bug is approved and
ready we need to coordinate with that bug so that both this bug and that bug
can be fixed close to simultaneously; if we don't check them in pretty close to
each other we'll have broken-looking error pages.

I'll post a new version of the latest patch here that addresses the tag
imbalance and the sane-looking HTML issues in a second.  Make sure to read the
instructions that will accompany the patch so you know how to test it, or else
you'll have broken error pages.
I fixed the tag imbalance, changed a few instances of the non-semantic <b/>
element to <strong/> (which I apparently overlooked earlier and should have
mentioned then), and converted the whole thing to be pretty.  I also added the
shared entity I suggested earlier.

You must apply attachment 192114 [details] [diff] [review] to your tree in order to test this patch.  If
you don't do this, the patch *will* fail to work properly.  You have been
warned.
Attachment #192473 - Attachment is obsolete: true
*** Bug 305634 has been marked as a duplicate of this bug. ***
I asked dria to look at the strings, and she suggested two small changes:
  - add quotes around "Work Offline" (I'd removed them because I forgot to use
the &quot; entity - oops)
  - change the appstring for proxyFailedConnect

I think we're actually finally oh-my-god done with the messages. Also, looking
through them, I noticed that most of the references to "Firefox" were in the
appstrings, not in the DTD. I think it'd be totally possible to make it so that
*all* of the references to "Firefox" were in appstrings, especially if that
meant that we lost our dependency on bug 302309, but I'm not sure that it
would.

Would it?
Attachment #192579 - Attachment is obsolete: true
1) I think the patch won't apply cleanly to either current trunk or branch, as
we already have changed all [] to <> there.

2) No file out side a branding/ bundle should hardcode an app name, wherever in
chrome it is, esp. not if it's in core code that is shared with other apps (and
if that file in mozilla/dom/locales/en-US/chrome/ is not, then we have a major
bug by itself). We should _always_ refer to brandShortName / brandFullName
everywhere outside branding bundles.
This is even important in app-specific code as we're doing things like calling
testing releases differently than the product name, and in that case it should
say "Deer Park" or whatever automatically even for those strings.
Yes, well, that's why we need bug 302729 (pretty HTML formatting for DTDs) and
bug 302309 (to enable the &brandShortName; entity) to land before this one, but
thanks for the reminder!
(In reply to comment #44)
> Yes, well, that's why we need bug 302729 (pretty HTML formatting for DTDs) and
> bug 302309 (to enable the &brandShortName; entity) to land before this one, but
> thanks for the reminder!

It seems you don't have your bugmail set up to receive notifications of changes
in bugs depending or dependent upon this one; bug 302729 was fixed a couple days
ago on both the branch and the trunk, so there's no need to test with another
patch in addition to the one here.
Thanks Jeff; I saw it had landed on trunk, but didn't know it had hit branch. I
must talk to BugZilla about that! :) 

Since I'm not sure that bug 302309 will land in time for Firefox 1.5, I've
opened (as per mconnor's suggestion) bug 305998 as a band-aid solution to try
and at least get the messages in as an override for Firefox 1.5 only, and then
we can get the product name stuff sorted out for Gecko 1.9 or whatever.

(if it sounds like I only 1/2 understand what I'm saying, there's a reason!)
Requesting that this bug be -'d for 1.8b4 since bug 305998 has come up with a
solution that will work for FFx 1.5, but be kept open, as this should definitely
be resolved for trunk / future :)
getting remaining 1.5 work under bug 305998
Flags: blocking1.8b4+ → blocking1.8b4-
(I assume the whiteboard status is now obsolete.)
Whiteboard: [ETA 08/09] [l10n impact]
Please note that attachment 196134 [details] [diff] [review] from bug 184144 was just checked in on trunk,
in case you'd like to further review the wording for the new error
(contentEncodingError).
Do we have any update for this bug? There is attached a patch without a review request for ages. It this bug still valid?
QA Contact: adamlock → docshell
Beltzner, what is the status of this bug? It contains a patch from you, which is four years old. Can this bug be closed?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: