Help tab text for more screens

[jane]

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.

Dashboard section screens help text

Dashboard section help text - plain text format

Uploading in both plain text and rtf so that it's visible (in rtf) to see where bold or other formatting should go.

(In [14836]) Help for dashboard. Props jane. see #13467

(In [14837]) Help for Updates screen. Props jane. see #13467

(In [14842]) Remove extraneous quote. Props duck_. see #13467

Posts section help test (edit posts, add new, categories, post tags), plain text only

Media section (library, add new) help text, plain text

(In [14855]) Help for edit.php. see #13467

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.

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.

(In [14868]) Help text for edit form. see #13467

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?

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?

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.

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.)

Links section help text (edit, add new/edit ind, link cats)

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.

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.

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.

Pages section help text (Edit, Add new), plain text

Comments section help text (Edit, individual edit), plain text

(In [14906]) Help for edit-comments.php. see #13467

(In [14909]) Help for links pages. Props jorbin. see #13467

(In [14913]) Help for cats and tags. see #13467

(In [14915]) Only show slug help text when global terms are disabled. see #13467

(In [14929]) Post and page help. see #13467

Appearance section help (themes, widgets, menus, editor), plain text

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).

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.

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 :)

(In [14951]) Help for Appearance screens. Props duck_, jane. see #13467

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.

Plugins section help text (installed, add new, editor)

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.

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.

(In [14956]) Update help for plugins.php. Props jane. see #13467

(In [14959]) Help for plugin-editor.php. see #13467

Oops, looks like we both started at the same time.

Users section help text (users, add new, profile), plain text

(In [14961]) strong FMI. see #13467

(In [14962]) strong FMI. see #13467

(In [14965]) Help cleanup. Props duck_. see #13467

Tools section help text (tools, import, export), plain text

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');

Users section changes added

can I write in typo here?

/wp-admin/plugin-install.php L.56

have teen labeled -> have been labeled

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?

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!

Related: #13565, suggesting to put these in a separate textdomain.

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"

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"

Contains fixes suggested by dougwrites

Pages

edit.php line 3 and post-new.php line 16: both "similar to to Posts" cut out a "to"

Jorbin: but "Publish immediately" is different from "Publish" -- both are in that box

dougwrites - Isn't immediately the default option rather then a characteristic to describe it. If you adjust it no longer says immediately.

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"

dougwrites-help-fix.3.patch should get it right. dougwrites, take a look.

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.

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"

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

Settings section help text (general, writing, reading, discussion, privacy, permalinks), plain text

Settings

type, line 2: "fields on the this screen" cut out "the"

typo, not type

(In [15000]) Settings help. props duck_, see #13467.

[15001]

SuperAdmin Section help text (many screens), plain text, props doug and andrea

(In [15004]) Help for multisite. props andrea_r, dougwrites, duck_. see #13467.

(In [15005]) Typo (fix, not add). props duck_. see #13467.

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.

Changes to make I18n more compatible with ()

Changes to make I18n more compatible

(In [15011]) Users help. props dragoonis. see #13467.

(In [15013]) Edit comments help links. see #13467.

(In [15014]) Edit comment help text. props jane, dougwrites. see #13467.

(In [15015]) Stick to the existing styles. see #13467.

Appearance redux, has custom header and background at bottom

(In [15019]) Custom header and background help. props jane, see #13467.

(In [15020]) The 'Help' tab on the custom background page should have, you know, custom background help. Oops. see #13467

For Posts > Add New Help, "Post editor" should be "Post Editor" (with a capital E) or "Post Editing Area" (which follows the Codex).

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.

@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.

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.

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.

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"

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.

While not intuitive, punctuation is *always* inside quotation marks in American English. en_US is the core locale.

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 &#8220;...&#8221; for quote mark and there's a few that uses "...". Shouldn't we make it consistent.

add_contextual_help() various clean up. Removes excess space, missing Period, Comma, forward slash punc mark

(In [15054]) Help whitespace/punctuation cleanup. props zeo, see #13467.

Small edit to the Dashboard help text

(In [15058]) Welcome to Dashboard help line. see #13467. props jane, her first patch (!)

Switch to HTML char entities: ' => &#8217; " => &#8220; and &#8221; and also typo: WordPressMU => WordPress MU, multiple user => multi-user

char-entities.patch:

' => &#8217;

" => &#8220; and &#8221;

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):

">" => &gt; or use &rarr;

Add trailing slash e.g:

/category/uncategorized => /category/uncategorized/

/wp-content/themes => /wp-content/themes/

Wrap %, /category/uncategorized, /wp-content/themes with <code></code>

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)"

(In [15094]) Entities cleanup for help. Props zeo. see #13467

(In [15095]) Punctuation fix. Props dougwrites. see #13467

Updated text for Connection Info screen.

Small edit to documentation link text

Small edits to Add New Media help text

(In [15098]) Clarify the connection information requested in request_filesystem_credentials() to reduce confusion surrounding FTP information versus your WordPress login. see #13467, props jane.

Grammar correction to Add New Link screen help

Page order help correction

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)

Added note in widget help about theme default widget display

Small edits to Add New Plugins help text

Small edit to documentation link text on Add New User screen

Small edit to documentation link text on Profile screen

Small edit to the general settings help text

Small edits to Media Settings help text

Wrong name for menu section.

(In [15101]) Help fix. props xibe, see #13467.

(In [15102]) MS help fixes. props dougwrites, see #13467.

(In [15103]) Help fixes, props jane. fixes #13467.

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.

Various cleanup, improvement.

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>

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.

(In [15126]) Help text cleanup. Props zeo. fixes #13467

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...

(In [15128]) Mark planet link for translation. Props xibe. fixes #13467

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.

Small improvement to MS Options help screen.

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? :)

A lot of the multisite strings seem quite dense.

I'm thinking that whole string should go. I'm going to do some cleanup.

No such 6th module in current version.

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! ;)

(In [15129]) Some MS help string cleanup and standardization. fixes #13467.

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.

Fix typo in MS options Help panel

(In [15131]) Help fixes. props kpdesign, fixes #13467.

(In [15132]) target=blank for help. props jorbin, see #13467

Since there are strong opinions on target=_blank, I wish to preempt:

1. The default contextual help links pre-3.0 were target=_blank.

2. 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.

More target="_blank"

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).

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.

(In [15135]) target=blank help fixes. props zeo, fixes #13467.

typo

http://core.trac.wordpress.org/browser/trunk/wp-admin/theme-install.php#L60 Documentation on Using Themes -> Documentation on Adding New Themes

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.

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.