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

[Martijn Hoekstra]

On Jul 30, 2013 4:58 AM, "Marc A. Pelletier" <marc at uberbox.org> wrote:
>
> On 07/29/2013 10:02 PM, Rschen7754 wrote:
> > If I'm reading this right, it *would* cause massive problems on the
English Wikipedia
>
> Oh, it *would* if the syntax was just disabled outright!
>
> Now, if it were me that was in charge of fixing wiki markup, this is
> what I would do:
>
> (a) require that syntactic elements opened in a template be closed in
> that template during transclusion* (without a change in code now; i.e.:
> deprecate but not enforce yet).
> (b) provide a mechanism by which templates which do this are
> categorized/marked and otherwise findable.
> (c) wait suitably long
> (d) convert current invalid (according to (a) and identified by (b))
> syntax by substituting still transcluded templates inline (thus not
> breaking content)
> (e) delete/blank/comment out those templates
> (f) render the previous syntax invalid (by implicitly closing any
> syntactic construct at the end of transclusion)
> (g) provide a list of all the subst done in part (d) to the community so
> that automated tools can fixup/convert/cleanup with new markup/LUA where
> applicable.

Something like the following process might be a little easier on the
projects. Assuming that ultimately want each page to be a valid fragment,
suitably defined:

Introduction period:

1. Deprecate the alternative *right now*, by publicly announcing what it is
exactly we would rather not see exist, wikitext wise.

2. Start engaging the projects, and set up wikiprojects that are
responsible for finding the cases where no reasonable alternative for the
current legitimate uses is, and work on expanding the language to make sure
these cases are covered as well as being responsible for setting up forums
for getting help on how to migrate away from depricated syntax.

Transition period:

3. For a suitably long time, display a warning when such a page is saved,
refering users to the local working group that can help them learn how to
write New Wikitext. More legitimate uses will emerge, and reasonable
alternatives must be found or created for everything we are able to do now.

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.

5. When the wikiprojects are no longer buckling under the load of the
stream of unimagined creative and useful yet horrible uses of wikitext they
didn't forsee, and a good deal of templates have been fixed, start showing
warnings when saving pages that transclude pages with deprecated syntax.
Repeat the above steps of waiting and fixing.

6. Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry.

7. Deal with the outcry by making a list of things yet to be fixed. Move
the deployment date to a month after all* bugs have been closed.

8. Block saving pages that contain brokenness. Expect outcry.

If outcry, roll back and go to 7.

9. With sufficient technical ingenuity, freeze and archive the dark legacy.
Don't make it mix with the brave new world.

10. Celebrate successful deployment, and wish each other a happy 2020.

An important consideration that all developers must keep in mind is that
though the current syntax is quite horrible, it also serves a purpose, and
though its existence in itself is quite horrible, the fact that it is
widely used is completely reasonable.

*: for a sufficiently reasonable value for all.

>
> Hopefully, whatever the delay in (c) is would need to be long enough
> that the more egregious cases or complicated templates have time enough
> to be transitioned manually, leaving the following subst/cleanup to take
> care of edge cases and little used templates where the disruption is
> nowhere as bad.
>
> -- Marc
>
> * This would include, indirectly, the "code fragment" templates like
> Erik describe since they contain fragments meant to be interpreted in
> the context of an open syntactic element** -- those are trickier to
> /find/, but (f) would make them pointless.
> ** Making, potentially, a giant leap towards making wikimarkup
> context-free which would solve so many problems with parsoid it's not
> even funny.
>
>
>
> _______________________________________________
> 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>