Closed Bug 133119 Opened 18 years ago Closed 9 years ago

Language in Image Acceptance Policy Pref Page Should Be Consistent

Categories

(SeaMonkey :: Preferences, defect, P4, trivial)

defect

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1b3

People

(Reporter: mrmazda, Assigned: ewong)

References

Details

Attachments

(1 file, 3 obsolete files)

2002032316 OS/2

Let's use either load or accept, not both. Ask me should be either "before
loading" or "before accepting", according to whether load or accept is the
appropriate word to use, and not "downloading".
.
Assignee: ben → morse
Component: Preferences → Image Management
QA Contact: sairuh → tever
currently we have:
"do not load any images"
"accept images that comes..."
"accept all images"

so yes, lets be consistent. either use "load" or use "accept"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.3beta
Mass reassigning of Image manager bugs to mstoltz@netscape.com, and futuring.
Most of these bugs are enhancement requests or are otherwise low priority at
this time.
Assignee: morse → mstoltz
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3beta → Future
QA Contact: tever → nobody
Reassigning to Prefs for review.
Assignee: mstoltz → ben
Component: Image Blocking → Preferences
QA Contact: nobody → sairuh
Product: Browser → Seamonkey
Assignee: bugs → prefs
QA Contact: bugzilla
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
Comment on attachment 126639 [details] [diff] [review]
Patch - change pref dialog text and help page

triage: Probably WONTFIX but if not definitely needs to be un-bitrotted.
Attachment #126639 - Flags: review?(iann_bugzilla)
Attachment #126639 - Flags: feedback?(jh)
Comment on attachment 126639 [details] [diff] [review]
Patch - change pref dialog text and help page

Trying to achieve consistency is good, so let's do this. The dialog behind the Manage Image Permissions uses "load", too, and I think it makes sense (if we accept images we also display them, right?).

"Accept images that come from the originating server only" sounds strange to me for another reason: it lays too much stress on "only" for my taste, as if only images that could not be found elsewhere would be allowed. Maybe a native speaker can comment on whether it's just me.

I'd suggest:
* Do not load any images
* Only load images from the originating server
* Load all images

The accesskeys probably need to be changed according to the final wording.

Since this is a UI change, consulting Neil is mandatory. But I guess that can wait until someone actually uploads a new patch.

Help looks differently today as well (it should describe all the options 1:1) so it needs to be changed accordingly (the part in the old patch is out-of-date).
Attachment #126639 - Flags: feedback?(jh) → feedback-
Oh, I forgot: FF only has "Load images automatically" under Options/Content.
Comment on attachment 126639 [details] [diff] [review]
Patch - change pref dialog text and help page

