Entertainingly, you can see from T299814 that we actually toned it down from initial designs, where we had the namespace bolded as well. :D

@Jonesey95
That is probably enough examples for now. In general, Template space does not have spacing, Category space does not have spacing, and multiple other namespaces do not have spacing, but based on the above exceptions, I suspect that there are at least a few pages in each of those namespaces that have spacing. Please do what is needed to eliminate these inconsistencies.

The inconsistencies are because we decided to only apply it to pages that had DiscussionTools enabled. This is unfortunately more complicated than just being namespace-based -- you can opt pages from non-discussion namespaces in, and opt pages from discussion namespaces out. I can look at any page and tell you exactly why it's displaying the way it does, but you can't make anything other than a broad generalization without looking at the page source.

So I absolutely agree we should pick one and make it consistent.

@doctaxon
We're talking about page titles as database values with prepended namespace titles, both parted by a colon.

If we care about the database representation, the title and the namespace are stored separately, and the lack-of-space makes it look like they're not.

(Disclaimer: this is a subjective discussion of how I parse things when reading them, and you may interpret this differently:)

A representation like "Project:Foo Bar" makes it look like "Project:Foo" and "Bar" might be the way that gets split up into units, whereas "Project: Foo Bar" makes me think "Project" and "Foo Bar" is the breakdown. If the goal is to indicate that the namespace and the title are related-but-separate, emphasizing that separation via the space seems better (to me).

Unfortunately, whether a namespace is a defining feature of the title or a modifier does depend on the namespaces. "User:DLynch" and "User_Talk:DLynch" and inexorably linked, but "Main:Village_Pump" and "Wikipedia:Village_Pump" are entirely unrelated. This makes a general rule for how we should display this when applied to non-talk namespaces a bit more challenging.

Wikipedia:Requests for comment

This page should not have talk page styling, but the footer template had __ARCHIVEDTALK__ to suppress reply links. I've instead put __NOTALK__ in the header template.

Either way, the notion that this styling should only be present depending on whether a page has a signature on it or not is simply misguided. Either that should be the default style everywhere or nowhere. The weird inconsistencies only highlight this. (Personally I also don’t think that what DiscussionTools is doing with <h2>-level headings, making them Arial and bolded even though we moved away from that style in 2014, is motivated by anything reasonable either.)

I also agree it should be consistent across all types of pages (talk & non-talk). The h2 re-styling can be disabled per-user in your preferences.

Have we got a global survey that these spaces are wanted in every wiki? In every language? In French they often use the colon with space before AND behind

Show me the mandate for this change that the global community supports.

@doctaxon: https://www.mediawiki.org/w/index.php?title=Bug_management/Development_prioritization#Why_wasn't_I_consulted_about_these_changes%3F

But we're talking about a general visual change, not about a bug or a part of project development.

If it's a general change affecting almost all members of the worldwide community, there should be an opportunity to discuss it, examine its necessity, and vote on it.

Vote: No. Software development is not a popularity contest.

It is so weird that currently "Namespace:Title" and "Namespace: Title" exist simultaneously, with "Namespace:Title" for non-talk page namespaces, and with "Namespace: Title" for talk page-associated namespaces. (Ignore my grey background styling and "Variants" link there).

Perhaps it would be better if there were some sort of consistency in having/not having spacing between the title and the namespace.

I think actually, would be in favour of a slight variation on this where every prefixed page has a space character in its page name after : rather than strange CSS padding.

So rather than

https://en.wikipedia.org/wiki/Talk:Smallpox

The page would be physically at:

https://en.wikipedia.org/wiki/Talk:_Smallpox

and have the space in the page name.

https://en.wikipedia.org/wiki/Talk:Smallpox would automagically redirect back to https://en.wikipedia.org/wiki/Talk:_Smallpox

In other words, the other way round to the way it is now.

This would improve legibility of all prefixed pages, facilitate automatic spellchecking, and insert a suitable linebreak opportunity in various places where this is a good idea.

Thoughts?

Before this patch, everyone wrote it the same way and the software always displayed it the same way. Attempts to change to a system where a space is added everywhere are likely to result in people writing it both ways forever, which I think will result in unnecessary complexity and disorganization.

