For reference, MW when importing pages does currently use > as a seperator/prefix, with a text string before (user selectable), called "interwiki prefix"

Thanks @Reedy! I'll add it to the table as a no-go.

How about a special character not used for wikitext formatting? for example ^?

One should also consider the ability of users with a variety of different keyboard layouts to type the character. I suspect that the hyphen is the easiest to type for most users, dollar a close second (may be replaced with other currency symbol) and tilde the hardest, but I haven't done the actual research!

This would include mobile IMEs as well, for example on my (Britsh locale) Android, the hyphen is available on the first page of numbers and symbols, whereas dollar and tilde require a second tap.

@PrimeHunter, @Redrose64, and some other volunteers might be able to give some good advice.

Maybe a simple . (period/full stop) could be considered? Since people need to be able to type .com, it should be easy to type in most languages and browsers.

In T332805#8719005, @Esanders wrote:

One should also consider the ability of users with a variety of different keyboard layouts to type the character. I suspect that the hyphen is the easiest to type for most users, dollar a close second (may be replaced with other currency symbol) and tilde the hardest, but I haven't done the actual research!

IIRC ~ is a PITA on French (AZERTY) keyboard; especially if you don't use it frequently and have either remapped a key, or remember the magic set of keys...

There's also the thought of how we shall sort the list of users, taking into account prefixes on things like Special:ListUsers (if they'll appear there in with other users)...

Which can "obviously" be done with custom sorting algorithms and stuff... But still stuff to consider :)

There's also the fun and games of $wgLegalTitleChars...

LegalTitleChars:
    default: ' %!"$&''()*,\-.\/0-9:;=?@A-Z\\^_`a-z~\x80-\xFF+'
    description: |-
        Allowed title characters -- regex character class
        Don't change this unless you know what you're doing
        Problematic punctuation:
          -  []}|#     Are needed for link syntax, never enable these
          -  <>        Causes problems with HTML escaping, don't use
          -  %         Enabled by default, minor problems with path to query rewrite rules, see below
          -  +         Enabled by default, but doesn't work with path to query rewrite rules,
                       corrupted by apache
          -  ?         Enabled by default, but doesn't work with path to PATH_INFO rewrites
        All three of these punctuation problems can be avoided by using an alias,
        instead of a rewrite rule of either variety.
        The problem with % is that when using a path to query rewrite rule, URLs are
        double-unescaped: once by Apache's path conversion code, and again by PHP. So
        %253F, for example, becomes "?". Our code does not double-escape to compensate
        for this, indeed double escaping would break if the double-escaped title was
        passed in the query string rather than the path. This is a minor security issue
        because articles can be created such that they are hard to view or edit.
        In some rare cases you may wish to remove + for compatibility with old links.

Which is customisable; + was added later, for example... So potentially users *may* already be using the prefix char. Or even have it disabled on their wiki.

Obviously less of an issue for WMF, but may be one for 3rd party wikis...

In T332805#8718963, @sgrabarczuk wrote:

How about a special character not used for wikitext formatting? for example ^?

https://meta.wikimedia.org/w/index.php?title=User:%5Edemon&redirect=no was used by at least one user, at one point... :)

Is the plan to just have one character? Or is there going to be some text like "Temp" before it?

In T332805#8719194, @Reedy wrote:

Is the plan to just have one character? Or is there going to be some text like "Temp" before it?

We're trying to actively avoid latin characters to avoid throwing off folks on other language wikis since the temp username will stay consistent if the user changes wikis but still has the temp cookie.

I filled out the table with all ASCII special characters, mostly to note which ones definitely won't work and which ones may have issues. Feel free to delete or document if any of the remaining ones would be bad ideas.

In T332805#8719356, @matmarex wrote:

I filled out the table with special characters, mostly to note which ones definitely won't work and which ones may have issues. Feel free to delete or document if any of the remaining ones would be bad ideas.

Thank you @matmarex. 🙌

Just to have some fun I counted current usernames that start with all of these proposed prefixes (and I added a goofy proposal of my own, 73^^9):

