Change 825418 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] [POC] Typographically correct language-specific namespace separator

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

Example on jawiki:
before

frwiki:
before

The only regression is the selection highlight doesn't include the space. This could be fixed with some JS (swapping out the content on a copy event):

In T315893#8184981, @Esanders wrote:

The only regression is the selection highlight doesn't include the space. This could be fixed with some JS (swapping out the content on a copy event):

Another issue with the CSS approach is that it breaks triple-click to select the whole heading in Chrome (works fine in Firefox).

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/be55d10977/w

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

[mediawiki/core@master] Alternative CSS approach to make triple click and highlighting work

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

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/a8aade8d69/w

Change 901688 abandoned by Esanders:

[mediawiki/core@master] Alternative CSS approach to make triple click and highlighting work

Reason:

squashed into parent

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

DISPLAYTITLE changes should be tested in any implementation of this.

In T315893#8906927, @stjn wrote:

DISPLAYTITLE changes should be tested in any implementation of this.

Per T306440:

The new markup is not added when the title is overridden using the wikitext {{DISPLAYTITLE:…}} or -{T|…}- forms. This may be improved in the future.

The parsing team can better speak to why these two cases are complex to support, but part of it is that is that DISPLAYTITLE allows HTML spanning the namespace and title.

I don't think this is a good idea. Titles are not normally typed with a space between the colon and the title, so I think displaying it with a space between the colon and the title could be confusing.

This also adds unnecessary complexity, both to code, and to the elegant system we currently have where what you see corresponds 1:1 with the proper title.

In fact, I'd recommend rolling back this change that is currently live in the talk namespace on mobile.

Related: T338151: Unexpected space between namespace and talk page title on pages in mobile subdomain

