Reword offline error text in the content area message

VERIFIED FIXED in Firefox 4.0b7

Status

()

defect
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: faaborg, Assigned: Margaret)

Tracking

unspecified
Firefox 4.0b7
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus -

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

(Whiteboard: [strings])

Attachments

(3 attachments, 4 obsolete attachments)

When the user does not have an internet connection (or they have specifically instructed Firefox to be in offline mode), we display the content are page shown in the attachment.  It contains a try again button and one bullet:

* Uncheck "Work Offline" in the File menu, then try again.

We either need to reword this based on the presence of the Firefox button (in which case we would need to say developer menu isntead of file menu), or only display the message if we know that we are in offline mode:

* Unchecked "Work Offline," and then try again

The assumption would be that since the user knows how to get into offline mode, they would also know how to get out of it, so we don't have to worry about changing the text based on the menu structure.
Screen shot of the current content area message.
Should be a simple change but requesting blocking since the text can confuse the user.
blocking2.0: --- → ?
Don't we go into offline mode automagically when the network disappears? That'd break the assumption that the user knows how to switch that on again.

Also, I recall talk about dropping the "Offline" switch alltogether, is that off the table?
If there is no connection offline mode isn't checked, I think we are saying to uncheck it just to be sure.  When it isn't checked the try again button will actually work.

I would like us to treat online and offline access per domain, but that's too complex for right now.
This has none of a patch, an owner, or a blocking decision but strings impact.

