Fix the allowed punctuation wording in user_edit_form

Confirmed. I guess D8 is the place to work on it.

more susinct:

'#description' => t('Spaces as well as these special characters are allowed: @.\'_-'),

How about this: Spaces as well as the following special characters are allowed: @.'_-

Patch attached.

more than @.'_- are allowed

I started another new issue related to this topic: #1290528: Disallow English symbols and math characters in Username

Closed a duplicate issue.

Oops. I didn't add the related duplicate issue correctly.

This is tricky. So the questions I think we need to ask are:

• Do we need to provide a list of every disallowed character?
• Is there some way to summarise the disallowed characters (eg. Non-printable ISO-88591 and non-breaking spaces, soft hypens, punctuation and math symbols, various space characters, bidirectional text overrides and various text hinting characters) that might do the trick?
• Does this text need to be in this interface, or can we link to another resource that lists the chars?

"Spaces as well as the following special characters are allowed" is a good solution to shorten the sentences and to get around the akward semicolon.
However, the names of the allowed characters should be spelled out for readability, because characters such as apostrophes are not always distinguishable from similar characters, especially when the help text is in a small font size.
Alternatively, the characters could be placed after their name.

How about this: Spaces and special characters are also allowed like periods(.), hyphens(-), apostrophes('""'), underscore (_) and the @ symbol.

Patch attached.

Re-rolled patch according to #12

updating credit

updating credit

The modules/user/user.module file does not exist anymore and forms now follows the PSR-4 standard.
You should now look in core/modules/user/src/AccountForm.php

In #25 I mistakenly changed the SiteConfigureForm, please ignore the previous patch, Here is the correct one that targets the AccountForm,

Working on this.

I'm a mentor. Helping @danharper to work on the issue.

GO @danharper!

Patch applies properly and solves the issue marking as RTBC.

It would be nice to have screenshots of this. @danylevskyi, @danharper - can you work with another sprinter to add screenshots to this issue?

double post

I'll do the screenshots.

1. Before:
   
2. After:
   

Great. Can we add the screenshots to the issue summary and also use the issue summary template?
https://www.drupal.org/issue-summaries

I am setting the priority to Normal. Per https://www.drupal.org/core/issue-priority "minor" issues are cosmetic changes. Here the description was giving incorrect information about what characters are allowed.

Added a beta evaluation.

Per suggestion from @webchick, I searched for the string "Spaces are allowed;" to make sure that this is the only instance of the string, but it also shows up in another file (site configuration form). The description should be changed in both places.

core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
177:      '#description' => $this->t('Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores.'),

Also, we should run this by UX maintainer since this change affects a form used by a lot of people.

Also, let's simplify the string to: "These special characters are allowed: space, period (.), hyphen (-), apostrophes (‘), underscore (_), and the @ sign."

Why double quotes? I think that should stay single quotes.

Addressing comment #48.

(') is an Apostrophe and (‘) is a Left Single Quotation mark Which one is this issue referring to?

Sadly, when this patch was presented in front of everyone at DrupalCon Barcelona, we discovered that we don't know what ' is. So we should figure that out. ;)

(') is an Apostrophe and (‘) is a Left Single Quotation mark Which one is this issue referring to?

Good question. I tested both and they are both accepted.

I think we need to check the code and see what is actually allowed.
Then... we might need to re-evaluate if we actually want to list them *all*.

And I think a reference, added to the issue summary, clarifying what is a single quote, apostrophe, smart quote, back tick, etc.

I checked with a program called Ultra Character Map on OSX

' is called "Apostrophe" and doesn't have a unicode value
` is called "Grave Accent" it is unicode u0060
‘ is called a "Left Single Quotation Mark" it is unicode u2018
’ is called a "Right Single Quotation Mark" it is unicode u2019

In UserNameConstraintValidator::validate() the code to check for invalid username characters is:

preg_match('/[^\x{80}-\x{F7} a-z0-9@_.\'-]/i', $name)
|| preg_match(
'/[\x{80}-\x{A0}' .       // Non-printable ISO-8859-1 + NBSP
'\x{AD}' .                // Soft-hyphen
'\x{2000}-\x{200F}' .     // Various space characters
'\x{2028}-\x{202F}' .     // Bidirectional text overrides
'\x{205F}-\x{206F}' .     // Various text hinting characters
'\x{FEFF}' .              // Byte order mark
'\x{FF01}-\x{FF60}' .     // Full-width latin
'\x{FFF9}-\x{FFFD}' .     // Replacement characters
'\x{0}-\x{1F}]/u',        // NULL byte and control characters
$name)

related info as to how we format the *code* for the string:
https://www.drupal.org/coding-standards#quotes

single quote strings should be used by default. Their use is recommended except in two cases:

Deliberate in-line variable interpolation, e.g. "<h2>$header</h2>".
Translated strings where one can avoid escaping single quotes by enclosing the string in double quotes. One such string would be "He's a good person." It would be 'He\'s a good person.' with single quotes. Such escaping may not be handled properly by .pot file generators for text translation, and it's also somewhat awkward to read.

Updated issue summary.

I think it makes sense to only tell people the "logical" characters..

#448074: @ style mentions for usernames which send notifications for D.o is possibly relevant

I'm going to make an attempt to clarify the text and submit a new patch for review.

Looks like several people were trying out all kinds of special characters yesterday after the Live Review, and lots of them can be used - too many for making a definite list.

The best solution might be to make a non-exclusive list of examples:
Several special characters are allowed, including space, period (.), hyphen (-), apostrophes (‘), underscore (_), the @ sign, and more.

And only include examples that we can clearly identify.

ok. but I think if we are going to include the word "apostrophe" then it should be ' and not ‘ which is a Left Single Quotation Mark.

@susanb maybe you had some questions when you tried?

I suggest

Several special characters are allowed, including space, period (.), hyphen (-), apostrophes ('), underscore (_), the @ sign.

without the "and more" since the "including" says that.

uhh.. and that is the only plural, ... and and. :)

so really I suggest. ...

Several special characters are allowed, including space, period (.), hyphen (-), apostrophe ('), underscore (_), and the @ sign.

I can confirm what @ifrik says in #61 ;)

Can't we just write something like the following?

Most of the special characters are allowed, including space, period (.), hyphen (-), apostrophes ('), underscore (_), the @ sign.

Or what about explaining the characters that are *not* allowed?

Most of the special characters are allowed, except all non-printing characters like invisible or fake spaces, line jumps or right-to-left marks for example.

The validation is working, so its more the case of changing the text, I agree with YesCT and we should make it identifieable with the symbols between ().

Patch and screenshot attached, implementing YesCT suggestion

Verified the issue with the patch ' fix_the_allowed-827468-67.patch'.
1.The phrase is now displayed as ' Several special characters are allowed, including space, period (.), hyphen (-), apostrophe ('), underscore (_), and the @ sign. '
2.Error is displayed if other special characters are written in username
Attached snapshot for reference.

@Truptti: thanks for reviewing the patch!

Can you update the issue summary and replace the old screenshots with yours? Also, the proposed resolution needs to be updated to reflect @YesCT's suggestion in #63.

@alimac : Updated the screenshot and the proposed resolution in the issue summary.

It seems that the state is automatically changed to a failure in the test. But the patch pass the tests now.

YAY! So happy to see this in! Sorry it didn't happen LIVE at Drupalcon "Brewshaloona"! ;)

Committed and pushed to 8.0.x. Thanks!!

(Sorry, not sure who to credit so just crediting everyone.)