Jan Hidders wrote:
>Steve Callaway wrote:
>>nevertheless. HTML is //much// simpler.
>That is simply not true. One of the reasons that the WikiWiki mark-up was
>invented is exactly because HTML didn't work well and was seen as
I don't see how you can establish this in any objective manner.
Even a survey would only shows that most people feel that one as simpler,
which is not at all the same thing as one's actually *being* simpler.
Myself, I think that <h6> is simpler than ======,
because it's simpler to read the "6" than to count the "="s.
But == is simpler than <h2>, because I don't have to count the "="s there.
We can do psychological testing to determine when simplicity switches,
but other people will switch it at slightly different times.
Best all around to allow both methods.
You know, this is like allowing both American and Commonwealth spellings.
I find it difficult to remember to write "analyze" or "spelt",
but it's easy as pie to learn to read them.
Similarly, if Steve has trouble writing ===, he can still read it,
and if you have trouble writing <h3>, then you can still read that too.
It's just that here the reading is occuring on the edit page
rather than in the text of the article directly.
-- Toby Bartels
>Toby Bartels wrote:
>>The question isn't how easy "'''" is to learn.
>>The question is how easy "<b>" is to learn.
>>The answer to that is, it's pretty darned easy;
>>therefore, since people will try it, it should be allowed.
>>If having two ways to write the same thing is bad,
>>then honestly "'''" should go before "<b>" does.
>>(Note the "if"; I think that "'''" is great -- easier to type.
>>In fact, it should actually be rendered as <strong>,
>>which is even harder to type but is almost always more correct.)
>Or <em> maybe?
''' = <strong>, '' = <em>.
>Many people comne to wikipedia completely ignorant of HTML. Many people
>on the net don't even know what HMTL is -- really! Some of them are my
>friends! Many people *with websites* use Dreamweaver or some such and
>have no idea what <b> means.
I don't see the relevance of that.
It's not like they know what ''' means either before they arrive.
Surely *more* people will know <b> than ''' before coming here,
and most of these people won't be ace programmers either.
>I think the most important point is that wiki must be easily readable in
>both raw & rendered formats. The eye skims over ''' very easily, whereas
><b> and </b> arrest the flow.
This I think *is* relevant.
Since I don't believe that we need only one method for every purpose,
I would keep both <b> and ''' but still prefer '''
(barring making a distinction between them as suggested below).
>I would hesitate before [removing support for] <b> and <i> in wiki markup, but I
>change those to the equivalent ' whenever I see them, and I don't think
>they should be encouraged.
I do the same changes myself, except in very special cases
where <b> is actually more appropriate than <strong>.
Then one day when I convince y'all to render ''' as <strong> instead of <b>,
then everything will be perfect!
I'm not about to get upset if you change by <b> to ''', however,
and could be convinced to follow your lead exactly if you work at it;
I'll only get upset if you mess with <var>, as explained in another post
(not yet made, or look on Jan's page).
-- Toby Bartels
> * Delete uploaded files
> o There's also a revert-to-previously-uploaded-version feature,
> I'm not sure if this is sysop or everybody.
Anybody can revert, and anybody can delete a single old revision;
but only sysops can delete the whole image and its description.
> * Protect and unprotect pages (locking them against edit by other
> users who are not also logged in as sysops).
Forgot about that one.
> Traditionally this was in fact used only on the main page, but
> some of the policy pages are also locked, which I'm not sure I
> approve of. Here are all the pages currently protected:
> o Wikipedia:Upload_log
> o Wikipedia:Deletion_log
These are a special case: the software requires that they be in
a special format so that it can add to them. While it would be OK
to make certain edits (adding text, etc.), some would break things,
so this is just a safety precaution.
> o Wikipedia:What_Wikipedia_is_not
> o Main_Page
> o Wikipedia:Neutral_point_of_view
> o Wikipedia:Copyrights
> o Wikipedia:Policies_and_guidelines
> o United_States_Constitution/Article_One (I'm a little
> confused by this one; I've since unprotected it. It's just a
> redirect anyway...)
> o Wikipedia:IP_probation_watchlist
> o Wikipedia:Most_common_Wikipedia_faux_pas
> o Wikipedia:Blocked_IPs
> o Wikipedia:Naming_conventions
> o Wikipedia:Administrators
> o Wikipedia:Policy
I think some of these may have had a history of vandalism, but I'm
with you that most of them should be unprotected. Anyone else
remember more details here--they seem to have been protected when
my head was buried in software, so I missed a lot of discussion.
> There are also a handful of 'developer' features available only
> to a few of the programmers for purposes of finding and fixing
> bugs: database queries, showing the PHP configuration variables,
> and enabling/disabling a read-only mode to prevent edits to the
> database in the middle of certain upgrades. --Brion VIBBER »
Sysops can do "SELECT" queries on the database. Only developers
can do updates and deletes.
Stephen Gilbert wrote:
>What if you want a bold italic font? I know of only
>three ways to do it on Wikipedia, and none are pure
>wiki syntax: <b>''Bold italic''</b>, <i>'''Bold
>italic'''</i>, or <b><i>Bold italic</i></b>.
''''' gives bold italic (more precisely, <em><strong>),
but this is buggy on some browsers.
If you find that it makes a difference to your browser
exactly how you go about specifying the effect,
then you might consider reporting that to Lee;
he could choose the rendering method that bugs the fewest browsers.
(But I suspect that he would give this very low priority ^_^.)
-- Toby Bartels
> Then one day when I convince y'all to render ''' as (strong)
> instead of (b), then everything will be perfect!
'' and ''' are already rendered as (em) and (strong).
I'll have a more detailed reply later, but for now let me
say that I'm definitely on the side of removing the _need_ for
HTML as much as possible, but I'm open to allowing it.
>>Sysops can do "SELECT" queries on the database. Only developers
>>can do updates and deletes.
> There had been some discussion a while ago of changing that and
> restricting all direct DB access to developers; I guess I got it
> mixed up with the implementation in my memory. As I recall the
> points of contention were:
> 1) Users' passwords were stored in the database in plaintext.
Hr. Daniel Mikkelsen wrote:
>My idea with the "controversial issue" flag/page-link would be to use it for
>articles that are still "contested" at Wikipedia. Many articles that in
>themselves regard controversial issues have been splendidly NPOVed, and
>wouldn't need to be flagged.
>But others, where people bicker back and forth, or where someone still doesn't
>consider the article to be NPOVed, would benefit from it.
First, I don't think that this should be encouraged just because
a reader doesn't think that an article is NPOV but hasn't time to fix it.
Although you can't vote automatically from a page anymore,
the listing at [[Wikipedia:Votes for NPOVing]] serves this purpose.
You apparently think that this won't be used widely
because there's a threshold of trouble involved;
but adding "This is a [[controversial issue]]."
at the end of the introductory paragraph is quite easy,
and it's hard to justify removing it if the statement is literally true.
Listing on [[Wikipedia:Votes for NPOVing]] is a more reasonable threshold IMO.
However, the pages where people bicker back and forth
could reasonably stand be flagged for the benefit of casual readers
(or to calm down the authors, although I don't think that that will work).
But casual readers won't be tipped off by a link to [[controversial issue]].
The only way that I think that this will work is an entire paragraph,
placed after the introductory paragraph in Wikipedia's patented '', say:
''This is a [[controversial issue]], and the authors of Wikipedia
have yet to come to a consensus on the best way to present it
from a [[neutral point of view]]. Please bear that in mind while reading,
and if you wish, help us to craft this article in a way
that will be fair to all viewpoints.''
Since the existence of bickering is fairly clear cut,
people can easily justify including or removing this.
Even the bickering authors of the article know that they're bickering,
even if each does think that said bickering is all the other side's fault.
(A computer script to determine whether there's bickering might be better,
except that I have no idea how this could be implemented.
Lots of edits is no evidence; even lots of reverts could just be vandalism.)
People that just jumped in from Google are told up front what's going on,
and a page like [[Wikipedia:Controversial issues]] (redirected to from
[[controversial issue]] for ease of linking) will explain the policy,
not serve as a list (although a list would appear on "What links here").
I'm not convinced that this is necessary at all, but if it is,
then I think that it'll work better out front like this
than as a subtle flag that only insiders will notice.
-- Toby Bartels
Vicki Rosenzweig wrote in part:
>Toby Bartels wrote:
>>Neil Harris wrote:
>>>(Name of issue here) is a [[controversial issue]], with widely differing
>>>points of view... &c.
>>"'''Evolution''' is a [[controversial issue]],
>>with widely differing points of view."
>Also, of course, "'''God''' is a [[controversial issue]], with widely
>differing points of view",
>Seriously. Evolution isn't half as controversial as whether Jesus is God.
That's kind of the point;
[[Evolution]] shouldn't be flagged but it *will* be (my prediction),
rendering the flag largely useless.
That said, [[God]] probably shouldn't be flagged either --
although I haven't looked at that article, so ¿who knows?.
-- Toby Bartels
Resent after bounce, change in subscriber name.
- ------- Start of forwarded message -------
|From: tarquin <tarquin(a)planetunreal.com>
|Date: Tue, 30 Jul 2002 12:55:57 +0100
|Steve Callaway wrote:
|>It occurs to me that there is going to be an awful lot of reworking if we
|>ever do go to an XML format Wikipedia (and this definitely needs discussion
|>at some point soon). I would have said that HTML is a more generally
|>accepted standard and that Wiki formatting is a highly localised phenomenon.
|>You can do a lot more with HTML format than you ever can with Wiki
|Au contraire. The beauty of Wiki Markup is that is is independent of
|what is sent to the browser.
|When XML finally (!) hits the road, all it will take is a few tweaks to
|the script so '' is converted to a different tag instead of <I>, and we
|can go on writing wiki markup as before.
|If anything, XML is another reason for preferring wiki markup to HTML.
|Another good reason, from http://c2.com/cgi/wiki?WhyWikiWorks, is:
| > It's an intelligence test of sorts to be able to edit a wiki page.
|It's not rocket science, but it doesn't appeal to the VideoAddicts
|<http://c2.com/cgi/wiki?VideoAddicts>. If it doesn't appeal, they don't
|participate, which leaves those of us who read and write to get on with
My markup experience goes back to 1978, when Runoff was a pup found on
the doorstep by the FAA in Oklahoma City, and goes on through the
various *ROFFS, DEC's own RNO, Symbolics Concordia (where I was doc
manager), VAX Document (whose development group I managed), HTML, XML
(a disastrous experience with Arbortext products), and a couple of
others I can't now recall, as well as Framemaker and other word
processors, so it is with some authority that I can say that Wiki
Markup is the best, most comfortable, pound-for-pound most functional
markup language I have ever used.
It is simple, easy to learn, and provides almost all that any writer
needs to do the job of putting words in order. Tables are dreadful,
but they almost always are. Some kind of simple table specifier that
would permit creation of two-column and three-column tables is about
the only thing I miss. Even there, you can do most of what you want
just by putting a blank space at the beginning of a line.
The ability to sneak out into HTML is handy, but prone to non-wikiness
if the next person to come along can't figure out some arcanely nested
construction. A back door to XML would be a mistake in my opinion
because you can do *anything* with XML and I don't think we want to be
able to *anything*, we want *anyone* to be able to edit a page.
Implement in XML, sure, but hide it, because I don't ever want to code
in it. I don't really want to code at all, and Wiki Markup gives me
the impression that I'm not coding and I don't have to.
- ------- End of forwarded message -------
> I volunteered ages ago to try & reorganise naming conventions,
> and tie them in with things like presentation conventions, Wiki
> Projects and "basic topic" pages.
> I'm still mulling it over, and I'e got to the point where I'd like
> to start laying out ideas.
> There's no way this can be cleanly refactored overnight, so I'm
> thinking of using the Meta wiki, to first set out a page scheme and
> then start refactoring. That way "normal service" (!) won't be
> disturbed on the wikipedia: namespace.
> Any objections if I discreetly set up in a corner of MetaWikipedia?
That would be a good way to do it; another method that Mav used for
some of the element pages is to create a page ".../Temp", do all of
the editing there, and then delete it (after moving it to its final
spot). This wasn't an anticipated use of the delete feature, but I
think its a good one.
I rather like the way my reorganization of all the policy pages came
out; you might use that as a model for reoganizing naming conventions.