Core: Add screen name functionality

[tobyzerner]

This is a central issue for discussion about allowing other characters in usernames, and the related complications.

Currently we only allow alphanumeric, underscores, and hyphens in usernames (Laravel's alphadash rule). I think it's pretty clear that we need to relax this constraint though since Flarum is already quite popular in non-English environments.

However, one does not simply allow other characters. We need to consider:

• User profile URLs. Currently we use the username as the sole identifier in the URL, as in forum.com/u/username. Unicode and spaces _can_ work in URLs, but things get ugly with URL encoding. Is this worth dealing with? Do we want to use the numeric ID in the URL instead of the username? What about making a latin slug from the username, and putting that in the URL in addition to the ID?
• Mentions. In particular, whitespace. @JoshyPHP has suggested a syntax like @"foo bar". @[foo bar] would also work. What do we think? Any other issues with this?

Related discussion:
http://discuss.flarum.org/d/915-spaces-non-ascii-characters-in-usernames

465

[FirestarterUA]

Very userful library for thats task: https://github.com/jbroadway/urlify

[dcsjapan]

Taking your points one at a time:

• Handling of user profile URLs should really be discussed in the wider context of slug transliteration and encoding (see #194) as this is something we're going to have to deal with in any event. I'll add a suggestion to that issue when I'm done here.

What about making a latin slug from the username, and putting that in the URL ...?

While this is possible for many languages, it would be very impractical for some, and nigh impossible for others. I'll explain in more detail in the issue linked above; in any case, this should be dealt with as a URL issue rather than as a username issue.

• Mentions could certainly be handled as @JoshyPHP suggested. The only problem I see there is that users will tend to expect Flarum's mentions to work just like Twitter.

Would it be possible to have the delimiters (quotation marks or brackets) inserted automatically by the autocomplete function? That would make the process more transparent to users. (Of course you would have to adjust the autocomplete function so it can recognize unicode usernames and present them as candidates.)

[Dakoom]

I think that usernames without spaces is too much "computer style". I would try to find a way to permit the spaces. It could be that when there is a space in a username, in the profile URL you get automaticaly something like forum.com/u/user_name.

[kirkbushell]

Better yet, a proper URL, like user-name. I agree that this should be supported.

[CoderFetch]

A while back I used a simple URL format:
forum.com/member/the-slug.the-id

[lkhrs]

Call me old-fashioned, but I actually prefer the old style of usernames with no spaces. Just something nostalgic about it.
And the other issue is that whenever I see a username with spaces somewhere I'm always checking their profile to see what their actual username is, because of the way some software worked in the past.

[Webinsane]

It is not urgent since Flarum is not a shop. In future both options would be nice.

[tobyzerner]

I think that usernames without spaces is too much "computer style". I would try to find a way to permit the spaces. It could be that when there is a space in a username, in the profile URL you get automaticaly something like forum.com/u/user_name.

The problem with this is that if you convert spaces into another character, you can easily get clashes. e.g. if there are two users, "Joe Blogs" and "Joe_Blogs", which one does forum.com/u/Joe_Blogs take you to?

[kirkbushell]

The slug generation would manage that just fine.

[tobyzerner]

@kirkbushell I don't understand, how?

[kirkbushell]

When you generate the slug, you make sure you don't get duplicates, and either include a convention to resolve it (ie, including ids in URLs, or appending 1, 2, 3.etc. for duplicates), or don't allow the same name twice. Finally, you can always block certain characters (such as underscore), but I don't see the point in that.

[lkhrs]

@kirkbushell I think that's way too complicated than it needs to be. Why should Toby go to all that trouble just for spaces in usernames?

[kirkbushell]

@lkhrs I'm not saying he should, just that it is rather easy to support. He asked for clarification regarding how you would handle the slug generation.

[maliayas]

Unicode usernames should be considered together with security.

See https://labs.spotify.com/2013/06/18/creative-usernames/

[dcsjapan]

@maliayas Good point! :+1:

It might be easiest to just leave usernames as they are and provide an optional "screen name" feature for sites that want to allow their users more sophisticated names.

Of course, it would still be necessary to consider how _screen names_ would interact with _mentions_. But it would simplify thinking about usernames as login credentials / user profile URLs.

[Webinsane]

Please do not complicate things and keep the "screen names" out of mentions, logins and user profile URLs.

[franzliedke]

Well, if we were to have screen names, we'd have to use those for mentions, right? As those would be the ones visible on forum posts. Or would we show both? That's just too complex IMO.

[Webinsane]

Use screen names just as an optional filed. In profile cards and profile pages bellow the username. I think Discourse did good job on these while keeping simplicity in the user code structure.

[chapay]

@Webinsane :+1: for not complicating things and keep usernames and screen names separated. Twitter is another good example.

[kirkbushell]

Great idea!

+1

[franzliedke]

[tobyzerner]

We have discussed this and decided to stick with ASCII-only usernames, and add screen name functionality to the core. Maybe one day we will consider supporting unicode in usernames, but for now it's too difficult.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[askvortsov1]

What else needs to be done here other than ensuring that we're using display name where relevant? I feel like actual implementations is something we could leave to extensions for now, and revisit after stable?

[franzliedke]

This comment still stands as official goal, as I see it. What you described (making sure the display name - from #1246 - is used wherever possible) and relying on extensions for the rest may be a valid MVP, or definitely a good next step.