[wp-trac] [WordPress Trac] #26879: Hello, new users. Here is an Error.

WordPress Trac noreply at wordpress.org
Sat Mar 8 10:23:39 UTC 2014


#26879: Hello, new users. Here is an Error.
-------------------------------------------------+-------------------------
 Reporter:  mrtortai                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  3.9
Component:  Upgrade/Install                      |     Version:  3.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion docs-feedback  |     Focuses:
  needs-testing                                  |
-------------------------------------------------+-------------------------

Comment (by Hanni):

 OK, my apologies for the delay. Here's a patch.


 {{{
 wp-load.php
 }}}


 1. I hesitated over the capitalisation of Open Source, but followed the
 examples set by the wordpress.org/about/ page.

 2. I've changed thousands to countless; at this point in time one could
 perhaps think that the user is aware of WP, as they are installing it.
 Regardless there are a few points to make here:

    a) Thousands is a conservative estimate, I believe,
    b) It sounds a little.. boasty? This doesn't fit with the general
 humble tone of most WP copy.
    c) Again, countless will stand the test of time.

 3. Generally speaking smiley faces are both abused and over-used to the
 point of becoming both redundant, and replacing proper sentences, so in
 this case I'd  vote for avoiding use of a smiley face on this page if at
 ll possible.

 4. Played around about with is built which felt strange / awkward tense-
 wise (but i may be confusing between English and French), and therefore
 tried is built and maintained, which, whilst wordier, seems to sit a bit
 better.


 {{{
  setup-config.php:
 }}}


 1. I removed the somewhat superfluous sentence about getting started as
 it's repetitive - the button on the proceeding page is "Let's Get
 Started!", implying that by clicking on that, you're, well, getting
 started. So to be then told we need blah blah so you can get started seems
 a bit off or illogical. Perhaps.

 2. Now to the main text, proposing something along the lines of

 "OK! We'll need some information about your database.

 This information is available through your web host. If you don't have it,
 you'll need to get in touch with them. Here's what you need:"

 So, most people just need to know which information they need, not the
 immediate explanation about what happens if it goes wrong - they'll
 naturally skip over the whole paraprah if it's too long, so splitting it
 up here. if something does go wrong, or they're confused, they'll re-read
 all information naturally, IMHO. In short, I'm trying to make sure the
 important bit is read.

 I hesitated over changing here's what you need to here's what you'll need,
 but in the end decided aginast it as there's a you'll need in the previous
 sentence.

 3. Got rid of number 5  - table prefix (the host won't usually provide /
 dictate the table prefix so this could be confusing - pointed out by @DH-
 Shredder)

 4. In all places, Need more help? We got it. Has been changed to "Need
 more help. Check out our documentation."
 In this case an alternative could have been "Codex" but In an idea world
 one day it won't link to the codex; documentation is a familiar word, and
 will be useful should the link point somewhere else one day.  Codex seemed
 to jargon-y.

 5. So, I ran into a dilemma, and did a bit of grepping   to see what
 generally seems to happen with the codebase. I wanted to separate out the
 text a bit, and noticed that <br /> tags had been used within one single
 PHP tag instance in the proposed patch, but couldn't find at quick glance
 (?) cases of this happening elsewhere within the codebase. HTML seems to
 generally be separated out from any echoed text.

 Unfortunately, this led to creating a couple of extra translatable strings
 of text (I created two new paragraphs, each of one line, effectively, to
 avoid using a br tag.) This leads me to needing help and input from those
 who know what they are doing with such things:

    a) It creates extra translation strings. Boo. However, it avoids
 including HTML in a translatable string, which seems to be something WP
 avoids.
    b) Aware that with the first version of wp-load.php, and indeed with
 the links to the documentation the reverse is happening - an a href is
 being included in a translatable string. To my uneducated eye, I suspect
 this is something of a different case, as, at least the docs link could go
 to a translated version of the codex page (shudder).  So, in short, I did
 the best with the little knowledge I have, and some kind help from @DH-
 Shredder.

 At this point.. @vanillalounge - help?!


 6. Changed let's go to title case just for consistency with previous page,
 and, from what I can see, with buttons within WP generally. However, I
 notice that later on in setup-config the buttons aren't title case, so, it
 appears we don't have a "rule" here. It'd be nice to have some
 consistency, so, what's the opinion or consensus here?


 7. I replaced "good stuff" with paraphernalia, but this is going too far
 the other way, I think - from the overly simple / stands out for that
 reason to the overly complicated and standing out as too wordy. Where's
 the juste milieu here?

 8. Changed shouldn't to can't (in place of cannot which sounds a bit too
 formal). Then moved tale prefix can't be empty & please go back and try
 again onto the same line, as they are more closely related to each other
 than to then the help link.  Nonetheless, this draws attention to the fact
 that they are two slightly staccato sentences, in close proximity to one
 another, so an option could be to use a semicolon here.

 Also, if Table Prefix is being capitalised, perhaps it should be "Table
 Prefix"? This makes the sentence slightly less easier to parse, though, so
 I didn't do this.

 Oh my! You reached the end of this wall of text! Phew! In which case...

 I've also uploaded a second patch which uses the second, alternative
 direction for wp-load.php, just in case that should be preferred. I
 attempted to merge the two directions, so as to draw attention to free &
 Open Source, as @mrtortai pointed out that this wasn't currently
 mentioned.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26879#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list