In my opinion, whatever we're trying to solve by adding this space (confused newer editors?) is not worth giving up the simplicity and elegance and consistency of the current system.

I have some other arguments against in my previous comments if you'd like more details.

In my opinion, it might be better to just stick with the current "Namespace:Title", but the "Namespace:" will be transformed into some sort of "tag label" (with border, background colour or any style configured, what ever that is appropriate). Which means that if needed you can copy paste the entire "Namespace:Title", but at the same time make normal users easily understand that the actual title is the one behind the "Namespace:". This might be a better way to solve the situation of "Namespace:Title" being confusing or grammatically inaccurate, at the same time improve readability perhaps.

If we intentionally add space (even on the link) becoming "Namespace:_Title", it will further complicate matters that shouldn't be complicated to begin with, because majority of the long-term contributors are familiar with "Namespace:Title" naming.

Since nobody seems to want to finish this task, can we please roll it back in production? Developers are welcome to continue working on it on test platforms to incorporate the bug reports listed above.

I think you’d have more luck petitioning this at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Discussion_Tools_usability_improvements_becoming_default right now.

In terms of finishing this, resurrecting @matmarex's https://gerrit.wikimedia.org/r/c/mediawiki/core/+/825418 looks viable. It goes significantly further than the DiscussionTools implementation by exporting-and-using the colon-separator message, so wikis where adding a space wouldn't be typographically-correct will automatically cope with that.

It's insane that this change got so much well-reasoned pushback here and then still managed to make it through to production. Something is profoundly broken in the software development process here.

For enwiki at least, this changes applies to ~76% of namespace prefixed pages. I'd like to get this to the remaining 24%. The main issue is that the current feature and preference lives in DiscussionTools, so we need to:

• Move the feature to core
• Create a core preference that is initially disabled for anyone who has DT visual enhancements disabled.

Now that visual enhancements are default-enabled everywhere - this should be much more straightforward.

Unequivocal no to making it a core preference. This is a clear instance where a global community vote should simply happen on whether this style should be present or not. If the community at large ends up disagreeing with having a full-width space there, then the developers should not force their will on everyone either in DiscussionTools or elsewhere. FWIW, I would’ve probably voted yes to it if the space was smaller, but it is not, unfortunately, and inserting a full-width space there seems like a really Anglo-centric decision to begin with (in most of the languages, Discussion: Main Page is already a purely technical name that has no proper declension to denote the sense of ‘Discussion of Main Page’).

This is a clear instance where a global community vote should simply happen on whether this style should be present or not.

A global vote doesn't make sense, because different languages have different rules. It's why I referenced that patch in my last message, which respects language rules for colon-spacing.

In T315893#12125265, @DLynch wrote:

A global vote doesn't make sense, because different languages have different rules. It's why I referenced that patch in my last message, which respects language rules for colon-spacing.

A global vote would make sense because this is a global change that was not consulted about with any language community. What the issue at hand here is whether the community considers page names a technical representation of the name or something that should follow typographic rules of the specific language to a tee. If you’d wish to make the case to the community that colons would be language-dependent, you can merge the patch and make that case once it lands. As https://translatewiki.net/wiki/Special:Translations/MediaWiki:Colon-separator shows, however, there is a number of languages that do not have : as the separator symbol at all. Is the plan to redirect https://zh.wikipedia.org/wiki/Wikipedia：首页 to https://zh.wikipedia.org/wiki/Wikipedia:首页 once the downstream effects of this change would be felt by editors?

A global vote would make sense because this is a global change that was not consulted about with any language community.

We don't have global votes for every feature change - and this one has also been deployed for several years on almost all wikis, with an easy way to turn it off via preference.

Sometimes it is better not to sit in an ivory tower and ignore all criticism, no matter how valid. If the change is uncontroversial, then it would surely be confirmed by such a vote. As it currently stands, the deployed solution is not uniform in how it gets applied (so similar pages can have different separator styling) and if it requires a setting to fix that, then a much easier thing would be to poll people on whether this is necessary at all. And you cannot easily disable this enhancement while keeping all the other ones, so that point is moot.

Is the plan to redirect https://zh.wikipedia.org/wiki/Wikipedia：首页 to https://zh.wikipedia.org/wiki/Wikipedia:首页 once the downstream effects of this change would be felt by editors?

