Opened 14 years ago
Closed 14 years ago
#13467 closed task (blessed) (fixed)
Help tab text for more screens
Reported by: | jane | Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Administration | Keywords: | has-patch |
Focuses: | Cc: |
Description
Opening ticket so I'll have a place to upload the text for each help screen. Static text for 3.0, hopefully can make it pull from edited handbook in future version. Should have them all uploaded tonight.
Attachments (55)
Change History (159)
#1
@
14 years ago
Uploading in both plain text and rtf so that it's visible (in rtf) to see where bold or other formatting should go.
@
14 years ago
Posts section help test (edit posts, add new, categories, post tags), plain text only
#6
@
14 years ago
Note that if we want different text for different post types and taxonomies, we'll need to switch on the type. edit.php could use Post terminology for all types except page.
#7
@
14 years ago
Other Help is automatically appended in screen_meta(). Some of the help links there conflict with the ones here. Maybe move those into a function that can be optionally added.
#9
@
14 years ago
What is the plan here, if I may ask?
Are we going to write the Missing Manual for WordPress, repeat everything that our eyes tell us without needing any (con)textual help, and then add all that to the admin interface?
Is anyone actually thinking?
I usually stay away from UI/UX tickets, because I’ve found that they are governed by rather peculiar concepts of professional standards and peer review, but this new idea drives the chaotification of the admin UI to a whole new level.
And all that as we are about to go into string freeze?
#10
@
14 years ago
Previous text lost in crash, had to rewrite in shorter form :(
1) I have to agree with Demetris, in that it's a big ol' chunk of text that has been added - I should know, I just spent a couple hours translating it all :) Some really seem redundant (really? explaining drag'n'dropping?), or describing usages that have been in place since 2.7.
That being said, I did learn a couple things, mostly because I've never batch-edited posts before, for instance :)
2) I can't help be be concerned on the supplementary strain this might put on shared-hosts installs, with limited memory. We at WPFR already often advise users to disable the translated (along with plugins) before launching the WP update, as this frees quite a lot of memory. Adding so much text might mean that more shared-hosts will be fighting failing updates. I might be wrong, but has this been taken into account?
#11
follow-up:
↓ 12
@
14 years ago
We're beating a dead horse when it comes to memory limit issues, I think -- #13307. In the grand scheme of package size, we're not adding much text, and text is getting very significantly compressed.
#12
in reply to:
↑ 11
;
follow-up:
↓ 14
@
14 years ago
Replying to nacin:
In the grand scheme of package size, we're not adding much text, and text is getting very significantly compressed.
So be it.
Then again, reading the last comments on #13307, I would clearly not be against Denis' suggestion (which is in line with the present ticket), adding this to the upgrade screen:
"The upgrader doesn't work on all servers. If the upgrade fails on your server, don't panic! Upgrade WP manually by following these instructions (with a link to a codex article), and things will be fine." (Note: the instructions should tell users to delete the .maintenance file.)
#13
follow-up:
↓ 15
@
14 years ago
We meant to have this kind of help text in the help tab back in 2.7, we just never got around to it. It all seems obvious to us, but if you've watched new users trying to get up to speed, you understand that often the web-savviness level is low to non-existent.
The fact that Xavier, who wrote a book on using WordPress, learned something from it shows that it's not only useful to newbies.
#14
in reply to:
↑ 12
@
14 years ago
Replying to xibe:
reading the last comments on #13307, I would clearly not be against Denis' suggestion (which is in line with the present ticket), adding this to the upgrade screen
Just to provide an answer to that before we return from our tangent to regularly scheduled programming. Though it can be considered in the future, that comment was unrelated to the issue of #13307. Since we now increase memory_limits in the admin area for the downloading of the package (once the user has upgraded to 3.0), only servers that block memory_limit bumps will have an issue after 3.0, and they would have a problem anyway, regardless of the package size.
#15
in reply to:
↑ 13
@
14 years ago
Replying to jane:
The fact that Xavier, who wrote a book on using WordPress, learned something from it shows that it's not only useful to newbies.
"Co-wrote", I might add -- and I wasn't the one in charge of the "everyday use" section :)
Replying to nacin:
Though it can be considered in the future, that comment was unrelated to the issue of #13307
I'm not judging that, only that I think we should keep a notice that, if all fails, manual update is still possible - and that such help text could be considered as part of the present "help text" ticket :)
(...) they would have a problem anyway, regardless of the package size.
Alright, then. Horse, buried.
#21
@
14 years ago
Made a couple of changes when I thought necessary (e.g. GNU Public License to GNU General Public License). My only other thought is that the last paragraph for theme-install.php doesn't read well to me (seems to be saying the same thing twice, but slightly differently).
#22
follow-up:
↓ 23
@
14 years ago
duck_: "Upload a theme manually" is referring to the fact that you can actually upload a ZIP file through theme-install and let WP unzip and install for you. The old-fashioned way is then uploading into wp-content yourself.
I think it's clear enough, with "Upload" capitalized and there being an upload filter link.
#23
in reply to:
↑ 22
@
14 years ago
Replying to nacin:
duck_: "Upload a theme manually" is referring to the fact that you can actually upload a ZIP file through theme-install and let WP unzip and install for you. The old-fashioned way is then uploading into wp-content yourself.
I think it's clear enough, with "Upload" capitalized and there being an upload filter link.
Oh okay, thought it was talking about the same process. Sorry for misunderstanding :)
#25
@
14 years ago
FYI, Doug Provencio wrote first drafts of these screens, and will continue to help out by proofing for typos, etc. I'm not catching everything in the interest of getting them posted quickly so there's time to include them. Doug will comment here when he finds typos. For example, in the Links screen text, line 7 "using he Options Screen" should be "the". My oversight.
#26
@
14 years ago
We als need to do a run to cleanup formatting and make it consistent. Settle on strong or em. Apply strong/em to "For more information:". Use lists where needed and give them some styling.
#27
@
14 years ago
Second patch to remove plugins_search_help function (no longer used in core after 13467-plugins-help.diff), not bundled in case it was wanted to be kept for some reason.
#34
@
14 years ago
I have noticed the usage of ’ in some patch files. On my screen this shows up as a funny char (question mark)
The output of the following is ' and seems to work nicely.
htmlspecialchars("'", ENT_QUOTES, 'UTF-8');
#35
@
14 years ago
- Cc tai added
can I write in typo here?
/wp-admin/plugin-install.php L.56
have teen labeled -> have been labeled
#36
@
14 years ago
Plugins Section
Tai: You just beat me in pointing out been instead of teen
also, originally line 34, in plugin-editor: "click once any file name" -- add "on" after once -- I think Duck got that, but it was still in the nightly build.
For (originally line 9) in plugins.php, "C:\xampplite\xampplite\htdocs\wordpress/wp-content/plugins" is problematic. Can we just say, ".../wp-content/plugins in your directory" with or without the ellipis, to get around identifying different servers and local hosts?
#37
@
14 years ago
Posts Section
post-new.php: line 25 "Post editor -- Enter the text for you post" should be "your"
Same, line 26, "Publish (immediately)" is confusing because there is bolding but not parentheses for immediately in the Publish box. Reformat?
Same, line 28: "If you link other WordPress sites" should be "link to other"
edit-tags.php, line 64: uh, someone else got here first and already changed "category" to "tag" Thanks!
#39
@
14 years ago
Users Section
going from the corrections/numbers of Dragoonis: users-new.php, line 115: "Editors can publish posts, manage posts as well as manage other people" is confusing; how about "Editors can publish and manage their own posts as well as other people's posts" unless I'm misunderstanding that set of capabilities?
same, line 121, missing word in "Uncheck the box if you do not the password to be included in the welcome email." should be "do not want the password"
#40
@
14 years ago
Links Section
Building on Jorbin's corrections/numbering:
Now line 47 in link-manager.php "to several sites in WordPress community are included as examples" I think should be "sites in the WordPress community"
Line 49 is now the location of the "he" that should be "the"
#41
@
14 years ago
Pages
edit.php line 3 and post-new.php line 16: both "similar to to Posts" cut out a "to"
#42
@
14 years ago
Jorbin: but "Publish immediately" is different from "Publish" -- both are in that box
#43
@
14 years ago
dougwrites - Isn't immediately the default option rather then a characteristic to describe it. If you adjust it no longer says immediately.
#44
@
14 years ago
Jorbin: now I see that; the confusion is that people's eyes are going to see "publish immediately" and "publish" in that same box. Reverting to "Publish (immediately)" is clearer than referring to "Publish" twice for that same box. The parentheses are not in the line of siight, but "immediately" can change...
On link-manager, I was suggesting adding a "the" rather than subtracting a "several"
#45
@
14 years ago
- Cc aaron@… added
dougwrites-help-fix.3.patch should get it right. dougwrites, take a look.
#46
@
14 years ago
jorbin: it took me a moment to realize you had in fact gone back to the original "publish (immediately)" on edit-form-advanced.php, which is now OK with me! Thanks for both your quick work and your patience.
#47
@
14 years ago
Tools
Going by duck_'s numbering:
tools.php, line 14: "you'll be you'll be on your way" cut out one "you'll be"
#48
@
14 years ago
Related: [14989]
Menu translatable strings cleanup.
- Take out <strong> of the translatable part of For more information:
- Include support forums and Codex links inside translations, because most translators would want to change them to their local documentation sites or Codex prefixes
@
14 years ago
Settings section help text (general, writing, reading, discussion, privacy, permalinks), plain text
#55
@
14 years ago
As far as I know, all patches on this ticket have been committed in some way. Please continue typo reviews and report anything not in trunk, or not in a patch after this comment.
#62
@
14 years ago
For Posts > Add New Help, "Post editor" should be "Post Editor" (with a capital E) or "Post Editing Area" (which follows the Codex).
#63
@
14 years ago
This text in users.php is wrong:
"To add a new user for your site, click the Add New button at the top of the screen or Add New in the Appearance menu section."
As we all know, there is no "Add New" (user) in the Appearance menu section.
#64
@
14 years ago
@jottlieb Thanks for the catch! Must have been a copy and paste error along the way.
@zeo: I'm moving away from that (the Codex standard); you may have noticed I used 'screen' instead of 'panel' and 'subpanel' as well. I want the only extra capitalized things to be the actual section/screen names themselves, so Post editor is ok.
#65
@
14 years ago
Some of the text, such as mentions of editing themes in Menus help, doesn't really apply to MU setups. I think we can put in some cap checks for edit_themes, edit_plugins in a few places.
#66
@
14 years ago
Yeah, I had done that already with global terms. We should prioritize a sweep for typos so we can more reliably freeze the strings soon.
#67
@
14 years ago
Super Admin/multisite
numbering from duck_'s multisite-help.2.diff:
2 tiny typos:
line 27 ms-options.php "available upload space for each site You can change" need to add period "." between site and You
line 57 ms-users.php "profile page by for clicking" cut out the "for"
#68
@
14 years ago
In wp-admin/media-upload.php:
... which gives percentages, says “crunching,” and upon completion ...
shouldn't it be:
... which gives percentages, says “crunching”, and upon completion ...
removed comma outside "..." or delete it.
#69
follow-up:
↓ 70
@
14 years ago
While not intuitive, punctuation is *always* inside quotation marks in American English. en_US is the core locale.
#70
in reply to:
↑ 69
@
14 years ago
Replying to nacin:
While not intuitive, punctuation is *always* inside quotation marks in American English. en_US is the core locale.
Oh ya, my bad.
One more thing. Some string uses Entity (either number or name) e.g “...” for quote mark and there's a few that uses "...". Shouldn't we make it consistent.
@
14 years ago
add_contextual_help() various clean up. Removes excess space, missing Period, Comma, forward slash punc mark
@
14 years ago
Switch to HTML char entities: ' => ’ " => “ and ” and also typo: WordPressMU => WordPress MU, multiple user => multi-user
#73
@
14 years ago
char-entities.patch:
' => ’
" => “ and ”
WordPressMU => WordPress MU
multiple user => multi-user (multi-user is the most common word used to define MU even though same meaning)
For consideration (not in patch):
">" => > or use →
Add trailing slash e.g:
/category/uncategorized => /category/uncategorized/
/wp-content/themes => /wp-content/themes/
Wrap %, /category/uncategorized, /wp-content/themes with <code></code>
#74
@
14 years ago
Menus
Tiny punctuation typo -- missing comma in what should be a pair.
In Appearance section.2.txt, nav-menus.php, line 49, "(the new default theme Twenty Ten, does)" should be "(the new default theme, Twenty Ten, does)"
#78
@
14 years ago
this one still seems out there:
Super Admin/multisite
numbering from duck_'s multisite-help.2.diff:
2 tiny typos:
line 27 ms-options.php "available upload space for each site You can change" need to add period "." between site and You (6th paragraph)
line 57 ms-users.php "profile page by for clicking" cut out the "for" (3rd paragraph)
#82
@
14 years ago
If any typos previously mentioned here that did not find its way into a commit, please re-open.
Otherwise, please open new tickets for any additional typos.
#83
@
14 years ago
- Keywords has-patch added
- Resolution fixed deleted
- Status changed from closed to reopened
13467-cleanup.diff includes:
- Documentaion => Documentation
- whitepace cleanup
- Take out URL of translatable string
- Theme Repository => Theme Directory
- Plugin Repository => Plugin Directory
- Link with text to WordPress Planet instead of plain URL
- Wrap bunch of string with <code>...</code>
#84
follow-up:
↓ 88
@
14 years ago
Also, some link to Codex under Help has the attribute target="_blank" and some don't. Not sure whether to provide patch with or without target="blank" for external link.
#86
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
That last commit forces the user to get the latest articles from the WP Planet, which are in English. We at WPFR have our own planet, with French blogs. Hence, it would be cool if the string could be reverted to a state where local team can point to local planets...
#88
in reply to:
↑ 84
@
14 years ago
Replying to zeo:
Also, some link to Codex under Help has the attribute target="_blank" and some don't. Not sure whether to provide patch with or without target="blank" for external link.
These should all be target="_blank" and also translatable. I'll go through and handle.
#89
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
ms-sites.php:23 (/wp-admin/ms-sites.php?action=editblog&id=1)
The network admin arrives at this screen to make choices for a given site by clicking on the Edit link on the Sites screen available to them in the Super Admin navigation menu.
Really, I can't make head nor tail from this phrase - and thus am having a difficult time translating it. Isn't there a better wording somewhere? :)
#91
follow-up:
↓ 92
@
14 years ago
I'm thinking that whole string should go. I'm going to do some cleanup.
#92
in reply to:
↑ 91
@
14 years ago
Replying to nacin:
I'm thinking that whole string should go. I'm going to do some cleanup.
Alright then, giving up on ms-fr_FR.po for today. Weeee! ;)
#94
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Fix typo in role name and capitalize Subscriber in Help screen for ms-options.php, lines 19 and 28. Also replaced spaces w/tabs (lines 10 and 37). Patch 13467-ms-options.1 attached.
#97
follow-up:
↓ 99
@
14 years ago
Since there are strong opinions on target=_blank, I wish to preempt:
- The default contextual help links pre-3.0 were target=_blank.
- From MarkJaquith: "If you do venn diagram of the people who need help and the people who know how to open a link in a new tab, they're probably not overlapping."
This is the behavior we're using in 3.0.
#98
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
13467-target_blank.diff includes:
- Adds missing target="_blank" to external link
- Removes Duplicate target="_blank"
- target="_blank" position consistency, add after href attribute
...plus few minor enhancements (see patch).
#99
in reply to:
↑ 97
@
14 years ago
Replying to nacin:
This is the behavior we're using in 3.0.
target="_blank" - this should be the default for all external links in the core especially links that point to Codex. I wouldn't mind opening a ticket and making a patch for this. Let me know.
#101
@
14 years ago
- Keywords has-patch removed
- Resolution fixed deleted
- Status changed from closed to reopened
typo
http://core.trac.wordpress.org/browser/trunk/wp-admin/theme-install.php#L60
Documentation on Using Themes -> Documentation on Adding New Themes
#103
@
14 years ago
All links that points to Codex need to be reviewed.
A few of them are just placeholder (for example: http://codex.wordpress.org/Super_Admin_Sites_SubPanel) which is fine. Why not create a placeholder for other sub panel/menu too?
For example, Comment-> Edit Comment-> Help tab, under "More information:" there's a link to http://codex.wordpress.org/Administration_Panels#Comments. Why not add additional link to http://codex.wordpress.org/Comments_Edit_Comment_SubPanel?
I think it's better to add an empty placeholder page in Codex rather than adding any existing Codex page that are too general, useless or obsolete. At least we can fill the empty Codex page after the release.
#104
@
14 years ago
- Resolution set to fixed
- Status changed from reopened to closed
tai/zeo please open new tickets for little issues like this as the main purpose of this ticket has been achieved and it makes it much easier for us to have a focused discussion and for people to not report duplicate issues.
I have created tickets for the two issues raised: #13735, #13736
Marking as Fixed - New changes to be made against other tickets.
Dashboard section screens help text