Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#12872 closed defect (bug) (fixed)

Screen Options calls all post types "posts"

Reported by: caesarsgrunt's profile caesarsgrunt Owned by: nacin's profile nacin
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

The option "Posts per page" under Screen Options on edit.php should change to reflect the page type - eg "Books per page" for a custom post type of Book.

Might be a problem with "Pages" - Pages per page is a little confusing".
One solution would be to make it something like "{{post_type_label}} per list" or "Show [input] {{post_type_label}} at once".
An alternative would be to make it "Items per page", but I don't really like that.

Attachments (3)

12872.1.diff (2.0 KB) - added by caesarsgrunt 14 years ago.
12872.2.diff (3.3 KB) - added by caesarsgrunt 14 years ago.
Change label to "# [post_type]"
12872.3.diff (3.5 KB) - added by caesarsgrunt 14 years ago.
Change label to "# [post_type] at a time"

Download all attachments as: .zip

Change History (21)

#1 @caesarsgrunt
14 years ago

Or even just make it "Show [input] {{post_type_label}}", without mentioning that it's per page or whatever.

#2 @caesarsgrunt
14 years ago

Or perhaps the pest answer is "{{post_type_label}} per screen", seeing as we already have the label "screen options" etc.

#3 @nacin
14 years ago

To me, "per screen" sounds better than "per page". Could use some UX feedback on this one.

#4 @uglyrobot
14 years ago

I agree with per screen.

Also the post updated notice (yellow box) on the post.php screen says "Post updated. View post" on custom post types. It needs to be updated. The view button next to permalinks shows the custom post type name correctly.

#5 @caesarsgrunt
14 years ago

  • Keywords has-patch added

This first patch shows the correct post type label.

It also changes all instances of "{{Items}} per page" to "{{Items}} per screen" so that we don't end up with "Pages per page", as well as for consistency with other places where "screen" is used instead of "page".

I'll look at the yellow notice issue in a separate patch.

#6 @nacin
14 years ago

  • Owner set to nacin
  • Status changed from new to accepted

"per screen" has UX sign-off. Patch looks good, will kick the tires on it and check it in soon when I have a chance.

#7 follow-up: @jane
14 years ago

I like using the word screen instead of page in general, but when we're talking specifically about pagination, which is what this is, page is probably more appropriate. "Items per page" would be my suggestion (and was, via IRC, before reading this thread, ha).

#8 in reply to: ↑ 7 @caesarsgrunt
14 years ago

Replying to jane:

I like using the word screen instead of page in general, but when we're talking specifically about pagination, which is what this is, page is probably more appropriate. "Items per page" would be my suggestion (and was, via IRC, before reading this thread, ha).

Thanks for weighing in, Jane.

I personally feel that "{{post type}} per screen" is more in keeping with language elsewhere in the admin, such as "Screen Options", "Show on screen", etc, and I also think that it could cause a certain amount of confusion with Pages as a post type.

However, your suggestion of "Items per page" does have the advantage of being more similar to the existing label, which it's true doesn't seem to cause much confusion, so I am happy with it as a second-best option.

So long as one or other gets committed I'll be happy!

#9 @caesarsgrunt
14 years ago

Alternatively, what do you think about "Show [input] {{post_type_label}}", without mentioning that it's per page?

#10 follow-up: @jane
14 years ago

Screen refers to everything within the browser, while items-per refers to paginated views, so page is more correct than screen. "Show [post-type]s" would be better stated as "List [post-type]s" based on how we use Show currently in the media uploader. Not that I like the sound of it.

Side note: I just went and looked at Screen Options as it is in 2.9. I thought we'd agreed to get rid of that "Options" header above the #-per-page back in 2.9 (the whole thing is for screen options, and the # is for displaying on screen, after all (which is the label for the upper section). When this ticket gets done one way or another, could the person making the patch also get rid of that Options header? It almost makes it look like you can decide how many posts per page to show on your blog or something.

If that gets fixed, then whatever the #-per-page language is, it will be the completion of the header, "Show on screen," and just having "_ [post-type]s" would be adequate. Alternately, "_ [post-type]s at a time" would work.

#11 in reply to: ↑ 10 @jane
14 years ago

Forgot how trac autoformats with underlines, not my intention. Restating underlined parts to be more understandable.

Replying to jane:

Screen refers to everything within the browser, while items-per refers to paginated views, so page is more correct than screen. "Show # [post-type]s" would be better stated as "List # [post-type]s" based on how we use Show currently in the media uploader. Not that I like the sound of it.

Side note: I just went and looked at Screen Options as it is in 2.9. I thought we'd agreed to get rid of that "Options" header above the #-per-page back in 2.9 (the whole thing is for screen options, and the # is for displaying on screen, after all (which is the label for the upper section). When this ticket gets done one way or another, could the person making the patch also get rid of that Options header? It almost makes it look like you can decide how many posts per page to show on your blog or something.

If that gets fixed, then whatever the #-per-page language is, it will be the completion of the header, "Show on screen," and just having "# [post-type]s" would be adequate. Alternately, "# [post-type]s at a time" would work.

#12 @caesarsgrunt
14 years ago

If I understand right, you're saying

  1. Remove the "Options" header
  2. Change the "# posts per page" to "# [post_type]" or "# [post_type] at a time".

Sounds good to me.

Which string do you prefer? With or without at a time?

#13 @jane
14 years ago

@caesarsgrunt: Yes, you understand correctly. Part of me likes "at at time", but the part of me that thinks about translation thinks just "# [post-type]s" is probably better, so I'd say no 'at a time'.

#14 @caesarsgrunt
14 years ago

I speak multiple languages and can't see a problem re translation with "at a time" - eg Spanish, "# [post-type] a la vez" - but okay, I'll do it without.

@caesarsgrunt
14 years ago

Change label to "# [post_type]"

#15 @caesarsgrunt
14 years ago

There it is without "at a time". It's trivial enough to change that I'll upload it with as well, then you can commit whichever you like.

@caesarsgrunt
14 years ago

Change label to "# [post_type] at a time"

#16 @caesarsgrunt
14 years ago

Patch 3 is with "at a time". Rather than add it to each string I've made "%s at a time" a separate string for translation, which I think is better than the previous system of having a load of individual but similar strings.

#17 @nacin
14 years ago

I'd prefer just "[ # ] Posts", though, what about "Show [ # ] Posts"?

#18 @nacin
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [14157]) Change the 'per page' screen options strings. fixes #12872, props caesarsgrunt.

Note: See TracTickets for help on using tickets.