On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde rarohde@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@gmail.com wrote:
On Jul 30, 2013 4:58 AM, "Marc A. Pelletier" marc@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:
- Deprecate the alternative *right now*, by publicly announcing what it
is
exactly we would rather not see exist, wikitext wise.
- 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:
- 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.
- 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.
- 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.
- Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry.
- 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.
- Block saving pages that contain brokenness. Expect outcry.
If outcry, roll back and go to 7.
- With sufficient technical ingenuity, freeze and archive the dark
legacy.
Don't make it mix with the brave new world.
- 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@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ 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
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