Timwi wrote: We would if we could. See ToL talk for more.

Copied from http://en.wikipedia.org/wiki/Talk:Violence_against_Israelis#Lists (posted here so I don't have to repeat myself five times) I dispute the factual accuracy of the various terrorism against Israel in {year} pages because sources for the reports therein are (apart from the word of a single Wikipedian) fragmentary or non-existent. I will happily withdraw the accuracy disputes when each item on each list is annotated properly. —No-One Jones 10:37, 27 Aug 2004 (UTC) Mirv has added the "factually disputed" tag to this set of articles without disputing any individual item. Are we to annotate each item in each article to meet this criteria?

Are we to apply this level of citation to a set of articles? Is this level of citation to apply to Violence against Israelis alone?

Pete/Pcb21 wrote: Can I regard this as an official statement that you will not mind those multi-template boxes breaking when a new parser is introduced that will support the "correct" way? :) If that is the case, then that will make my job for the new parser way easier.

[The current way of doing template taxoboxes] isn't really supposed to work at all. It would be virtually impossible for me to make your current way work with a real parser. To compensate, I am perfectly happy to help you convert all the taxoboxes to a proper structure. Greetings, Timwi

Pete/Pcb21 wrote: Can I regard this as an official statement that you will not mind those multi-template boxes breaking when a new parser is introduced that will support the "correct" way? :) If that is the case, then that will make my job for the new parser way easier. Thanks, Timwi _______________________________________________ WikiEN-l mailing list WikiEN-l(a)Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l

Ævar Arnfjörð Bjarmason wrote: Of course, this simple example would still work. But picture this: Template:A contains: I ''li Template:B contains: ke'' hamburgers currently, {{a}}{{b}} would yield "I <em>like</em> hamburgers", but only because it sticks the pieces together and then tries to make sense of it. Why is this bad? Picture this: Template:A contains: {| | nowrap Template:B contains: | Text |} Is the "nowrap" a table cell attribute or text in a separate cell? Does this change depending on whether there is a newline after "nowrap"? ... And this is just a simple example. Because a parser is not a converter. The current not-really-a-parser is actually a converter: It looks out for particular syntax elements like ''these'' and turns them into <em>HTML tags</em>. This is bad because it means that several of these conversions can interfere with each other: I ''like [[hamburger|hamburgers'']] produces invalid HTML. It gets even worse when it tries to locate {{template inclusions}} and replaces them with some other text, not knowing what it is or how it fits into the document structure. A real parser analyses the document's structure. It turns the wiki text into a data structure in memory that actually bears resemblance to the structure of the document. It creates a "heading" element where there is a heading, instead of turning some strategically-placed equals signs into <h#> tags. Your terminology "auto-completion" reveals that you are thinking in terms of conversion. Don't think of it as auto-completion; for example, if a '' has no matching '', I can tell the parser what to do independently of what it does when there *is* a matching ''. There are several possibilities: make an italics element (what you would probably call auto-completion); make a text element (i.e. pretend the "''" was actually text); or bail out saying "syntax error". Of course, we don't want the latter. My parser currently does the second: It turns the '' into text. I did that because this is also how the current not-really-a-parser functions. However, I can easily change that. In our specific case, there would be a document (a template) that has a {| with no matching |}. What should it do? Unfortunately, none of the three options make it work the way you have come to expect from the current not-really-a-parser. Timwi _______________________________________________ WikiEN-l mailing list WikiEN-l(a)Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l