subject: [Wikipedia-l] Sysop status

body:
maveric149 wrote in part:

>Again I would like to restate my proposal to have an 'old hand' status that
>would allow users that have been around a while and are generally trusted to
>move pages and edit protected pages.

I don't think that I've done this before,
so I'd like to officially state my agreement on this.
30 days/30 edits, mentioned before, seems reasonable offhand.
Is there agreement that we do want to open up these two functions,
and that the only thing left to discussion is the criteria?

>Aside.... Is the name "Pedia Wiki" used anymore? Or does our wikiware have no
>name? :-(

Sure it has a name: "Phase III Software".
Sounds like a .com startup.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


list: wikipedia-l

source: pipermail-mbox

from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Sysop status

body:
> Unfortunately, LDC never got around to porting the promote/demote
> feature of Phase II to Phase III, so Jimbo (possibly a developer)
> will have to promote you two. I'm sure nobody will object to your
> promotion.

I already did.  Any of the developers can do it directly to the
database.  I do plan to build screens for that, but I've got my head
buried in a new recent changes implementation at the moment that I
really want to get out first.

> Again I would like to restate my proposal to have an 'old hand'
> status that would allow users that have been around a while and
> are generally trusted to move pages and edit protected pages.
> Not everyone wants to have to keep up with the mailing list or
> have the burden of being seen as some type of cop just to have
> the ability to do stuff like moving pages or editing the Front
> Page. These things can't really be entrusted to totally green
> users that signed-up 5 minutes before and are totally unaware of
> our editing policies and naming conventions but I see no reason
> to deny this to longtime users.

If you want to give this out more freely (and I agree it should be),
then it will become a maintenance headache unless it's automated
somehow.  Obviously "logged in as a user" is one criterion, and then
something like having edited some number of articles over some period
of time.

> Aside.... Is the name "Pedia Wiki" used anymore? Or does our
> wikiware have no name? :-(

If you think it oughta have a name, give it one!


subject: [Wikipedia-l] User Contribution Tracking

body:
> I have been inactive a while.  Can someone tell me whether the
> user contribution page is going to return to listing contributions
> or is it going to stick with the recent changes format of within
> last 30 days?

The limits are important, because otherwise some of the lists would be
thousands of entries and bog down the server.  But the count limit and
the time limit are both completely selectable in the URL.  I don't
want to have links on the page for anything more than 30 days or 500
results, because then they might get spidered. But if you want to see
you contributions, just make yourself a link on your own page with a
URL that has a large day count, like this:

http://www.wikipedia.com/w/wiki.phtml?title=Special:Contributions&target=Mirwin&days=999&limit=100

It will be slow, but it will give you the info.


from_name: Daniel Mayer

subject: [Wikipedia-l] "Copyright violation" question (just the opposite of what you think)

body:
I just had an interesting experience with an apparent copyright violation.

The text in [[Marina Tsvetaeva]] is very similar and in many cases exactly
the same as text in an external website. One user deleted the text in the
article citing a copyright violation on our end. Even though I saw obvious
similarities between our version and theirs I wasn't so sure /we/ were the
ones who violated copyright because the article existed in pretty much the
same form since before the move from the UseMod wikiware back in February.

My suspicion that we in fact were not violating any copyright was confirmed
when user:sjc claimed authorship and stated that the text had been in the
public domain for 12 years.

I am not sure if the external website used the public domain version by sjc
or one of our earlier versions, but as Wikipedia grows we will increasingly
find apparent copyright violations on our end that are in fact just the
opposite: other websites taking our text and using it in a way that is not
compatible with our license (there is also the issue of public domain text
too.... Remember, cite your sources!).

What should we do in such cases? Furthermore, should we make a rule that if a
Wikipedia article "fails" the Google test AND is over a set number of weeks
old, then we should give the original contributor the benefit of the doubt
and /not/ delete the text?

We almost lost a great article on Marina Tsvetaeva and I don't want to lose
any others due to this type of mixup.

--mav


subject: [Wikipedia-l] Help from a sys admin requested

body:
>Somehow in the last few weeks/months the cookie on my
>portable has gotten messed up and I cannot remember/hack the current
>password phrase for the wikipedia site.   My meta account still works
>fine, apparently I never changed the password phrase there.

I added your email address to your user record.  You can help me test
out the "e-mail me a new password" function now. :-)


subject: [Wikipedia-l] Is it just me or is Sorceforge a @$#%^&*^%$#?

body:
>Another page that mangles itself, with a table this time. I wonder if
>it's the result of a page wider than will fit on the screen?
>
>http://www.wikipedia.com/wiki/Zhou_Dynasty_%28690_AD_-_705_AD%29

I'm beginning to agree with Neil that I'll have to do some
browser sniffing and put out different code for Netscape.


from_name: Ray Saintonge

body:
Daniel Mayer wrote:

>My suspicion that we in fact were not violating any copyright was confirmed
>when user:sjc claimed authorship and stated that the text had been in the
>public domain for 12 years.
>
>What should we do in such cases? Furthermore, should we make a rule that if a
>Wikipedia article "fails" the Google test AND is over a set number of weeks
>old, then we should give the original contributor the benefit of the doubt
>and /not/ delete the text?
>

This points to a need for a policy on procedures when someone suspects a
copyright violation.  I suspect that this issue will arise more
frequently as  Wikipedia becomes bigger.  It doesn't do to have members
deleting articles on the mere suspicion that it may violate copyright.

Eclecticology

>


body:
On Tuesday 30 July 2002 10:34 pm, you wrote:
> Hi All,
>
> I have been inactive a while. ?Can someone tell me whether the user
> contribution page is going to return to listing contributions or is it
> going to stick with the recent changes format of within last 30 days?
> Was this change due to a performance issue or as a result of refactoring
> the wiki software?
>
> Personally I found the old format extremely useful in quickly browsing
> to subjects that I had previously found interesting and was able to
> contribute to. ?It was also fun/useful to be able to see a list of my
> contributions without me having to build and maintain a list manually.
> Easier to find skimpy entries or augment articles of interest with
> additional information.
>
> It was also useful on the occasion a few months ago when I was labeled
> <b>TROLL</b>. ?In response to my defensive reaction to this offensive
> allegation, Rgamble actually looked up a few of my contributions and
> affirmed that he/she thought I was contributing more than I was damaging
> and that he/she therefore did not consider me a troll.
>
> As things stand right now on the contribution page he/she would have
> been unable to respond semi-quantitatively due to an inability to easily
> audit a random sampling of past contributions.
>
> mirwin

I just added a link to all of your contribs since Feb 8, 2002.

--mav


subject: [Wikipedia-l] Re: Parsing

body:
On Tue, Jul 30, 2002 at 01:14:53PM -0700, Toby Bartels wrote:
>
> I do disagree with you there, thinking that ''' is more difficult,
> although *only* because more newbies will know <b> to begin with --
> they are inherently of pretty much the same complexity
> (I see two minor arguments each for relative simplicity).
> This is minor, and the difference will probably only lessen with time.

I think the relevant arguments have already been mentioned:
- both are equally easy to learn
- many newcomers already know <b>
- other newcomers are a bit intimidated by HTML tags
- raw text with ''' is slightly easier to read than with <b>

> I argue that the HTML tag itself is the best wiki markup for most of
> these. It's just a few situations where we have something better, or where
> the HTML is so complicated that we *need* something better. Then I'm with
> you; I just wish that this weren't an antiHTML crusade.

That crusade is just me. Please don't let my extreme point of view stop you
from agreeing with more reasonable points of views. :-) Even I could
probably be convinced to use HTML tags for certain mark-up if we cannot find
good Wiki alternatives. However, if there is a good Wiki alternative then we
should use that and that alone. But you probably agree with me there.

> Well, Lee has just informed me that <strong> and <em> are taken care of;
> it was only Phase II that rendered ''' and '' suboptimally as <b> and <i>.

This means that the mark-up has even now again become more complex because a
writer now has to decide between ''' and <b> and know the difference. If
there had been only one notation we wouldn't even have had this discussion
and/or the developers would have had to consult Wikipedia-l for adding new
mark-up. We are failing in keeping the mark-up simple. That is bad.

-- Jan Hidders

PS. This discussion is probably coming out of everybodies noses by now, so I
    suggest we wrap it up, or continue it by e-mail.


from_name: Stephen Gilbert

subject: [Wikipedia-l] Re: Parsing

body:
--- lcrocker at nupedia.com wrote:
> As comfortable as all of us are with HTML, /we/
> aren't the kind of
> people we want editing articles (except maybe those
> on computer
> subjects).  We want Bridge players writing about
> Bridge, and cat
> breeders writing about cats, and campers writing
> about camping--the
> kind of people who have never even heard of HTML are
> the kind of
> people we want most to attract and make use of.  We
> computer nerds
> are used to dealing with special syntaxes; it is we
> who should adapt
> to them, not the other way around.

Hear, hear! You have convinced me sir. I say we phase
out the HTML and use Wiki markup exclusively.

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


from_name: Michael R. Irwin

body:
lcrocker at nupedia.com wrote:
>
> >Somehow in the last few weeks/months the cookie on my
> >portable has gotten messed up and I cannot remember/hack the current
> >password phrase for the wikipedia site.   My meta account still works
> >fine, apparently I never changed the password phrase there.
>
> I added your email address to your user record.  You can help me test
> out the "e-mail me a new password" function now. :-)

Many thanks Lee!  The tests I ran were successful.  Details below.

I attempted to login and then without entering the password clicked
on the "e-mail me a new password" button.   Approximately 30 seconds
later when I queried my mail the message with the password was waiting
there in the queue.   The subsequent login worked like a charm.

The second test I ran:  I logged out.  Then attempted to log back
in with an incorrect pass phrase.   I then hit the "email me a new
password" button.   Once again the message was waiting in the queue
30 seconds later.   I logged in and changed the password to a new
phrase.   Logged out and back in successfully.

Then I attempted to change my preferences via the special pages
menu at the top.   After I clicked the drag down, I looked over
the options for a few seconds and it apparently timed out and logged
me out.   This happened a couple of times before I quickly selected
preferences and hit the go button to successfully get to the preferences
instead of being logged out via a time out.

Not a major bug but it could be pretty disconcerting to a new user
and provide an incorrect poor initial impression of the robustness of
the wikipedia software.  I report the behavior here in case it is new
behavior related to the addition of the new (or at least previously
untested :) ) "email me a new password" function.

Thanks Again!
mirwin


subject: [Wikipedia-l] Refactoring of Naming, Projects, etc