To query all dbs, easiest is to use spark/presto and look at wmf_raw.mediawiki_user:

 with distinct_names as (
 select distinct user_name
   from wmf_raw.mediawiki_user
  where snapshot='2023-02'
)

 select sum(if(left(user_name, 1) = '!', 1, 0)) as `names_that_start_with_!`,
        ...
        sum(if(left(user_name, 4) = '73^^9', 1, 0)) as `names_that_start_with_leet_temp`
   from distinct_names
;

FWIW these are characters that can be found in a standard Persian keyboard (as a way to check for universality of the choice): !٬٫﷼٪×،*)(ـ+÷؟|

I personally prefer ~ as it was used to note users before but I acknowledge it's hard to use in non-standard keyboards

@RHo The em dash might not throw any issues technically or visually, but I think people might have trouble typing — on a standard keyboard. And they might need to do it on Talk pages, while making blocks or when filtering logs.

In T332805#8727676, @Prtksxna wrote:

@RHo The em dash might not throw any issues technically or visually, but I think people might have trouble typing — on a standard keyboard. And they might need to do it on Talk pages, while making blocks or when filtering logs.

Good point. I like some of the suggestions @Ladsgroup makes about characters on a standard Persian keyboard as a check. Particularly × as suggestive of negative/not-an-account.

In T332805#8727149, @Ladsgroup wrote:

FWIW these are characters that can be found in a standard Persian keyboard (as a way to check for universality of the choice): !٬٫﷼٪×،*)(ـ+÷؟|

I personally prefer ~ as it was used to note users before but I acknowledge it's hard to use in non-standard keyboards

Hi all, FYI that the Design Strategy team recently wrapped up initial usability testing of IP masking (desktop+mobile)—findings deck located here—and the * issue popped up in the user tests as well. A large proportion (up to half) of the 25 English-speaking testers interpreted the temp account *23-15.498 as representing their IP address (in part or in whole). For some testers, the * contributed to that interpretation by looking like it was being used to obscure part of their IP address.

Thanks for cleaning up the table @Niharika and the numbers @Milimetric :)

Looking the the available options I think the only ones that make sense to me are ~, ^ and -.

Having unbalanced quotes seems weird. The period, backtick and comma are too small. I've seen the dollar sign be used as a prefix for crypto at some places, but other than that the currency sign on the keyboard would be different per geographic location. I don't have an objective reason for not liking ! or \, just don't find them suitable.

I really like !

! is readily identifiable as a character, widely available on keyboards and I like this implication of NOT as in NOT a permanent account.

Some more thoughts:

• ! is probably the easiest to type out of all of these (on mobile touch keyboards too). The "not" meaning might be obscure, but it definitely conveys the unusualness of these user names. On the other hand, it may be surprising to speakers of Spanish, where exclamations are usually written "¡like this!", so the non-inverted mark at the beginning of a word may be unexpected.
• ~ will be slightly annoying to type in some languages, e.g. Polish, where it's used as a dead key in an alternative way of inserting characters with diacritics. No one ever uses this input method in practice, but it's enabled by default, so it's confusing for people when typing a tilde doesn't work. (Yes, this is also a problem with typing wikitext signatures.)
• \ will definitely be confused with / by everyone.
• - and ^ I dislike for no reason.
• ? (already ruled out, but bear with me) was another option I liked, due to the ease of typing and the association with something unknown, just like we don't know who these users are. Alas, it needs to be encoded in URLs like /wiki/User:%3FFoo instead of /wiki/User:?Foo. I wouldn't rule it out just because of that, but it might be enough to prefer other options.

I don't think that - (the hyphen-minus) is a good choice for the first character, because the same character is used to exclude items from a search, which could result in finding everything except the user you were looking for.

Also, there are thousands of accounts named things like -Username, -Username-, or -=Username=-.

These three: ~ ^ \ are all hard to type on an iPhone (English), because you have to click through to the third keyboard before you can find them.

! and the year (20nn) seem like they would be the easiest to type.

Thanks for all the input folks! We'll be posting these options in the next community updates on Meta and are hoping to get some more feedback there.

• ? (already ruled out, but bear with me) was another option I liked, due to the ease of typing and the association with something unknown, just like we don't know who these users are. Alas, it needs to be encoded in URLs like /wiki/User:%3FFoo instead of /wiki/User:?Foo. I wouldn't rule it out just because of that, but it might be enough to prefer other options.

