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