What wiki is this? This is due to https://phabricator.wikimedia.org/T125222

You can set the namespace, for example: https://fr.wikipedia.org/wiki/MediaWiki:Templatedata-doc-subpage

Does this resolve your issue?

Hmm, this won't work, I think, since the message seems to specify a subpage, while I'm using a whole new namespace.

See T187007 for background. An example template is on https://www.wikidex.net/wiki/Plantilla:Personaje, documentation in https://www.wikidex.net/wiki/Documentaci%C3%B3n_de_plantilla:Personaje

In T189989#4060889, @Ciencia_Al_Poder wrote:

Hmm, this won't work, I think, since the message seems to specify a subpage, while I'm using a whole new namespace.

See T187007 for background. An example template is on https://www.wikidex.net/wiki/Plantilla:Personaje, documentation in https://www.wikidex.net/wiki/Documentaci%C3%B3n_de_plantilla:Personaje

Ah, I see. So may a config option for a wiki that specifies namespaces, as well, and not just subpages?

Yes, that would work for us.

Change 950794 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Krinkle):

[mediawiki/extensions/TemplateData@master] Load GUI on action=edit if page has templatedata even outside NS_TEMPLATE

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

Change 950794 merged by jenkins-bot:

[mediawiki/extensions/TemplateData@master] Load GUI on action=edit if page has templatedata even outside NS_TEMPLATE

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

That patch is related, but I'm not sure if it resolves this task. Please close it if it's good enough.

On our wiki, I decided it was a good idea to move the documentation template subpages into a new custom namespace, to avoid those subpages appear in link suggestions (Extension:LinkSuggest). However, this […]

The above patch makes the GUI show up for the purpose of edge cases. It provides a "good enough" solution for edge cases, like personal sandboxes, demos, and temporary forks. It's probably not great for your case, as it doesn't offer the GUI when creating new pages.

A similar potential for a bug existed in VisualEditor when it comes to suggesting templates to include. That one uses templatedata-doc-subpage to exclude matching results from NS_TEMPLATE.

Given that the social convention around MediaWiki, as originated on Wikipedia, is to use /doc pages I would generally suggest going along with that. It is not sustainable for the entire ecosystem to support multiple ways to do the same thing. In some cases we need to due to mutually exclusive requirements between important use cases, but I don't see that being the case here. I believe you could transition slowly/gradually, so there's no big barrier there either.

For the original request, I would suggest declining this request.

In T189989#9137913, Krinkle wrote:

Given that the social convention around MediaWiki, as originated on Wikipedia, is to use /doc pages I would generally suggest going along with that. It is not sustainable for the entire ecosystem to support multiple ways to do the same thing. In some cases we need to due to mutually exclusive requirements between important use cases, but I don't see that being the case here. I believe you could transition slowly/gradually, so there's no big barrier there either.

For the original request, I would suggest declining this request.

Thankfully, not everything has to be WMF-centric, and polluting the template namespace with documentation, styles, etc is a no-go for me.

However, I'm not going to fight for this feature when the solution is as simple as this JS snippet in MediaWiki:Common.js:

// Load TemplateData in Template_documentation namespace
if ( mw.config.get('wgCanonicalNamespace') == 'Template_documentation' &&
  mw.loader.getState('ext.templateDataGenerator.editTemplatePage') == 'registered' )
{
  if ( $( '.tdg-editscreen-placeholder' ).length === 0 ) {
    $( '<div class="tdg-editscreen-placeholder">' ).prependTo( '#mw-content-text' );
  }
  mw.loader.load('ext.templateDataGenerator.editTemplatePage');
}

Sharing for anyone interested (subject to breakages on upgrades due to changes in layout or module names).

I'll let the maintainers of the extension the decision about declining this task