@Novem_Linguae Hypothetically, if the "proper" title was also changed to include a space (e.g. if the canonical URL was https://en.wikipedia.org/wiki/Talk:_Drew_Doughty, if mw.config.get('wgPageName') returned 'Talk:_Drew_Doughty', and so on), would you consider that a better approach?

Change the output of mw.config.get('wgPageName')? That's a massive change that would break all sorts of user scripts and gadgets. I would definitely not be in support of that.

Think of all the if ( mw.config.get('wgPageName') === myString ) type code that would need to be rewritten.

In T315893#8912017, @Novem_Linguae wrote:

I don't think this is a good idea. Titles are not normally typed with a space between the colon and the title, so I think displaying it with a space between the colon and the title could be confusing.

This also adds unnecessary complexity, both to code, and to the elegant system we currently have where what you see corresponds 1:1 with the proper title.

I think with this kind of change, it is mostly a ‘deploy and then see if anyone objects on solid grounds’ approach. If the page title code is still Talk:Cat, there’s nothing that makes a stylistic change to how title gets displayed wrong. And, to be honest, I’ve always found the style we are currently having a bit too technical. It is true that the title should still match the URL, but it does in the proposed change. This is what matters. If that were to change (like, if some browsers copied CSS content), we would need to consider not doing this.

In T315893#8912096, @matmarex wrote:

@Novem_Linguae Hypothetically, if the "proper" title was also changed to include a space (e.g. if the canonical URL was https://en.wikipedia.org/wiki/Talk:_Drew_Doughty, if mw.config.get('wgPageName') returned 'Talk:_Drew_Doughty', and so on), would you consider that a better approach?

This would significantly complicate i18n. frwiki would have to have Discussion_:_Drew_Doughty, jawiki ノート：メインページ and so on. If it could not be expected that all page names (except in mainspace) are prefixed with the namespace name + :, it would be such a disruptive change.

And if it only differed in the top heading, everybody would start imitating it elsewhere (because people hate inconsistencies), increasing the gap between internal and aesthetic names.

Titles are not normally typed with a space between the colon and the title, so I think displaying it with a space between the colon and the title could be confusing.

The spaces are generated with CSS so not copy/pasted, and anywhere the user types a space it is stripped by the software. I don't think we have had any other negative feedback about this feature as deployed on talk pages, so it seems very unlikely it will cause cause widespread confusion at this point.

This would be such a breaking change I can't believe the casualness with which you're discussing it. Once you add the space people are going to imitate in writing because people hate inconsistency. They would hate it if it said "Wikipedia: Sandbox" in the heading but "Wikipedia:Sandbox" in the rest of the interface (watchlist, contributions, notifications, etc.), and they would start writing it with the space in wikitext. And so much of the MediaWiki ecosystem already assumes a page name with a prefix consists of "prefix + : + title", even for French, CJK, and RTL scripts. This is not something up to WMF, let alone one team. It deserves an RFC on Meta at minimum.

For the record, imitating space in text is not a problem: [[Wikipedia: Ignore all rules]] already gets linked to a page without a space even if you write it that way.

That's not the point. If this ever came to pass, everybody would start writing [[Wikipedia: Ignore all rules]] instead of [[Wikipedia:Ignore all rules]] and it would be a matter of time they would be demanding the interface follow suit (if not the reversal of the change). So any part of interface displaying the name of a page would have to be modified to mirror the heading, and scripts would no longer be able to assume e.g. the text of a .mw-changeslist-title matches the internal name of the linked page. The effects the change would have are so wide-reaching it should never come down to a decision by a handful of people.

I agree to @Nardog s comment above and I am not convinced that we really need this separator style, Nardog has explained his reason, and this is my reason too.

Please explain me, why do you want such a separator and why it's important to have this.

So far the talk page version of this is enabled by default on 3 wikis, and enabled by tens of thousands more as a beta feature, with no such issues reported to date. As the talk page deployments progress we will continue to monitor for such issues.

Furthermore, the change is implemented with CSS, so communities can override the separator site-wide, or disable it fully should they wish.

At least in German, not using a space after the colon is a spelling mistake, so in principle I would welcome such a change (for all page titles in all non-0 namespaces). The same would go for subpages, where in many instances there would be spaces needed before and after the slash. However, it is unclear whether we really need to enforce spelling rules on page titles outside the main namespace.

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

Any reference to a page that does not match what the top heading looks like on the page itself is going to be perceived as a mistake. If communities can override it then it shouldn't be imposed on them in the first place, because they didn't ask for it.

In T315893#9108838, @Nardog wrote:

Any reference to a page that does not match what the top heading looks like on the page itself is going to be perceived as a mistake. If communities can override it then it shouldn't be imposed on them in the first place, because they didn't ask for it.

Yes, I fully agree with this.

Where is the discussion, done before this change, where communities had the possibilities or the opportunities to agree or disagree with this.

In T315893#9108778, @doctaxon wrote:

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

Text that is presented to our readers necessarily needs to comply with spelling and typography rules. So imo it makes a lot of sense to differentiate between what is used internally (URL etc.) and what is displayed to everyone. I have long proposed a similar thing for subpages; however, in that case it is more complex, as the slash needs to be distinguished from the title itself first.

In T315893#9108778, @doctaxon wrote:

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

Text that is presented to our readers necessarily needs to comply with spelling and typography rules. So imo it makes a lot of sense to differentiate between what is used internally (URL etc.) and what is displayed to everyone. I have long proposed a similar thing for subpages; however, in that case it is more complex, as the slash needs to be distinguished from the title itself first.

In T315893#9108853, @doctaxon wrote:

Where is the discussion, done before this change, where communities had the possibilities or the opportunities to agree or disagree with this.

@doctaxon: Offtopic, see https://www.mediawiki.org/wiki/Bug_management/Development_prioritization#Why_wasn't_I_consulted_about_these_changes%3f

In T315893#9108902, @XanonymusX wrote:

In T315893#9108778, @doctaxon wrote:

This has nothing to do with German spelling but with namespace separation. So the blank style is a programming language spelling mistake. I never saw this spelling within any other programming using namespaces.

Text that is presented to our readers necessarily needs to comply with spelling and typography rules. So imo it makes a lot of sense to differentiate between what is used internally (URL etc.) and what is displayed to everyone. I have long proposed a similar thing for subpages; however, in that case it is more complex, as the slash needs to be distinguished from the title itself first.

No, I disagree but you are wrong too. The words within the page title name indeed should be spelt orthographically. But the colon is not an orthographically colon but a namespace separator within the title database item, and with this it's programming language but not German language with its orthography. In spite of this the page name title is written in the URL without blank or separator, too. Why do we need such differences.

In T315893#9108949, @Aklapper wrote:

In T315893#9108853, @doctaxon wrote:

Where is the discussion, done before this change, where communities had the possibilities or the opportunities to agree or disagree with this.

@doctaxon: Offtopic, see https://www.mediawiki.org/wiki/Bug_management/Development_prioritization#Why_wasn't_I_consulted_about_these_changes%3f

The Bug management pages' subject is about bugs, but not about software changes which has nothing to do with any bugs.

In T315893#9108971, @doctaxon wrote:

No, I disagree but you are wrong too. The words within the page title name indeed should be spelt orthographically. But the colon is not an orthographically colon but a namespace separator within the title database item, and with this it's programming language but not German language with its orthography. In spite of this the page name title is written in the URL without blank or separator, too. Why do we need such differences.

As I said, once it is presented prominently to our readers, text needs to comply with spelling rules. Most readers are completely unaware of namespaces. It would never be acceptable to have such a technical use of punctuation in page titles in ns-0; in other namespaces it is less dramatic, but still not great. Another idea I had in mind for quite some time would be to distinguish the namespace through a different colour (something grey, I guess) or font. The way it used to be written is definitely not what should be aimed for in the long run …

In T315893#9109017, @XanonymusX wrote:

In T315893#9108971, @doctaxon wrote:

No, I disagree but you are wrong too. The words within the page title name indeed should be spelt orthographically. But the colon is not an orthographically colon but a namespace separator within the title database item, and with this it's programming language but not German language with its orthography. In spite of this the page name title is written in the URL without blank or separator, too. Why do we need such differences.

As I said, once it is presented prominently to our readers, text needs to comply with spelling rules. Most readers are completely unaware of namespaces. It would never be acceptable to have such a technical use of punctuation in page titles in ns-0; in other namespaces it is less dramatic, but still not great. Another idea I had in mind for quite some time would be to distinguish the namespace through a different colour (something grey, I guess) or font. The way it used to be written is definitely not what should be aimed for in the long run …

Namespace 0 is not the point of this discussion, we discuss namespaces > 0

In T315893#9108973, @doctaxon wrote:

The Bug management pages' subject is about bugs, but not about software changes

@dotaxon: Wrong.

It is crucial that there is a visual spacing, but not a space character, if any.

• That means: As soon a page headline or any other displayed element is taken by C&P, no space character is inserted and may pollute wikitext by insertion, making search for strings and replacement of page names more difficult (it is legal yet, and there may be _ rather than space or lowercase letters).

For many people, separation of page name elements make semantic elements more readable.

• Visual separation of namespace+: and subpage hierarchy by / is considered helpful by many who are not wiki insiders over decades.
• Separation of page name components should offer may-break-here hints after : and / on long lines, rather between two words of a component.

A project wide feature to display all page headlines where subpages are enabled would be fine with me.

In T315893#9109221, @PerfektesChaos wrote:

It is crucial that there is a visual spacing, but not a space character, if any.

• That means: As soon a page headline or any other displayed element is taken by C&P, no space character is inserted and may pollute wikitext by insertion, making search for strings and replacement of page names more difficult (it is legal yet, and there may be _ rather than space or lowercase letters).

For many people, separation of page name elements make semantic elements more readable.

• Visual separation of namespace+: and subpage hierarchy by / is considered helpful by many who are not wiki insiders over decades.
• Separation of page name components should offer may-break-here hints after : and / on long lines, rather between two words of a component.

A project wide feature to display all page headlines where subpages are enabled would be fine with me.

Again, so long as the giant title at the top of a page is shown with particular styling, people are going to perceive any representation of the page name that doesn't have the same styling as erroneous. In fact people already overwhelmingly write page names with in place of _ even though the underscore is technically part of the internal names.

So it's a matter of time they will start writing page names with a space after the colon after the namespace prefix, and this mere CSS trick will end up, as you point out, "making search for strings and replacement of page names more difficult".

Another important thing to consider is that conventions vary across languages. If you really want to stick to orthography, then it wouldn't be fair if you didn't also accommodate French, Japanese, etc. where they write : , ： rather than : . Except on jawp they prefer the English style if the preceding text is Latin characters, which some NS prefixes are. So if you're going to do this at all, you should allow different punctuation for different namespaces. Some orthgraphies may not use colons at all. And you're going to have to account for all this in all relevant parts of the software. "A can of worms" wouldn't even begin to describe it.

I would like to re-iterate that personally, I do not see this as ‘the end of the world’ deal. Existing editors will not start writing titles that way from this being a feature, many editors copy their titles and that would continue to work the same, and if some editors will start writing title this way, this is absolutely not a big deal.

I'm missing this colon space in discussion page histories like https://de.wikipedia.org/w/index.php?title=Diskussion:DocMorris&action=history

In T315893#9115270, @doctaxon wrote:

I'm missing this colon space in discussion page histories like https://de.wikipedia.org/w/index.php?title=Diskussion:DocMorris&action=history

I don't think it's been rolled out to action=history yet.

action=history winds up using a completely different path to generating the title ($this->msg( 'history-title', $this->getTitle()->getPrefixedText() )->text()) which would only get converted to this new markup if we changed the output of Title's methods to actually include a space character. The change as-written will only apply to pages that generate their title using Parser::formatPageTitle.

In T315893#9118084, @DLynch wrote:

action=history winds up using a completely different path to generating the title

See also:
https://en.wikipedia.org/w/index.php?title=IPhone&action=history
vs
https://en.wikipedia.org/wiki/IPhone

Note that in @Esanders' example, the history page is also missing the DISPLAYTITLE changes (thus "IPhone").

In T315893#9118097, @Esanders wrote:

In T315893#9118084, @DLynch wrote:

action=history winds up using a completely different path to generating the title

See also:
https://en.wikipedia.org/w/index.php?title=IPhone&action=history
vs
https://en.wikipedia.org/wiki/IPhone

but: ( https://en.wikipedia.org/wiki/Talk:IPhone ) both vs Talk:iPhone (without separator), sure because of DISPLAYTITLE

If it's so very important to have a dumb separator margin which nobody was really missing before, we should work on a consistent solution: either for all page titles, action and special pages consistently or for no page at all consistently.

There were always some inconsistencies and strange things.

• iPhone on page headline but IPhone in category or other page list and search results.
• IPhone as title of revision history.
• _ and %XY in URL page names.

We should try to make such strange things like subpage names in namespace more readable and comprehensive by inserting some visual structure wherever possible.

• We cannot refrain from improving 99 % of the cases if there are some 1 % left where current solutions are too difficult. Perhaps one day iPhone is shown in categories and page history as well. Anyway, the page headline is displayed correctly right now.

The Title functions must not insert any space character.

• Every adapted presentation shall be created by CSS only.
• C&P shall yield the generic name as today.

BTW, hopefully people discovered C&P functionality and will not type letter by letter someWikipedia talk:Manual of Style/Accessibility/Alternative text for images

• However, if they type an extra space after : universe will survive.

Change 825418 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] Typographically correct language-specific namespace separator

Reason:

Not working on this currently

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

I don't see Diff pages mentioned here. This page is missing the spacing between the namespace and the title:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&curid=3252662&diff=1298003401&oldid=1297993417

The corresponding page in regular (non-Diff) view has the spacing:

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)

Please make this spacing consistent on all pages that use the Namespace:Pagename format at the top of the page.

DiscussionTools's customized page titles follow the same rules as {{DISPLAYTITLE:}}, which is only supported on normal page views, but not in diffs, while editing, in page histories, etc. (see T72275 and T26139).

Having an actual space character is not important, but you really need to put in a <wbr> opportunity in case the page name is really loooooooooooooong.

I've noticed this on nowiki talk pages for a few weeks, at least, and I thought it was a graphical bug, as it is inconsistent with other non-main namespace page types. (Only seeing it on talk pages and other pages functioning like talk pages.)

I think it would be wise to make this visual change opt-in based on consensus, rather than opt-out for individual projects. :S

Now that this feature is halfway rolled out and the sky has not fallen, it's time to finish the job and make this spacing consistent. As it stands right now, the spacing is different from page to page, and from page view to page view, with no apparent logic. The spacing should be added to every page view where a page title with a colon is shown.

Examples:

• Wikipedia:Requests for comment (normal page view; spacing is present)
• Wikipedia:Requests for comment (section edit view; spacing is present)
• Wikipedia:Requests for comment (history view; spacing is not present, but there is a real space after the colon before "Revision history")
• Wikipedia:Requests for comment (diff view; spacing is not present, but there is a real space before "Difference ...")
• Wikipedia:Requests for comment/Apteva (normal page view; spacing is NOT present, even though it is a subpage of the above page)
• Wikipedia:Requests_for_comment/April_Fools' (normal page view; spacing is present, even though it is a subpage of the same page as /Apteva)
• Wikipedia:Arbitration Committee (normal page view; spacing is NOT present, even though it is the same namespace as the above pages)
• User:ClueBot (normal page view; spacing is NOT present)
• User:ClueBot/FalsePositives (normal page view; spacing is present, even though it is a subpage of the above page)

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.

Edited to add: Some or all of the above descriptions may apply only with the Discussion Tools feature enabled. Nevertheless, there are inconsistencies that need to be addressed one way or the other.

Would recommend reverting to no space everywhere. 1) It was fine that way for many decades. 2) Adding a space in some places (displayed page title) and not others (mw.config.get('wgPageName'), search results) introduces unnecessary complexity / inconsistencies / technical debt. It's likely to result in people writing it both the old way and the new way forever, which is confusing. Right now everyone writes it (e.g. creating wikilinks on talk pages, creating wikilinks in projectspace, etc.) without a space and this is simple and elegant and consistent.

