Templates complicate the "is this valid"
test. Multiple templates can
contain invalid syntax which when used together form proper syntax.
[..snip..]
The former contains invalid syntax since the table is not closed, the
latter contains meaningless characters since the table wasn't started.
But used together, the two form a table. For example:
{{TableStart}}
Some text
|-
Perhaps another row
{{TableStop}}
That example also contains individually meaningless markup characters
(the |-), but after transclusion would render a complete table.
So where do you place the validation logic? If you validate the
Template pages themselves, they'll fail - so do you omit Templates
from conformance? If so, what about transcluding pages from other
Namespaces?
I'm not trying to say that a validator is a bad thing, or that it
wouldn't be useful. I'm just wondering how all the false positives
can be accounted for.
We had this exact problem at
http://en.wikipedia.org/wiki/WP:WS
(a discontinued project for "validating" wiki syntax, for a very
very simplistic definition of "validate").
It was all about balance - that if you opened something you should
close it, or if you close something you should have opened it -
including for templates, tables, headers, links, bold and italics.
It only looked at a single page (i.e. no template transclusion)
so this would pass, since the number of "{{" equals number of "}}" :
{{TableStart}}
Some text
|-
Perhaps another row
{{TableStop}}
... and this would pass, since number of "{|" equals number of "|}" :
{|
Some text
|-
Perhaps another row
|}
... but this would fail, because number of "{|" does not equal number
of "|}" :
{|
Some text
|-
Perhaps another row
{{TableStop}}
... and the resolution was to change it to one of the first two forms
(i.e. you had to close a table in the same way that you opened it).
People forgetting to close tables did happen, but it was not a common problem.
Far more common was "[[unclosed brackets" or "an unclosed ''bold or
'''italics".
And yes, for the record, false positives were a problem, such as for
things like "[a,b)" as a mathematical notation, as opposed to someone
mistyping an external link.
A simple error
message saying "tag tag not closed", either
inline when displaying the page, or as an error on save, would be much
easier and much clearer.)
And if they don't already understand the jargon and don't understand
what it is they haven't done according to the definition of wikitext?
The above project was opt-in, which worked well. So an integrated validator
could maybe work as a preference that people had to explicitly enable -
( "[X] Show me verbose errors when saving invalid wiki text." )
Also rather than just saying "there was this error", what would be really
nice would be if you could get a list of common solutions for a problem,
with a point and click interface to apply a canned solution. Probably around
95% of the solutions to the problems found were quite mechanical
transformations, and if these transformations were available from a pick-list,
then that would be nice.
For example:
Problem: Unclosed bold on line: "an unclosed ''bold on a line".
Possible solutions (with radio boxes shown to select preferred solution) :
1) Remove unclosed bold from line (i.e. "an unclosed bold on a line".)
2) Close bold after first word (i.e. "an unclosed ''bold'' on a
line".)
3) Close bold at end of line (i.e. "an unclosed ''bold on a
line''".)
4) I will manually edit to resolve this.
Same thing could potentially be used for headings, link brackets, etc.
A new parser that issues the user with error messages
from what they
typed in - rather than just producing rubbish as now - will, I
predict, be considered unacceptable.
If it's opt-in for the current behaviour + warning messages, and behaves
the same as now by default, then surely that should be acceptable?
-- All the best,
Nick.