On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde rarohde@gmail.com wrote:
On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
<snip> > 4. Block the creation of new templates with deprecated syntax. Also block > saving templates that were free of deprecated syntax would an edit > introduce deprecated syntax. <snip>
Strictly speaking this is impossible. While there are some common cases that could be recognizable on a per template basis, there are other cases that are only recognizable as problems when placed in the context in which the are used.
To give a ridiculous example:
A template {{foo}} consisting of "> Nothing here <" looks innocuous enough until embedded in a page that reads "<div{{foo}}/div>".
Because templates can contain tag, table, and other markup fragments, the implications for the parser aren't necessarily clear until the template is used in context with other elements. So one could identify this as an issue when saving the page that uses it, but there is no general way to identify all templates that might be problematic at the time the template is written.
-Robert Rohde
Drat, you are clearly right. I was hoping there was a way to dream up a transition where at no point a seperation between "old syntax transcusion" and "new syntax transclusion" would have to be made until the very last moment (my step 9 above). It should still be possible to find and mark templates that are broken through a one time exhaustive search (find all transclusions, and check if the generated DOM for the transcluded fragment is identical to the generated DOM of the fragment itself) and make a split there.
My first thought was that it would be completely unfeasible bordering impossible to do that on every page save, but now that I think of it, while it would undoubtably be very rough on the backend, for a cause as noble as moving away from template madness it might be worth it ( a single extra query and the number of inclusions extra full page parses - but some parse results could be cached for a transitional period, and you can stop once you have found one failing parse). The WMF devs should be far more able to estimate its impact, but It's a little soon to discuss that, as the wish to deprecate the current semantics hasn't even been officially stated.
--Martijn
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe