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.