body:
--- Daniel Mayer <maveric149 at yahoo.com> wrote:
> In my opinion having two separate RecentChanges for
> Wikipedia and Metapedia
> is why activity is comatose on the meta. But then I
> would be uncomfortable
> about having something like a meta namespace unless
> the display of meta pages
> in RecentChanges were turned off by default for
> users -- we are first an
> encyclopedia not a social club.

Software developers, how difficult would it be to have
the ability to display Recent Changes by namespaces?
There could be checkboxes on the preferences page
allowing people to select which namespaces would be
displayed.

Perhaps the more important question is, would such a
feature be a big performance hit?

Stephen G.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


from_name: Brion VIBBER

subject: [Wikipedia-l] Re: Parsing

body:
Daniel Mayer wrote:
> <hint>WikiTable parsing</hint>
> (Sorry, there is no wiki equivalent of that tag ;-)

Oughtn't it to be:

   -->WikiTable parsing<!--

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Sysop status

body:
Toby Bartels wrote:
> maveric149 wrote in part:
>>Aside.... Is the name "Pedia Wiki" used anymore? Or does our wikiware have no
>>name? :-(
>
> Sure it has a name: "Phase III Software".

Phase I: A lot of hot air.
Phase II: A rather liquid state of affairs.
Phase III: The software seems a lot more solid now!

-- brion vibber (brion @ pobox.com)


subject:
[Wikipedia-l] "Copyright violation" question (just the opposite
 of what you think)

body:
Ray Saintonge wrote:
> This points to a need for a policy on procedures when someone suspects a
> copyright violation.  I suspect that this issue will arise more
> frequently as  Wikipedia becomes bigger.  It doesn't do to have members
> deleting articles on the mere suspicion that it may violate copyright.

Well, we can start by experimenting with potential policies on
[[Duesseldorf]] and [[Great Sandy desert]], both of which are recent
additions to the wiki which include text that is duplicated verbatim
on/from an external website without a citation.

My first step was to ask in the Talk: page about source & copyright
status, noting the similarity with given URLs.

-- brion vibber (brion @ pobox.com)


from_name: Fred Bauder

subject:
[Wikipedia-l] Problems with anonymous editing of Middle
  Eastern conflict-related articles

body:
At 10:18 AM 7/31/02 +0200, Uri Yanover wrote:

A long eMail about problems with the [[controverial issue]]s of Palestine
and Israel.

I'm not sure folks should be blocked from making anonymous contributions,
but what I would like you to do, if you have the time and expertise is to
do something about the shape the articles have gotten into.

For example, the Palestine article has become quite long and unwieldy,
impossible really to read or edit.  Is there some graceful way it would be
broken up into managable pieces? For example, could some of the history get
moved, perhaps into articles on Canaan, or the Philistines or Judea or
Roman occupation of Judea?

There is no need to feel like the Little Dutch Boy. You are not alone in
your view that the pages should be accurate nor are your opponents.

Fred Bauder


body:
At 04:36 PM 7/31/02 +1000, Karen AKA Kajikit
> wrote:
>Another page that mangles itself, with a table this time. I wonder if
>it's the result of a page wider than will fit on the screen?
>
>http://www.wikipedia.com/wiki/Zhou_Dynasty_%28690_AD_-_705_AD%29

I couldn't duplicate this with my Netscape 4.7, but I had the sidebar off
here. Which is what I have had to do to use the new software. I just
generally hate sidebars anyway.

Fred Bauder


from_name: Jimmy Wales

body:
Lars Aronsson wrote:
> Here is one method: Do nothing until the copyright owner presses
> charges.

Well, "pressing charges" is a bit late in the game.  Under the DMCA,
an ISP has a "safe harbor" against copyright violations by users, so
long as there is a "takedown" policy in place.  Upon the receipt of a
proper written complaint, I'm required to take down the disputed
material.  If the person who posted it wants to make a proper written
response claiming to have the right to the material, then I can put it
back up pending those two parties suing each other, but my liability is
limited.

However, we have other concerns that extend beyond mere legal liability.

First, we want to have a solid reputation for the intrinsic reason
that we want our encyclopedia to be a good one, well respected, and
useful.  We don't want to get the reputation of "the so-called
encyclopedia that really just stole articles from all over the web."

Second, we want potential licensees to have a level of comfort about
the content.  Print publishers will not have the protection of the
DMCA ISP safe harbor provisions, and so they will desire to have a
stronger defense than a laissez-faire attitude on our part could
provide.

--Jimbo


body:
At 09:59 PM 7/31/02 +1000, Karen AKA Kajikit asked:

>If you have the sidebar off how do you get to all the pages? I find it
>essential!

In the standard skin there is a pulldown menu at the top labeled special
pages.

Fred Bauder


subject: [Wikipedia-l] Editing a redirected page

body:
If one attempts with the new software to edit a redirected page (by
fiddling with the URL) one is simply redirected to the destination.

So it becomes impossible to resurrect a page once it has been redirected.

Fred Bauder.


body:
Jimmy Wales wrote:

>Lars Aronsson wrote:
>
>>Here is one method: Do nothing until the copyright owner presses
>>charges.
>>
>
>Well, "pressing charges" is a bit late in the game.  Under the DMCA,
>an ISP has a "safe harbor" against copyright violations by users, so
>long as there is a "takedown" policy in place.  Upon the receipt of a
>proper written complaint, I'm required to take down the disputed
>material.  If the person who posted it wants to make a proper written
>response claiming to have the right to the material, then I can put it
>back up pending those two parties suing each other, but my liability is
>limited.
>
Of course, in the general case, waiting until someone presses charges is
waiting too long to do anything, though there may still be anxious
plaintiffs who try to by-pass earlier steps.  Hopefully those cases
would be thrown out of court for failing to give a proper notice to the
ISP in the first place. It does seem to me that "proper written
complaint" involves more than a complete stranger appearing out of
nowhere and saying "That's mine!"; there has to be a modicum of evidence
that he has the right to make that demand.

Steve's "Tsvetaeva" article appears to present quite a different
situation.  I have no reason to doubt that he had the original copyright
on the material, and that at some point he chose to abandon that
copyright - all this over a twelve year period.  We are really dealing
with the situation where something which has gone into the public domain
has ben used or incorporated into someone else's work, and a blanket
copyright on that user's application has been alleged to apply on a part
of that work that was no longer copyright.

This is a risk of success.  As Wikipedia develops a positive reputation
for its content we can expect a lot more of this to happen.  In
practical terms there will always be a time lag while things unfold, if
for no other reason than that it takes time for our unknown plagiarist
to "research" and put his material together.  Logs and other proof can
be kept.  Under U. S. copyright law what I write today goes into the
public domain on Jan. 1, 2098.  This letter is covered by GNU-FDL, but
if my great-grandson chooses to dispute the fact in the year 2070, what
evidence will remain?  (assuming that I had not raised the subject in
the letter)   What confidence can we have that Jimmy will be able to
argue the point at that time?

Even if every Wikipedia article has GNU-FDL statement attached there is
no practical way of enforcing it upon all users.  At some point I read
something from Lee where he had imbedded a watermark into a picture that
he uploaded.  It would probably be helpful to embed a watermark that
claims coverage under GNU-FDL in every picture that is uploaded;
something of the sort could probably also happen with material in other
special media such as sound.  Text material will remain a problem.  It
would also be an interesting experiment to put watermarked and
undisputedly legal but very desirable illustrations into some of the
most popular articles, and try to track what happens to them on the net.

It is without regret that I predict that the copyright industry will
eventually become the victim of its own recent successes.  Disney's
mouse has been eating cheese for 75 years, but wholesome family values
have inhibited any suggestion that in all that time he ever had to
relieve himself in the can.  A mouse that is so full of shit will just
have to blow up sooner or later.

Eclecticology


subject: [Wikipedia-l] Editing a redirected page

body:
> If one attempts with the new software to edit a redirected page
> (by fiddling with the URL) one is simply redirected to the
> destination.  So it becomes impossible to resurrect a page once
> it has been redirected.

When you arrive at a redirected page, you'll notice that the
subtitle is "Redirected from..." with a link; that link will take
you to the original page.  Clicking "edit" while there will edit
the redirect page, not the destination.  You'll notice that
"redirect=no" has been added the URL--if you want to use the
URL directly, you'll have to do that too.


from_name: Uri Yanover

subject: [Wikipedia-l] Problems with anonymous editing of Middle Eastern conflict-related articles

body:
Dear Wikipedians,

I've wanted to write this letter for a long time, but has delayed it deeming
the upkeep of Wikipedia principles more important than my comfort. But the
principles become broken anyway, and my comfort is as well gone; therefore
I'll tell you what troubles me below.

It is not a secret that Wikipedia is at occasions the scene of massive
content wars between the supporters of various positions. This is natural
and expectable, the resolution coming at the end of each such war being an
improvement to the original article. However, there's one content war that
is unique, in several ways. It concerns the Arab-Israeli, and
Palestinian-Israeli conflicts.

During the recent months, Wikipedia has been the target of almost daily
twiddling, in sum amounting to vandalism, from different supporters of the
Arab position on the internet, most often editing the page anonymously. I do
not oppose them stating their views; however, their style of modifying bits
here and there, copy & pasting copyrighted articles, linking to pages of
explicitly propagandist nature, coupled with the fact that they do not have
a clue of what NPOV and Wikipedia in general is all about, creates a serious
problem.

On the other side of this equation, however, there's me. There aren't too
many people who are aware of the complex history of the region on Wikipedia;
out of them, there are fewer less who are ready to share they knowledge (by
risking to pace on the mine-field of political discussions). Although I do
not claim to be deeply knowledgeable, it is often only up to me to include
the Israeli perspective in these articles.

This is not to say that I don't get any help from you - I often do, and I'm
deeply grateful for it. But unfortunately, I am one man, yet what I face is
a whole horde of anonymous trolls. Just removing random changes and fixing
"omissions" takes all the time I can spare for Wikipedia; considering the
growing popularity of the site, I have to admit that my outlook on further
contribution grows grimmer; needless to say that this disappoints me, as I
have a deep sympathy to the Wikipedia effort, and politics (in forms
relevant to this discussion) are far from being on the list of my favorite
topics.

The basic premise of the Wiki concept is that in an open environment, an
article which can be edited by many participants, enjoys peer cooperation,
and as a result becomes better. I feel that this premise cannot work in this
case, as the troll cut-ins are random, and they certainly are not interested
in improving the article. The situation is too heated-up to allow normal
cooperation.

I should make it clear that in such an environment, my own ability to write
good-quality content (that is belonging to a NPOV, researched,
carefully-worded) is impaired. It is not just my personal comfort that
suffers; trolling does hurt Wikipedia by creating biased content, which
could, if uninterrupted, in the long run jeopardize Wikipedia's reputation
as a source representative and respective of different perspectives, and
showing understanding to various positions, not just one.

My request for you, then, is to block some of the most contested articles
(the list can be discussed elsewhere) from being edited by anonymous
("IP-only") users. Logged-in users will have access; whoever wishes to
include his points, will be able to do it in the traditional Wiki fashion -
by debate and cooperation. It seems to me as the optimal way of promoting
the peaceful conclusion of this content war - by disarmament, and minimal
impairing of Wiki rights.

If you have any other proposals - I'll be glad to know them. I do not know
which course we shall ultimately take, but I am confident that it is in our
power to bring about a proper, comprehensive solution for this situation.

With deepest respect,
            Uri Yanover


from_name: tarquin

body:
Daniel Mayer wrote:

>On Tuesday 30 July 2002 12:01 pm, you wrote:
>
>
>>I volunteered ages ago to try & reorganise naming conventions .......
>>Any objections if I discreetly set up in a corner of MetaWikipedia?
>>
>>tarquin
>>
>>
>
>If you are planning on doing major work then I also suggest that you do as
>Lee indicated and make a /Temp page so that everybody can monitor the process
>and help out easily (especially me since I promised to do the exact same
>thing). However, if you are doing work that will not really leave the page
>
>
>looking incomplete or messy during the process then I say we just un-protect
>the page and let you go at it (I can't remember, are your a sysop? We have so
>many now...).
>
It's major work in the sense that the page structure & names may be
different to what currently exists.  I'm not *exactly* sure what I'm
aiming for yet either... hence my idea to set up fresh.
A link on the existing Naming pages to the work in progress would be
good, as I'd be very glad of input :-)
I'm not a sysop -- could I be made one?

tarquin


subject: [Wikipedia-l] 'old hand' status

body:
>maveric149 wrote in part:
>
>>Again I would like to restate my proposal
>>to have an 'old hand' status that
>>would allow users that have been around
>>a while and are generally trusted to
>>move pages and edit protected pages.
>
>I don't think that I've done this before,
>so I'd like to officially state my
>agreement on this. 30 days/30 edits,
>mentioned before, seems reasonable offhand.
>Is there agreement that we do want to open
>up these two functions, and that the only
>thing left to discussion is the criteria?
>...
>-- Toby Bartels

There seems to be a growing consensus that these two
functions should be available to many more users than
they are now.

The 30 day AND 30 edit automatic promotion idea was
really an off hand suggestion of mine. The 30 day part
seems reasonable enough to me but I am now not sure
about the 30 edit part -- which may be a ridiculously
low number of edits for an entire month. What does
everyone else think? Would changing the criteria to 30
_pages_ edited AND 30 day old account seem more
reasonable?

During my first month I averaged 10 edits a day --
most which were clustered around several different
pages per day. I still easily surpassed 30 pages
edited in a month. Heck, if we wanted to we could even
make it 30 pages edited in the article namespace in
order to promote editing of articles over chatter on
talk or user pages (which I know I am guiltily of --
sorry, I developed a bad habit in my early wiki
days..). At any rate I don?t think any harm will be
done to those that take two or three months to hit the
30 edit/pages edited/articles edited threshold -- we
are in fact giving users /extra/ features and not
holding back current ones.

LDC -- would it be possible/easy to allow an 'old
hand' (or whatever we decide to call this ? I never
liked "trusted hand" though) the ability to edit a
protected page /without/ being able to
protect/unprotect the page (which is a meta function
that should be limited to admins me thinks)?