I'm strongly opposed to this because of the URL encoding issue. I don't see a good reason for making the URLs less type-able, given that there are plenty of options that don't have this problem. If we decide to do this, I'd expect that decision to be continually questioned by users in the future.

• ! is probably the easiest to type out of all of these (on mobile touch keyboards too). The "not" meaning might be obscure, but it definitely conveys the unusualness of these user names. On the other hand, it may be surprising to speakers of Spanish, where exclamations are usually written "¡like this!", so the non-inverted mark at the beginning of a word may be unexpected.

? has this issue in Spanish too. I'm not sure whether it is a big problem, but either way ? doesn't have the advantage over ! for this reason.

With ! being so easy to type, I think it's my favourite option.

Using the year as a prefix will actually make name lengths longer, compared to using a 1-character prefix - even over time.

Assuming we use prefix + decimal number as the name pattern, here's how user name length would scale if the rate of increase was constant (say 10 million new temporary users per year):

Even the 2-digit prefix doesn't help, and has other downsides: we'd have to disallow registered usernames starting with any two digits, and (thinking optimistically) we'd run out of prefixes in 100 years.

And a bit of an absurd example, assuming exponentially increasing numbers of new temporary users (10 million in the first year, 100 million in the second year, etc), to illustrate the point:

In T332805#8805045, @Tchanders wrote:

Using the year as a prefix will actually make name lengths longer, compared to using a 1-character prefix - even over time.

Assuming we use prefix + decimal number as the name pattern, here's how user name length would scale if the rate of increase was constant (say 10 million new temporary users per year):

Year	New users this year	Total users	Max name length (+1 char)	Max name length (+2 char year)	Max name length (+4 char year)
1	10,000,000	10,000,000	8+1	8+2	8+4
10	10,000,000	100,000,000	9+1	8+2	8+4
100	10,000,000	1,000,000,000	10+1	8+2	8+4

Even the 2-digit prefix doesn't help, and has other downsides: we'd have to disallow registered usernames starting with any two digits, and (thinking optimistically) we'd run out of prefixes in 100 years.

And a bit of an absurd example, assuming exponentially increasing numbers of new temporary users (10 million in the first year, 100 million in the second year, etc), to illustrate the point:

Year	New users this year	Total users	Max name length (+1 char)	Max name length (+2 char year)	Max name length (+4 char year)
1	10,000,000	10,000,000	8+1	8+2	8+4
2	100,000,000	110,000,000	9+1	9+2	9+4
...	...	...	...	...	...
10	10,000,000,000,000,000	11,111,111,110,000,000	17+1	17+2	17+4

Hi @Tchanders - my understanding was that the year prefix would be used so the incrementing number resets at the start of each year, so the Total users is inconsequential.
So for example in Year 2023, the ten millionth user would look like 2023-10000000 and 13 characters long, and then ten years later in 2023, the 100 millionth person who is actually the ten millionth temp account that year would still be 13 characters long 2023-10000000. Is this possible?

Hi @Tchanders - my understanding was that the year prefix would be used so the incrementing number resets at the start of each year, so the Total users is inconsequential.

I've included "Total users" because this affects "Max name length (+1 char)".

So for example in Year 2023, the ten millionth user would look like 2023-10000000 and 13 characters long, and then ten years later in 2023, the 100 millionth person who is actually the ten millionth temp account that year would still be 13 characters long 2023-10000000. Is this possible?

This is correct - see the first table. Compare "New users this year" to "Max name length (+4 char year)" - both are the same every year. Then compare "Total users" to "Max name length (+1 char)" - both increase. However, even after 100 years, the 1 char approach is still fewer characters.

(The second table imagines that the number of new users per year keeps increasing. "Max name length (+4 char year)" is still based on "New users this year".)

In T332805#8805496, @Tchanders wrote:

Hi @Tchanders - my understanding was that the year prefix would be used so the incrementing number resets at the start of each year, so the Total users is inconsequential.

I've included "Total users" because this affects "Max name length (+1 char)".

