Last modified: 2014-11-04 22:53:07 UTC
Some templates are only used to save keystrokes (http://en.wikipedia.org/wiki/Template:User is a good example) or are otherwise . Rather than force the servers to go through all the hoopla in keeping cached copies up to date, etc., or trying to discourage users from making such templates (pointless) allow templates to be marked as substitute-only, the way signatures are handled now. Doing this through an edit would be best, so some sort of marker (<!--subst-->, for example) that tells the server to just subst: the included template even if subst: is not explicitly used.
I think this could be quite useful also for templates that should always be used with subst for other reasons. Examples are broiler-plate notifications to users (those messages should not change over time) and deletion requests that contain a link to a subpage by day (as is the case on the german wp for example). There is constant trouble with people forgetting the subst: part. This feature could solve that. As for the marker, I would suggest __SUBST__, to be consistent with other meta-markers used in mediawiki (like __NOTOC__ and such).
This is an amazingly good idea. I see TONS of potential uses for this. Currently, our only option is for a bot to run through pages using these sorts of templates and replace them with subst: calls - a task which is done almost never.
changed bug summary to be more descriptive
As a user I also would be grateful if this feature were implemented
The setting of such a flag is impossible/hard to undo. What I think we need is to _not parse_ anything in the template namespace. Then I could make a template vfd_ and a template vfd with as only code {{subst:vfd_}}. Then using {{vfd}} would result in substitution of {{vfd_}} always. It would also make it possible to use the dates in templates, simply by using {{subst:DAY}}, which because of not parsing would end up in the article if this template was substituted there.
The setting of such a flag is trivial to undo: remove the __SUBST__. I'm not sure what the problem is—of course you cannot undo setting that flag ''retroactively'', but that is impossible ''no matter what'' solution you come up with for forcing substitution. The whole idea behind substitution is that you don't keep track of changes to the original. Likewise, the inclusion code for that is very easy: instead of putting in the template contents, you first scan for __SUBST__ (you'll have to read the contents anyway), and if you find it, simply turn on substitution as if subst: had been used in the link. This is a simple enhancement to the input layer. Your suggestion is far more drastical, and is very likely to break existing templates.
*** Bug 2476 has been marked as a duplicate of this bug. ***
Strongly support this. We're presently working on a bot that would automatically subst certain templates, but putting it in software would be better.
I also strongly support this. If we need to have a way to override forced substitution, we can have something like {{transclude:pagename}}. So, {{pagename}} by default transcludes, alternatively substitutes if __SUBST__ is found, {{subst:pagename}} always substitutes and {{transclude:pagename}} always transcludes.
bug 2777: request for a {{substall:foo}} beside {{subst:bar}} is a request about substitution to be done at all levels of nested templates. It is a nice to have which saves would save time because as evetery level would equire a save in orther that "subst" would take effect. The syntax discussed here should still ofer a way to implement "substall".
This is indeed a very important feature - frankly, teh template namespace is kind of getting out of control with stuff that has no reason not to be substed - I've increasingly seen templates that are just article text that people want in multiple articles that are being done with straight template usage - and often with meta-templates. This is both a server load problem and a new user problem - templates are not intuitively editable. The ability to force substitution of a template would provide a solution to these problems that does not depend on tedious debate to get people to realize that they're being dense.
I'm not sure how a __SUBST__ flag would ever decrease the amount of debate necessary - we can already have debates about whether to add "<noinclude>please always use subst: for this</noinclude>", and we'll still need debates about whether to use "__SUBST__". I guess it might cut down the number of people saying "well, *why* should I always use subst:?", but they'll still want to know "*why* does it contain __SUBST__" (quite apart from those who will be just plain surprised that it works at all). Nor can I see how putting text in multiple articles would ever have anything to do with this: if they wanted a subst, they'd already be using one - or just using copy-and-paste, which is all "subst" is, really. All that being said, I do see that this could be a useful feature, simply as an "idiot-proofing" flag for templates that should be being used this way already. We'd have to make sure the flag was *only* read during the "pre-save transform" stage, else a vandal could cause a whole host of pages to be changed on next view. Even then, there's the potential for someone to, say, replace a stub template with "This article sucks!!! __SUBST__", and watch as everyone else inadvertently vandalises articles by editting them and substing in that text, but I guess that would be easy enough for an expert-ish user to spot.
I would suggest that rather than being a wikitext setting like __TOC__, this be a database flag settable by checkbox/special page/whatever (or it could just be an array, take your pick). Ability to set the flag could be restricted by usergroup, such as to admins in Wikipedia's case, and furthermore it would be much faster to check for when doing a page save (at least naïvely; of course, the __SUBST__ flag could be implemented as actually setting a database flag).
Due to possible abuse, I (like Simetrical) would suggest that only a certain user group (admin sounds good as default) could set a template to be substituted by default -- a flag or mode sort of like page protection, semi-protection, and cascade protection... I wrote a bit about it at http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=105666294#Forcing_template_substitution It would need to be applied by a admin (a trusted editor, I hope), not just any person, to limit possible edit wars. There might need to be an inverse to "subst", something like "trans", to enable transclusion when needed. This is a good idea, I think; it could go in a lot of directions.
I don't think this is a good idea at all. There is {{x}} and {{subst:x}} and who cares knows about it and does not want to get confused by different behaviour. There would be no way to tell quickly off-hand whether a template would be substituted or not. The only way I can think of to make this work in a less disturbing way would be to re-introduce {{msg:x}} for transclusion, leaving {{subst:x}} for substitution and {{x}} for whatever a __SUBST__ or other marker in the template indicates with a default for possibly transclusion. Then, on an edit, {{x}} would be changed to either {{msg:x}} or the template text, so that {{x}} would just be a shorthand to a default and never be stored as "{{x}}" itself. However in my opinion it is less troublesome to have users learn the proper use of templates.
I just independently came up with this proposed enhancement myself, and I thought the __SUBST__ marker (good proposal, that) should only change the default; templates can then still be transcluded with {{msg:x}} / substituted with {{subst:x}}, overriding the default (of course, another option might be to prohibit the overrides at the admin level). A workaround for the vandalism problem, apart from access control, might be to replace all {{x}} by either {{msg:x}} or {{subst:x}} when an article is saved, thus overriding the default and making the article impervious to a change of the default. The downside is that this may make the wiki source a little dense with all those msg: and subst: flags.
I think that this is a great idea also. While I know that some think it is better to train someone, I've learned that the workload at the Wikis is staggering when you think about it, and people tend to do things they want to do. Figuring out templates and following regulations are usually not at the top of the list of the kind of user who would use a template to add text an article's mainspace. I would have to problem with this feature being restricted to admins, and I think the __SUBST__ idea would work nicely.
There are huge issues with this, at least on en.wp. Last time I generated a list, I had over 50,000 pages that were improperly transcluding one supposed-to-be-subst:'ed template. If the template ever changes (rare but possible), the Wikimedia servers will probably go bonkers. I'm doing what I can in AWB, but it's slow; 50,000 pages could take several months at the edit rates I can maintain. Simply adding a __SUBST__ or (I think this is better) __FORCESUBST__ marker would be good. Making it a checkbox on the edit page accessible only to a certain (configurable) level of user would be OK. The only thing is, it wouldn't fix the huge unsubsted backlogs; they'd have to wait until the page was next edited, and then it would look funny to the user making the edit ("I didn't subst: that. What's going on?"). It would prevent future additions to that monolithic list, though.
This would be tremendously useful.
How can we prevent this from being used for vandalism: forcing a mildly popular, but not large use template to substitue could be extremely annoying and would have to be reverted on every page, especially if the template is changed at the same time (e.g. to obscenities or hate speech). I don't think such an option, if it is added, should be enabled on any mediawiki project ever.
(In reply to comment #20) > How can we prevent this from being used for vandalism: forcing a mildly > popular, but not large use template to substitue could be extremely annoying > and would have to be reverted on every page, especially if the template is > changed at the same time (e.g. to obscenities or hate speech). I don't think > such an option, if it is added, should be enabled on any mediawiki project > ever. > It is possible that the feature could be used for vandalism, but a vandal who edits a template and then includes it on a lot of pages where it isn't supposed to be used would have to be reverted on each page anyway. There's not really much change except the text that would have to be reverted ({{template}} versus ''wikicode'' [[markup]]).
(In reply to comment #21) > (In reply to comment #20) > > How can we prevent this from being used for vandalism: forcing a mildly > > It is possible that the feature could be used for vandalism, but a vandal who > edits a template and then includes it on a lot of pages where it isn't supposed > to be used would have to be reverted on each page anyway. There's not really > much change except the text that would have to be reverted ({{template}} versus > ''wikicode'' [[markup]]). I think you missed carrick's point. What would happen if the keyword was added to a template that was already used on many pages? If all the pages using the template were automatically substed, then reverting the template would not fix all the pages. If the pages were not automatically substed, then we'd have an inconsistency where pages are using a template that is supposed to be subst-only.
(In reply to comment #22) > I think you missed carrick's point. What would happen if the keyword was added > to a template that was already used on many pages? If all the pages using the > template were automatically substed, then reverting the template would not fix > all the pages. If the pages were not automatically substed, then we'd have an > inconsistency where pages are using a template that is supposed to be > subst-only. > Perhaps it shouldn't be a wikicode marker, then. Maybe another action like 'protect' or 'delete' that can be restricted by user group. A simple checkbox on the edit page would probably do it. That is, if( userCan( 'marksubstonly' ) ) { echo $checkbox; } Or something along those lines. Thoughts?
As I said in comment 13 more than eighteen months ago, this should be restricted by usergroup. I will now go further and say that this will almost definitely not be implemented without restriction by usergroup, barring some clever way to retroactively reverse the change (unlikely). There are other issues with this. Currently there should be no way for any article's saved text to contain the text {{subst:templatename}} (there are a couple of obscure ones, but those are bugs). This necessarily creates a way for that situation to arise. This means that if I set Template:Template to subst automatically, and it's already used in some pages, the next person to edit the page will appear to have replaced the template call with a whole bunch of literal wikitext, and it won't be clear whether it was done automatically (without the user's knowledge!) or manually. If the template contained vandalism for whatever reason, the user would appear to be a vandal. Even if you avoid this by having a dedicated pseudo-user that will insert a revision substituting the template before the edit, say -- if so, this would be the *only* such pseudo-user to edit a large number of pages, which essentially introduces a new concept to most editors and might be confusing -- templates that must be substed but aren't are still in a kind of limbo. What happens to them if the master template changes? Logically their value should be fixed as of the time the subst-only flag is added, but how will that work? What if the revision as of the time the subst-only flag was added later got deleted, or even oversighted? Do you do all the substitutions immediately when the flag is added? You can't; it needs to be put on the job queue, which means the problem remains. Do you store the text to substitute in the job? Then say the revision needs to be oversighted (possibly due to a rogue admin, or an admin tricked by a clever vandal). You'll have a stream of pages over the course of hours having the oversight-required text being added to them, with no central record of where it's being added, and no way to stop it short of getting someone with database access to manually figure out which jobs are which and delete the appropriate ones. Substing to the current revision, as of whenever the job gets around to it, is probably the only feasible solution, but it creates issues too. Presumably the interface will indicate that editing the template will not affect existing pages, but that will be false while jobs are pending. You could have a different message displayed while it's still included in some pages, which could be checked using templatelinks. Also, what happens if the entire template is deleted while jobs are pending? Probably then you want to leave the template call alone -- the job would have to check this before substing. Even if all the above is handled, the previous revisions of the page will still contain calls to the template, which is invalid. This is probably not a problem, since you could just treat them as you would in a preview, showing the current value of the template, which is what they meant to do anyway (since they originally transcluded instead of substing). There may be other issues as well. Tim is probably the one to ask about this.
I have to admit I had not remembered originally that a page must be edited in any case for substitution to occur, but I think the point still stand, and the inability to track substitution will combine with the issue should this be implemented... has a substitution log ever been suggested?
Why not just have a tag <nosubst> whose content is removed by subst:, so it is only displayed if the template is transcluded? (a functionality somewhat similar to <noinclude> and <includeonly>) This way, you can display a big ugly warning to the user who misses the subst:, add the page to a special category or whatever you want. Much less intrusive than the other proposed changes.
(In reply to comment #26) > Why not just have a tag <nosubst> whose content is removed by subst:, so it is > only displayed if the template is transcluded? (a functionality somewhat > similar to <noinclude> and <includeonly>) > > This way, you can display a big ugly warning to the user who misses the subst:, > add the page to a special category or whatever you want. Much less intrusive > than the other proposed changes. > Dude, you rock! Why didn't I think of that?
That's bug 4484. This is a different request.
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > How can we prevent this from being used for vandalism: forcing a mildly > > > > It is possible that the feature could be used for vandalism, but a vandal who > > edits a template and then includes it on a lot of pages where it isn't supposed > > to be used would have to be reverted on each page anyway. There's not really > > much change except the text that would have to be reverted ({{template}} versus > > ''wikicode'' [[markup]]). > I think you missed carrick's point. What would happen if the keyword was added > to a template that was already used on many pages? If all the pages using the > template were automatically substed, then reverting the template would not fix > all the pages. If the pages were not automatically substed, then we'd have an > inconsistency where pages are using a template that is supposed to be > subst-only. This is where the admin, or approved user, restriction comes in. This is a common and established method for a boadload of scripts and templates already. It would be easy to implement here as well.
I have written an extension to do this: http://www.mediawiki.org/wiki/Extension:SubstControl It works using two MediaWiki: namespace pages to list templates that should always and should never be substituted, therefore only sysops (by default) can specify which templates should be affected. I have no idea if it stable enough for the likes of Wikipedia though.