Also, if we do decide to reinstate the "vote for?"
convenience feature, should this also be something
only available to 'old hands' and above (newbies of
course being less familiar with NPOV and our deletion
policy)? There still would be nothing stopping newbies
from bookmarking, linking to or searching for the
various "vote for" pages and editing them manually (as
we all have to do now). This would be an added bonus
for users as they graduate to 'old hand' status.

If we do choose to have a 'old hand' status, then the
only special features admins would have available to
them would be meta functions: page deletion, page
protection/un-protection, blocking IPs and the ability
to promote/demote users to/from ?old hand? and admin
status (just as it was in phase two -- although
"trusted hand" was a clone of "user" then). Admins
could also be encouraged to promote newbies who
obviously understand our policies and guidelines
earlier than 30 days to 'old hand' status before they
are automatically promoted.

--mav

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


list: wikitech-l

subject: [Wikitech-l] Logging in?

in_reply_to: <B96DB144.248A%cunctator@kband.com>; from cunctator@kband.com on Wed, Jul 31, 2002 at 03:22:44PM -0400

body:
Yeah, me too!

The Cunctator wrote:

> How come I don't stay logged in permanently once I log in now? In other
> words, why have the cookies been set to expire session/daywise?
>
> They shouldn't, I don't think.
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


subject:
[Wikipedia-l] "Copyright violation" question (just the
 opposite of what you think)

body:
>Of course, in the general case, waiting until someone presses charges is
>waiting too long to do anything, though there may still be anxious
>plaintiffs who try to by-pass earlier steps.  Hopefully those cases
>would be thrown out of court for failing to give a proper notice to the
>ISP in the first place.

Problem is that happy sequence will cost you a couple of thousand bucks.

Fred Bauder


subject: [Wikitech-l] Logging in?

body:
Yes, I always do that, but I always end up having to log back in the next day.

I have not investigated in a proper manner, so I will shut up until I do that.  :-)

Brion VIBBER wrote:

> Jimmy Wales wrote:
>  > The Cunctator wrote:
>  >>How come I don't stay logged in permanently once I log in now? In other
>  >>words, why have the cookies been set to expire session/daywise?
>  >>
>  >>They shouldn't, I don't think.
>  >
> > Yeah, me too!
>
> Did you click the checkbox for "Remember my password across sessions"
> when you logged in?
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at ross.bomis.com
> http://ross.bomis.com/mailman/listinfo/wikitech-l


from_name: Steve Callaway

body:
I have substantially refactored and will continue to refactor this article
until it does justice to a poet I rate in the very highest rank. It was a
straight cut and paste job from my original handout, and I never really
bothered to do much to it other than to expand my notes about Marina
Tsvetaeva's poetry. It looks very very jaded now, particularly in the light
of Viktoria Schweizer's biography. Some of it is just //wrong// e.g. the
Lily Feiler comments, the dates of Tsvetaeva's mother's TB, etc. We need
some way, however, of benchmarking our stuff which we import from our
private work, because otherwise this type of issue will surface from time to
time. Maybe a source comment on the /Talk page would be sufficient so that
people are aware of who's done what.

----- Original Message -----
From: "Daniel Mayer" <maveric149 at yahoo.com>
To: <wikipedia-l at nupedia.com>
Sent: Wednesday, July 31, 2002 7:37 AM
Subject: [Wikipedia-l] "Copyright violation" question (just the opposite of
what you think)

> I just had an interesting experience with an apparent copyright violation.
>
> The text in [[Marina Tsvetaeva]] is very similar and in many cases exactly
> the same as text in an external website. One user deleted the text in the
> article citing a copyright violation on our end. Even though I saw obvious
> similarities between our version and theirs I wasn't so sure /we/ were the
> ones who violated copyright because the article existed in pretty much the
> same form since before the move from the UseMod wikiware back in February.
>
> My suspicion that we in fact were not violating any copyright was
confirmed
> when user:sjc claimed authorship and stated that the text had been in the
> public domain for 12 years.
>
> I am not sure if the external website used the public domain version by
sjc
> or one of our earlier versions, but as Wikipedia grows we will
increasingly
> find apparent copyright violations on our end that are in fact just the
> opposite: other websites taking our text and using it in a way that is not
> compatible with our license (there is also the issue of public domain text
> too.... Remember, cite your sources!).
>
> What should we do in such cases? Furthermore, should we make a rule that
if a
> Wikipedia article "fails" the Google test AND is over a set number of
weeks
> old, then we should give the original contributor the benefit of the doubt
> and /not/ delete the text?
>
> We almost lost a great article on Marina Tsvetaeva and I don't want to
lose
> any others due to this type of mixup.
>
> --mav
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] Sysop status

body:
Yes.  I'm assuming that is the rule about making things redirects
instead, and keeping old pages in the database to avoid 404 errors
from search engine results.  (new junk pages with no useful content
can be deleted safely).  MANY deletions violate this rule.

kq

Jeroen Heijmans wrote:
>Also, because much of the deletions that do occur do not comply with
the Wikipedia
>policy on permanent deletion of pages (especially rule 6), I'm
sometimes confused.


subject: [Wikitech-l] Logging in?

body:
Jimmy Wales wrote:
 > The Cunctator wrote:
 >>How come I don't stay logged in permanently once I log in now? In other
 >>words, why have the cookies been set to expire session/daywise?
 >>
 >>They shouldn't, I don't think.
 >
> Yeah, me too!

Did you click the checkbox for "Remember my password across sessions"
when you logged in?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Sysop status

body:
>Yes.  I'm assuming that is the rule about making things redirects
>instead, and keeping old pages in the database to avoid 404 errors
>from search engine results.  (new junk pages with no useful content
>can be deleted safely).  MANY deletions violate this rule.

I'm probably a major offender here, so I'd like to argue that perhaps
the policy needs to be changed or clarified.  First, articles that
have no content or history should be deletable with less formality.
What we want to prevent is the loss of content.

Secondly, Wikipedia is dynamic in nature, and I don't think we should
play by the same rules as static websites in terms of keeping old
links alive.  Certainly in some cases it's warranted; if someone
moves "James Earl Carter" to "Jimmy Carter", and the old one has been
around for a long time (not just a few days), then it's reasonable to
expect that there may be external links to it and there's no reason
not to leave the redirect.  But if it is, say, a misspelling, I'd
rather just delete it.  We are under no obligation to keep our
mistakes around forever, and if someone links to it and finds it
broken, we have done him a service by forcing him to correct it.
Likewise, if someone creates a page and I think it needs a different
title, if I catch that error within a day or two and move it, I'll
just delete the old title.  There's not point in cluttering the
database with a redirect that's just a mistake, and hasn't been
around long enough to accumulate links.

And finally, anything outside encyclopedia namespace should be more
freely deletable as well.  Anyone who links to a talk page deserves
what he gets.