So for example in Year 2023, the ten millionth user would look like 2023-10000000 and 13 characters long, and then ten years later in 2023, the 100 millionth person who is actually the ten millionth temp account that year would still be 13 characters long 2023-10000000. Is this possible?

This is correct - see the first table. Compare "New users this year" to "Max name length (+4 char year)" - both are the same every year. Then compare "Total users" to "Max name length (+1 char)" - both increase. However, even after 100 years, the 1 char approach is still fewer characters.

(The second table imagines that the number of new users per year keeps increasing. "Max name length (+4 char year)" is still based on "New users this year".)

Gotcha, sorry I think I am mixing having the year as part of the name as a easier scannability factor and reducing the incrementing number to per year basis; with having a it as the prefix. I agree it would make sense to have a specific single special character like ~ or ! as the demarcating element if temp accounts, and the inclusion of YYYY as a separate issue.

In T332805#8747261, @matmarex wrote:

• ? (already ruled out, but bear with me) was another option I liked, due to the ease of typing and the association with something unknown, just like we don't know who these users are. Alas, it needs to be encoded in URLs like /wiki/User:%3FFoo instead of /wiki/User:?Foo. I wouldn't rule it out just because of that, but it might be enough to prefer other options.

I would avoid not because it gets encoded (like, for example space does), but because if you don't encode it, it breaks. We try to ensure people can copy page titles into the URL to easily navigate, and having ? will make that impossible. It will also make sharing links via chat clients tricky as they often notoriously buggy when handling URL encoding.

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

User:!1234-5678
User:2023-1234-5678
`

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Also, if you can type the "1234" part of the username, you'll be able to type the "2023" part. It won't be auto-incorrected to ¡ if your device is trying to "help" you type in Spanish.

In T332805#8828785, @Whatamidoing-WMF wrote:

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

User:!1234-5678
User:2023-1234-5678

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Also, if you can type the "1234" part of the username, you'll be able to type the "2023" part. It won't be auto-incorrected to ¡ if your device is trying to "help" you type in Spanish.

I think this is a good point. Readability seems like it would be important for many editors and anything over a group of 4 generally is a lot harder for humans to process, remember and recognise.

In T332805#8828785, @Whatamidoing-WMF wrote:

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

User:!1234-5678
User:2023-1234-5678
`

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Also, if you can type the "1234" part of the username, you'll be able to type the "2023" part. It won't be auto-incorrected to ¡ if your device is trying to "help" you type in Spanish.

Relevant to this discussion is recent findings from Growth team user testing on how well unregistered editors understand temporary accounts, with questions posed asking their understanding of the name format and preferences. There was a bit of confusion in the initial *YY-##.### format used (previous * prefix, * two-digit YY, period thousand separator for the incrementing number). Many participants thought that it was their IP address being used, but partially obscured, it seems due to the asterisk and the dot separators.

When shown a few other formats and asked to rate their preference, it was clear that something with a lexical prefix was preferred - in the test *Unregistered-23.15498 or *Temp-23.15498 were clearly top choice.

This initial set of findings with English participants is currently being run with folks in es, ja, and ar (see T328616) with amendments to the UI and username format being tested, which should provide more info about whether having a localisable/english word as part of the name could help as well for legibility.

In T332805#8828785, @Whatamidoing-WMF wrote:

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Evidence from the recent Spanish-language user tests (in which the sample temp account name is being shown as ~2023-15498) indicates that people do latch on to the 4-digit year as a source of meaning. Generally a larger proportion of testers are interpreting ~2023-15498 as randomly generated in some way, and a much smaller proportion are interpreting that it has anything to do with their personal IP address.

In T332805#8833371, @RHo wrote:

In T332805#8828785, @Whatamidoing-WMF wrote:

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

