Reporter's privacy statement checkbox labeled very badly

Assigned to


Other Applications
13 years ago
7 years ago


(Reporter: James Ross, Assigned: raccettura)


Windows 2000

Firefox Tracking Flags

(Not tracked)



(1 attachment)



13 years ago
The label for the privacy policy checkbox on the first page says:
  "Don't Show Privacy Statement Again"

Yet, I MUST check this to continue. It should say that I agree to the privacy
policy, as I think was the point. If it really does mean "don't show me this
again" then it should NOT affect whether I can continue.

Comment 1

13 years ago
I'm thinking of changing it to:
I read and agree to the above privacy policy.

any objections?

I may land that tomorrow.

Comment 2

13 years ago
sounds good to me. a=asa

Comment 3

13 years ago
Per discussion with mconnor, this is betterer than my earlier suggestion:

I have read and accept the above privacy policy.
Summary: Reporter's checkbox labeled very badly → Reporter's privacy statement checkbox labeled very badly

Comment 4

13 years ago
Checking in extensions/reporter/locales/en-US/chrome/reportWizard.dtd;
<--  reportWizard.dtd
new revision: 1.5; previous revision: 1.4
Last Resolved: 13 years ago
Resolution: --- → FIXED
*** Bug 294489 has been marked as a duplicate of this bug. ***

Comment 6

13 years ago
Do we have more goodies like this in reporter?

Crappy code gives crappy localizations, of course we have at least one
localization a'la "Don't Show Privacy Statement Again" in our 1.5 release, see
bug 317624.
The entity is misnamed, that should be fixed on the trunk.

I'd really like to know if I need to hunt for more problems like this or if
we just have this in one place.
Resolution: FIXED → ---
I found bug 317624 doing last-minute QA for nb-NO.

The reason we decided it was a showstopper for nb-NO was that the user doesn't currently accept the privacy policy. He might, in theory, sue the Mozilla Foundation after finding that the Reporter tool collects private information, saying "I never agreed to that."

It's a bit extreme, I know, but AFAIK it's a valid concern.

As painful as this might be, I think this calls for an audit of all 1.5 localizations.

Comment 8

13 years ago
Fine, I'll tweak that entity on the trunk tomorrow morning.

I don't see how a string change in May can be causing problems in November.  The string is supposed to be localized based on the string alone, not the entity name.  FWIW I should be able to use an md5 hash to name a string, with no ill effects.

Based on bug 317624 (I rely on the translations within) it looks like nb-NO just never updated that string since sometime before May 15, 2005.  Nothing to do with the entity name.  I checked several other's using google translate, and they appeared to be updated (mainly looking for the word "agree" as that's the big change).  Looks like it was checked in at 2005-07-21 08:37.  IMHO it should be reviewed before checkin.

Comment 9

13 years ago
Correction to above 2005-07-21 08:37 was a move, not initial checkin.
(In reply to comment #8)
> I don't see how a string change in May can be causing problems in November.

We never noticed that the string changed after translating the original one.

The best way to ensure that it gets on radar is to CC firefoxl10n or similar on relevant bugs.

Comment 11

13 years ago
Created attachment 204194 [details] [diff] [review]
rename entity
Attachment #204194 - Flags: review?


13 years ago
Attachment #204194 - Flags: review? → review?(mconnor)


13 years ago
Attachment #204194 - Flags: review?(mconnor) → review+
You need to log in before you can comment on or make changes to this bug.