String freeze: description for the username field is a bit misleading

I'd support a patch implementing this.

why do we say 'your full name' here. i think people are well aware what a username is by now.

I'm cool with this patch.

Doesn't apply to HEAD.

updated patch based which follows moshe witzman's comment. Dialog will now read:

Your preferred username: Punctuation is not allowed.

Patch created against HEAD revision on 7 December 2006. Seems to work fine for me but my first effort at creating a patch so needs a good review.

patch attached

The use of the word 'punctuation' sounds ... weird. (Also, the word 'punctuation' shouldn't be capitalized.)

This bug was duplicated at http://drupal.org/node/101049 where I have also posted a patch. Reposting here:

Periods, dashes, and underscores are all allowed actually.

In researching username validation I also discovered that the maxlength is incorrectly set to 56 when the database length is 60. This patch fixes the error by abstracting the length to a constant USER_MAX_LENGTH, which will make it easy to increase in the future and reduces the need for translation changes. I did the same for the email address.

There does not seem to be a reason for setting the username max at 56 rather than 60. The original commit that increases the maxlength from 32 to 56 is here: http://cvs.drupal.org/viewcvs/drupal/drupal/modules/user.module?r1=1.26&...

I also did a grep on modules/* and includes/* but didn't find any other references to the 56 character limit.

Looking like a good improvement.

The original issue concerned the use of non-western character sets, where some valid usernames included Chinese characters which would not normally be labelled as "letters" or "numbers". Also note moshe weitzman's good suggestion to simplify the guidance.

Form 1 of the string which would cover the second point:

Your preferred username: only letters, numbers, spaces, periods, dashes, and underscores are allowed.

Form 2 of the string which might also cover the original issue (but could possibly confuse people?):

Your preferred username. The following special characters are permitted "." "_" "-" " "(space).

I can live with either of the above.

I took out the username/email length junk as it should be a separate issue.

Patch uses "Your preferred username: only letters, numbers, spaces, periods, dashes, and underscores are allowed."

-1 to characters as they are not needed.

It only makes sense when you're mapping from a strange username -> allowed input, not allowed input -> possible usernames (which is what the users are doing). As you say in the original bug report, without a frame of reference it's unclear what differentiates characters from numbers and letters.

Alright, that's fine.

The original issue concerned the use of non-western character sets, where some valid usernames included Chinese characters which would not normally be labelled as "letters" or "numbers". Also note moshe weitzman's good suggestion to simplify the guidance.

Unicode classifies ideographic Chinese characters as "Letter, other", so "letters" is not too bad.

Perhaps we could say: "Use only words and numbers. Punctuation is not allowed except for a period, hyphen or underscore."

Not so sure about the use of "characters" as this includes all the special characters which are not punctuation yet will not be permitted such as "&", "%" (and many others).

Also an important bit of this string is the

Your preferred username

so let's not lose that.

I wonder if the patch given by ChrisKennedy at #11 will suffice? Despite some semantic imprecision I think it will be sufficient for users. As evidenced by the original issue, those that might wish to work around that imprecision seem to be managing. But English is my first language and this might be why I find the patch text fine. Wesley's view is better informed from a non-Western language perspective.

@Wesley - Is the proposed text confusing and we need to continue to try to find a better wording? Or is it imprecise but otherwise workable?

I agree with Wesley Tanaka, #11 is/could be confusing. I prefer #16.

#16 sounds fine for me too.

I see the V5 RC is out and there is a statement "With all the user interface strings frozen...". I don't understand the fix and release processes very well. How does this 'fix' get moved forward? More specifically, what can I do to help?

#16 it is then.

Regarding policy, here's what Dries sent to the dev list recently: "String are not 100% frozen yet, but will be when the first release candidate (RC) is made available. Once the RC is out, we'll try not to break strings unless we really have to." So we'll have to see if this bug qualifies as worthwhile or not.

Committed to HEAD.