Timwi wrote:

Pete/Pcb21 wrote:

...

Timwi wrote:

...

{{Taxobox | color = pink | name = Domestic Dog | image = [[...]] | regnum = [[Animal]]ia | ... etc. ... }}

We would if we could. See ToL talk for more.

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.

Firstly, those who have worked on ToL taxoboxes would I am sure fall deeply in love with anyone who implements optional parameters to templates, otherwise the method you suggest for taxobox templates is completely impossible (not all species have images, authors, particular levels of taxa etc etc) so a single taxobox without optional parameters does not work (and the number of different taxoboxes required grows exponentially).

Having said that, if you are planning to break the existing code, which is a perfectly "correct" use of the existing functionality, I am sure people will very much do the opposite of love you! :)

Pete

--- Harry Smith lance6wins@yahoo.com wrote:

Copied from

http://en.wikipedia.org/wiki/Talk:Violence_against_Israelis#Lists

Where it should stay, but nevermind; I'll explain here but request that any further discussion go to the appropriate talk page.

(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.

Well, here are some examples, which I'll copy to the talk page:

* August 23: A female motorist was wounded by large rocks thrown at her vehicle while traveling late at night. ([[Violence in the Israeli-Palestinian conflict 2004]])

Here we have no name for the victim, no location for the attack, and no word other than that of the author (whose political views and agenda are well-known to anyone who watches Wikipedia's articles on the Middle East) on who was responsible. Without a source we don't even know that if the item is anything other than word-of-mouth rumour.

*April 28: An Israeli woman stabbed to death in Karmiel, Galilee. ([[Terrorism against Israel in 2001]])

This item at least has a location, but the rest of it suffers from the same vagueness: no name, no way to confirm that this even happened, and no way to tell if it even belongs in the list.

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?

In controversial and politically-charged articles, citations are of paramount importance but are all too often omitted. The set of articles in question is just a particularly egregious example of the problem.

I would like the disputed tags remove till a factually inaccuracy is found. At that point I would like the inaccuracy corrected, so that the tag would not apply.

And I would like to see the disputed tags stay. [[Wikipedia:Accuracy dispute]] says the following:

*begin quote*

The accuracy of an article may be a cause for concern if:

* It contains a lot of unlikely information, without providing references. * It contains information which is particularly difficult to verify. * In, for example, a long list, some errors have been found, suggesting that the list as a whole may need further checking. * It has been written (or edited) by a user who is known to write inaccurately on the topic.

*end quote*

Reasons #2 and #4 (and perhaps #1) apply to the lists in question, which I think is ample reason to keep the disputes in place.

--Charles Podles ([[en:User:Mirv]])

__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

http://en.wikipedia.org/w/wiki.phtml?title=Violence_against_Israelis&dif...

Anon added this: "It should be noted, however, that more people have been killed by Israeli attacks on Palestinian cities than the reverse."

This might be true, and it might not be. I agree that it's very important to cite sources and especially important to cite sources on articles such as this one.

Note that i did not revert it.

On Sun, 29 Aug 2004 05:48:41 -0700 (PDT), Harry Smith lance6wins@yahoo.com wrote:

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?

I would like the disputed tags remove till a factually inaccuracy is found. At that point I would like the inaccuracy corrected, so that the tag would not apply.

Lance6Wins

---

Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l

Stan Shebs wrote:

I'm still wondering why this would matter.

It matters because it is impossible to generate a proper parse tree for a template that contains only part of a table. A table is one object.

So what if a group of templates is being used together? If that's going to be disallowed, that seems like a major change in the language, not a detail of parser implementation.

Maybe you are underestimating the vast differences in implementation between the current not-really-a-parser and what I am working on.

There is nothing wrong with using a group of templates together, but there *is* something majorly wrong with patching together one object (a table, in this case) using pieces from different places. It works with the current not-really-a-parser because it takes the wiki source texts from the templates, sticks them together somehow, and then converts them to HTML. This kind of practice is exactly what leads to all the problems with our current not-really-a-parser. A proper parser should parse each template individually, and then use its parse tree in the processing of the page that uses it.

Any definition of template that doesn't work a lot like a C-type preprocessor macro is likely to be difficult to explain to users.

Uhm. I don't think so. Editors are not supposed to know about C or similar pre-processors.

Quite to the contrary, I think it is quite hard to explain to users how the taxoboxes are patched together from little pieces that are scattered around several templates. If the entire table was contained in *one* template (which, of course, may include other templates inside it, but nevertheless it represents the whole table), I'm pretty sure that not so technically savvy people would have less trouble understanding the concept of templates.

I am sorry if I'm sounding like I'm pounding your current solution to the taxobox problem. I hope that at least some of you understand my position. I have put work into this parser, and it would be a shame if it's not going to be used just because it breaks something that 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:

However I just wanted to remark that your remarks smack of "blame the user".

Ah. Thanks for pointing that out; I apologise that I came across that way. (Well, re-reading my first e-mail, I see that I should have known. But when I saw those ... uhm ... you know :) )

It is hardly the users' fault that they (we) are using it as a text replacement mechanism - that is precisely the heritage of the template system through 1.2 and 1.3 and no-one has ever, until now, said anything different.

True. Which is no surprise because it has worked until now. But if those techniques proliferate, then introducing a new parser will eventually become impossible. And the current not-really-a-parser isn't really maintainable at all and has a lot of bugs (especially with templates) which are near impossible to fix. We would steer towards a static, inextensible template mechanism with loads of unfixable bugs.

This I'm trying to prevent from happening. :-)

Timwi

Ævar Arnfjörð Bjarmason wrote:

Why would it ever break? I can see it getting slow because it cannot be optimized but not breaking, all it's doing is just including one thing after the other

{{a}} gets Template:A which contains "foo" and {{b}} gets Template:B which contains "bar" hence

{{a}}{{b}} = foobar

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.

Why would this break in whatever parser you plan to implement?

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.

The only reason i can see why that would happen is if you were to implement some auto-completion of the table syntax. Sort of like tidy(html) for wikisyntax and do it before things get fetched from Template: rather than after everything has been included.

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

And the direct link to that talk is?

On Sun, 29 Aug 2004 11:20:23 +0100, Pete/Pcb21 pete_pcb21_wpmail@pcbartlett.com wrote:

Timwi wrote:

...

{{Taxobox | color = pink | name = Domestic Dog | image = [[...]] | regnum = [[Animal]]ia | ... etc. ... }}

We would if we could. See ToL talk for more.

---

WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l