I'm happy with Jens suggestion, though do we need to actually say "images" in any of the options as the starting statement is:
"Specify how SeaMonkey handles images."
As already mentioned patch has bitrotted.
Attachment #126639 - Flags: review?(iann_bugzilla) → review-
(In reply to comment #10)
> do we need to actually say "images" in
> any of the options as the starting statement is:
> "Specify how SeaMonkey handles images."

Hmm, my first thought was "why not, shorter is better, let's change it". Then I thought that this might cause a11y issues. I'm still not 100% sure it won't but I found that the other setting on the Images pref pane, "Animated images should loop", is already in short form ("As many times as the image specifies", "Once", "Never"). The difference here is that the introduction matches the options.

How about:

Load images from
( ) No server (block all images)
( ) The originating server only
(*) Any server
(In reply to comment #11)
> (In reply to comment #10)
> > do we need to actually say "images" in
> > any of the options as the starting statement is:
> > "Specify how SeaMonkey handles images."
> 
> Hmm, my first thought was "why not, shorter is better, let's change it". Then I
> thought that this might cause a11y issues. I'm still not 100% sure it won't but
> I found that the other setting on the Images pref pane, "Animated images should
> loop", is already in short form ("As many times as the image specifies",
> "Once", "Never"). The difference here is that the introduction matches the
> options.
> 
> How about:
> 
> Load images from
> ( ) No server (block all images)
> ( ) The originating server only
> (*) Any server

I think I like your original suggestion.  As in:

* Do not load any images
* Only load images from the originating server
* Load all images
(In reply to comment #12)
> I think I like your original suggestion.  As in:

Feel free to take, but if you do, make sure to request b3 blocking (l10n impact) and file a Help bug in the end. Thanks!
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #519124 - Flags: review?(iann_bugzilla)
Attachment #519124 - Flags: approval-seamonkey2.1b3?
blocking-seamonkey2.1: --- → ?
Attachment #519124 - Flags: approval-seamonkey2.1b3?
First you need to get a r+ then you ask for blocking?
Comment on attachment 519124 [details] [diff] [review]
Made the Image acceptance policy pref page more language consistent.

>+<!ENTITY accAllImagesRadio.label        "Load all images">
>+<!ENTITY accAllImagesRadio.accesskey    "d">
I would use "L" here
>+<!ENTITY accOrgImagesRadio.label        "Only load images that come from the originating server">
>+<!ENTITY accOrgImagesRadio.accesskey    "L">
I would use "n" here
> <!ENTITY disableImages.label            "Do not load any images">
> <!ENTITY disableImages.accesskey        "n">
Change this to "D"
> <!ENTITY viewPermissions.label          "Manage Permissions">
> <!ENTITY viewPermissions.accesskey      "P">

I still think we are needlessly repeating "load images" unfortunately I can not see a way of expressing it in a natural sounding manner. Perhaps Neil might if you request feedback/ui-review on the new patch?

Don't forget help needs updating as the original patch did that.

r- for the moment as new patch (with help changes) will need a review.
Attachment #519124 - Flags: review?(iann_bugzilla) → review-
Attachment #519637 - Flags: review?(iann_bugzilla) → review+
Attachment #519637 - Flags: ui-review?(neil)
Attachment #519637 - Flags: ui-review?(neil) → ui-review+
Keywords: checkin-needed
Attachment #126639 - Attachment is obsolete: true
Comment on attachment 519637 [details] [diff] [review]
Made the Image acceptance policy pref page more language consistent. (v2) [Checkin: comment 18]

http://hg.mozilla.org/comm-central/rev/a0aca3c04ef3
Attachment #519637 - Attachment description: Made the Image acceptance policy pref page more language consistent. (v2) → Made the Image acceptance policy pref page more language consistent. (v2) [Checkin: comment 18]
Leaving open for now since an answer for how to proceed with Help changes is needed (in this bug or a follow-up?).
Keywords: checkin-needed
Target Milestone: Future → seamonkey2.1b3
The rule under FF is that if you change the string, you must also change the entity, to help localizers in their task: can we please stick to it also for SM?
I was lucky to read the checkin, so I spotted it easily, but I guess not many other localizers have seen that.
While I'm changing the entities, I'll be doing the help on a separate patch
that I will attach to this bug.
(In reply to comment #20)
> The rule under FF is that if you change the string, you must also change the
> entity, to help localizers in their task

That rule also applies to SM in general. Even though I was not the reviewer here I thought that it didn't really apply here since it's just a clarification of expressions in English rather than a fundamental change of meaning. On second thought, maybe the change from Accept to Load justifies a change of entity names, though.
(In reply to comment #20)
> The rule under FF is that if you change the string, you must also change the
> entity, to help localizers in their task: can we please stick to it also for
> SM?
> I was lucky to read the checkin, so I spotted it easily, but I guess not many
> other localizers have seen that.

I wouldn't have blocked for this bug; but since the l10n changes landed without entity changes I will.

I would ask the help changes go to a followup for easier tracking, since the first part of this bug already landed. And tracking one bug for disjoint releases is a pain.
blocking-seamonkey2.1: ? → b3+
This patch includes entity changes so it requires a re-review.
Attachment #519637 - Attachment is obsolete: true
Attachment #520867 - Flags: ui-review?(neil)
Attachment #520867 - Flags: review?(iann_bugzilla)
Attachment #520867 - Flags: ui-review?(neil)
Attachment #520867 - Flags: review?(iann_bugzilla)
Attachment #519637 - Attachment is obsolete: false
Attachment #520867 - Attachment is obsolete: true
I have quite confused myself.  I submitted a new patch but realized that 
the old patch (v2) was already committed.  So. I will spin off two new
bugs that will.  1) Cover the entity changes I had planned. (bug #643676)
                 2) Fix the help. (bug #643677)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to comment #23)
> (In reply to comment #20)
> > The rule under FF is that if you change the string, you must also change the
> > entity, to help localizers in their task: can we please stick to it also for
> > SM?
> > I was lucky to read the checkin, so I spotted it easily, but I guess not many
> > other localizers have seen that.
> 
> I wouldn't have blocked for this bug; but since the l10n changes landed without
> entity changes I will.
> 

Moved to Bug 643676
blocking-seamonkey2.1: b3+ → ---
Depends on: 643676
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.