User:!1234-5678
User:2023-1234-5678
`

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Also, if you can type the "1234" part of the username, you'll be able to type the "2023" part. It won't be auto-incorrected to ¡ if your device is trying to "help" you type in Spanish.

Relevant to this discussion is recent findings from Growth team user testing on how well unregistered editors understand temporary accounts, with questions posed asking their understanding of the name format and preferences. There was a bit of confusion in the initial *YY-##.### format used (previous * prefix, * two-digit YY, period thousand separator for the incrementing number). Many participants thought that it was their IP address being used, but partially obscured, it seems due to the asterisk and the dot separators.

When shown a few other formats and asked to rate their preference, it was clear that something with a lexical prefix was preferred - in the test *Unregistered-23.15498 or *Temp-23.15498 were clearly top choice.

This initial set of findings with English participants is currently being run with folks in es, ja, and ar (see T328616) with amendments to the UI and username format being tested, which should provide more info about whether having a localisable/english word as part of the name could help as well for legibility.

See also T332805#8719355: Having any letters (or other words in specific language) is a I18n burden since temporary accounts are global (connected to SUL) and works across wikis.

In T332805#8842376, @Bugreporter wrote:

In T332805#8833371, @RHo wrote:

In T332805#8828785, @Whatamidoing-WMF wrote:

I don't think that raw length should be the primary consideration. As eight digits is a reasonably foreseeable number of accounts, we might want to consider formatting the usernames for readability:

User:!1234-5678
User:2023-1234-5678
`

The year prefix contains relevant meaning that might be useful for future editors ("Oh, that temporary account was three years ago. There's no point in trying to contact them...").

Also, if you can type the "1234" part of the username, you'll be able to type the "2023" part. It won't be auto-incorrected to ¡ if your device is trying to "help" you type in Spanish.

Relevant to this discussion is recent findings from Growth team user testing on how well unregistered editors understand temporary accounts, with questions posed asking their understanding of the name format and preferences. There was a bit of confusion in the initial *YY-##.### format used (previous * prefix, * two-digit YY, period thousand separator for the incrementing number). Many participants thought that it was their IP address being used, but partially obscured, it seems due to the asterisk and the dot separators.

When shown a few other formats and asked to rate their preference, it was clear that something with a lexical prefix was preferred - in the test *Unregistered-23.15498 or *Temp-23.15498 were clearly top choice.

This initial set of findings with English participants is currently being run with folks in es, ja, and ar (see T328616) with amendments to the UI and username format being tested, which should provide more info about whether having a localisable/english word as part of the name could help as well for legibility.

See also T332805#8719355: Having any letters (or other words in specific language) is a I18n burden since temporary accounts are global (connected to SUL) and works across wikis.

Yes, this is a consideration that we are looking at in some unregistered editor usability testing - showing a number of different formats - only with symbols and Western Arabic numbers, vs with localised and English lexical prefix/suffix.
@Mraish has wrapped up some usability testing with Spanish users where it seems the ~ +YYYY year prefix format tested quite well in addressing the confusion and feedback from the previous rounds, and did as well as with word labels. The four year format seems to make it super clear to participants that it is a random/non-IP related name.

Will post info from more testing with Arabic and Japanese folks as relevant.

Is anyone talking/thinking about how these names are going to look in regular use? I was reading the updates here and couldn't help but think about a discussion thread or revision history where you might see activity from different temp users and accidentally group it together, like:

• <<Totally nice reasonable thing>> ~~~~ !2023-12345
  • <<Really Nasty Mean thing>> ~~~~ !2023-12355
    • Hey, @!2023-12345 this is your last warning before we block your account ~~~~ SomeAdmin

I wonder if some more randomness in the layout of the temp numbers would help, like !2023-12-355 and !2023-123-45

In T332805#8857049, @Milimetric wrote:

Is anyone talking/thinking about how these names are going to look in regular use? I was reading the updates here and couldn't help but think about a discussion thread or revision history where you might see activity from different temp users and accidentally group it together, like:

• <<Totally nice reasonable thing>> ~~~~ !2023-12345
  • <<Really Nasty Mean thing>> ~~~~ !2023-12355
    • Hey, @!2023-12345 this is your last warning before we block your account ~~~~ SomeAdmin

I wonder if some more randomness in the layout of the temp numbers would help, like !2023-12-355 and !2023-123-45

Honestly I found it difficult to spot the differences between the two usernames in your proposal too. I do think this is a topic that needs more discussion though. Personally, I would rather that the temporary usernames look as different as possible from eachother, and that there's a very slim likelihood of a temporary username looking similar to another. If a GUID wasn't so long for this use case, I'd have recommended that.