String freeze: inconsistency in username field description

See the discussion at http://drupal.org/node/45453 for why it is the way it is.

here's a patch for 6.x

+1 from me. I read that other discussion and it didn't look to me like they intentionally left out the spaces possibility to me. It looks more like it got lost in the shuffle. If I missed a comment that addresses it, feel free to point that out.

Michelle

I think it could be tweaked a bit to flow better.

What about:
"Your preferred username. Spaces are allowed, but punctuation is not allowed except for periods, hyphens, and underscores."

or even removing the first unnecessary part:

"Spaces are allowed, but punctuation is not allowed except for periods, hyphens, and underscores."

or:

"Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores."

I prefer the last option personally.

Here is a patch to change it to "Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores."

This is also the description for the field on the new installation setup page.

What about cases where a rule has been setup (admin/user/rules) to not allow spaces or some other normally allowed punctuation?

If we are going to correct this is there a way where someone can easily change this wording to accommodate any rules they may have setup?

In that case you can change the string via locale.module or with a custom module that uses hook_node_alter.

Btw, the easiest way to override this string is to use the fast translation functionality of settings.php as introduced by http://drupal.org/node/131061

FWIW, I don't think the bit with Your preferred username should be removed. Possibly reworded, but not removed. I'm too tired for proper argumentation right now, and might even disagree with this statement after having slept on it. But there you go.

The title of the field is already "Username", therefore "Your preferred username" is not adding anything helpful.

Moving to the documentation component, to maybe get the docs team looking at this.

This looks good, although there's a patch somewhere in the queue to allow for ' in usernames.

didn't mean to set to needs work, sorry.

Having this right for any kind of site as the access rules are possible to override does not look cleanly possible. Or anyone has ideas for incorporating the data as set on the site (as in the allowed HTML elements for example on the input format help)?

The argument, that the rules may be overridden, holds not only for spaces but for any other character as well.
This is IMHO a serious flaw that I'd like to have generically fixed, if we just had a little more time.
The most we can do for now seems to be:

• Add "spaces" as allowed chars (as in the patch) -> therefore +1
• Add an admin definable string for the username rules at admin/user/settings
• Add a hint at admin/user/rules, stating that "if you add rules affecting usernames, you might want to inform your visitors by editing the usernames help text on l(admin/user/settings)."

Rerolling to remove 69 lines of offset.

I would note that if this patch were to be applied, it would clear up an inconsistency.

In the installer, the description for the Username field uses the same language proposed by this patch:

Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores.

However, user.module uses:

Your preferred username; punctuation is not allowed except for periods, hyphens, and underscores.

Hope I was clear enough in #17 that I support this patch. There is no reason not to RTBC it.

The two other points I made are related to a reasonable throw-in by mfer in #8 and Gabor in #16. Might be better to open up another issue for that though, as I guess this would take some weeks to get fixed.

For the additional issues about communicating access rules to the registrant, I just created the new issue #200789.

Keith, you did not attach your reroll.

New (or rather, old) patch attached.

(As an aside, I am 100% certain that I attached a patch to my comment in #18, since I looked at it later. And, surely there was a patch there when Pancho set it to RTBC in #19 thirty minutes later. However, I get a file not found error if I do a wget http://drupal.org/files/issues/username_wording-2.patch (before submitting this followup). Perhaps there is some strange edge case here that eats comment attachments. Or, perhaps I'm just losing it. Either explanation is plausible.)

And, to be sure, there is a patch.

Patch still there. Actually, I just realized that Pancho had set this to RTBC.

Just cosmetics: stripped the first 7 lines of ignored files. Remains RTBC.

Thanks, committed.