**Rush** wrote on `2014-07-25 18:38:35 (UTC)`

Sorry, my lack of response to that wasn't meant to be opaque or rude, I've been trying to figure out the best way to make the argument.

I've been here before and the culmination of my thinking boils down to 'oh no not again!', but that's a really difficult thing to communicate.  I'm hoping I can at least relate challenges I see here from previous experience.

===The case of tags===

This exists: http://fab.wmflabs.org/project/view/40/

Only nobody remembers project 40, everyone remembers the name shown at the top as `Trusted User Tool`, the most common way to reference a project when projects reach a certain scale, especially in Phabricator, is via the `/tag/name` mechanism.  Only that doesn't work out for this name. 

This doesn't exist: http://fab.wmflabs.org/tag/Trusted%20User%20Tool/
This doesn't exist: http://fab.wmflabs.org/tag/Trusted_User_Tool/

This does exist: http://fab.wmflabs.org/tag/trusted_user_tool/

Technically per [spec](http://en.wikipedia.org/wiki/URL_encoding) the above should work out the spacing UTF8 as %20 and that should be fine, but as anyone who has done url encoding is aware users do not understand URL encoding.  Thus the human option of replacing %20 control character with '_'.  Which I think is the sanest option, and we should mimic it, to do otherwise is to intentionally create a disparity in how a project is referenced.

If we don't follow the Phabricator standard we now have two names for one thing.  This inconsistency means we end up with a page in the wiki that boils down to "how to translate your project name into the tag name".  Because it isn't precisely URL spec, even if you ignore the case sensitivity issues.

Versus:

This exists: http://fab.wmflabs.org/project/view/47/
This exists: http://fab.wmflabs.org/tag/operations-core/

===On readability and flat namespacing===

Taking the case of https://www.mediawiki.org/wiki/Extension:GoogleLogin

Because the project namespace is flat we have to infer hierarchy (sub grouping) with a mostly sane single string naming scheme

Bugzilla:

    Mediawiki
      -> Extensions
         -> GoogleLogin

Phabricator:

    mediawiki-extensions-googlelogin

Or

    Mediawiki-Extensions-GoogleLogin

We are representing the same hierarchy and maintaining namespace isolation consistency with this paradigm.  googlelogin is ambiguous while mediawiki-extensions-googlelogin is not.

Taking this camel case idea down the line it becomes things like:

ResearchAndReview-GrantProposals-Ready

versus encouraging lower case and readability:

research-grantmaking

We are labeling things more than we are naming them.  Eventually it becomes necessary to follow proper noun usage with things like: GoogleReady-OAuth-LoginProtocol.  The limitations of flat namespacing mean we end up with 10, 20, 30 and up character strings for which the CAmELCase usecase is not more readable except in the simplest of cases.  

Once we start doing camel case it will be an issue of having to respect all proper nouns which make strings less readable, and going back because we realize it's adding far more problems than it creates readability it will be impossible.  The intangible problem of why some `Projects` are now `projects` is essentially very difficult culturally.  External references all end up inconsistent if we try to change this later.

===URL's and Case===

So when creating a project name we are really creating a URL reference for a bucket of objects.  This isn't the same with other things within the Phabricator landscape.  We don't try to hit phab.com/theawesometicket or phab.com/myawesomelegalagreement.  We do reference phab.com/tag/project-foo.  When you get right down to [it](http://tools.ietf.org/html/rfc4343) case sensitivity and URL's is confusing.  Technically, case should be ignored in the FQDN.  Google.com and GOOGLE.com are equivalent, but should be respected in the trail.  GOOGLE.com/foo and google.com/Foo are distinct.  Even that falls apart though because different server implementations can handle those cases in different ways.  Even the w3 takes a pragmatic approach.  See http://www.w3.org/TR/WD-html40-970708/htmlweb.html and http://www.w3.org/tr/wd-html40-970708/htmlweb.html where rather than respecting the case sensitivity they just redirect, which is pretty much the sane approach for reference documentation like that I guess.  But demonstrates the weirdness.

Shown out of love:

yes: http://en.wikipedia.org/wiki/case_sensitivity
yes: http://en.wikipedia.org/wiki/Case_sensitivity
no: http://en.wikipedia.org/wiki/CASE_SENSITIVITY

So projects are going to be directly referenced as URL's and URL's are finicky.  There are [characters](http://tools.ietf.org/html/rfc3986#section-2) that are OK to use as project names in the absolute sense -- it won't stop you, but are not valid in a URL

I've been doing a lot of testing for how we can move the namespace from bugzilla to phabricator and it has only reinforced these ideas.

Right now in bugzilla we have names that when translated look like: one-two-three/four

This isn't a valid project reference, because it is not a valid URL.  That only works as phab.com/tag/one-two-three_four/

If we allow characters in project names that are not valid in a URL we are going to make things much harder for us and users.

===Referencing===

Projects are also referenced in remarkup as well but this comes with its own inconsistencies. As an example you can refer to user @rush and project #operations-requests.  But if we allow non-standard URL characters such as spaces we end up with these cases:

no : #Trusted User Tool
yes: #Trusted_User_Tool
yes: #trusted_user_tool

Note the same happens for ampersand:

project `foo_and_bar` is fine: `foo_and_bar`
project `foo&bar` is *not* fine: `foo_bar`

The way this is handled under the covers is this reference is a "hashtag", and since it's infeasible to parse out spaced tags it is converted to the i_am_snake_case whenever a project with a space is created. That means we have two cases within the context of phabricator ignoring the /tag/Trusted User Tool fiasco, it can't be referenced as project in remarkup within any text field as written.

===Character Groupings===

Probably allowed: 

`abcdefghijklmnopqrstuvwxyz0123456789-._~:[]!'()*+,;=`

Missing due to custom use: 

`# @`

Missing due to inconsistency in reference or incompatbility:

 `ABCDEFGHIJKLMNOPQRSTUVWXYZ&?/`


===tl;dr=== 

we are going to regret allowing things to be named in ways that create inconsistent references across the application.  please let's not do this and condemn ourselves to explaining it every day for the next ten years 


`mediawiki-extensions-googlelogin` ftw