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

Tue Jul 30 11:36:44 UTC 2013

On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde <rarohde at gmail.com> wrote:

> When discussing issues like this.  One should keep in mind that we
> don't really want to be in the business of "solving" hard problems
> simply by pushing the difficulties onto other people.  Wikitext has
> some characteristics that make parsing it hard (some might say
> ridiculous).  Changing wikitext will create problems elsewhere (and a
> lot of work for volunteers).  In addition one should be careful that
> any changes are made in such a way that important workflows are not
> made significantly harder for editors.
>

my point three wasn't something trivial, and will require a heck load of
engineering (for refrerence:
3. For a suitably long time, display a warning when such a page is saved,
referring 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.
)

>
> To give a common example, see {{nom}}, which consists of:
>
> style="background: #FDD; color: black; vertical-align: middle;
> text-align: {{{align|center}}}; {{{style|}}}" class="no table-no2" |
> Nominated
>
> A clever person will quickly realize that this is used in a table context
> like:
>
> {|
> | Golden Globes || Best Actress || {{nom}}
> |}
>
> Where the {{nom}} template carries with it not just the text
> "Nominated" but also part of the styling to be applied to the table.
>
> This would seem to be a hard example to reimplement in a context
> agnostic way.  At present the template content only makes sense
> because it is placed in the context of a wiki table.  Getting around
> that would seem to be awkward.  You could try to fudge it by applying
> the {{nom}} styles to something like a div block.  However, placing
> that block within the table cell would run the risk of cell padding
> and other table properties causing conflicts or bad appearance, not to
> mention that such an approach couldn't be used if the template is also
> passing colspan / rowspan directives to the cell.  Alternatively, one
> would pretty much have to pull all or most of the table into the
> template, which would seem to lead to new headaches and make the
> source that is much more complicated for authors than the present
> version.
>

I'm convinced that the MediaWiki devs will be able to device a way to do
this better. My markup and style foo is too weak to even speculate about
what that better may be like.

>
> This is one of the examples where there would seem to be few good
> alternatives.  Maybe the devs who are imagining reengineering wikitext
> can also think up good alternatives for some of the uses they might
> contemplate making obsolete?
>

> -Robert Rohde
>

When I said celebrate a happy 2020, it was a case of ha ha only serious.
There are easy nor quick fixes for these issues, and any change will not
only cost a lot of engineering, but will also require a lot of effort from
the communities to fix the breakages it will introduce, which is why I find
it so important to have this discussion long before engineering plans are
drawn up.

>
> P.S. {{nom}} and its sister templates are an example of templates that
> VE can't presently handle.
>

Which is why I think it is very important to have this discussion. I also
think I made my points on this thread and list to a sufficient level, and
will try to sit back and read what the people who really know what they are
talking about have to say about it.

>
> On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
> <martijnhoekstra at gmail.com> wrote:
> > 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>
> > _______________________________________________
> > 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>
>
> _______________________________________________
> 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>
>