This page explains that when you edit the TemplateData code, "If you have made errors, it will not let you save." How can this edit, which broke the TemplateData code, be explained then?
https://en.wikipedia.org/w/index.php?title=Template:Infobox_university/doc&diff=next&oldid=879525244
Can someone please clarify this documentation?
Simple. Hacky unexpected usage results in unexpected behaviour and breakage.
Someone made an error, and the page was saved with the error, which appears to contradict the statement I quoted above. I believe that this page's documentation should be clarified.
Judging by the tags on the edit, they edited raw wikitext of the page rather than using the specialized TemplateData editing tool. Thus their edit wasn't subject to its scrunity.
Thank you for the actual helpful answer! I have updated the page to reflect the difference between using the tool and using a wikitext editor.
That's the wrong answer. The hacky transclusion means that what's in the page is actually irrelevant. In fact the page content might have changed without any edit to the page.
That's clearly documented mediawiki behavior.
IP editor: Your explanation does not make sense to me. In the edit I linked above, an editor replaced the word "description" in the TemplateData code with the word "descriptiwon", which presumably caused the TemplateData error. I don't see any evidence of a "hacky transclusion" in that edit, but I might be missing something. If you have a better explanation that answers my original question, feel free to edit this Help page to clarify it. Thanks.
Err... The expected use of this extension is directly embedding the templatedata tag to the page. All templates or lua modules that override that behaviour are clear hacks(https://phabricator.wikimedia.org/T124338). Also you're wrong about the change, template transclusions were also added.
Perhaps you have an incomplete understanding of how templates work. Templates are entirely free to fully ignore all parameters used to call it. Or to parse them differently and output something different from the input.
So what was input was not necessarily what was output by the template. That coupled with the hacky use results in unexpected behaviour.
It will only be possible to fully prevent bad saves if/ when templatedata is moved to its own page like .CSS,.js and lua modules.
The last bit is something that you and I can firmly agree on. Storing programming code such as Template Data in an unprotected page that was designed to store template documentation is simply bad programming practice. I look forward to Template Data being moved to its own set of pages, which is something that should have happened long ago.
Raw text editing is much simpler and has more flexibility than any custom tools, and the errors are very visible and easily fixable.
It also allows for easy experimentation with new features, before a custom toolset is updated or even without the need to build one in the first place -- which is a dramatic time and effort saver.
Due to the above, the ability to edit raw data is seen as a strength of a wiki rather than a drawback.
The maximum use I see for encorcing syntactic correctness is to run a syntax checker before saving -- and again, it can only produce a warning rather than a hard error because there's a possibility that the user is trying something that the syntax checker doesn't know about.
I'd estimate that it would cost roughly US$250k of staff time to move TemplateData into an MCR slot now; most of that cost would be in making a lot of decisions about how MCR would operate, rather than specific to TemplateData itself. I don't think there's appetite for that right now, sorry.
As someone who donates roughly US$100K worth of volunteer time to en.WP every year, this answer leaves me a little cold. Discussing the cost of fixing a suboptimal programming decision is probably not the best approach to take with the volunteers who are left to deal with the consequences of that decision.
It wasn't a "decision". TemplateData (created in 2012–13) did not use MCR slots (created in 2017–2022) due to the polarity of time.
Yes, in retrospect, we could have foreseen this abuse and held up eight years of development, but all things must be weighed against each other. Similarly, the decision to create the #tag hack (made in ~2008) is the root cause of a lot of problems here, but it was also vital in helping editing communities establish things they felt that they needed at the time.
If you think that this is an important issue and worth the expenditure, I would encourage you to make your views known to the people that make decisions on this, but the people trying to help you on here aren't any of them, sorry.
I wonder whether the error-checking mechanism is looking for typos, or looking for valid JSON formatting. I'm guessing that it's the latter.
It's looking for schema compliance. So valid JSON, and valid against the TemplateData specification.
