robert wrote:

All templates and parser functions (of which ns is) are substituted in signitures to reduce server load. The user talk namespace will *alway* be accessible via User_talk regardless of localisation or configuration. Suggest WONTFIX.

You did not understand the issue. It does not matter, whether or not you can access a NS via its canonical name. One of the points is what is being displayed. You don't want e.g. "User talk" displayed inside a chinese signature link, do you?

If server load is really a concern, and you really are expecting users not to have
enough understanding and awareness to use "subst" where appropriate, then, please,
add a checkbox "do not automatically SUBST templates in signature code", and leave it unchecked by default. This checkbox need be available (and evaluated) ONLY if "signature without automated link" is arelady checkmarked. This should be a pretty small minority of all cases already.

No the issue is understood perfectly.

It's not a issue of users not understanding where to subst. Its that any use of templates inside of a Signature causes each and every page that the user signs to be added to the job que each and every time the template is edited.

Adding a checkbox and saying "please don't subst where inappropriate" isn't going to solve the issue, because substing anywhere at all is the core issue with server load, and allowing users' to chose to not subst just removes the entire point of autosubsting to prevent server load.

Apparently you did not understand the issue.

It's *not* about templates in the first place, it is about *constants*
like {{NS:x}} or {{PAGENAME}} etc., at least these are the problem.
They do *not* place anything in the job queue, since they are not
edited by anyone.

Adding a checkbox and saying "please don't subst where inappropriate" is
going to solve the issue.

Users can and will always add whatever they need (or want) manually, they
can subst a userspace page, to save typing, or do something else instead
of signing, when signing ~~~~ does not produce the desired result.
So forcing an automated subst where it is inappropriate will only make
users lifes a little harder. Odds are, that they will hate programmers
for it ;-)
So not solving this problem is not going to solve any problems. :-)

Btw. instances of signatures where subst is inappropriate should imho
be pretty rare, see above.

That checkbox may allow users to not subst constants. But it also allows them to bypass a core bit of code added for performance related to templates.

Users have a common tendency to want to transclude things rather than subst. And even though it harms the server, they'll do it even if you tell them not to.

So a checkbox will *not* be accepted as it allows users to bypass the performance security against what the sysadmin of the site has set to keep good performance of their wiki.

Now, give out a patch that will let the system differentiate between a constant and a template, and it may actually be accepted. But anything which allows users to bypass sysadmin settings and lower performance won't be accepted.
If Wikimedia were to enable the checkbox on it's wiki, you know users will start bypassing that performance security.

Are you aware that there is no point at all denying users the
ability to not use subst in their signatures?

Are you aware that users, who do not get what they need out of
~~~~, will simply type something else?

Are you aware that users can and will use any wikitext then,
be it with, or without subst?

So what the hell is keeping you from accepting a RARE special
case for those who most likely understand it? If the suggested
checkbox is not displayed unless someone disables auto-linking
their signatures, the vast majority of (uneducated) users will
never see it, leave alone checkmarking it.

I understand the grievance against template calls not subst'ed
and being inserted in lots of talk pages semiautomatically,
especially by "power users" who are likely to both use the
"don't subst" feature, and sign lots of contributions. The
implied risk of a huge job queue, which btw., most likely
would be of little use for the wikis original intent, is
imho indebatable.

So I also understand the suggestion to make a distinction between
those {{'s signalling a constant, etc., and those ones of
something with the potential to fill the job queue.
I understand that likely noone might be interested in coding
it for me. Currently, I don't know how to make it, but I can
certainly find out.

How about generally not subst'ing constants? That avoids the
complication of adding a checkbox, but users likely would
rarely type {{subst:some-constant}}, as you said, so this
is also a performance drawback during page rendering,
is it not?

If you don't mind, I reopen this bug and take care of developing
a patch.

"([[User {{NS:1}}:myname]])" is so wrong. Why don't you use [[User talk:yourname|{{ns:user talk}}:yourname]]?

Let's avoid a fight about exactly what sig format would be ideal. :)

I'm clarifying the summary for what's requested here. Please limit further comments to implementation details of how this might be accomplished (eg, whitelist or configuration marker or...)