If it helps, zhwiki has had this turned on by default for everyone for the last year and doesn't seem to mind. So the change has definitely been felt there.

And you cannot easily disable this enhancement while keeping all the other ones, so that point is moot.

A separate core preference would fix that.

Re: Other langauges and Anglo-centricity - we haven't had complaints from other languages (where it has been deployed for years) - nor seen them disable it via on-wiki CSS.

In T315893#12125349, @DLynch wrote:

If it helps, zhwiki has had this turned on by default for everyone for the last year and doesn't seem to mind. So the change has definitely been felt there.

My point here is that relying on colon-separator could potentially introduce confusion about how page titles work in languages that use non-standard Unicode symbols for separators, like Chinese (but not limited to it, see my link). Currently, they still use the same separator as everyone else. I get that you have considered copying, great, but if you rely on a message that can have different symbols, then it’s only natural that someone in Tigrinya will eventually write their page names incorrectly because of a visual difference.

I'm inclined to think that if it was going to cause problems, we'd have seen it already from the discussion pages on those languages. We really do have years of this being deployed without any complaints of it causing issues for users.

I would be more worried if it was ever going to affect the Main namespace, because that's the one where we expect loads of people to be editing without yet having learned how wikipedia works.

I feel like no dev here understands what I am saying about colon-separator. We do not currently have a solution deployed that changes the : symbol entirely to something else (for Tigrinya, to ፦, which is notably not :). If you rely on colon-separator for display reasons, then it would change the : symbol for those languages, and it would inevitably introduce friction for people, because not everyone always copies the page titles, sometimes we also just write them using the keyboard (and if you as an English speaker saw the title written as Talk–Main Page, you would have no reason to assume that it needs to be written as Talk:Main Page).

I understand what you're saying. I am saying that this does not appear to be a problem in practice, with a lot of evidence that this hypothetical problem has not materialized.

In T315893#12125506, @DLynch wrote:

[...] this does not appear to be a problem in practice, with a lot of evidence that this hypothetical problem has not materialized.

It hasn't materialized because it hasn't been implemented! No titles currently appear as Talk–Main Page in *any* language, so what exactly is your "evidence" about what people would do if such a change were to be implemented?

Currently things appear as “Talk: Main Page” in most languages. We have not seen a spate of complaints about redlinks to “Talk:_Main_Page”. So users are clearly not blindly linking things to whatever it looks like.

Ugh. [[Talk: Main Page]] is rendered as a blue link in MediaWiki. [[Wikipedia：首页]] is not. This conversation radicalised me about the need for a wide public vote on this matter much more than any single complaint did, because if this is the level of testing this decision is getting approached with, we should not rely on the WMF’s expertise on what’s better for us.

If the people who made this change were operating under this serious misconception about how page titles work, I'm not at all confident in their analysis of cost/benefit on this.

@DLynch Please, at least until this discussion is resolved, can this be reset to get rid of the space? Individual wikis can use CSS to re-add the space if they want, or make any other modifications to the way titles display.

(Sorry for the slow reply, I was getting lunch.)

In T315893#12125567, @stjn wrote:

Ugh. [[Talk: Main Page]] is rendered as a blue link in MediaWiki. [[Wikipedia：首页]] is not. This conversation radicalised me about the need for a wide public vote on this matter much more than any single complaint did, because if this is the level of testing this decision is getting approached with, we should not rely on the WMF’s expertise on what’s better for us.

Fair point, _Main_Page wasn't the appropriate way it would have broken, my only excuse is that I was typing on a phone and rushing my reply. However, we also haven't seen a spate of people on zhwiki redlinking the theoretical [[Wikipedia：首页]] (which, for other readers, has been written using the zhwiki colon-separator which is FULLWIDTH COLON) -- if that's the sort of thing a Chinese writer is prone to manually writing when presented with something that looks (to me) identical to : , I'd think it'd have come up.

I do agree there are two languages that have genuinely confusing outcomes if we used colon-separator:

• Sylheti (syl) is &nbsp;꠪&#32; (a non-breaking space, then a SYLOTI NAGRI POETRY MARK-3, then a regular space)
• Tigrinya (ti) is ፦&#32; (a ETHIOPIC PREFACE COLON, then a regular space)

