Phabricator project display names use awkward capitalization and hyphenation
Closed, ResolvedPublic

Description

Splitting this off from T43.

Currently Phabricator project display names are awkwardly using capitalization and hyphenation. For example, "Bugzilla-Migration" should be "Bugzilla migration". I boldly fixed this project name, but apparently that caused issues. T910 was filed about links breaking due to project renames. What other issues are there to address before we can fix project names?

Quim mentions project name guidelines, though Phabricator opened to the public less than a month ago, so I'm not sure how there would be appropriate guidelines in this area already.

MZMcBride updated the task description. (Show Details)
MZMcBride raised the priority of this task from to Needs Triage.
MZMcBride added a project: Phabricator.
MZMcBride changed Security from none to None.
MZMcBride added subscribers: MZMcBride, Qgil, QuimGil.
Qgil triaged this task as Low priority.EditedOct 26 2014, 5:06 AM

See T705: Approve the Phabricator project guidelines, which was basically an evolved summary of the discussions we had in T43: Decide how to organize projects and T283: Document a process to request new projects.

For problems with spaces, check T283#3518 - T283#3526 - T43#649

As you can see in these tasks, we had long and slightly heated discussions about the topic of spaces vs dashes and underscores. At some point we had to settle on an agreement in order to write the migration script and move forward onto the many other open tasks.

I'm not a fan of the dashes and underscores either, and I do like the looks of natural language for humans, with spaces. However, right now I prefer to respect the decision we made, not touch the system we have which we know it works, focus on higher priority tasks, and complete the Bugzilla and RT migrations.

Once we are all using Phabricator, we can revisit this discussion and see whether the current situation can be improved.

As for the capitalization, we are just following Phabricator's title case default. I just got used to it, it's almost like a characteristic tone of voice. I would say this is also worth discussing after we all have used this tool for some time.

I read through the linked discussions. The issue that @flimport raises seems to be that /tag/Foo%20Bar and /tag/Foo_Bar do not currently redirect to /tag/foo-bar. We need slightly more aggressive URL normalization, but this is trivially solvable with a PHP script.

This task is focused on the project display names. I don't really care about the URL name. Whether we use spaces, hyphens, or underscores in the URL isn't important to me. The labels that users actually see in the software is. "MediaWiki-Core-Team" and similar project display names are pretty bad. I'd even prefer CamelCase to hyphens, though both options are far behind my first preference of simply using normal words with normal spaces in what we show to users.

jeremyb added subscribers: Aklapper, jeremyb.EditedOct 29 2014, 5:25 AM

maybe you mean @Aklapper or @chasemp. @flimport is just a bot.

I'd even prefer CamelCase to hyphens, though both options are far behind my first preference of simply using normal words with normal spaces in what we show to users.

+1, see also T894.

Qgil added a comment.Oct 29 2014, 8:39 AM

If you run the CamelCase against a dozen of real projects at https://bugzillapreview.wmflabs.org/project/query/all/ you will probably agree that even the combination of underscores and hyphens is more readable. Besides, it might introduce more questions marks when searching for a term inside a CamelCased string.

Dzahn added a subscriber: Dzahn.Oct 29 2014, 10:15 PM

how about the ones that combine CamelCase, hyphen and underscore? example "Commons_App-Android", "Browser_Support_Apple-Safari". I don't see the underscore being mentioned in guidelines. can it be replaced with - ?

In the meantime (T894) we've replaced underscores by hyphens/dashes so one item less in the mix. As mentioned earlier, using spaces would break certain URLs plus automatic linking of mentioned projects in comments.
Not sure what proposed actionable items are left in this task.

I get that we needed this for the migration, but is there a reason to keep it now?

In T911#16545, @Qgil wrote:

If you run the CamelCase against a dozen of real projects at https://bugzillapreview.wmflabs.org/project/query/all/ you will probably agree that even the combination of underscores and hyphens is more readable. Besides, it might introduce more questions marks when searching for a term inside a CamelCased string.

I definitely don't agree that the use of any symbols between words is more readable than, no symbols between words.

I definitely don't agree that the use of any symbols between words is more readable than, no symbols between words.

Great, you would have been a prodigy in Ancient Rome, like Caesar. :) https://en.wikipedia.org/wiki/Scriptio_continua

As for the task, I doubt we know yet how well project names are doing; AFAIK we don't even know exactly how the search engine is going to work.

Qgil added a comment.Nov 27 2014, 9:56 AM

Scriptio continua is still in use in Thai, other Southeast Asian abugidas (Burmese, Khmer, Javanese, Balinese, Sundanese script), Lao, and in languages that use Chinese characters (Chinese and Japanese).

You see, it's not that bad. :)

Now seriously, please let's stick to this decision (that, I repeat, came after a long and dense discussion) while we are still in the process of mass-creation of projects. Currently it is important to consolidate a few practices which are based purely on social conventions, like the project guidelines. Before only a reduced group of admins could create/rename projects, now we have a lot more flexibility. Progress is progress.

When the novelty of creating new projects is passed, when we have all these projects backed by well-behaving hashtags with dashes, and when we will put more time to investigate Differential details and constraints, we will be in a better position to discuss this topic and find alternatives, if needed.

To make this situation clear, I would like to propose that we change the status of this task to "Open, Stalled", marking a point of reopening after the project migrations, before the code review migration.

Qgil moved this task from To Triage to Need discussion on the Phabricator board.Nov 27 2014, 9:56 AM

Okay, so I see two options here:

  • hack Phabricator to change spaces into hyphens when generating the primary hashtag; and/or

Would implementing one of these two options allow us to write "Release engineering" instead of "Release-Engineering"? Please say yes.

@Krinkle, why is https://phabricator.wikimedia.org/project/view/609/ called Technical-Debt instead of Technical-debt?

@MZMcBride: I don't think adding redirects would improve anything. Nothings points to those urls in the first place. It's safe to say we're not concerned about users manually constructing urls.

If we want the #-syntax to work, we can add them as "Additional hash tags" (aka aliases) to projects. For example, Continuous-Integration-Infrastructure (#contint) and Continuous-Integration-Infrastructure (#continuous-integration). We can add aliases with underscores if that's what we really want, but that's imho not useful either. If we only use hyphens, then there's no reason to expect an underscore to work. Seems simple enough to just standardise on one thing (e.g. hyphens) and don't create expectations about other formats.

Phabricator #-syntax doesn't support spaces inside values. Entering two words separated by space in the comma-separated list of "Additional hashtags" results in them being interpreted as two separate hashtags (when saved, they're normalised to be comma-separated also).

@Nemo_bis: See T75892 instead.

Why? I don't want scattered discussions, I want consistency.

jayvdb added a subscriber: jayvdb.Dec 29 2014, 4:07 PM
Qgil added a comment.Feb 16 2015, 10:45 PM

There is an interesting reply from Evan about the use of spaces in project names: https://secure.phabricator.com/T7284#96783

We don't specifically recommend things one way or the other, but spaces in projects names are definitely allowed/supported/expected and considered a normal use case.

Even if we got used to the dashes, I don't think they are preferred to the natural spaces. We could just remove the requirement to have dashes in project names, and let the wiki way evolve the current situation. The requirement for leaving an additional hashtag when renaming a project would stay.

What do you think?

obviously I would prefer projects have normal sentence style structure, without hyphens underscores, etc.

In T911#1042449, @Qgil wrote:

What do you think?

Basically nothing has changed since the last evaluation, hence no reasons to change something.

Restricted Application added a subscriber: scfc. · View Herald TranscriptJun 16 2015, 12:52 PM
Aklapper lowered the priority of this task from Low to Lowest.Dec 6 2015, 2:38 PM
Krinkle removed a subscriber: Krinkle.Sep 29 2016, 7:37 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptSep 29 2016, 7:37 PM
Aklapper closed this task as Resolved.Sep 29 2016, 11:32 PM
Aklapper claimed this task.

Latest revision says "should" instead of "must" plus for a while now Phab has been supporting type-ahead "Find Project" proposals in comments when writing #whatever. Hence closing as resolved.