In T315893#11530676, @Novem_Linguae wrote:

Would recommend reverting to no space everywhere. 1) It was fine that way for many decades. 2) Adding a space in some places (displayed page title) and not others (mw.config.get('wgPageName')) introduces unnecessary complexity / inconsistencies / technical debt. It's likely to result in people writing it both the old way and the new way forever, which is confusing. Right now everyone writes it (e.g. creating wikilinks on talk pages, creating wikilinks in projectspace, etc.) without a space and this is simple and elegant and consistent.

I agree 100% with this if and only if the WMF development team is not committed to finishing this task by making the spacing consistent at the top of every page view. PLEASE do not leave this partly done, as has been done with so many projects (e.g. Visual Editor, Vector 2022, etc.). This one at least should be easy to undo if that is necessary.

Adding my voice to this also. I'm not a fan of this mismatch style. I'm trying to figure out (unsuccessfully) why Wikipedia:Requests for comment has a space when it doesn't seem to have discussion tool features like Wikipedia:Requests for comment/April Fools' has. This shouldn't be so difficult and yet it is. So either apply the same logic everywhere or just revert. In this current state, this is worse than it was before.

I also agree to @Novem_Linguae and @Gonnym repeating their arguments. With these we should revert the space display.

Why? Where can I read the reasoning behind adding this whitespace? What purpose does this (currently... forever?) half-baked change serve other than introducing inconsistency? I also strongly recommend reverting back to without spaces.

Why? Where can I read the reasoning behind adding this whitespace?

Rules of English grammar are clear in that a colon is followed by a space. Because we have been doing it wrong until now seems like a poor reason to keep doing it wrong.

We didn't do it wrong, because it's not a grammar case. We're talking about lemmas, short topic terms, not about sentences or parts of them which should be grammatically correct. We're talking about page titles as database values with prepended namespace titles, both parted by a colon.

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.