subject: [Wikipedia-l] Re: Parsing

body:
> I've hacked the phpwiki code to add a new namespace
> [[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
> [[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].
>
> The code will make TeX create an image (PNG) of the formula. Those
> images will be cached, they will be created only once and will be
> shared between articles. ( [[math:E=m c^2]] might be used on many
> pages ).

That's almost exactly what I had in mind; only I think it would be
better for the back end to have to have a spearate process
communicating with the Wiki code over IPC--the "TeX server"--
which will take formulas and return images, out of a cache if
they've been rendered already, calling TeX to render them if needed.
The cache will be indexed by a hash function on a canonicalized
text of the expression.

The wiki end of this won't be hard.  The other server is the real
work.  I'm afraid I can't take on that project right now, but if
that server gets built, I'll be happy to call it.


subject: [Wikipedia-l] Sysop status

body:
good points, all.  Should we reconsider/clarify/expand on the policy?

kq

Lee wrote:
>I'm probably a major offender here, so I'd like to argue that perhaps
>the policy needs to be changed or clarified.  First, articles that
>have no content or history should be deletable with less formality.
>What we want to prevent is the loss of content.
>
>Secondly, Wikipedia is dynamic in nature, and I don't think we should
>play by the same rules as static websites in terms of keeping old
>links alive.  Certainly in some cases it's warranted; if someone
>moves "James Earl Carter" to "Jimmy Carter", and the old one has been
>around for a long time (not just a few days), then it's reasonable to
>expect that there may be external links to it and there's no reason
>not to leave the redirect.  But if it is, say, a misspelling, I'd
>rather just delete it.  We are under no obligation to keep our
>mistakes around forever, and if someone links to it and finds it
>broken, we have done him a service by forcing him to correct it.
>Likewise, if someone creates a page and I think it needs a different
>title, if I catch that error within a day or two and move it, I'll
>just delete the old title.  There's not point in cluttering the
>database with a redirect that's just a mistake, and hasn't been
>around long enough to accumulate links.
>
>And finally, anything outside encyclopedia namespace should be more
>freely deletable as well.  Anyone who links to a talk page deserves
>what he gets.
>
>
>
>
>
>[Wikipedia-l]
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l


body:
Hmm. Well, in a way I think we should be much more proactive in checking
copyright. It will also help to highlight deficient articles (the Tsvetaeva
one which was considered initially problematic was a stinker).

I have done a major refactoring of the Tsvetaeva article today; it will be
interesting to see whether this one gets "borrowed" at any point. There were
a number of factual inaccuracies in the original article, + a lot of hearsay
evidence and these have now been corrected. It is also an altogether more
balanced and encyclopaedic piece, concentrating on the specifics rather than
my own take on things.

----- Original Message -----
From: "Lars Aronsson" <lars at aronsson.se>
To: <wikipedia-l at nupedia.com>
Sent: Wednesday, July 31, 2002 2:31 PM
Subject: Re: [Wikipedia-l] "Copyright violation" question (just the opposite
of what you think)

Ray Saintonge wrote:
> This points to a need for a policy on procedures when someone suspects a
> copyright violation.

Here is one method: Do nothing until the copyright owner presses
charges.  This way, we can all focus on writing new articles and avoid
wasting time on playing police.  Maybe this is too easy.  Does it need
to be more compliated?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: The Cunctator

subject: [Wikipedia-l] 'old hand' status

body:
Official hierarchies of users are still undesirable, whether they're called
an "old hand" or not.

I still strongly believe in
http://www.wikipedia.com/wiki/The+Cunctator/How+to+build+Wikipedia

(See "Avoid Cabals".)


subject: [Wikitech-l] Logging in?

body:
How come I don't stay logged in permanently once I log in now? In other
words, why have the cookies been set to expire session/daywise?

They shouldn't, I don't think.


from_name: Karen AKA Kajikit

body:
I just tried to submit an error report on a display problem... it saved
okay, but then I realised that I forgot to include my email, or where in
the wikipedia I saw the problem etc... so I attempted to add a comment,
and it didn't want me to. So then I tried to write a seperate error
report to attach a screenshot, and it timed out and gave a 'zero data'
error. So I tried to resubmit the report AGAIN and it told me not to
double-submit. GRRRRRRR...

It's not like the problem is a big issue - Netscape does not like
right-aligned inline images - they interfere with the display of the
floating toolbar and push it down to the bottom of the page below the
entry. It's a nuisance and it makes the page look messy and be a bit
more awkward to use, but it's not a major problem. The buttons still
work, they're just in the wrong place.

I'll put the screenshot in here since I went to all the trouble of
taking 3 shots and pasting them together in photoshop and resizing them
etc...

--

Karen AKA Kajikit

You can take the dragon out of Alfandra, but you can never take Alfandra
out of the dragon (or the Kitty)...

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
and now Ample Aussies Mailing List:
http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maltaentryscreenshot.jpg
Type: image/jpeg
Size: 24431 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020731/40ae9c73/attachment.jpg


from_name: Lars Aronsson

body:
Ray Saintonge wrote:
> This points to a need for a policy on procedures when someone suspects a
> copyright violation.

Here is one method: Do nothing until the copyright owner presses
charges.  This way, we can all focus on writing new articles and avoid
wasting time on playing police.  Maybe this is too easy.  Does it need
to be more compliated?

--
  Lars Aronsson (lars at aronsson.se)
  Aronsson Datateknik
  Teknikringen 1e, SE-583 30 Linuxk?ping, Sweden
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Re: Parsing TeX

body:
On 7/31/02 3:20 PM, "Jens Frank" <JeLuF at gmx.de> wrote:
> Building an interpreter as mighty as TeX to process formulas is a big
> task, and using PHP would take very long to parse one formula.
>
> I've hacked the phpwiki code to add a new namespace
> [[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
> [[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].
>
> The code will make TeX create an image (PNG) of the formula. Those
> images will be cached, they will be created only once and will be
> shared between articles. ( [[math:E=m c^2]] might be used on many
> pages ).
>
> Processing one formula took about one minute on a very old 486/DX2,
> why I didn't submit the code to LDC for review or comments, yet.
>
> Do we have numbers of the utilization of the server, whether a
> feature like this can be added?
>
We should see what PlanetMath is doing/work with them. They're a GFDL
math-encyclopedia using TeX and some interesting back-end software. There's
no need for us to reinvent the wheel if not necessary.


body:
Another page that mangles itself, with a table this time. I wonder if
it's the result of a page wider than will fit on the screen?

http://www.wikipedia.com/wiki/Zhou_Dynasty_%28690_AD_-_705_AD%29

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' - and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


from_name: Hr. Daniel Mikkelsen

subject:
[Wikipedia-l] Problems with anonymous editing of Middle Eastern
 conflict-related articles

body:
On Wed, 31 Jul 2002, Uri Yanover wrote:

> It is not a secret that Wikipedia is at occasions the scene of massive
> content wars between the supporters of various positions. This is natural
> and expectable, the resolution coming at the end of each such war being an
> improvement to the original article. However, there's one content war that
> is unique, in several ways. It concerns the Arab-Israeli, and
> Palestinian-Israeli conflicts.
>
> During the recent months, Wikipedia has been the target of almost daily
> twiddling, in sum amounting to vandalism, from different supporters of the
> Arab position on the internet, most often editing the page anonymously. I do
> not oppose them stating their views; however, their style of modifying bits
> here and there, copy & pasting copyrighted articles, linking to pages of
> explicitly propagandist nature, coupled with the fact that they do not have
> a clue of what NPOV and Wikipedia in general is all about, creates a serious
> problem.
>
> On the other side of this equation, however, there's me. There aren't too
> many people who are aware of the complex history of the region on Wikipedia;
> out of them, there are fewer less who are ready to share they knowledge (by
> risking to pace on the mine-field of political discussions). Although I do
> not claim to be deeply knowledgeable, it is often only up to me to include
> the Israeli perspective in these articles.

I hold opinions opposite to your viewpoint in these matters (pro-Palestine),
and from this end the problem looks very different. There are tons of Middle
East articles, and they're far too large, and (IMO) are generally only NPOV on
the surface, the deep bias is Israeli.

When I touched some of these articles, my additions and changes were generally
reverted, and the original (imo) biased viewpoints often strengthened. There
were at least four people doing this, you included, and it made me feel very
powerless and depressed about Wikipedia in its entirety. (This is part of the
reason I've called for an npov-dispute page, to be linked to from articles like
this).

However, it appears the situation has changed. Browsing a few of the articles
lightly today I find they're less biased than they used to be, and from your
comments it appears there are fewer stone-walling people maintaining them.

Any conclusions? I still think most of these pages aren't really npov. Someone
suggested splitting up the articles and shortening them - I think that would be
a very good idea. I also think these articles should be marked much more
clearly as being controversion - so that people won't so easily be provoked by
the content being passed off as encyclopedic facts.

While I'm not up to date as to the current content of these articles, I
consider the earlier (and perhaps current) large scale bias in the article to
be just as big a problem as small but numerous vandalisms.

-- Daniel


from_name: Jeroen Heijmans

subject: [Wikipedia-l] Sysop status

body:
Daniel Mayer wrote:

> I say Jeroen and Danny would make a great sysops. However I know Jeroen used
> to use the "vote for deletion" feature of phase II Pedia Wiki a lot and at
> least several of the entries submitted had to be removed from the deletion
> queue as not being valid for administrative removal. But I still trust that
> Jeroen will /not/ abuse the delete page sysop feature and when there is /any/
> question that a page should be removed that that page be first placed on the
> vote for deletion page for a day or two -- which is the general policy anyway.

Yes, I'm aware of that; it's actually the reason I didn't consider becoming a sysop before.

Also, because much of the deletions that do occur do not comply with the Wikipedia
policy on permanent deletion of pages (especially rule 6), I'm sometimes confused.
The vote feature allowed me to state my opinion without using a Talk-page; if somebody
disagreed (usually Maveric), that was fine with me. Which reminds me: LDC said on
Sourceforge that the voting feature needs to be discussed before it comes back. I agree
with Maveric that it should come back; any objections?

> Unfortunately, LDC never got around to porting the promote/demote feature of
> Phase II to Phase III, so Jimbo (possibly a developer) will have to promote
> you two. I'm sure nobody will object to your promotion.

LDC himself has already contacted me to do the job, so he's working on it.


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] External use of main wiki uploads

body:
To my international friends, let me first say that I haven't
forgotten you, and upgrading the international wikis is high on my
agenda (see, for example, http://www.piclab.com/wikitest/wiki.phtml ,
which is the new software in German, courtesy of Magnus Manske.)

But, it's a slow process. In the meantime, I'd like to ask that those
of you who handle the policy and instruction pages on the active
international wikis please make it a written policy, and try to
enforce, that if you upload a file for use by a foreign wiki, make a
note of that on the image description page.  That way, we'll know not
to delete it as an orphan, and we'll have a better idea what needs to
get copied over when we do install the new software (after which e'll
have to separate the image directories).

I'm not quite ready to solicit translations yet (there is still a
feature or two I want to add first), but those of you who think you
may be taking on the translation task might want to browse the new
code base (see http://wikipedia.sourceforge.net ) and compare the
files "Language.php" and "LanguageDe.php" to see what needs to be
done and estimate the work (Magnus did it a couple of days).


from_name: Daniel Mayer

subject: [Wikipedia-l] 'old hand' status

body:
On Wednesday 31 July 2002 03:49 pm, you wrote:
> Official hierarchies of users are still undesirable, whether they're called
> an "old hand" or not.
>
> I still strongly believe in
> http://www.wikipedia.com/wiki/The+Cunctator/How+to+build+Wikipedia
>
> (See "Avoid Cabals".)

Who is expanding the influence of a creating a Cabal (like we ever agree on
anything)? How is allowing the majority of active users the ability to edit
the Main Paqe and other protected pages and the ability to administratively
move pages a top heavy approach? Denying the majority of active users the
ability to do these things is rather un-wiki in my book.

I might be wrong, but wouldn't taking powers previously only usable by a
relative few and allowing a great deal more people to have them, tend to
democratize things?

Wikipedia is a large target and admins are needed to protect the site from
constant vandal abuse and unclutter the database as LDC puts it. This allows
most users to concentrate on creating and editing content.

Old hands will be needed to help maintain Wikpedia and the history of its
articles and all users regardless of database status will do what they always
have done; contribute like hell and learn the wiki way by helping create what
someday might very well be the best darn encyclopedia there is.

--mav


from_name: Pierre Abbat

subject: [Wikipedia-l] Talab.jpg

body:
It's in Arabic. Can anyone here figure out what it means?

phma


from_name: Jens Frank

subject: [Wikipedia-l] Re: Parsing

body:
> >I haven't changed any <var> tags, though I have created formulae myself
> >with '' around variables, because I'd seen it done like that.
> >The $$ for <var> idea is interesting, but I don't think it will make
> >formulae significantly easier on the eye in raw form.
>
> I don't think that the '' version is easy on the eye either.
> Easy on the eye would be a limited implementation of TeX
> that would render the wiki input $$x^2 y = z_1$$ into HTML as
> <var>x</var>2<var>y</var>?= <var>z</var>1.
> But that opens up its own whole new can of worms.
> OTOH, $$x$$2$$y$$?= $$z$$1 would be an improvement,
> and $$x$$^^2^^$$y$$?= $$z$$__1__ would be even better.
> (This won't quite work, since ^^ and __ can't be interpreted as toggles,
> but I'm not sure how to deal with that right now.)

Hi,

Axel Boldt proposed to have some elegant way to include TeX-formulas
into wiki text.

Building an interpreter as mighty as TeX to process formulas is a big
task, and using PHP would take very long to parse one formula.

I've hacked the phpwiki code to add a new namespace
[[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
[[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].

The code will make TeX create an image (PNG) of the formula. Those
images will be cached, they will be created only once and will be
shared between articles. ( [[math:E=m c^2]] might be used on many
pages ).

Processing one formula took about one minute on a very old 486/DX2,
why I didn't submit the code to LDC for review or comments, yet.

Do we have numbers of the utilization of the server, whether a
feature like this can be added?

Regards,

JeLuF


subject: [Wikipedia-l] Re: Parsing TeX

body:
On Wed, Jul 31, 2002 at 03:34:10PM -0400, The Cunctator wrote:
> We should see what PlanetMath is doing/work with them. They're a GFDL
> math-encyclopedia using TeX and some interesting back-end software. There's
> no need for us to reinvent the wheel if not necessary.
>

As far as I can tell they write entire articles in (La)TeX, converting them
using LaTeX2HTML, which does much more than just converting formulas. I
tried to embedd LaTeX2HTML first, and it was more work than writing a
feature-reduced LaTeXformula-2-PNG.

Regards,

JeLuF


body:
Fred Bauder wrote:
>
> At 04:36 PM 7/31/02 +1000, Karen AKA Kajikit
> > wrote:
> >Another page that mangles itself, with a table this time. I wonder if
> >it's the result of a page wider than will fit on the screen?
> >
> >http://www.wikipedia.com/wiki/Zhou_Dynasty_%28690_AD_-_705_AD%29
>
> I couldn't duplicate this with my Netscape 4.7, but I had the sidebar off
> here. Which is what I have had to do to use the new software. I just
> generally hate sidebars anyway.

If you have the sidebar off how do you get to all the pages? I find it
essential!

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


subject: [Wikipedia-l] Page deletion (was: Re: Sysop status)

body:
lcrocker at nupedia.com wrote:

>>Yes.  I'm assuming that is the rule about making things redirects
>>instead, and keeping old pages in the database to avoid 404 errors
>>
>>
>>from search engine results.  (new junk pages with no useful content
>
>
>>can be deleted safely).  MANY deletions violate this rule.
>>
>>
>
>I'm probably a major offender here, so I'd like to argue that perhaps
>the policy needs to be changed or clarified.  First, articles that
>have no content or history should be deletable with less formality.
>What we want to prevent is the loss of content.
>
>Secondly, Wikipedia is dynamic in nature, and I don't think we should
>play by the same rules as static websites in terms of keeping old
>links alive.
>
I've posted a suggestion that would help this.
It's also at the foot of this page:
http://www.wikipedia.com/wiki/Wikipedia_talk%3AWikipedia_policy_on_permanent_deletion_of_pages

see the "Suggestion for non-existing pages" section. It's already posted
to SourceForge


from_name: Neil Harris

subject: [Wikipedia-l] Re: Parsing TeX

body:
The Cunctator wrote:

 >On 7/31/02 3:20 PM, "Jens Frank" <JeLuF at gmx.de> wrote:
 >
 >
 >>Building an interpreter as mighty as TeX to process formulas is a big
 >>task, and using PHP would take very long to parse one formula.
 >>
 >>I've hacked the phpwiki code to add a new namespace
 >>[[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
 >>[[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].
 >>
 >>The code will make TeX create an image (PNG) of the formula. Those
 >>images will be cached, they will be created only once and will be
 >>shared between articles. ( [[math:E=m c^2]] might be used on many
 >>pages ).
 >>
That's a _really brilliant_ hack -- the idea of using the TeX code as
the name of a page is the obvious right thing!
We should have a garbage-collector sweep up orphan math: pages every so
often.
We should also be really cautious about TeX doing insecure things. Is
there a subset of TeX syntax we could parse and validate before we pass
it to TeX?

 >>
 >>Processing one formula took about one minute on a very old 486/DX2,
 >>why I didn't submit the code to LDC for review or comments, yet.
 >>
 >>
The new server should run that code in about 0.5 second on one of its
two processors, given typical CPU scaling figures.
See http://field.hypermart.net/CPU/cpu.htm

 >>
 >>


subject: [Wikipedia-l] Net-safe TeX code

body:
Also, see this discussion on making TeX safe.

http://hilbert.math.albany.edu:8800/hm/emj/1995/msg00121.html
http://hilbert.math.albany.edu:8800/hm/emj/1995/msg00134.html

Neil


subject: [Wikipedia-l] Sample: TeX - Donald Knuth Markup Language for Mathematical Text

body:
As I understand it, the problem with TeX is that it is an absolutely
general Turing-complete programming  language, and you can change the
lexer on the fly, etc. We should use a subset of TeX with only the basic
symbol-rendering stuff, and very little else.

Here's a syntax for a subset of TeX macros in a vaguely BNF-style
notation, basically specifying anything that comes after a backslash.

http://www.csci.csusb.edu/dick/samples/comp.text.TeX.html
http://www.csci.csusb.edu/dick/samples/comp.text.TeX.Mathematical.html

Would limiting TeX to using only these macros make it
* safe?
* complete enough for our purposes?

If so, then we could write a TeX-parser that would "sanitize" (and
canonicalize, if necessary) any input TeX before letting the real TeX
interpreter see it. Probably using Bison and C.

Neil


subject: [Wikipedia-l] pyLaTeX - LaTeX Document Processing Framework

body:
PyLaTeX appears to have a TeX parser (and much more!) written in Python,
and it's at
http://pylatex.sourceforge.net/

I'm not sure of the licence. I guess if we restrict the macros to a
"safe" set, we shouldn't need any more than the lexical analyser.

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020731/2955f82f/attachment.htm


subject: [Wikitech-l] Re: Re: [Wikipedia-l] Re: Parsing TeX

body:
On Wed, Jul 31, 2002 at 02:02:48PM -0700, lcrocker at nupedia.com wrote:
> > I've hacked the phpwiki code to add a new namespace
> > [[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
> > [[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].
> >
> > The code will make TeX create an image (PNG) of the formula. Those
> > images will be cached, they will be created only once and will be
> > shared between articles. ( [[math:E=m c^2]] might be used on many
> > pages ).
>
> That's almost exactly what I had in mind; only I think it would be
> better for the back end to have to have a spearate process
> communicating with the Wiki code over IPC--the "TeX server"--
> which will take formulas and return images, out of a cache if
> they've been rendered already, calling TeX to render them if needed.
> The cache will be indexed by a hash function on a canonicalized
> text of the expression.
>
> The wiki end of this won't be hard.  The other server is the real
> work.  I'm afraid I can't take on that project right now, but if
> that server gets built, I'll be happy to call it.

Hi,

I moved this to wikitech-l since it will be much to detailed for
wikipedia-l.

The code is ready. It doesn't use IPC, no client/server. It only
exec's a shell script.

The PHP script creates a tempfile with suffix .tex and calls a
shellscript with the name of the tempfile as a parameter.

The script
- renders TeX to DVI using LaTeX
- converts DVI to eps using dvips
- renders eps to PNG using convert from ImageMagick
- removes all tempfiles created by LaTeX

The .png has the same name as the .tex. The name is the
MD5-Hash of the formula. The .png will placed in an
image directory of the webserver, in my implementation
it's /upload/, but should probably be different, e.g.
/upload/math/.

The PHP code than adds the formula and the name of the
image file to a new table in the database. Using this
cache it decides whether to render a formula.

It then replaces [[math:formula]] by
<img src="/upload/imagename.png" alt="formula" align="middle">
(OK, using the TeX-Formula as alt-text is not always really
readable, but always better than no alt-text at all)

The only thing still to be done is preparing some TeX preamble to
prevent something like

	[[math:\mbox{\include{"/etc/passwd"}}]]

Alternatively, everything could be installed chroot, but
this would have to include Apache and PHP and LaTeX.

The shell script looks like this:

#!/bin/sh
exec >> /tmp/tex2png.log
exec 2>&1
set -x
cd /tmp

echo $*
cat $1
echo

latex $1
dvips -E $1
convert -density 110 $1.ps $1.png
cp $1.png /home/jf/wiki/phpwiki/newcodebase/upload/
chmod a+r /home/jf/wiki/phpwiki/newcodebase/upload/$1.png
rm ${1}*

$1 is the hashcode of the formula.

Providing the diff of the PHP-code would take a little
time - I have to remove my attempts in wiki-table-markup
first.

For an example see

	http://jeluf.mine.nu/jf/newcodebase/wiki.phtml?title=Triangle

but please keep in mind - it's a 486/DX2 66 with 20 MB RAM,
a machine I normaly use for fetching mail only.

Regards,

JeLuF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020801/b1a7c942/attachment.pgp>


subject: [Wikipedia-l] Proposal for table syntax

body:
tarquin wrote:
>The key details are:
>* one cell per line (and not one row per line)
>* formatting information is seperate from data
>
>These both increase the clarity considerably. Someonoe who jsut wants to
>edit the data can skip the header line, no matter how ugly and
>comlicated it may be.

That also decreases the usefulness considerably.  One *cell* per line?  You couldn't organize data in columns--you couldn't have a piece of information with an explanation immediately beside it of what the information is, the way we have on the U.S. Presidents pages, the countries pages, the various tree of life pages....  You must have meant two, at least?

kq


from_name: Ray Saintonge

subject: [Wikipedia-l] suggestion: truncated watch list

body:
tarquin wrote:

>  Could the WatchList page be limited to a number of days like
> RecentChanges?
> Mine is getting rather long & it takes a while to generate.
> Maybe a truncated WatchList page could give a link to a complete
> watchlist which would be displayed as a dumb list with no dates &
> times of edits (which I presume is what causes the load on the server)

At the risk of being slightly sarcastic, wouldn't a better solution be
to edit your own WatchList to remove things that you no longer really
need to watch?
Eclecticology


subject: [Wikipedia-l] Proposal for table syntax

body:
Jan.Hidders wrote

>As I also suggested on the talk page of
>
>http://meta.wikipedia.com/wiki.phtml?title=Wiki_markup_tables
>
>why not something more WYSIWIG, like:
>* [| starts a table rule
>* |] ends a table rule
>* consecutive rules belong to the same table
>
>Like
>
>[| Name               || Bill Clinton  |]
>[| Musical instrument || Saxophone     |]
>
>-- Jan Hidders
>
I speak as a person who finds tables to be a struggle.  (My 12-year old
son had it figured out on the first day of a one-week web design course,
but that's another story.)    In the old days :-)   when typewriters
were in fashion you could put something in table form by simply using
the tab (or tabular)  key; an advanced typewriter user would even learn
to set tabs.  Now, even though word processing programs (perhaps
grudgingly) allow this use of the tab, I hesitate in other software
because the results are often unpredictable.

In those tab days (even before that name was usurped by a certain
soft-drink manufacturer) nobody even considered the possibility of
having his data in neat little boxes.  The HTML community has made it a
serious challenge for the user to get rid of them.  If you can't restore
the old function of the tab key then I vote for the one line=one row
approach as being more intuitive and more WYSIWIG.

The example above gives me cause for concern because it really only has
one data set.  What will it look like when you add Harry Truman's piano
or some other president's fiddle?

I very much believe that with most non-technical users the need for
tables of data will be on a very elementary level.  A person who wants
to fill in a table of presidents and their musical instruments will be
quite content to leave the complexities of the periodic table to someone
else.  Those of us who have contributed to the "List of Novelists" since
it has started to become an annotated list would probably find a table
format less ragged than what we have now, but a contributor
(particularly a newbie) may hesitate to do anything if he finds the code
too complicated.  Exaggerated mathophobia was once a characteristic of
English majors, and I would be surprised if that has changed.

Why can't we just bring back the tab?

Eclecticology


body:
>>  Could the WatchList page be limited to a number of days like
>> RecentChanges?
>> Mine is getting rather long & it takes a while to generate.
>> Maybe a truncated WatchList page could give a link to a complete
>> watchlist which would be displayed as a dumb list with no dates &
>> times of edits (which I presume is what causes the load on the
server)

>At the risk of being slightly sarcastic, wouldn't a better solution
be
>to edit your own WatchList to remove things that you no longer
really
>need to watch?

The software should be able to deal with capacity issues like this,
though I agree that it's probably better to have a smaller
watchlist.  Another suggestion is to just create a page under your
user space that's just a collection of links to the pages you're
interested in.  Then you can use the "Watch links" feature to look
for changes on all those pages, and the ones on your watchlist will
appear bold there, so you get a two-level watchlist.


subject: [Wikipedia-l] Proposal for table syntax

body:
I've pondered this & gone a bit radical. I've outlined an idea on meta:

http://meta.wikipedia.com/wiki.phtml?title=Wiki_markup_tables

The key details are:
* one cell per line (and not one row per line)
* formatting information is seperate from data

These both increase the clarity considerably. Someonoe who jsut wants to
edit the data can skip the header line, no matter how ugly and
comlicated it may be.

I've also put in details of table syntax from other wikis: the moinmoin
style used at Meatball and the Wookee format that has been implemented
on Unreal Wiki.

tarquin


from_name: Brion VIBBER

subject: [Wikipedia-l] Proposal for table syntax

body:
koyaanisqatsi at nupedia.com wrote:
> tarquin wrote:
>>The key details are:
>>* one cell per line (and not one row per line)
[..]
> That also decreases the usefulness considerably.  One *cell* per line?
 > You couldn't organize data in columns--you couldn't have a piece of
 > information with an explanation immediately beside it of what the
 > information is, the way we have on the U.S. Presidents pages,
 > the countries pages, the various tree of life pages....
 > You must have meant two, at least?

That's one cell per line of *markup*.

-- brion vibber (brion @ pobox.com)


body:
On Thu, Aug 01, 2002 at 02:11:46AM +0200, Jens Frank wrote:
>
> For an example see
>
> 	http://jeluf.mine.nu/jf/newcodebase/wiki.phtml?title=Triangle

It looks beautiful. That is going to make a lot of the contributers on
mathematics very happy. A few comments though:

I'd prefer a bit shorter and easier-to-read mark-up. Axel Boldt suggested [$
x \leq y $] and Toby Bartels $$ x \leq y $$. Since $$ already means
something in LaTeX I'd prefer Axel's suggestion. Maybe we could even let [$$
x \leq y $$] be a displayed formula? There should be a difference between
in-line and displayed formula.

It would be nice if we could stay close to what is done on planetmath.org so
that it wouldn't be too hard to interchange write-ups. They are working with
a separate preamble in which you can include extra packages. That's very
nice if you want to do special stuff like commuting diagrams in category
theory. However, I can see how that would complicate the implementation and
one could ask if it would be worth it. At least our assumed preamble should
be very similar to their default preable.

Concerning safety I think I'd prefer Lee's solution including a time-out for
TeX that takes too long to compute. It's the most robust solution and other
solutions like parsing (a limited subset of) TeX would probably mean that we
would have to decide which subset we support which would probably turn out
to be too restrictive.

-- Jan Hidders


subject: [Wikipedia-l] Proposal for table syntax

body:
>> tarquin wrote:
>>>The key details are:
>>>* one cell per line (and not one row per line)

>koyaanisqatsi at nupedia.com wrote:
>> That also decreases the usefulness considerably.  One *cell* per line?

brion vibber wrote:
>That's one cell per line of *markup*.

I'm on a roll misunderstanding things these days.  I'm glad school doesn't start again for a few weeks, and the GRE is well behind me.

kq


subject: [Wikipedia-l] New wiki markup

body:
There have been a lot of good suggestions for new wiki markup
elements, and the arguments about whether or not to continue
using/relying on HTML have brought up some good points on both sides,
but I think I'm growing more firmly entrenched in the "simplify,
simplify" position.

There is a tension of goals here: (1) the primary goal of our wiki,
as I see it, is to encourage the totally computer-inept to write and
edit articles.  Getting people like that to parse the text out of
<table> syntax and get the tags to match up right will just drive
them away.  (2) The goal to have pretty-looking articles.

We can solve the problem of tables by using a clean, easy to read,
and forgiving table markup syntax--I rather like tarquin's, although
I'd make it optional whether to put the cells of a row on one markup
line or subsequent lines, and it needs to do things like produce an
accurate table with sloppy markup that leaves out cells, and so on.

That still leaves us no way to specify headings, caption, spans, and
cell backgrounds, and the like.  We would also like to be able to do
things like float images, colorize text, and so on.

So here's a radical proposal: take more advantage of CSS to allow us
gurus to prettify articles without complicating the wikitext.  Create
some method of attaching an inline stylesheet to a page or group of
pages, and put things like image floats, table backgrounds, padding,
fonts, and so on in the style sheet, and leave the wikitext alone.

Of course, that will require some way for the stylesheet to identify
elements in the wikitext.  We can auto-number things like images and
tables, and use IDs, e.g., "#image1 {float:left; padding-
right:10px;}", etc.  But that leaves things like inline quotes,
formulas, and other needs.  We can probably take care of most of that
by coming up with a clean, unobtrusive way to indicate "span"
and "div" IDs in the wikitext.  Then that will be the only odd
markup, and everything else can go into the stylesheet.


from_name: Axel Boldt

subject: [Wikitech-l] DNS entry for wikipedia.com

body:
Are there any reasons that the DNS entry for wikipedia.com still
points to the old server rather than to the new? When I type a URL
into a browser, I always omit the "www", expecting that it won't make a
difference.

Axel


subject: [Wikipedia-l] Proposal for table syntax

body:
Since Wiki markup often ignores single \n, my proposal could be modified
to *allow* several cells per line.
However, I think the following is easily graspable:
||
| Name
| Bill Clinton
||
| Musical instrument
| saxophone
||

It's *long* in raw form, yes. But it's also clean.

||
| Name| Bill Clinton
||
| Musical instrument | saxophone
||

This is good too, but there's more work involved in finding the limits
between data. One could use spaces to set it out nively in raw form --
but then if the data changes the spaces change. It's a bit faffy.

I think my motivation stems on part form the rapidly growing table of
phonemes on the SAMPA page.

koyaanisqatsi at nupedia.com wrote:

>That also decreases the usefulness considerably.  One *cell* per line?  You couldn't organize data in columns--you couldn't have a piece of information with an explanation immediately beside it of what the information is, the way we have on the U.S. Presidents pages, the countries pages, the various tree of life pages....  You must have meant two, at least?
>
>kq
>
>
>
>


subject: [Wikitech-l] TeX security

body:
Neil wrote:

>We should also be really cautious about TeX doing insecure things. Is
>there a subset of TeX syntax we could parse and validate before we
>pass it to TeX?

There are two dangerous commands in TeX: the ability to write to
arbitrary files, and the ability to call shell scripts. Both are
disabled in all standard TeX distributions. Parsing and validating is
thus not necessary (and next to impossible without reimplementing a
good chunk of TeX). We have to start TeX in a temporary directory
which is cleaned out afterwards, and we have to guard against
run-away TeX processes which eat time and/or memory. The TeX process
needs to have its resources limited.

See also the discussion at http://groups.google.com/groups?threadm=d55ab765.0111091929.1e4b9af4%40posting.google.com&rnum=1

Axel


subject: [Wikipedia-l] 'old hand' status

body:
>> I might be wrong, but wouldn't taking powers previously only
>> usable by a relative few and allowing a great deal more people
>> to have them, tend to democratize things?

> Are you suggesting an automatic way of granting sysop status?
> If so, I like it.

No, what he suggested (and with which I agree, though I'm not quite
sure how to implement it yet) is a third status in between J. Random
Anonymous user and sysop, which will be able to edit protected pages
and use the "move" function, and which will be automatically given to
someone who hangs around for a while.


from_name: Jimmy Wales

subject: [Wikipedia-l] 'old hand' status

in_reply_to: <200208012038.g71KcSg19960@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Aug 01, 2002 at 01:38:28PM -0700

body:
What's the purpose of the sysop status, then?

The only reason we had the sysop status originally was that we really
did need to "delete" some pages, and at that time, our delete function
was royally destructive, i.e. it deleted the page and all the history.
So it was too powerful to have people using it indiscriminately.  But we
wanted to let a few people use it, because it really was useful.

Now, if the delete is no longer destructive in that way, i.e. if
there's a way to ordinary users to revive a deleted page, then we don't
really need sysop status except for "old hand" type of functions.

As I see it, we should *strive* to have only one level of user, in spirit.

I am comfortable with these levels:

1. Not-logged-in -- you can edit pages, etc., but you're penalized in
some minor respects.  The reaso for this is that it's more productive
for people to choose a consistent identity, rather than possibly
having a different ip number every day.  And if you remember '24',
it's a pain to have to refer to someone by a number.

2.  Logged-in -- you can do anything that's not 'royally destructive',
i.e. anything that's not irreversible, EXCEPT edit some protected
pages.  Again, we like to keep the number of protected pages to a low
level to just dissuade some of the more annoying and lame vandalism
attempts, like putting spurting penis pictures on the homepage.

3.  Old-hand/sysop -- should be granted in an apolitical manner based
on being essentially "legit" -- sysops should be able to do a tiny
number of destructive (irreversible) things, IF we need to have those
abilities for some reason.  (For example, some kinds of deletes do
need to be irreversible for legal reasons.)  This status should be granted
more or less automatically, and whatever privileges it give should, by
strong social custom, NEVER be used "in anger", i.e. to "pull rank to win
an argument".  There are only technical reasons to even have such a status.

4. Developer -- should be granted the ability to run arbitrary SQL
commands.  MAYBE this should not be part of the software, now that
developers can log in to the machine directly using ssh.  Access to
this should be highly restricted to people who (a) are techies actually
working on stuff, maybe development but maybe writing and running some
ad hoc log analysis scripts, etc. and (b) who agree that 'developer'
status should NEVER NEVER (DOUBLE NEVER) be used "in anger".

----

The main role that the Cunctator has taken for himself here is very
much appreciated by me...  I think that a big part of our success is
openness and non-cabalism.  Social pressure works better than the iron
rule of code.

--Jimbo


from_name: Tomasz Wegrzanowski

body:
On Thu, Aug 01, 2002 at 11:37:08AM +0200, Jan.Hidders wrote:
> On Thu, Aug 01, 2002 at 02:11:46AM +0200, Jens Frank wrote:
> >
> > For an example see
> >
> > 	http://jeluf.mine.nu/jf/newcodebase/wiki.phtml?title=Triangle
>
> It looks beautiful.

No it doesn't.

On my Konqueror with fairly big fonts all TeX-generated images are
much too small and placed too low.

Screenshot of paragraph is attached.

What should be done is:
* size of it should be configurable by user
* they should always be vertically aligned in a way that looks nice in
  case of bigger or smaller fonts.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot.png
Type: image/png
Size: 4319 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020801/b1b2631b/attachment.png>


subject: [Wikitech-l] TeX security

body:
I just realized that TeX by default can also read all files on the
system that the process has permissions to read, and we may want to
restrict that; this is done with the line
 openin_any = p
in the file texmf.cf.

Axel


subject: [Wikitech-l] Generating TeX

body:
JeLuF wrote:

> The script
> - renders TeX to DVI using LaTeX
> - converts DVI to eps using dvips
> - renders eps to PNG using convert from ImageMagick

Pdftex combined with a pdf-to-png converter should be faster since it
skips a conversion step.

Axel


body:
On Thu, Aug 01, 2002 at 01:58:55PM +0200, Tomasz Wegrzanowski wrote:
>
> On my Konqueror with fairly big fonts all TeX-generated images are
> much too small and placed too low.

Strange, because it says 'align="middle"'. What does Konquerer do on
www.planetmath.org? Do you like their set-up if you view with big and small
fonts? On my IE it looks acceptable.

-- Jan Hidders


subject: [Wikipedia-l] Proposal for table syntax

body:
On Thu, 1 Aug 2002, tarquin wrote:

> ||
> | Name
> | Bill Clinton
> ||
> | Musical instrument
> | saxophone
> ||

> ||
> | Name| Bill Clinton
> ||
> | Musical instrument | saxophone
> ||

I like it. Smells like wiki.

-- Daniel


subject: [Wikipedia-l] Proposal for table syntax

in_reply_to: <3D4926C7.4090503@planetunreal.com>; from tarquin@planetunreal.com on Thu, Aug 01, 2002 at 01:17:11PM +0100

body:
On Thu, Aug 01, 2002 at 01:17:11PM +0100, tarquin wrote:
> Since Wiki markup often ignores single \n, my proposal could be modified
> to *allow* several cells per line.
> However, I think the following is easily graspable:
> ||
> | Name
> | Bill Clinton
> ||
> | Musical instrument
> | saxophone
> ||
>
> It's *long* in raw form, yes. But it's also clean.

As I also suggested on the talk page of

http://meta.wikipedia.com/wiki.phtml?title=Wiki_markup_tables

why not something more WYSIWIG, like:
* [| starts a table rule
* |] ends a table rule
* consecutive rules belong to the same table

Like

[| Name               || Bill Clinton  |]
[| Musical instrument || Saxophone     |]

-- Jan Hidders


body:
On Thu, Aug 01, 2002 at 02:16:33PM +0200, Jan.Hidders wrote:
> On Thu, Aug 01, 2002 at 01:58:55PM +0200, Tomasz Wegrzanowski wrote:
> >
> > On my Konqueror with fairly big fonts all TeX-generated images are
> > much too small and placed too low.
>
> Strange, because it says 'align="middle"'. What does Konquerer do on
> www.planetmath.org? Do you like their set-up if you view with big and small
> fonts? On my IE it looks acceptable.

http://planetmath.org/?op=getobj&from=objects&id=947

On attached screenshot first and third images (heigth 34)
are aligned well, the second (heigth 37) is a bit too low,
but it's acceptable.

Does TeX have some trick which would allow us to get information about
how generated images should be placed in final text ?
It certainly uses such algorithm internally.
That might be the best solution.

But doing it the way planetmath does is still ok.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: planetmath.png
Type: image/png
Size: 3555 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020801/6849d361/attachment.png>


subject: [Wikipedia-l] New wiki markup

body:
> What happens if somebody inserts a new table/figure?
> You renumber? And the complexity step from doing no formatting
> to doing a little formatting becomes relatively big.

That's why I'm throwing the suggestion out there--to get feedback.

> Couldn't we just try a little harder to come up with a WikiWiki
> markup?  There is already table markup that does column-spanning,
> border selection and alignment of text in cells.

I really hate MoinMoin syntax.  It's every bit as ugly and complex as
HTML, without the benefits.

>  << float left <<
>  >> float right >>
>  >> center <<
> for tables and figures?

Not bad, but "<" and ">" are already something of a hassle; perhaps
less if HTML goes away.

But the upshot of my proposal is that there already exists a
technology for separating content and visual styling, and that we
should do exactly that.  Style is important, and we need to be able
to let people create attractive articles that take advantage of the
technology, so we need /more/ style elements.  But content and style
really are separate things, and the more wikisyntax we create for the
purpose of style, the more it becomes a bloated, non-standard new
language that does only half the job.  I disagree with Toby about
HTML, but I agree with him that just reinventing the wheel with a new
non-standard language isn't a solution.  CSS gives us an opportunity
to really do it right: let the gurus tweak the style as much as they
want, while still letting the regular folk see the content unobscured
by megabytes of markup.

>And do we really need colored text?

Absolutely.  It's a function of the technology we have, and we should
take advantage of it where it's useful (without overdoing it, of
course).  See [[Poker]], for example.  Those articles would be much
less readable and useful without red text and suit symbols.

Let for formally solicit proposals: folks, give me a clean,
unobtrusive, user interface for (1) specifying spans and divs in
wikitext with class and/or id; (2) attaching a stylesheet to a page,
and being able to edit it.


subject: [Wikipedia-l] Wiki Table syntax already a feature request

body:
There is already a feature request for a simple wiki
table format on Sourceforge at:
http://sourceforge.net/tracker/index.php?func=detail&aid=584459&group_id=34373&atid=411195

Here is the idea:

<wiki table, center, thin line>
|{light blue} ^ '''Mailing label''' ^|/
|Name:         |John Doe             |/
|Address:      |2000 Main Street     |/
| Postal Code: |123456               |/
</wiki table>

NOTE: ^ would signify that the text between should be
centered and / would signify the end of a row.
I'm not sure if this would be possible, but it would
be nice to also have spaces after the | and before the

text to be the same as   in an HTML table.

Would render the same as:

Mailing
label

Name: 	John Doe

Address: 	2000 Main Street

    Postal Code:
	123456

The above wiki table seems a lot more intuitive to me
than either the HTML table or the other wiki table
syntax proposals.

--mav

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] 'old hand' status

body:
> What's the purpose of the sysop status, then?
> The only reason we had the sysop status originally was that we
> really did need to "delete" some pages, and at that time, our
> delete function was royally destructive, i.e. it deleted the page
> and all the history. So it was too powerful to have people using
> it indiscriminately.  But we wanted to let a few people use it,
> because it really was useful.
> Now, if the delete is no longer destructive in that way, i.e. if
> there's a way to ordinary users to revive a deleted page, then we
> don't really need sysop status except for "old hand" type of
> functions.

Delete is still every bit as destructive and permanent.  The only
history of deleted pages will be in periodic database dumps.  (I've
only done two since the new server was in place, and I still don't
have a cron job for it--I need to get some indication of how you plan
to archive them, if you do, before I can do that).

> The main role that the Cunctator has taken for himself here is very
> much appreciated by me...  I think that a big part of our success is
> openness and non-cabalism.  Social pressure works better than the
> iron rule of code.

I'm all for "openness" in making information available to people, and
letting people add their own. But I utterly reject the idea that one
can deal with malicious, destructive people without some means of
self-defense; and such people do, and will continue to, exist.  I
don't think it's too bad an idea for "edit protected pages" and "move
page function" to be open to logged in users, but it does make me a
little nervous.  But "delete" should definitely be locked down, and
block/unblock IP.

Here's another suggestion, and one that would be easier to implement:
instead of just "logged in" being the criterion, how about "logged
in, and with an apparently valid e-mail address" (and I'll get
cracking on that "e-mail user" function).


subject: [Wikipedia-l] 'old hand' status

body:
On 7/31/02 11:07 PM, "Daniel Mayer" <maveric149 at yahoo.com> wrote:
> Who is expanding the influence of a creating a Cabal (like we ever agree on
> anything)? How is allowing the majority of active users the ability to edit
> the Main Paqe and other protected pages and the ability to administratively
> move pages a top heavy approach? Denying the majority of active users the
> ability to do these things is rather un-wiki in my book.
>
> I might be wrong, but wouldn't taking powers previously only usable by a
> relative few and allowing a great deal more people to have them, tend to
> democratize things?
>
Are you suggesting an automatic way of granting sysop status? If so, I like
it.


subject: [Wikipedia-l] Proposal for table syntax

body:
On 8/1/02 3:27 PM, "Jan.Hidders" <hidders at uia.ua.ac.be> wrote:
> I didn't interpret the example that way, but rather as a table with
> properties of Bill Clinton. If you want a table of presidents and their
> favourite instrument you would write this:
>
> [|  '''President''' ||  '''Instrument''' |]
> [|  Bill Clinton    ||  Saxophone        |]
> [|  Harry Truman    ||  Piano            |]
> [|  Abe Lincoln     ||  Bag pipes        |]
>
I'm pretty sure Lincoln played the fiddle.


body:
><wiki table, center, thin line>
>|{light blue} ^ '''Mailing label''' ^|/
>|Name:         |John Doe             |/
>|Address:      |2000 Main Street     |/
>| Postal Code: |123456               |/
></wiki table>

I don't like it at all.  Tarquin still has the best idea so far--it
just needs to be fleshed out a bit.


subject: [Wikipedia-l] 'old hand' status

body:
lcrocker at nupedia.com wrote:
>>Now, if the delete is no longer destructive in that way, i.e. if
>>there's a way to ordinary users to revive a deleted page, then we
>>don't really need sysop status except for "old hand" type of
>>functions.
>
> Delete is still every bit as destructive and permanent.  The only
> history of deleted pages will be in periodic database dumps.  (I've
> only done two since the new server was in place, and I still don't
> have a cron job for it--I need to get some indication of how you plan
> to archive them, if you do, before I can do that).

Under phase II, deleted articles were retained in the table of old
versions, and if necessary could have been restored by a sysop querying
the database. (There never was a pretty interface set up for this.)

I think the issue came up once, but the article in question had been
deleted (accidentally) before that feature was in place, so was long
gone from the database.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] 'old hand' status

body:
> Under phase II, deleted articles were retained in the table of old
> versions, and if necessary could have been restored by a sysop
> querying the database. (There never was a pretty interface set up
> for this.)

I didn't realize that.  I could make delete less destructive, say, by
moving everything to an "archives" table that gets taped off every
now and then.


subject: [Wikipedia-l] Year in Review Backwards

body:
Some time ago, I posted a question on the talk page of Year in Review,
regarding the use of the Year in Review/Backwards pages, which are all
orphan pages. I received one reaction (from Toby) voting for deletion
after I put it on the votes for deletion page, but it was not deleted by
any sysop. Now that I am one myself, I can do that, but I want to bring
this topic to the attention for one last time. Unless I receive
reactions, I'll delete the pages.


from_name: tarquin

body:
  Could the WatchList page be limited to a number of days like
RecentChanges?
Mine is getting rather long & it takes a while to generate.
Maybe a truncated WatchList page could give a link to a complete
watchlist which would be displayed as a dumb list with no dates & times
of edits (which I presume is what causes the load on the server)


subject: [Wikipedia-l] 'old hand' status

in_reply_to: <200208012356.g71NuKb11998@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Aug 01, 2002 at 04:56:20PM -0700

body:
It seems to me that we need both -- a destructive delete when something just
has to go, and a nondestructive delete, the primary purpose of which is to turn
article links back into '?' links (i.e. edit links rather than read links), without
a lot of fuss and muss.

And yes, destructive delete should be locked down.

And yes, we need methods of self defense.  The challenge is to have
just enough self-defense without providing ourselves with temptations
to cliquism and power games.

lcrocker at nupedia.com wrote:

> > Under phase II, deleted articles were retained in the table of old
> > versions, and if necessary could have been restored by a sysop
> > querying the database. (There never was a pretty interface set up
> > for this.)
>
> I didn't realize that.  I could make delete less destructive, say, by
> moving everything to an "archives" table that gets taped off every
> now and then.
>
>
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Stephen Gilbert

subject: [Wikipedia-l] Year in Review Backwards

body:
--- Jeroen Heijmans <j.heijmans at stud.tue.nl> wrote:
> Some time ago, I posted a question on the talk page
> of Year in Review,
> regarding the use of the Year in Review/Backwards
> pages, which are all
> orphan pages. I received one reaction (from Toby)
> voting for deletion
> after I put it on the votes for deletion page, but
> it was not deleted by
> any sysop. Now that I am one myself, I can do that,
> but I want to bring
> this topic to the attention for one last time.
> Unless I receive
> reactions, I'll delete the pages.

I don't even know what they are. Did they serve a
purpose at one point?

Stephen Gilbert

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Proposal for table syntax

in_reply_to: <3D496FCB.9050102@telus.net>; from saintonge@telus.net on Thu, Aug 01, 2002 at 10:28:43AM -0700

body:
On Thu, Aug 01, 2002 at 10:28:43AM -0700, Ray Saintonge wrote:
> Jan.Hidders wrote
> >
> >Like
> >
> >[| Name               || Bill Clinton  |]
> >[| Musical instrument || Saxophone     |]
>
> The example above gives me cause for concern because it really only has
> one data set.  What will it look like when you add Harry Truman's piano
> or some other president's fiddle?

I didn't interpret the example that way, but rather as a table with
properties of Bill Clinton. If you want a table of presidents and their
favourite instrument you would write this:

[|  '''President''' ||  '''Instrument''' |]
[|  Bill Clinton    ||  Saxophone        |]
[|  Harry Truman    ||  Piano            |]
[|  Abe Lincoln     ||  Bag pipes        |]

WYSIWIG enough? :-)

-- Jan Hidders


subject: [Wikipedia-l] New wiki markup

body:
On Thu, 1 Aug 2002 lcrocker at nupedia.com wrote:

> There is a tension of goals here: (1) the primary goal of our wiki,
> as I see it, is to encourage the totally computer-inept to write and
> edit articles.  Getting people like that to parse the text out of
> <table> syntax and get the tags to match up right will just drive
> them away.  (2) The goal to have pretty-looking articles.

(3) The goal of having form-independent content, parseable to as many formats
as possible (print to books, read aloud, XML, etc.). This agrees better with
simple wiki markup only, than with HTML. For this goal, mixed wiki and HTML
markup is the worst case.

-- Daniel


subject: [Wikipedia-l] New wiki markup

body:
lcrocker at nupedia.com wrote:

>That still leaves us no way to specify headings, caption, spans, and
>cell backgrounds, and the like.  We would also like to be able to do
>things like float images, colorize text, and so on.
>
>
>
the header block in my table suggestion would set CSS for the table (or
be parsed into HTML -- depends on browser support)
Something like
[[table:president]]
or
[[table:chemicalelement]]
would guarantee the same look for all the tables on the chemical elemnt
page, or the data talbes that have recently started to appear on US
president pages.
more complex stuff could be set in that block for individual non-preset
styles. I think the computer-inept will skim over a single line of
complicated-looking markup that clearly has little to do with the data
of the table.


subject: [Wikipedia-l] Proposal for table syntax

body:
>
>
> It's also Ok if you
>name one famous Belgian that invented a music instrument. Without checking
>Wikipedia first, of course.
>
>
Wild guess: Adolph Sax?


body:
On Thursday 01 August 2002 04:05 pm, LDC wrote:
> ><wiki table, center, thin line>
> >
> >|{light blue} ^ '''Mailing label''' ^|/
> >|Name: ? ? ? ? |John Doe ? ? ? ? ? ? |/
> >|Address: ? ? ?|2000 Main Street ? ? |/
> >| Postal Code: |123456 ? ? ? ? ? ? ? |/
> >
> ></wiki table>
>
> I don't like it at all. ?Tarquin still has the best idea so far--it
> just needs to be fleshed out a bit.

So long as it is easy to code in wiki by the HTML-phobic and is able to do
the above I really don't give a damn what proposal wins. I just wanted to put
forward another idea to stir the pot.

--mav