What's the triage or ETA status here?
blocking2.0: ? → beta7+
(In reply to comment #0)
> The assumption would be that since the user knows how to get into offline mode,
> they would also know how to get out of it, so we don't have to worry about
> changing the text based on the menu structure.

I actually never go into offline mode but still need to get out of it sometimes :(
Duplicate of this bug: 597425
Assignee

Comment 8

9 years ago
Posted patch patch (obsolete) — Splinter Review
Here's a patch that removes the reference to the file menu. It may not be ideal, but it's better than sending the user to the wrong place.

I did an mxr search, and there's also a reference to this in dom code (http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/appstrings.properties#49). Should we switch that string as well?
>Should we switch that string as well?

yeah, thanks for catching that
Also need to rev the entity name.
Though that affects a bunch of downstream consumers that override this as well (thunderbird, fennec), sigh.
Assignee

Comment 12

9 years ago
(In reply to comment #11)
> Though that affects a bunch of downstream consumers that override this as well
> (thunderbird, fennec), sigh.

Is there a solution to that?
Assignee

Comment 13

9 years ago
Posted patch patch v0.2 (obsolete) — Splinter Review
Here's a patch that updates all the entities if we want it. However, like gavin pointed out, it would affect a lot of people.
Attachment #476409 - Attachment is obsolete: true
I don't think there's a way around it, no.
We could use a hack like http://hg.mozilla.org/mobile-browser/rev/c72e9cdf31ca (graceful fallback to the old string if localizers/overriders don't get the change, at the risk of increased odds that localizers will get it wrong)...

Comment 16

9 years ago
As mentioned in bug 593125, why not simply put an online/offline toggle directly within the content area when you get this error?

Comment 17

9 years ago
(In reply to comment #16)
> As mentioned in bug 593125, why not simply put an online/offline toggle
> directly within the content area when you get this error?

oops - I meant "as mentioned in bug 596121 ".
That's harder (the page isn't currently privileged), and covered by bug 435325.
Assignee

Comment 19

9 years ago
(In reply to comment #15)
> We could use a hack like http://hg.mozilla.org/mobile-browser/rev/c72e9cdf31ca
> (graceful fallback to the old string if localizers/overriders don't get the
> change, at the risk of increased odds that localizers will get it wrong)...

This could work for the string in overrides/netError.dtd, but what about the string in appstrings.properties. Would we need to do something similar, or would changing that string be okay because it isn't in an override file?
Assignee

Updated

9 years ago
Assignee: nobody → margaret.leibovic
Regarding the DTD stuff, I frankly don't recall why and how that was supposed to work. Like, we do need to signal somehow that the old value changes. I'm wondering if we can hack the alias into the xhtml file, and rely on potentially double-defining the entity in the right order. (Yac) (Yes, I told margaret something different just a minute ago)

For .properties, we could make the code check the new string, and fall back to the old one if it doesn't find it. I guess that'd require us to leave netOffline in place there, which might actually be a good idea.
Assignee

Comment 21

9 years ago
Posted patch patch v0.3 (obsolete) — Splinter Review
Attachment #476425 - Attachment is obsolete: true
Attachment #476931 - Flags: review?(dolske)
Assignee

Comment 22

9 years ago
Posted patch patch v0.4Splinter Review
Attachment #476931 - Attachment is obsolete: true
Attachment #476940 - Flags: review?(dolske)
Attachment #476931 - Flags: review?(dolske)
Comment on attachment 476940 [details] [diff] [review]
patch v0.4

Now I remember why this trick looks familiar, I did it in the v.3 patch on bug 538910. :)
Attachment #476940 - Flags: review?(dolske) → review+
Assignee

Comment 24

9 years ago
http://hg.mozilla.org/mozilla-central/rev/e6f66ee57044
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED

Comment 25

9 years ago
:l10n should have really been CCed on this bug.  Here's a bunch of comments, even though it might be too late for that...

(In reply to comment #0)
> When the user does not have an internet connection (or they have specifically
> instructed Firefox to be in offline mode), we display the content are page
> shown in the attachment.  It contains a try again button and one bullet:
> 
> * Uncheck "Work Offline" in the File menu, then try again.
> 
> We either need to reword this based on the presence of the Firefox button (in
> which case we would need to say developer menu isntead of file menu),

Why didn't we choose this path?  We did the same thing for bug 593126, for example, and I fail to see how this bug is different.

> or only
> display the message if we know that we are in offline mode:
> 
> * Unchecked "Work Offline," and then try again
> 
> The assumption would be that since the user knows how to get into offline mode,
> they would also know how to get out of it, so we don't have to worry about
> changing the text based on the menu structure.

That's the wrong assumption, as indicated earlier in comment 0.  The user might get into offline mode if their network connection is dead.  We do not ask the user whether they want to go into the offline mode, and they might have no idea where the "Work Offline" menu item is for them to uncheck.  I think the net effect of this change will be getting out of the offline mode more difficult for the fraction of our users who don't have the location of every menu item memorized.  I don't have any data on this, but I have a hunch that this fraction may be the majority of our users.

Comment 26

9 years ago
Bugzilla's user auto-completion helped me fail to CC :l10n on the previous comment.  For those who get this as their first mail on this bug, please see comment 25.
Assignee

Comment 27

9 years ago
(In reply to comment #25)
> :l10n should have really been CCed on this bug.  Here's a bunch of comments,
> even though it might be too late for that...

I'm sorry, I probably should have indicated that I talked to Axel in person
this afternoon, but he wasn't around to r+ the final patch because he was
flying from SFO to Germany.

This is supposed to be a quick fix to prevent us from directing the user to a
non-existent menu item. Unfortunately we're approaching string freeze, so it's
hard to implement ideal changes at this point :(
Assignee

Updated

9 years ago
Attachment #476940 - Flags: feedback?(l10n)
Can we at least hint towards "Work Offline" being a menu item?

* Uncheck the "Work Offline" menu item, then try again.

'Uncheck "Work Offline"' is close to being completely useless to users who haven't actually checked it and don't know our menus by heart.
Comment on attachment 476940 [details] [diff] [review]
patch v0.4

I think that Ehsan's comment is really about UE, not l10n. I only commented about the actual technical details about how to tweak shared neterror messages, really, and those look good in this patch.

(PS: I asked similar UE questions in comment 3, I guess :-) )
Attachment #476940 - Flags: feedback?(l10n) → feedback+

Comment 30

9 years ago
(In reply to comment #27)
> This is supposed to be a quick fix to prevent us from directing the user to a
> non-existent menu item. Unfortunately we're approaching string freeze, so it's
> hard to implement ideal changes at this point :(

My comment was also half l10n and half UE, but Dao's comment 28 was a lot clearer on the l10n side.  Translating "Uncheck work offline" is going to be tricky, I don't think that it even makes a lot of sense in English.

But anyway, why is it hard to fix this the right way?  Can't you use the same technique as bug 593126?  I'd totally understand if you have too much on your plate and too little time for this, but I don't see why the correct solution is hard...

At the very least, we should have a bug on file for the right fix.
(In reply to comment #30)
> But anyway, why is it hard to fix this the right way?  Can't you use the same
> technique as bug 593126?

The error page isn't privileged.

Comment 32

9 years ago
(In reply to comment #31)
> (In reply to comment #30)
> > But anyway, why is it hard to fix this the right way?  Can't you use the same
> > technique as bug 593126?
> 
> The error page isn't privileged.

Fair enough.  I'll shut my mouth then!  :-)

... before doing that, I still think that comment 28 should be addressed.
Posted patch address comment 28 (obsolete) — Splinter Review
faaborg said he was fine with this.
Attachment #477357 - Flags: review?(l10n)
Attachment #477357 - Attachment is obsolete: true
Attachment #477360 - Flags: review?(l10n)
Attachment #477357 - Flags: review?(l10n)
Comment on attachment 477360 [details] [diff] [review]
address comment 28 (real patch)

r=me. I did already r- a sign-off for the previous version of this patch because the localizers apparently didn't change the string at all. Can we make the _2 something that's less subtle on what's the intention of that string? Not sleeping my jetlag off, so I don't really have a good suggestion.

Also, a quick post .l10n may help trigger the senses of our localizers.
Attachment #477360 - Flags: review?(l10n) → review+
Landed that, with a rename and L10N note that should hopefully help.
http://hg.mozilla.org/mozilla-central/rev/17c0971e7380
Looks good, thanks.
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
OS: Windows 7 → All
Hardware: x86 → All
Flags: in-litmus-
Target Milestone: --- → Firefox 4.0b7
You need to log in before you can comment on or make changes to this bug.