[Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

[Martijn Hoekstra]

On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde <rarohde at gmail.com> wrote:

> On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
> <martijnhoekstra at 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 at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>
>