They're smaller languages, but this is an argument in favor of not just going with the @matmarex patch, and instead doing something more-basic with a configuration or message specifically for this rather than trying to inherit from something else.

Please, at least until this discussion is resolved, can this be reset to get rid of the space?

@Mr._Starfleet_Command I don't think there's much point to doing so for anyone but enwiki?

As noted above, this has been released as-is everywhere-but-enwiki for somewhere between eight(-ish? I'd need to check) months and three years, and isn't causing problems. The other wikis have had a chance to adjust it via site CSS if they object to it, so for them rolling it back suddenly would be just as much of a randomly-changing-things result. The only recent development was the enwiki release on Monday, and there's not any particular link title-correctness reason to not have it there since links handle randomly inserted spaces around the namespace-separator just fine.

I still think @DLynch is not getting it. Changing from "Namespace:Title_name" to either "Namespace:_Title_name" (URL link) or "Namespace: Title name" (page title display) is a BIG cosmetic change (or even technical change if URL link change is being considered). Why don't we ask one by one language editions of Wikimedia projects (or perhaps just ask through Meta Wiki) for the final concensus regarding the implementation of it?

As far as I know, many people dislike the current implementation of "Talk: Title name" (although just cosmetic change), so what data that you have obtained (maybe through A/B test or something) for claiming that statistically people do not mind about the changes?

I think the reasoning here is: "we tried it and few people said anything, so it must be okay".

In my opinion that's not really an acceptable way for deciding how to make changes to Wikipedia.

In T315893#12126837, @Jacobolus wrote:

I think the reasoning here is: "we tried it and few people said anything, so it must be okay".

In my opinion that's not really an acceptable way for deciding how to make changes to Wikipedia.

Maybe, but we should discount objections that are just variations on "it's different!" and are not grounded in principles of computing or orthographic conventions. A lot of people don't like changes at first, simply because it's different, and then complain in vague terms, but once people have become used to it then OK. We need to only consider comments that are specific and relevant.

I think on this basis, @DLynch is completely understanding and getting it and there's no need to patronise him.

In T315893#12126847, @Bugreporter2 wrote:

Maybe, but we should discount objections that are just variations on "it's different!" and are not grounded in principles of computing or orthographic conventions. A lot of people don't like changes at first, simply because it's different, and then complain in vague terms, but once people have become used to it then OK. We need to only consider comments that are specific and relevant.

It is not simply just about "people dislike it because it is different", it is because the imposed decision of turning "Namespace:Title_name" to "Namespace:_Title_name" (URL link) or "Namespace: Title name" (page title display) for every single Wikimedia projects is just too one-sided and Anglocentric!

In my opinion, if everyone here do care about orthographic conventions and such, it would be better if there is a multilingual configuration just for the colon between namespace and title name, so that different language communities can freely decide if they want "just colon", "colon with subsequent whitespace", "colon circumfixed by two whitespaces", or any other configuration. In this case we can refer to how Growth team manage to tailor special page aliases for different languages, something similar to:

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/refs/heads/master/GrowthExperiments.alias.php

@Hakimi97 I think you're misunderstanding the technical side of this -- no change has been made to the URLs. They've always (well, for a long time) been flexible about accepting putting spaces around the :, but we haven't changed how we generate them or what we consider the canonical page URLs to be.

In T315893#12126861, @Hakimi97 wrote:

In T315893#12126847, @Bugreporter2 wrote:

Maybe, but we should discount objections that are just variations on "it's different!" and are not grounded in principles of computing or orthographic conventions. A lot of people don't like changes at first, simply because it's different, and then complain in vague terms, but once people have become used to it then OK. We need to only consider comments that are specific and relevant.

It is not simply just about "people dislike it because it is different", it is because the imposed decision of turning "Namespace:Title_name" to "Namespace:_Title_name" (URL link) or "Namespace: Title name" (page title display) for every single Wikimedia projects is just too one-sided and Anglocentric!

In my opinion, if everyone here do care about orthographic conventions and such, it would be better if there is a multilingual configuration just for the colon between namespace and title name, so that different language communities can freely decide if they want "just colon", "colon with subsequent whitespace", "colon circumfixed by two whitespaces", or any other configuration. In this case we can refer to how Growth team manage to tailor special page aliases for different languages, something similar to:

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/refs/heads/master/GrowthExperiments.alias.php

Is it really though?

As far as I can tell, the only major language that differs from this colon+space convention is French, which requires a non-breaking space before the colon, as well as a normal breaking space after it. I'd support making this the default pattern for French as an alternative.

For CJK languages, their colon is a full-width character. Not sure what's going on here. These can be a bit complicated. Opting out of the space may be appropriate for these languages.

Finally, like it or not, English is the canonical language for MediaWiki so it is the default.

So local opt-outs can be accommodated I think.

In T315893#12126864, @DLynch wrote:

@Hakimi97 I think you're misunderstanding the technical side of this -- no change has been made to the URLs. They've always (well, for a long time) been flexible about accepting putting spaces around the :, but we haven't changed how we generate them or what we consider the canonical page URLs to be.

Let say the "addition of space between page namespace and page title" is just a cosmetic changes through altering the CSS, is it hard to make " .mw-page-title-separator::after { content: ' '; }" configurable on language-by-language basis?

In T315893#12126865, @Bugreporter2 wrote:

So local opt-outs can be accommodated I think.

The exact main concern here is the local opt-outs being not possible. Like I said, unless if there is a configuration like how https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/GrowthExperiments/+/refs/heads/master/GrowthExperiments.alias.php is being done. I think it is a requirement to have a language-based switch or config to enable/disable spaces surrounding the colon between namespace and title name, regardless or URL config or CSS config.

In T315893#12126866, @Hakimi97 wrote:

is it hard to make " .mw-page-title-separator::after { content: ' '; }" configurable on language-by-language basis?

It's more complicated than just making it a per-wiki setting, but it reacting based on the current user's chosen language is what stjn and I were talking about with that colon-separator patch earlier today. Because of the mentioned issues with colon-separator we'd probably want to make a new message specifically for this purpose instead, but the patch already shows what would need to be done for that.

In T315893#12126870, @DLynch wrote:

It's more complicated than just making it a per-wiki setting, but it reacting based on the current user's chosen language is what stjn and I were talking about with that colon-separator patch earlier today. Because of the mentioned issues with colon-separator we'd probably want to make a new message specifically for this purpose instead, but the patch already shows what would need to be done for that.

A new i18n message title-namespace-separator sounds like the way to go. There's a reason i18n guidelines suggest to avoid message reuse.

Given the lack of requests for translating the separator I don't think that is a priority for now, and while our APIs are mostly tolerant of additional whitespace, they would not handle different separators so it would be a vastly more complicated undertaking and beyond the scope of this task.

Change #1311451 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/core@master] Add 'spaceafternamespace' preference, inherit from 'discussiontools-visualenhancements'

https://gerrit.wikimedia.org/r/1311451

Change #1311452 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Remove namespace separator CSS, upstreamed to core

https://gerrit.wikimedia.org/r/1311452

In T315893#12127566, @Esanders wrote:

Given the lack of requests for translating the separator I don't think that is a priority for now, and while our APIs are mostly tolerant of additional whitespace, they would not handle different separators so it would be a vastly more complicated undertaking and beyond the scope of this task.

Okay. A wiki config could be introduced instead to specify which sides of the colon get the space. Based on some quick research:

@SD0001 Filed as T432346

You must know that it's indeed not a language issue or an orthography issue, to put a space behind the colon. We are not talking about sentences or word terms in any language. We are talking about namespaces and page titles, that are bound to a string by a colon. So it's not advisable to change anything to something that looks like colon-space with the intention to correctify a language-based issue.

In T315893#12128387, @doctaxon wrote:

You must know that it's indeed not a language issue or an orthography issue, to put a space behind the colon. We are not talking about sentences or word terms in any language. We are talking about namespaces and page titles, that are bound to a string by a colon. So it's not advisable to change anything to something that looks like colon-space with the intention to correctify a language-based issue.

This task is now just about applying the change to other namespaces. I think this is a good comment for T432346 (I generally agree with your point).

In T315893#12128387, @doctaxon wrote:

You must know that it's indeed not a language issue or an orthography issue, to put a space behind the colon. We are not talking about sentences or word terms in any language. We are talking about namespaces and page titles, that are bound to a string by a colon. So it's not advisable to change anything to something that looks like colon-space with the intention to correctify (sic) a language-based issue.

I disagree. It is an orthography issue. The output needs to be human-readable, not machine-readable. Whatever code is used internally is not important; it's what's presented to the reader that IS.

Update
hi y'all – a quick note to say: before this upcoming Monday is over, you can expect a more thorough response from me that lays out the concerns we understand you to be raising and the solutions we think could address them.

And for context, my name is Peter. I work as the product manager for the Editing Team and am the person who is responsible for these changes.

In T315893#12131057, @ppelberg wrote:

Update
hi y'all – a quick note to say: before this upcoming Monday is over, you can expect a more thorough response from me that lays out the concerns we understand you to be raising and the solutions we think could address them.

Update
Hi y'all – below are the key concerns we understand you – volunteers at en.wiki – to be identifying as well as the paths forward we see as feasible.

Can you please let us know what (if anything) the below might be missing and/or misunderstanding?

Concerns

1. Inconsistent on non-discussion pages
   1. As currently implemented, spaces do not appear within the page titles of non-discussion pages. The same is true of discussion pages that include the __NOTALK__ magic word (see listing search).
2. Inconsistent on action/special pages
   1. As currently implemented, spaces do not appear within the page titles of action/special pages. E.g. history, diffs, search-results, etc.
3. Potential confusion
   1. Some people might think they need to write a space when typing a link because of how the page title appears.

Potential paths forward

1. The Editing Team could create a new preference that applies to all namespaces for showing the space after colon. It would default to false if the user had previously disabled DiscussionTools visual enhancements. Otherwise it defaults to true.
2. You all could pass the proposal which would override the space for all users at en.wiki.

Notes
With regard to "Issue 3," we agree this potential exists and we think this change will help. In parallel, we think it's useful to consider that the search suggestions for "User:Bob" and "User : Bob" being different is a pre-existing issue. The question for us then becomes whether we think the space in the heading is going to cause people to write "User: Bob" substantially more than they would have previously.

EDIT: updated language to specify the summary above is scoped to concerns volunteers at en.wiki have raised. Thank you to @Jonesey95 for causing me to realize this would be helpful.

I think that @ppelberg summarizes the concerns well for the English Wikipedia. I can't speak for the other languages that have concerns about colon spacing or non-colon separator characters. Thanks for taking the time to write it up.

A proposed third path forward, detailed in some feedback above, is to make the space appear on all views of all pages, including those mentioned at T432324.

The proposal in "path forward #2" to override the space is a workaround for this task being incomplete. I will be happy to propose undoing it when this task is complete. I proposed it only because the inconsistency is confusing and the rollout was done prior to the task being finished per the scope in the task's title and per any sort of reasonable consistency.

@ppelberg I think, most of Wikipedia users don't want any spaces around the colon, I am indeed not the only one. I told the reasons above. We first should figure out the ratio. So first let's survey across the global wikiverse, if a space is wanted with or without DiscussionTools.

You missed a potential path forward: revert this change which has nothing to do with discussions per se, and let any wiki which wants add their own CSS rule implementing whatever extra space they want before or after the colon. This style feature should not depend on any change to Mediawiki software, and this misfeature was a pointless waste of developer and community time.

T432748: Insert space character after namespace+colon in canonical page names is NOT a duplicate of this bug. It is a completely different approach. This is extremely irresponsible, @Aklapper.

I'm kind of sad how there's so much time spent over such a tiny thing (which I worked on a few years ago). I think it's up to English Wikipedia community to decide if they want to override it for themselves. Personally I think the space is neat and makes the titles more readable.

I don't think we should make any code changes at this time. IMO it'd be best not to change the DiscussionTools formatting, with a CSS space (because it has been like this on other projects for a few years now), and not to change the default MediaWiki formatting, without any spaces, either (because I don't think a CSS space is a great way to change it; there are too many inconsistencies in where it's applied). In other words, I'd close this task.

If anyone tries to make this change again (and I hope it won't be for a few years at least), I'd suggest looking into doing it as suggested in T432748.

@Bugreporter2 You could have simply pointed me to T315893#12128478 which I had missed, instead of going personal and calling me "irresponsible". Please read https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette. Thanks.

In T315893#12148416, @matmarex wrote:

I'm kind of sad how there's so much time spent over such a tiny thing (which I worked on a few years ago). I think it's up to English Wikipedia community to decide if they want to override it for themselves. Personally I think the space is neat and makes the titles more readable.

The opposition isn’t coming just from English Wikipedia, it just got highlighted by the deployment of features by default there. It’s very easy to mischaracterise the opposition as being about ‘change aversion’ when the problem is that DiscussionTools developers imposed a poorly thought out change by their privileged access on a subset of the pages and the action views and now you guys refuse to reconsider its impact or to consult with the community about it.

I'd like to echo @matmarex's view here. While I understand that people have different preferences regarding the spacing, I personally find the spacing introduced by DiscussionTools improves readability. It has already been used on some projects for several years, and I don't see a compelling reason to revisit it now. I also agree that there is little value in making further code changes at this time, either to the existing DiscussionTools formatting or to MediaWiki's default title formatting. Given the amount of discussion this has already generated over such a minor visual detail, I'd support closing this task.

In T315893#12149445, @stjn wrote:

It’s very easy to mischaracterise the opposition as being about ‘change aversion’ when the problem is that DiscussionTools developers imposed a poorly thought out change by their privileged access on a subset of the pages and the action views and now you guys refuse to reconsider its impact or to consult with the community about it.

They clearly engaged and reconsidered. It's just that the reconsideration didn't go your way.

In T315893#12150428, @doctaxon wrote:

I'd like to echo @matmarex's view here. While I understand that people have different preferences regarding the spacing, I personally find the spacing introduced by DiscussionTools improves readability. It has already been used on some projects for several years, and I don't see a compelling reason to revisit it now. I also agree that there is little value in making further code changes at this time, either to the existing DiscussionTools formatting or to MediaWiki's default title formatting. Given the amount of discussion this has already generated over such a minor visual detail, I'd support closing this task.

Keeping it different between page ‘types’ is probably the worst outcome one can imagine from this discussion. Closing this task without either reverting DT spacing or introducing it everywhere is not a solution. There is zero reason why this ‘readability’ option should be on discussion pages but should not be on content pages (a lot of times differing on pages in the same namespace). [I would also note that if the narrative is that everyone is fine with this change globally, it would win a potential vote about it, so it’s weird then to avoid that vote on such a trivial manner!]

Please note that user script prettyPageHeading@PerfektesChaos does provide a solution for that since 2015.

• Between namespace: and page title a visual space is inserted, and around / as well.
• C&P of entire page header does not change anything in spacing.
• Subpage levels of page can be linked independently on individual request.

The concern is that C&P of the page headline and inserting into wikitext will create different formatting, while working.

• All people are expecting namespace:title with no space. Searching within wikitext would not find the location of new link formatting, both in browser textarea and insource: site search.

If introducing visual spacing, which I prefer for both : and /, this must not affect C&P.

The English Wikipedia has decided not to hide this inconsistent spacing while also encouraging the WMF developers to finish this task (and, by extension, T432324). See this discussion. Thanks.

In T315893#12304789, @Jonesey95 wrote:

The English Wikipedia has decided not to hide this inconsistent spacing while also encouraging the WMF developers to finish this task (and, by extension, T432324). See this discussion. Thanks.

The close has been amended to strike the part that said

<s>"I would strongly encourage the WMF folks to prioritize pushing this over the finish line as soon as possible"</s>

The close now only says

"I think there is a valid point being made here which is that leaving this in a half-done state (for whatever value of half you prefer) is a worst case scenario"

which I read as meaning that reversion is an equally valid solution.

In T315893#12304789, @Jonesey95 wrote:

The English Wikipedia has decided not to hide this inconsistent spacing while also encouraging the WMF developers to finish this task (and, by extension, T432324). See this discussion. Thanks.

But there was no discussion of T432748: Insert space character after namespace+colon in canonical page names, which is the real solution to this issue.

Might be related: T432820: [APNT] Fullwidth/halfwidth colons, a subtask of T432814: Umbrella: CJK-related automatic punctuation normalization in title resolution.