from_name: Robert

subject: [WikiEN-l] Gaia theory article disambiguation

body:
We need a bit more clarification.  I have been doing some
more reading on this topic, and have disovered that many
claims Anthere has been making in the Gaia articles are
incorrect.  Anthere has saying that we must refer to
certain ancient religious and mystical views of the Earth
and/or cosmos as "Gaia theory". In point of fact, the
people who developed those ideas never referred to those
ideas with this terminology!  More to the point, these
ideas have no relation Gaia thoery.  Even today most
English speakers do not use this terminology for those
ideas. Anther is mistaken on this point.

More problematic is her curious claim that Dr James
Lovelock's Gaia hypothesis is based upon these earlier
mystic and religious beliefs. In point of fact, Dr.
Lovelock says no such thing. Lovelock is an atmospheric
scientists, and his Gaia hypothesis grew out of his study
of atmospheric gases. He did *not* use science to build
upon earlier mystical beliefs; he created his own
hypothesis by applying ideas from Biology to findings from
atmospheric science.  Anthere's claims that all these
religious and mystical views must be viewed as precursor's
to Lovelock's hypothesis are incorrect; they seem to part
of her own belief system, and they have no basis in
historical fact. Having watched a detailed interview with
Lovelock on how he developed his hypothesis, and having
read two different accounts by him on the same topic, I can
say with some certainty that Anthere's beliefs about the
origins of the Gaia hypothesis are totally off-base.

Now, it may be true that a tiny number of radical left-wing
ecology activists (for example, Gaiains) have developed
certain religious and/or political beliefs based on
Lovelock's ideas. They may even have mistakenly come to
believe that Lovelock didn't originate the Gaia hypothesis,
but merely added science to previous mystical belief
systems.  But so what?  We can certainly mention this set
of beliefs in the article on Gaians, but it would be
grossly inapprorpiate to jam it into an article on
atmospheric science and biology, i.e. the [[Gaia theory]]
article.

Finally, Anthere keeps demanding that since some people mix
together science, radical politics, and these new-age
belief systems, we are somehow obligated to cram all of
this into the science articles.  She is plainly wrong. We
in Wikipedia already have a convention for dealing with
this; we already have a clear and working precedent.
Consider the topics of Biological evolution and [[Quantum
Mechanics]]: As many of you know, these are modern
scientific theories, and our articles on these topics
reflect this fact.  Yet many new-age writers have come to
believe that Quantum mechanics and/or evolution somehow are
related to ancient mystical and religious belief systems.

As many of you know, many new-age folks try to connect
Quantum Mechanics with Daoist or Buddhist philosophy, and
claim that it is "proof" of the validity of these
religions. I have also seen Orthodox Jews try to fuse
Kabbalah (Jewish mysticism) with Quantum mechanics. But so
what? Frankly, there are many individuals and groops that
insist that Quantum menchanics or evolution has some
mystical or political significance.  Do we then rewrite
encycloepdias to make them in lin with the religious or
political demands of these groups or individuals?  No.
That would be a violationf our NPOV policy.

What we have always done for these issues is to create new
articles on these poltical or religious groups, and explain
their viewpoints.  We have always done this in the past, it
makes it easy to stay NPOV, and provides useful
disambiguation.

Can you imagine how misleading it would to start pushing
mystical, religious topics, and political topics, into our
articles on Biological evolution, and on Quantum Mechanics?
 Why then should we do the same for the Gaia hypothesis?
(Also called the Gaia theory.)  Answer - we shouldn't. It
would confusing and a violation of NPOV.

Again, from discussions on this list and on the Talk pages,
it is looking like the following disambiguation scheme
should be implemented:

*****

Gaia: This is a [[disambiguation]] page. The term Gaia may
refer to

[[Gaia (mythology)]] - Discussion of the Greek and Roman
goddeess.

[[Gaia theory]] - A group of scientific theories about how
life on Earth may regulate the planet's biosphere to make
it more hospitable to life. This discusses all scientific
views on the subject in general, including the views of
Drs. James Lovelock, Lynn Margulis, Richard Dawkins, Carl
Sagan, etc.

[[Gaia hypothesis]]- A subset of the above article; this is
a discussion of Dr. James Lovelock's ideas on Gaia theory.

[[Gaia theory analogs]] - A discussion of proto-scientific,
mystical and religious views that some people believe are
related to Gaia theory.

[[Gaians]] - A discussion of the small left-wing radical
political and environmentalist group.

(Of course, other articles could be made as well, if
needed.)

*****

We must not push mystical, political or religious ideology
into our science articles on Gaia theory, Biological
evolution, or Quantum Mechanics, etc. All I am asking is
that we continue to follow the same disambiguation and NPOV
policy that we also have followed.  Is this clear?

Robert (RK)

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


list: wikien-l

source: pipermail-mbox

from_name: Christopher Mahan

subject: [WikiEN-l] Please stop the trolling.

body:
--- Vicki Rosenzweig <vr at redbird.org> wrote:
> At 05:55 PM 7/1/03 -0700, Robert wrote:
> >Please stop the trolling. This is the English Wikipedia
> >list.  Stop using this list for French discussions.
>
> Not everything you, or I, find irritating is trolling. I agree
> that on this list, specifically, English is preferable. That
> doesn't make the use of French trolling.

To Vicki and Jimbo,

Agreed, the french might have been a little too much on the list.
I wanted to reach Anthere in her mother tongue to express myself to
her, without being interfered with by RK (or seeming to cater to RK),
and yet wanted the discussion public because there are people here at
the W-en who read french.

Besides, according to my wife, my body shape, hair distribution, and
general brutish behavior mean I could easily pass as a troll, so I'll
not get offnded there :)

=====
Christopher Mahan
chris_mahan at yahoo.com
818.943.1850 cell
http://www.christophermahan.com/

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


list: wikipedia-l

from_name: The Cunctator

subject: [Wikipedia-l] Please help test new features

body:
On 7/2/03 2:56 PM, "Erik Moeller" <erik_moeller at gmx.de> wrote:

> Brion-
>> It's also mysteriously in a table and there are no line breaks. :)
>
> I think it looks nicer in a table, but that's easy to change in Skin.php.
>
>> I notice that duplicate headings (which is not unlikely to occur with
>> subheadings) are marked with a numbered suffix after the first one. Better
>> than nothing, but this is fragile for linking; if the major sections are
>> rearranged in order, the numbers for the minor sections will change.
>
> So what else do you suggest?
>
>> Indeed. If we're adding features to make it easier to edit, I'm not sure
>> it makes sense to hide them from new users...
>
> My reasoning for this was that Wikipedia has two uses:
> - a work of reference
> - a collaborative editing system used by us.
>
> We need to find the right balance between making editing easy and making
> reading Wikipedia unobtrusive. Some work on this is being done in the Skin
> department, for example, where we will probably end up with a Skin
> preferred by editors, and one that is more friendly to non-editing users.

This would be a terrible violation of the basic Wiki-nature of Wikipedia.


from_name: Toby Bartels

subject: [Wikipedia-l] Intro for readers of this list

body:
Richard Grevers wrote:

>In fact - links to disambign articles are a perfect use. You can make it
>clear what sense of a word you are linking to.

Erm ... why would you ever /deliberately/ link to a disambig page like this?
Why not just link to the page that that section of the disambig page links to?
The purpose of disambig pages is almost entirely
to catch links that /don't/ go where they really ought to go.

Perhaps you mean links to articles that have
several brief discussions that are separated by horizontal rules?
That makes some sense.

-- Toby


from_name: Mark Christensen

body:
> > We need to find the right balance between making editing easy and
> > making reading Wikipedia unobtrusive. Some work on this is being
done
> > in the Skin department, for example, where we will probably end up
> > with a Skin preferred by editors, and one that is more friendly to
> > non-editing users.

> This would be a terrible violation of the basic Wiki-nature of
Wikipedia.

No it wouldn't.  Anybody can use any skin they want!  The idea is only
to give people tools optimized for use.  Readers and casual editors
don't want confusing and redundant links.  Long time editors don't mind
trading increased learning curve for more functionality, and the
potential to do what they want with one or two less clicks.

Making wikipedia easier to use for everybody isn't a terrible violation
of basic wiki-nature, it's just being nice to users.  And, that -- in my
opinion -- is a just a good idea.

--Mark Christensen


subject: [Wikipedia-l] Re: Intro for readers of this list

body:
Karl Eichwalder wrote:

>Daniel Mayer wrote:

>>Sounds cool. But why not just make another article?

>Because we write for readers.  Some subjects are more complex and it is
>a real pain if you as a reader are forced to download a bunch of
>articles to get the idea of the subject in question.

[[X]] should still have enough about Y
that you can understand what you need of Y to get an idea of X.
That doesn't mean that more detailed information on Y
can't or shouldn't go in a separate article --
if people are tyring to link to [[X#Y]], then that's probable.

>Also people will start adding stuff to article which are "not
>complete" (they will not lookup other articles first); thus duplicating
>of info usually happens and in the end the article is long again.

But isn't this a /good/ thing???
We /want/ them to write more about the subtopic,
and once that page becomes very long, then we can split it up too.
True, duplication is bad, but that's not likely if the title is good.

Let me give a rough example:

We begin by writing an article on topic [[X]].
It starts small, but as it grows, it expands to look like this:

"= X =
"
"In [[context]], X is '''definition'''.
"
"Introductory paragraph.
"
"== Y1 ==
"
"Stuff about Y1 in the context of X.
"
"== Y2 ==
"
"Stuff about Y2 in the context of X.
"
"== Y3 ==
"
"Stuff about Y3 in the context of X.

Then it gets kind of long, so we split, say, Y2 into its own article,
which might be [[Y]] or might need a longer name like [[Y2 in X]],
depending on the specific situation.  Let's suppose just [[Y2]].
Then [[Y2]] looks like this:

"= Y2 =
"
"In [[X]], Y2 is '''definition'''.
"
"Much the same as the earlier paragraph about Y2.

That's a whole paragraph, so it's not too short.
Meanwhile, [[X]] is edited to look like this:

"= X =
"
"In [[context]], X is '''definition'''.
"
"Introductory paragraph.
"
"== Y1 ==
"
"Stuff about Y1 in the context of X.
"
"== Y2 ==
"
"Somewhat less about [[Y2]] than before.
"For more information, see [[Y2]].
"
"== Y3 ==
"
"Stuff about Y3 in the context of X.

Now there is no point in linking to [[X#Y2]]; you /want/ to link to [[Y2]].
Meanwhile, people start writing more about Y2 in [[Y2]].
They wouldn't have written this in [[X]],
since it may be too much detail to write about in an article on X generally.
But it's right at home in [[Y2]], and it doesn't duplicate stuff in [[X]],
because reading [[X]] makes it clear that detail about Y2 is in [[Y2]].

Several good examples of this can be found all at once
among the country articles on [[en:]].

>This leads to the conclusion that fragment identifiers are a good thing.

The only way that I'd really want to use them here
is to have [[Y2]] redirect to [[X#Y2]] for a while.
Now that I think about it, that might be /very/ useful.

It's becoming clear to me that we're going to have to
continue to allow [[X#Y2]], since so many people want it;
and there are wikis (like Wiktionary and probably [[pl:]])
whose users plan to employ it pretty freely.
I /would/ like people to think long and hard
about how it can be used properly, however;
and I know that we'll have to have some discussions on <wikiEN-L>
about how we all want to use them best on [[en:]].
But other wikis can have other policies,
even ones that I rather disagree with,
without destroying the world. ^_^

-- Toby


body:
Brion Vibber wrote:

>Toby Bartels wrote:

>>However, one discussion of policy has recently come up.
>>That's over whether to allow links from article [[Z]]
>>to section [[#Y]] in article [[X]], through the markup "[[X#Y]]";
>>or whether to allow links only from the same article [[X]],
>>through the markup "[[#Y]]".

>We have allowed such links since nearly a year ago, but you had to make
>an anchor yourself by putting in some HTML tag with an 'id="anchorname"'
>attribute.

We've allowed them, but only in anticipation;
they weren't intended to work yet (or that wasn't publicly announced).

>The discussion is whether to automatically _create_ anchors from
>headers, which is needed for Erik's proposed automatic table of contents
>generation for pages with more than three headers.

There hasn't been any controversy on <wikitech-L> over this as such;
the controversy has been over whether or not we ought to
now disable the [[X#Y]] links /when/ we do this.

>The anchor names would change if the header text is changed, so if a
>header is changed, a link specifically to it will end up just going to
>the whole article instead of that section specifically.

For this reason (and your recent answer to my technical question),
I think that we can stand to continue to allow [[X#Y]] --
especially since some wikis really want them.
But individual wikis should think carefully
about what the best practices in their case will be.

-- Toby


body:
On 7/2/03 4:25 PM, "Mark Christensen" <mchristensen at humantech.com> wrote:

>>> We need to find the right balance between making editing easy and
>>> making reading Wikipedia unobtrusive. Some work on this is being
> done
>>> in the Skin department, for example, where we will probably end up
>>> with a Skin preferred by editors, and one that is more friendly to
>>> non-editing users.
>
>> This would be a terrible violation of the basic Wiki-nature of
> Wikipedia.
>
> No it wouldn't.  Anybody can use any skin they want!  The idea is only
> to give people tools optimized for use.  Readers and casual editors
> don't want confusing and redundant links.  Long time editors don't mind
> trading increased learning curve for more functionality, and the
> potential to do what they want with one or two less clicks.
>
> Making wikipedia easier to use for everybody isn't a terrible violation
> of basic wiki-nature, it's just being nice to users.  And, that -- in my
> opinion -- is a just a good idea.

If "Anybody can use any skin they want!" were true, I would agree with you
100%.

But only logged-in editors can use any skin they want. Forcing editors to
log in to use useful features is a violation of Wiki-nature. I'm willing to
hedge on "terrible".

I'd first try to develop an interface that avoids confusion without
requiring cookies, etc. That would be the optimal solution.


body:
The Cunctator wrote:

>Erik Moeller wrote:

>>We need to find the right balance between making editing easy and making
>>reading Wikipedia unobtrusive. Some work on this is being done in the Skin
>>department, for example, where we will probably end up with a Skin
>>preferred by editors, and one that is more friendly to non-editing users.

>This would be a terrible violation of the basic Wiki-nature of Wikipedia.

I don't see a problem with having skins optimised for reading and editing.
I do see a probelm with making the former the default,
although even that doesn't seem to me to be isurmountable.
What /would/ be a terrible violation is the make the default skin
a skin in which there is no "'''Edit this page'''" link at all --
but I don't think that Erik is proposing that for /any/ skin.

-- Toby


body:
Erik Moeller wrote in part:

>Brion VIBBER wrote:

>>It's also mysteriously in a table and there are no line breaks. :)

>I think it looks nicer in a table, but that's easy to change in Skin.php.

Some of the reasons why using tables for layout is bad
can be found on [[meta:Wikipedia accessibility]]
(and pages and sites linked from it).

>>I notice that duplicate headings (which is not unlikely to occur with
>>subheadings) are marked with a numbered suffix after the first one. Better
>>than nothing, but this is fragile for linking; if the major sections are
>>rearranged in order, the numbers for the minor sections will change.

>So what else do you suggest?

The natural thing for me would be [[X#Y#Z#...]].
If this gets too long ... well, that's a pretty good sign
that [[X#Y]] really should go onto its own page!

>By having the neat "edit this section" feature only for headings, we
>encourage people to create headings for their own editing benefit. They
>will reorganize talk pages to have them to be able to respond quicker in
>the future. We provide no such incentive if we also implement the feature
>for rules.

I'll buy this.

-- Toby


body:
>> Making wikipedia easier to use for everybody isn't a terrible
>> violation of basic wiki-nature, it's just being nice to users.  And,
>> that -- in my opinion -- is a just a good idea.

> If "Anybody can use any skin they want!" were true,
> I would agree with you 100%.

> But only logged-in editors can use any skin they want.
> Forcing editors to log in to use useful features is
> a violation of Wiki-nature. I'm willing to hedge on
> "terrible".

> I'd first try to develop an interface that avoids
> confusion without requiring cookies, etc. That would
> be the optimal solution.

First, "wiki-nature" is a vague and somewhat undefined entity.

While I would certianly agree that it is valuable and could be violated,
I would also argue that there is a reasonable requirement that you
explain what it is in "wiki-nature" that would be violated by this
proposal.

Not only that, while I agree that the "wiki-nature is valuable, I don't
agree that it is an ultimate value, so I would also think it reasonable
that you explain why precisely it is that convenience for users of the
wikipedia is ''less valuable'' than the particular aspect of wiki nature
in question.


list: wikitech-l

from_name: Matthias Jordan

subject: [Wikitech-l] Suggestion: new script in languages

body:
Hi, folks.

Today I really wondered why my own CVS copy of Phase3 did not show those
funky "edit only this section" links like that one on test.wiki does.
Then I found out that LanguageDe.php misses many new keywords that are
neccessary for this feature (and also for others).

I wrote a small script (quick and dirty) that compares two language
files and searches for missing keywords. I'd commit the script into the
CVS if you folks want it there. It's a bash script, though.

Bye!
Matthias


from_name: Brion Vibber

body:
On Thu, 3 Jul 2003, Erik Moeller wrote:
> Stan-
> > The TOC should be just above the first section heading.
>
> You are absolutely right, I have changed the behavior accordingly (not on
> test.wiki yet). Looks very nice.

Updated test to cvs version... Definitely looks a bit cleaner now.

But...

Markup note:

1  About Wikipedia

Ewwwwwwww! :)

The great Tim Berners-Lee gave us ordered and unordered lists for a
reason. A minimum of semantic markup allows for reasonable rendering on
non-graphical browsers -- text, speech, PDAs, etc -- and for appropriate
navigation techniques in non-mouse environments.

Now, if we really don't like the way the bullets/numbers are rendered in
an unordered or ordered list, we can suppress or change that in the style
sheet.

Just because you _can_ emulate the whole of HTML 4 with just
 and
 and liberal use of the style attribute hardcoded on every element
doesn't mean you should. :)

-- brion vibber (brion @ pobox.com)>


list: textbook-l

subject: [Textbook-l] License issues

body:
Jimmy Wales wrote in part:

>I've been chatting with Larry Lessig about copyright and license
>issues, and of course he's a big proponent of his own Creative Commons
>licenses.

I agree, Creative Commons is just better.
And they have cool videos! ^_^

>Actually, what I think we should do, from the outset, is dual-license
>everything under both licenses.  That ensures that the text is
>compatible with Wikipedia.

That's not a bad idea in any case,
to allow compatibility with some other GFDL project.

>It's a bit late for Wikipedia proper to do much good with dual licensing,
>but for textbooks, it might be a good idea to do it from the outset.

How long until all text on Wikipedia is completely rewritten?  5 years? 10?
Everything that /I/ write on Wikipedia
is automatically free with /no/ restrictions,
because /everything/ that I write is free with no restrictions.
To be sure, such lack of restrictions applies only
insofar as what I've written is /new/ --
otherwise, the rest is still copyright as before,
and that material is licensed only under the GFDL.
But can it work to require people to dual license their submissions,
so long as the Creative Commons licence specifically applies
/only/ to the material that's new?
(For any given submission, that may be nothing, or everything.)
Does such an idea fit into copyright law at all?

-- Toby


from_name: Timwi

subject: [Wikitech-l] CVS

body:
Somebody sent me an anonymous (no name, no from address) e-mail in
response to a mail I sent to this list. Since I don't know who the
sender is, I guess I'll have to reply through the list. Please let me
know if this is not the correct way of doing it.

I'd be very grateful if the sender of the mail showed themselves.

> are you timwi from LJ by any chance?

Yes.

> cause if you are, im thinking you might have some ideas to try to
> reduce load to our servers and optimize this whole sheebang.

Why does it take a Timwi from LJ to do database optimisations? :-)

Anyway - yeah, I was going to have some looks at it later on. I'm
waiting for my first patch to go through first though -- I wouldn't like
to spend time on it if it's not going to be used anyway.

I noticed that pages with a lot of links (like the "List of XYZ topics"
pages) take a long time to edit. I'm imagining it updates some table for
all those links even if just one of the links was changed, or something.
Is that the case? Perhaps if someone could point me at a particular file
and line where this is happening? Thanks in advance! :)

Greetings,
Timwi


subject: [Textbook-l] linearity

body:
Magnus Manske wrote:

>OK, practical question: How does the software on a given page *know*
>what page is next? It doesn't until we tell it. The best place is within
>the page/article/module, don't you think?

I think that mav is right -- stick it all in the URL.
(I will reply to his post with one problem that I see.)

>Or, we show all possible links, like "Next page in Biology", "Next
>page in Chemistry", etc.

For my proposed application, with different orders for the same material
being counted as different "books" to allow teachers to choose the order,
this would be rather difficult to keep track of, with a link like
"Next page in Calculus using course sequence #14".
Or was this class using course sequence #4? -- I forget. ^_^

-- Toby


subject: [Textbook-l] linearity

body:
Daniel Mayer wrote in part:

>Links on the TOC to specific modules would have info in them (after a & or ?)
>that would give placement info. So clicking on a link to the first module in
>Chapter one would give
>http://textbook.wikibook.org/en/organic_chemistry_level_1:module1?textbookTOCid=45369&moduleid=1&chapterid=1

I see one problem with this -- this URL is not static if we change the TOC.

My solution: each module should have a unique, descriptive name,
like [[Carboxyl group]], so <http://textbook.wikibook.org/en/Carboxyl_group>
will always get you to that module, but with no Previous/Next links.
<http://textbook.wikibook.org/en/Carboxyl_group?textbookTOCid=45369&moduleid=1&chapterid=1>,
however, will give you the links appropriate to textbook #45369.
(We can let every English textbook use the same system here,
so there's no need to specify "organic chemstiry level 1" in the URL.)
Then the "Next page" link goes to, say,
<http://textbook.wikibook.org/en/Amine_group?textbookTOCid=45369&moduleid=2&chapterid=1>,
with both the moduleid and the title of the page having changed.

>Play around with this link:
>http://transitorienteddevelopment.dot.ca.gov/project/stateViewProjectOverview.jsp?projectId=10&&stationId=7
>Change the project and station ids and that will change which entry you are
>looking at.

That works well, except that as in your suggestion,
if they change the database, then it's not static.
("This page gives an overview of the null. Data was collected in  null.
Use the menu on the left to get more information about the". ^_^)

-- Toby


from_name: Julie Kemp

subject: [WikiEN-l] Effing Gaia Theory

body:
Robert -- what part of "you are becoming tiresome pushing your
anti-Anthere agenda " don't you get?

At present, every one of your Gaia e-mails comes across to the readers
as an attack on Anthere.  Several of us have asked you to back off for a
bit and give it (and all of us) a rest.  Could you please just do that?

Great that you are finding stuff to support your view.  Have to say,
though, that based on almost two years of participation and observation
here, not to mention having some research experience myself, I know very
well that it's easy to find information on one's own agenda, and that
some people, including you, have not always been up front about evidence
that might support another POV.  I say this in full knowledge that it
may bring on one of your pre-emptive strikes, BTW.

I am not a scientist, and I have to say that my first thoughts when
hearing the words 'Gaia Theory' have a lot more to do with all that
mystical/philosophical/religious stuff -- basically, that's the first
context I heard them in, probably in popular fiction or boredly browsing
in a New Age shop while the husband checked out Eastern Philosophy  My
point is, I'm not sure it's as cut and dried as you want to make it out
to be, and your constant barrage of e-mails makes it very hard for
people who might want to help resolve the issues to actually give them
serious thought.

Please just give us a break
J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030702/4eed1139/attachment.htm


subject: [Textbook-l] NPOV (Was: Textbooks)

body:
Jimmy Wales wrote in part:

>Larry preferred the term 'unbiased', and with some good reason, but I
>always felt that 'NPOV' better avoided a lot of sticky epistemological
>issues about Truth With A Capital T.  It's a social concept, not an
>epistemological concept.

"neutral point of view" is problematic, in that it's not a POV at all.
[[fr:]] says "la neutralit? de point de vue", which is subtly different:
"the neutrality of point of view".

-- Toby


from_name: Thomas Corell

body:
Matthias Jordan wrote:
> Hi, folks.
>
> Today I really wondered why my own CVS copy of Phase3 did not show those
> funky "edit only this section" links like that one on test.wiki does.
> Then I found out that LanguageDe.php misses many new keywords that are
> neccessary for this feature (and also for others).
>
> I wrote a small script (quick and dirty) that compares two language
> files and searches for missing keywords. I'd commit the script into the
> CVS if you folks want it there. It's a bash script, though.

You know phase3/maintenance/checktrans.php ?

and you can tell about the differences?

--
Smurf

smurf at AdamAnt.mud.de
-------------------------  Anthill inside! ---------------------------


from_name: Graham Burnett

subject: [WikiEN-l] Re: WikiEN-l digest, Vol 1 #513 - 8 msgs

body:
>Message: 1
Date: Tue, 1 Jul 2003 17:55:47 -0700 (PDT)
From: Robert <rkscience100 at yahoo.com>
To: wikien-l at wikipedia.org
Subject: [WikiEN-l] Please stop the trolling.
Reply-To: wikien-l at wikipedia.org

Please stop the trolling. This is the English Wikipedia
list.  Stop using this list for French discussions.

RK

Blar blar blar. Geez give it a rest Robert, you are really getting on my
tits with your constant blabbing on about trolling and vandalism.


subject: [Wikitech-l] CVS

body:
Hi,

02.07.2003 14:01:47, Lightning <> wrote:

> But yes, i follow lj-dev, and fb quite closely and Im constantly
> impressed by the things you guys pull off. like memcache, which had me
> droooling. I just figured since you help run (probably) one of the
> biggest mysql/apache clusters/websites in the internet, with some of
> the biggest traffic and DB loads you would have a couple of things to
> say on the subject.

Hm. You say you are following lj_dev, but you seem to be missing
something. First, I am not running any servers, let alone LiveJournal
ones, apart from my little development installation which I use only for
testing. Hopefully, I'll have a Wikipedia one soon too. Secondly, both
MemCacheD and FotoBilder (and S2 as well) were programmed almost
entirely by Bradfitz and Avva; I and other volunteers were not invited
to participate in the development of it.

Nevertheless, I have learnt quite a bit about database optimisation from
LJ, and I suppose I could take a look at Wikipedia code.

P.S.: If this is off-topic, please let me know and I'll stop.

Greetings,
Timwi


from_name: Erik Moeller

body:
The following features are currently tested on
        http://test.wikipedia.org :

* Automatic table of contents. A TOC-table is added to pages that contain
more than three headings. This table links to the individual sections
within the article and hopefully makes navigation easier.
* Editing of individual sections. You need to be logged in to test this.
Just click the "[edit]" link next to a headline to change the text of that
particular section.
* Linking into the Special: namespace with parameters. See Brion's
separate mail for details.

Please help us test these features before we put them on the live server,
otherwise, things might break unexpectably.

Thanks,

Erik


from_name: james duffy

subject: [WikiEN-l] Over the weekend...

body:
>From: Toby Bartels <toby+wikipedia at math.ucr.edu>
>Reply-To: wikien-l at wikipedia.org
>To: wikien-l at wikipedia.org
>Subject: Re: [WikiEN-l] Over the weekend...
>Date: Sat, 28 Jun 2003 11:16:26 -0700
>MIME-Version: 1.0
>Received: from pliny.wikipedia.org ([130.94.122.197]) by
>mc10-f2.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Jun
>2003 11:13:20 -0700
>Received: from pliny.wikipedia.org (localhost.localdomain [127.0.0.1])by
>pliny.wikipedia.org (8.11.6/8.11.6) with ESMTP id h5SIDII05099;Sat, 28 Jun
>2003 18:13:18 GMT
>Received: from mathserv.ucr.edu (mathserv.ucr.edu [138.23.203.200])by
>pliny.wikipedia.org (8.11.6/8.11.6) with ESMTP id h5SICaI05055for
><wikien-l at wikipedia.org>; Sat, 28 Jun 2003 18:12:36 GMT
>Received: from math-cl-n01.ucr.edu (math-cl-n01.ucr.edu [138.23.203.119])by
>mathserv.ucr.edu (8.11.7/8.11.7) with ESMTP id h5SI9jP18151for
><wikien-l at wikipedia.org>; Sat, 28 Jun 2003 11:09:45 -0700 (PDT)
>Received: (from toby at localhost)by math-cl-n01.ucr.edu (8.11.7/8.11.7) id
>h5SIGQ113313for wikien-l at wikipedia.org; Sat, 28 Jun 2003 11:16:26 -0700
>(PDT)
>X-Message-Info: UZmYcfFpTCewzfqvyl1d15R59mlxBfYY
>Message-ID: <20030628181625.GB12850 at math-cl-n01.ucr.edu>
>References: <BAY1-F69xKZMqA4dxfE0000d390 at hotmail.com>
>In-Reply-To: <BAY1-F69xKZMqA4dxfE0000d390 at hotmail.com>
>User-Agent: Mutt/1.4i
>Sender: wikien-l-admin at wikipedia.org
>Errors-To: wikien-l-admin at wikipedia.org
>X-BeenThere: wikien-l at wikipedia.org
>X-Mailman-Version: 2.0.13
>Precedence: bulk
>List-Help: <mailto:wikien-l-request at wikipedia.org?subject=help>
>List-Post: <mailto:wikien-l at wikipedia.org>
>List-Subscribe:
><http://mail.wikipedia.org/mailman/listinfo/wikien-l>,<mailto:wikien-l-request at wikipedia.org?subject=subscribe>
>List-Id: Discussion list for English-language Wikipedia
><wikien-l.wikipedia.org>
>List-Unsubscribe:
><http://mail.wikipedia.org/mailman/listinfo/wikien-l>,<mailto:wikien-l-request at wikipedia.org?subject=unsubscribe>
>List-Archive: <http://mail.wikipedia.org/pipermail/wikien-l/>
>Return-Path: wikien-l-admin at wikipedia.org
>X-OriginalArrivalTime: 28 Jun 2003 18:13:20.0975 (UTC)
>FILETIME=[F4ED25F0:01C33DA0]
>
>james duffy wrote in part:
>
> >Is there any program that can be written to keep track of any new users
> >coming from those IPs and perhaps highlight them to a handful of senior
> >figures on wiki?
>
> >But that private eye program should not be generally available. All users
> >should be treated with the presumption of innocence.
>
>Watch out that we don't develop a corps (or cabal?) of "senior figures"
>that keep tabs on suspected bad guys without others' knowing what's going
>on.
>We have [[meta:List of Michael's pseudonyms]] available to all;
>any list of DW's pseudonyms should similarly be open to inspection.
>To be sure, such lists should state up front that these are /suspected/.
>(Michael's now does.)
>
>
>-- Toby

The reason why I suggested this method is to avoid mass troll hysteria
breaking out as can happen, understandably given the behaviour of some
trolls, everyone was spending their time watching the IPs and all ganging up
on some new user, with each new user from those IPs being presumed guilty
until proven innocent.

What I was suggesting that a very small number of universally respected
wikipedians (eg, Jimbo, Brion and Mav) would have access to a program that
would give them the chance to spot suspicious activities by "new" users from
the range of IPs associated with DW or Michael. They could privately monitor
the situation and if they are seriously worried that the likes of DW is back
then raise the issue with everyone. In addition as now we would all be
keeping our eyes out. And if we all had suspicions we could raise the issue,
with they having the additional program to check out general wiki suspicions
about a user.

To call that some sort of elitist cabal is misleading. Everyone organisation
on the planet have people to keep an eye out for potential problems. After
all I and most wikipedians have no access to the programs that run wiki, nor
do I want it. But that does mean that those that do are some sort of
secretive elitist canal. Unless wiki has some sort of program, we give
trolls like DW the advantage, unless individual users do what I did and
spent hours and hours trawling through the suspicious user's contributions
to find patterns.

But having mass access to to such a program could cause more problems than
it would solve and risk creating witchhunts. Allowing one or two universally
accepted people a chance to /quietly/ check out the behaviour of a
mysterious user first would offer wiki a chance calmly to keep an eye out
for DW et al, in the process causing miminal disruption to wiki unless they
have clear evidence that /something is going on/ when the issue would be
raised with everyone.

JT

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


body:
I could find the following problems:

> * Automatic table of contents. A TOC-table is added to pages that
>   contain more than three headings. This table links to the individual
>   sections within the article and hopefully makes navigation easier.

The TOC is invalid HTML for two major reasons:
* The top-level LI elements are not enclosed in an UL or OL
* The child ULs are outside the parent LIs.

> * Editing of individual sections. You need to be logged in to test
>   this. Just click the "[edit]" link next to a headline to change the
>   text of that particular section.

The [edit] link does not display when you're logged out, but when you
log in it is set as a default. This is potentially confusing to users.
Settings should not change by creating an account :-)

> * Linking into the Special: namespace with parameters. See Brion's
>   separate mail for details.

Seems to work great! :-)

Greetings,
Timwi


from_name: sgilbert at nbnet.nb.ca

subject: [Wikipedia-l] Intro for readers of this list (Was: "Edit this

body:
wikipedia-l-request at wikipedia.org wrote:

Daniel Mayer wrote:

> brion vibber wrote:
> >We have allowed such links since nearly
> >a year ago, but you had to make an anchor
> >yourself by putting in some HTML tag with
> >an 'id="anchorname"' attribute.
>
> Sounds cool. But why not just make another article?

Yet another reason: it would allow for a master index for the FAQ
pages, allowing people to quickly scan all the questions and jump
to the one of interest.

- Stephen G.

-------
Wikipedia: The Free Encyclopedia
http://www.wikipedia.org


subject: [Wikipedia-l] Re: Wikipedia-l digest, Vol 1 #1216 - 14 msgs

body:
On 2 Jul 2003, at 20:43, The Cunctator wrote:

> > My reasoning for this was that Wikipedia has two uses:
> > - a work of reference
> > - a collaborative editing system used by us.
> >
> > We need to find the right balance between making editing easy and making
> > reading Wikipedia unobtrusive. Some work on this is being done in the
> > Skin department, for example, where we will probably end up with a Skin
> > preferred by editors, and one that is more friendly to non-editing
> > users.
>
> This would be a terrible violation of the basic Wiki-nature of Wikipedia.

A "reader" skin wouldn't make it hard for people to edit; it would
just keep things as simple and uncluttered as possible, with
navigation tools and an "Edit this page" link. The complicated stuff
would be tucked out of sight. If you want to argue wiki-nature, I'd
say this simple skin would be more "wiki" than our current
cluttered, full-featured and somewhat confusing interfaces.

- Stephen G.
-------
Wikipedia: The Free Encyclopedia
http://www.wikipedia.org


body:
Brion-
> It's also mysteriously in a table and there are no line breaks. :)

I think it looks nicer in a table, but that's easy to change in Skin.php.

> I notice that duplicate headings (which is not unlikely to occur with
> subheadings) are marked with a numbered suffix after the first one. Better
> than nothing, but this is fragile for linking; if the major sections are
> rearranged in order, the numbers for the minor sections will change.

So what else do you suggest?

> Indeed. If we're adding features to make it easier to edit, I'm not sure
> it makes sense to hide them from new users...

My reasoning for this was that Wikipedia has two uses:
- a work of reference
- a collaborative editing system used by us.

We need to find the right balance between making editing easy and making
reading Wikipedia unobtrusive. Some work on this is being done in the Skin
department, for example, where we will probably end up with a Skin
preferred by editors, and one that is more friendly to non-editing users.

On the other hand, I do (of course) believe that the section editing
feature is very useful, and can save us substantial bandwidth, so that
every signed in user should get it by default. Perhaps a better long term
solution is to show users the preferences screen when they sign in for the
first time.

> Another minor suggestion I made to Erik earlier but which would apparently
> be "hard" with his regexps :) would be to have the section editing
> separate on horizontal rules as well as headings.

While this would complicate matters indeed, it is not the only reason I
oppose it. One problem is that on many pages we have both section headings
and horizontal rules used to separate different parts of the article, i.e.

== foo ==

bar

-----

== baz ==

bam

-----

So you would end up with duplicate links (or if you eliminate the dupes,
you surprise the user by not showing them the edit link). Moreover, it is
unclear what an edit link next to the ruler would refer to; the part above
or below the ruler? You would have to place the link above or below, which
would look ugly.

But the most important reason not to do this is that horizontal rules are
evil. Not only are they ugly, they provide no information whatsoever about
the sections that follow or precede them. That's what section headers are
for: to separate different parts of a page. When the different parts of a
page are so separate that a new section would not be enough, they should
be moved to separate pages.

By having the neat "edit this section" feature only for headings, we
encourage people to create headings for their own editing benefit. They
will reorganize talk pages to have them to be able to respond quicker in
the future. We provide no such incentive if we also implement the feature
for rules.

Regards,

Erik


body:
On 7/2/03 5:00 PM, "Mark Christensen" <mchristensen at humantech.com> wrote:

>>> Making wikipedia easier to use for everybody isn't a terrible
>>> violation of basic wiki-nature, it's just being nice to users.  And,
>>> that -- in my opinion -- is a just a good idea.
>
>> If "Anybody can use any skin they want!" were true,
>> I would agree with you 100%.
>
>> But only logged-in editors can use any skin they want.
>> Forcing editors to log in to use useful features is
>> a violation of Wiki-nature. I'm willing to hedge on
>> "terrible".
>
>> I'd first try to develop an interface that avoids
>> confusion without requiring cookies, etc. That would
>> be the optimal solution.
>
<snip>
>
> But, from this last post you argue that skin design could be a way to
> hide useful features from a whole class of users (those who have not
> logged in for whatever reason).  If the original proposal suggested that
> features would be hidden this might potentially be a concern.  But as I
> see it nobody is suggesting that any features which are currently
> available to anon users will be take away, just that they may be
> available only from specific pages so that they don't clutter up every
> screen.
>
> But even if some features were only available to logged in users, I
> would not consider it a violation of the wiki way as long as anon users
> can "edit this page right now!!!".

You wrote: "If the original proposal suggested that features would be hidden
this might potentially be a concern." That's what the proposal is.

It's true that taking away features currently available to anon users would
be wrong, but that's different from adding new, hidden features.

Adding new, hidden features is also not right.


body:
Brion-

>> I think it looks nicer in a table, but that's easy to change in Skin.php.

> The table doesn't do anything a styled div wouldn't do. It's not tabular,
> it's a list with a caption. :)

Tables are predictable and dependable. CSS often isn't. ;-) But it's
probably safe to use it by now.

>> So what else do you suggest?

> One possibility would be to append the name of the upper header(s) to the
> lower header:

> == Culture ==
> === Blecchistan ===
> === Miscania ===
> == Language
> === Blecchistan ===

> ....
> ...
> ...
> ....

> These would remain consistent if the order of Culture and Language are
> changed, or if another named section with a 3-rd level Blecchistan header
> is added before or between them.

But not if the hierarchy is changed, and we would still have to retain the
numbering feature for H2 dupes. Also, these anchor names could get very
long, especially for H4 anchors.

> Suppose the edit links are small, unobtrusive,

I've tried to make them small and unobtrusive, any further suggestions in
that area?

> and by default are faded
> (so seemingly partially transparent on the solid background) until a
> mouseover darkens them up to full visibility?

Hm, can you demonstrate that?

Regards,

Erik


body:
Richard-
> I think it's highly confusing having the edit section link above and to the
> right of the section it refers to. Below and to the right would be the more
> natural position

I would like to have it displayed *right-aligned* with the section
heading, and that's how it looks in Mozilla. The HTML used is

[edit link]

Page title

Could this be improved somehow? Perhaps this is a case where a table
should be used?

Regards,

Erik


subject: [Wikitech-l] Re: Suggestion: new script in languages

body:
Hi, folks!

Thomas Corell wrote:

> You know phase3/maintenance/checktrans.php ?

Oops. No. I didn't. I guess I just learned about it the hard way. :-)
Thanks for the hint. (rm myfile ...)

Bye!
Matthias


body:
Stan-
> The TOC should be just above the first section heading.

You are absolutely right, I have changed the behavior accordingly (not on
test.wiki yet). Looks very nice.

Regards,

Erik


body:
Richard-
> Not only is the markup of the TOC dreadfully invalid,

Correct, that was the result of some code moving. I have fixed it, and
while I was at it, I've removed the
s entirely and replaced them with

s. (Not on test.wiki yet.)

> it looks really weird
> seeing both bullets and numbers.

This should no longer happen. (Didn't happen in Mozilla anyway.)

> How about omitting the numbers from the text and simply using ordered lists

We need the numbers because some people have auto-numbering turned on, and
the TOC numbers should correspond to the auto-generated numbers within the
headings.

Regards,

Erik


from_name: Erik Zachte

subject: [Wikipedia-l] Re: Please help test new features:  TOC layout

body:
The Table of Contents does not nest lower order entries.
Also the mixture of order and unordered lists is a bit too much for me.

Current version:

* 1 About Wikipedia
1.1 In particular
* 2 How do I do that?
* 3 Information and resources for contributors
* 4 Getting in touch
4.1 On Wikipedia
4.1.1 Technical
4.1.2 Participants
4.2 Other online media

I would prefer (2 unordered nested lists)

* About Wikipedia
  = In particular
* How do I do that?
* Information and resources for contributors
* Getting in touch
  = On Wikipedia
  = Technical
  = Participants
  = Other online media

Level 1 entries might be shown bold >or< level 2+ italic

---

Also I would prefer a smaller font for the TOC. It takes so much space
now on articles with many sections. I like the TOC idea, but it should
not push the real article out of view.

Erik Zachte


subject: [WikiEN-l] We can say what we like about...

body:
>
>Jtdirl said: We can say what we want about Adam [name omitted for privacy reasons] and Michael,  but
>they have never stooped to such a  level of vandalism.
>Adam von [name omitted for privacy reasons] wrote:
>How true...

I would go further and say that if Adam and Michael sorted out their problem
with Jimbo, I would welcome them back as legitimate contributors to wiki.
But I think that DW's behaviour is of such a serious magnitude that he
should be permanently barred from contributing to wikipedia.

So I make this call publicly to Adam: please if you want to come back to
wiki, talk it through with Jimbo and get it OKed with him. And if you come
back that way, I for one will be happy to work with you.

JT

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail


body:
> I agree completely. Take a look at how ugly and
> unusable this is: http://test.wikipedia.org/wiki/Be .

I have tweaked the HTML of the page a little; please let me know what
you think:

  http://www.lionking.org/~timwi/t/wikipedia/article.htm

In short, I've put the TOC in the top-right of the screen. I've changed
a few elements that are part of the skin; but that's not a problem, I
could use this as an opportunity to overhaul the skin. It seemed rather
hackish and weird to me.

Greetings,
Timwi


subject: [Wikitech-l] CVS

body:
Hi,

> i see your posts so often in lj-dev

You could say I'm trying to force my popularity, LOL ;-)

> and your name so much in bugzilla

That's because I enjoy fixing tiny trivial little buggies, er, buglets,
or whatever the diminutive of bug is. Naturally, I can fix more of those
in the same time as I can write entire features (which I also enjoy
doing, but they're not very welcome on LJ).

> , and since you've had a higher ranking in the bazaar than avva, i
> kinda assumed you had become part of the core team, and maybe worked
> for LJ. my bad.

Heheh. The Bazaar doesn't make someone a core member. :) I've been
almost hermetically kept away from the core team, you'd think they have
an aversion against me :-)

> Anyways.. do you see a possibility of memcacheD ever being useful in
> the wikipedia?

Someone would have to translate the API to PHP.

> obviously at this point it can't really be used because we would need
> a ton more memory and probably another server, but, would it be
> practical for the large ammount of text per article, and large ammount
> of constantly changing articles that wikipedia has?

Average articles on Wikipedia aren't that much larger than average
LiveJournal entries. Although you're quite right in saying that
Wikipedia articles are updated quite a lot more often than LiveJournal
entries, this is balanced by the fact that new LiveJournal entries are
produced in much greater quantities than Wikipedia articles. I seem to
remember having read somewhere that all of Wikipedia's articles in their
most recent versions total 4 GB or something? Contrast that with
LiveJournal's 80 GB ;-). Readers would benefit from MemCacheD no matter
what, even if editors don't (although I'm sure editors will, too).

> from what I assume, given that there was enough memory available it
> would do wonders for the article search, woulnt it?

Actually, this is an interesting point. I'm not sure MemCacheD will help
here because it certainly does not build an in-memory keyword search
index. It's just a cache, not an in-memory database :-). I don't know
how the search function works at Wikipedia (LiveJournal doesn't have
one), but the way I understand it, it performs an SQL query
(disregarding the Go button for now) that cannot be "translated" to
MemCacheD.

So, maybe the search will still have to be done on the database. But I'd
be very glad if we could speed up the servers by MemCacheD'ing
everything else.

Greetings,
Timwi


subject: [Wikipedia-l] RE: Please help test new features

body:
How about editing conflicts? Do they work for the new section edit
feature?

I opened two windows for the same article and clicked edit for the same
section in both windows.

I changed the text in window 1 and saved it.
Then I changed the text in window 2 and saved it.

I did not receive an response 'Editing conflict'.

Is this because I did this from the same IP address,
or is it a 'feature' of the new release?

Erik Zachte


body:
Now that headers become even more important:

H3 and H4 are almost indistinguisable
(at least on Explorer 6 default settings).

This is quite confusing. A reason why many writers prefer '''bold'''
text for headers lower than H3.

Also the font size for the headers is quite large.
Small paragraphs with huge headers is quite ugly.

This has been discussed before:
Can we have a smaller H4 in the stylesheets?

Erik Zachte


body:
Erik-
> How about editing conflicts? Do they work for the new section edit
> feature?

Yes, they should work. You probably could not trigger the edit conflict
for caching reasons; try the same with editing a whole page and the result
will be the same. Open + edit the page/section in different browsers to
trigger a conflict.

Regards,

Erik


from_name: Adam

from_email: Adam

body:
Jtdirl stated: Adam: please...come back to wiki, talk it through with Jimbo and get it OKed...and...I...will be happy.

Yes, but try and remember that it is Jimbo who has the problem with me, not I who has the problem with Jimbo. There is naught that I can to do to sway Jimbo, and in fact, this post here will almost certainly serve to harden Jimbo against me, for he has consistently sent me angry letters after any public statement in which I criticize him; he will certainly find it critical for me to "put the blame on him" and state that it is him who keeps me banned, not I (through my refusal to atone for various grievances) who keeps me banned.

Also, I do believe I have stated that my name isn't Adam on numerous occasions.

---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030703/df15da34/attachment.htm


from_name: Jimmy Wales

subject: [Textbook-l] License issues

body:
Toby Bartels wrote:
> How long until all text on Wikipedia is completely rewritten?  5
>years? 10?

That's a good question.

> Everything that /I/ write on Wikipedia
> is automatically free with /no/ restrictions,
> because /everything/ that I write is free with no restrictions.
> To be sure, such lack of restrictions applies only
> insofar as what I've written is /new/ --
> otherwise, the rest is still copyright as before,
> and that material is licensed only under the GFDL.
> But can it work to require people to dual license their submissions,
> so long as the Creative Commons licence specifically applies
> /only/ to the material that's new?
> (For any given submission, that may be nothing, or everything.)
> Does such an idea fit into copyright law at all?

Well, it's hard to say, but basically, I suspect that this approach
isn't helpful.

Here's the problem.  Imagine that each of the following snippets is
GNU FDL.

'ADE' <---- original article
'AbDE' <-- revision, but under the terms of the GNU FDL, this *must*
be released under GNU FDL.  Perhaps the 'B' portion is *also* released
under Attribution-ShareAlike.

After a sequence of further edits, including efforts by someone to
remove all of the original 'ADE' text, we end up with:

'abcde', where all of the parts are now released under GNU FDL and
Attribution-ShareAlike.  But since each step along the way included
some GNU FDL, it *still* has to be released under GNU FDL.

And ONLY if 'abcde' is really a competely new aggregation of parts can
*any* of it be released under Attribution-ShareAlike.

For example, if I write "Thomas Jefferson was the 3rd President" and
release this under the GNU FDL, and you come in and add "Thomas
Jefferson was the 3rd President, and he had red hair."  Well, your
work is a derivative work, and you have *no right* to release it under
Attribution-ShareAlike.  I suppose you could release 'and he had red
hair' under Attribution-ShareAlike, but ai yi yi, what a mess.

But really, there are no significant problems with GNU FDL.  It's
complicated, and it reads 'funny' in parts for our context.  I wish it
were simpler, like Attribution-ShareAlike, but it isn't, so there you
go.

--Jimbo


subject: [WikiEN-l] NPOV example

body:
http://www.wikipedia.org/wiki/Trade_war_over_genetically_modified_food

In the revision of 7:53 2 Jul 2003, we read:
>Friedrich-Wilhelm Graefe zu Baringdorf (Grune party), Vicepresident
>of the Landwirtschaftsausschuss (committee of agriculture?) of the
>European Commission said on the 1.July.03: "In America 55% of the
>consumers are against GM food and 90% in favor of a clear
>labelling. The Bush government is ignoring the demand of his own
>people."

A little rough, but the point of view is attributed.  It's completely
uncontroversial, I suppose, that Graefe did say such a thing, and it's
just the sort of thing that we expect Green Party politicians to say.

But in revision 8:03 2 Jul 2003, we see this new line appear: "Also
American consumer demand that, but the Bush administration is ignoring
that fact."  That's written as an assertion _by Wikipedia_.

This is a blatantly political statement, and whether or not it is
actually true is irrelevant.  (I personally think it is preposterous,
but that's the nature of finding POV claims, I suppose -- the ones
that stick out for us are the ones that we find particularly silly.)

Citing a politician from the German Green Party saying such a thing is
wonderful.  The cite itself gives the reader sufficient context to
evaluate the claim, and in any event _Wikipedia_ is not making a
political claim at all.

It would likely be helpful to have a balancing quote from a scientist,
of course, but it isn't strictly speaking necessary.

What *is* necessary is that Wikipedia avoid making claims of this
sort.

--Jimbo


from_name: Richard Grevers

body:
On 02 Jul 2003 19:22:00 +0200, Erik Moeller <erik_moeller at gmx.de> gave
utterance to the following:

> The following features are currently tested on
> http://test.wikipedia.org :
>
> * Automatic table of contents. A TOC-table is added to pages that contain
>
> more than three headings. This table links to the individual sections
> within the article and hopefully makes navigation easier.
> * Editing of individual sections. You need to be logged in to test this.
> Just click the "[edit]" link next to a headline to change the text of
> that  particular section.

I think it's highly confusing having the edit section link above and to the
right of the section it refers to. Below and to the right would be the more
natural position
--
Richard Grevers
Love is the triumph of imagination over intelligence


subject: [Wikipedia-l] Re: [Intlwiki-l] Announcing Wikimedia Foundation

in_reply_to: <r5ihe638wk3.fsf@gill.maths.keele.ac.uk>; from wiki@gwowen.freeserve.co.uk on Thu, Jul 03, 2003 at 04:22:20PM +0100

body:
Gareth Owen wrote:
> WWW stands for World Wide Web - three *english* words.  If other
> languages wish to replace there language codes with the equivalent
> abbreviation in their own language, I'm sure no-one will mind.
> (lwm.wikipedia.org for "le web mondial", peut-?tre?)

I don't really agree with this argument.  'www' is known worldwide as
the indicator for the 'main' website of any organization.  So although
'www' has its roots in English, it's really quite general.

--Jimbo


in_reply_to: <20030703125517.38054.qmail@web14704.mail.yahoo.com>; from cddvdlenscleaner@yahoo.com on Thu, Jul 03, 2003 at 05:55:17AM -0700

body:
Adam von [name omitted for privacy reasons] wrote:
> Yes, but try and remember that it is Jimbo who has the problem with
>me, not I who has the problem with Jimbo. There is naught that I can
>to do to sway Jimbo, and in fact, this post here will almost certainly
>serve to harden Jimbo against me, for he has consistently sent me
>angry letters after any public statement in which I criticize him; he
>will certainly find it critical for me to "put the blame on him" and
>state that it is him who keeps me banned, not I (through my refusal to
>atone for various grievances) who keeps me banned.

I have only complained to you privately when you have publicly lied
about the reasons that you were banned.

In any event, I'll gladly agree that you remain banned on my say-so,
as opposed to your own say-so.  But the ban remains in place because
of your refusal to agree to some basic standards of behavior, and your
refusal to apologize for your past dishonest actions.

If you're willing now to do those things, and to genuinely reform your
behavior, then we can talk.

> Also, I do believe I have stated that my name isn't Adam on numerous
> occasions.

Well, if you don't want people to call you Adam, Adam, then you should
reconfigure your software to reflect your name-of-choice.  Right now,
emails from you appear to come from "Adam von [name omitted for privacy reasons]".

--Jimbo


body:
On 02 Jul 2003 21:46:00 +0200, Erik Moeller <erik_moeller at gmx.de> gave
utterance to the following:

> Richard-
>> I think it's highly confusing having the edit section link above and to
>> the
>> right of the section it refers to. Below and to the right would be the
>> more
>> natural position
>
> I would like to have it displayed *right-aligned* with the section
> heading, and that's how it looks in Mozilla. The HTML used is
>
>
[edit link]

>
Page title

I just checked in Moz 1.4a, IE6 and Opera 7 - the edit link is definitely
higher than the header in all three - if I have the link right at the
bottom of the screen, the Heading is off the bottom of the screen. This
makes the link look as though it relates to the section above it.
The following markup achieves what you were aiming for:

[edit]
 This
is a very long heading that might clash with the float

i.e. transfer the float to the inline element small and make the heading a
child of the div.
Notice that I've also replaced the  element with an id on the
header, which is much more efficient and avoids problems with headers
accidentally inheriting styling intended for links in some browsers.

More efficient still would be

[edit]
 This
is a very long heading that might clash with the float

and then you can define
.editheader small {float:right; margin-left:5px;}
and skins can do groovy things like
.editheader {outline:1px solid #ccc;}

Richard (really looking forward to the day when users can specify their own
stylesheets, stored locally)

--
Richard Grevers
Love is the triumph of imagination over intelligence


body:
On 02 Jul 2003 19:22:00 +0200, Erik Moeller <erik_moeller at gmx.de> gave
utterance to the following:

> The following features are currently tested on
> http://test.wikipedia.org :
>
> * Automatic table of contents. A TOC-table is added to pages that contain
>
> more than three headings. This table links to the individual sections
> within the article and hopefully makes navigation easier.

Not only is the markup of the TOC dreadfully invalid, it looks really weird
seeing both bullets and numbers.
How about omitting the numbers from the text and simply using ordered lists

First section

Second section

the second section has

two subsections

etc.

and set the list-types via the skin stylesheet: e.g.
OL {list-style:upper-roman;}
OL OL {list-style:decimal;}
OL OL OL {list-style:lower-roman}
This also leaves better scope for internationalization: list numberings
include hebrew, katakana, georgian etc.
--
Richard Grevers
Love is the triumph of imagination over intelligence


body:
Richard Grevers wrote:

>Toby Bartels wrote:

>>Perhaps you mean links to articles that have
>>several brief discussions that are separated by horizontal rules?
>>That makes some sense.

>Yes - if you look at the page for [[Pitch]] for example, not all contexts
>link to articles (most have wiki links, but in some cases the target
>article is very broad and will be lucky to mention the word pitch once.

OK (I assume that you mean [[en:Pitch]]) ...
but the scheme that's being planned now
will do nothing for that example.
It doesn't even have horizontal rules!
(And much of that should move to Wiktionary too.)
That's why I said above that it makes only /some/ sense. ^_^

-- Toby


from_name: Ray Saintonge

subject: [Wikitech-l] European language wiki's to own server+database.

body:
Jeroen wrote:

>Hello,
>
>Proberly some of you will flame me, but I will take that for granted.
>
Disagreement is not a flame if it is done respectfully.

>My idea is to combine all the European language wikipedia's (except english
>and maybe spanish and portuguese) on one server and using one database,
>located somewhere in Europe.
>
>Here is why:
>
>* We will not be depending on the US anymore.
>
I'm as critical as any foreigner (relative to the US) about their
policies, but that alone does not make the case for the move.  Ideally,
it should not make any difference where the server(s) is located if we
are operating in a global environment   As a Canadian I would be just as
concerned about having the French Wikipedia dominated by European interests.

Of course, I still think that it would be worthwhile to have every
Wikipedia automatically backed up in a second country.  This sort of
reflects a street smart self-preservation instinct.  Given the
centralizing tendencies in the European Community and it's love for
bureaucracy, anything based in the EC would have to be backed up outside
that community since any two countries in the EC are now different in
name only.

>- As this can be considered a political issue, it is mostly a technical
>issue. Because when there are problems, we (Europeans) can solve this on
>hours, people in the US are still at sleep. This also includes fixing
>things on location.
>
This is a round the clock operation.  Hopefully, problems requiring
on-location attention will remain very few, but we can expect long
waitsin those cases no matter when the problem arises.

>- Also the performance will not be influenced by the English-language
>wikipedia.
>
This is not an argument for moving out of the US; only for moving them
to another server.

Eclecticology


body:
On Thu, 03 Jul 2003 08:29:06 +1200, Richard Grevers <lists at dramatic.co.nz>
gave utterance to the following:

> On 02 Jul 2003 21:46:00 +0200, Erik Moeller <erik_moeller at gmx.de> gave
> utterance to the following:
>
>> Richard-
>>> I think it's highly confusing having the edit section link above and to
>>> the
>>> right of the section it refers to. Below and to the right would be the
>>> more
>>> natural position
>>
>> I would like to have it displayed *right-aligned* with the section
>> heading, and that's how it looks in Mozilla. The HTML used is
>>
>>
[edit link]

>>
Page title

>
> I just checked in Moz 1.4a, IE6 and Opera 7 - the edit link is definitely
> higher than the header in all three - if I have the link right at the
> bottom of the screen, the Heading is off the bottom of the screen. This
> makes the link look as though it relates to the section above it.
> The following markup achieves what you were aiming for:
>
>
[ href="/w/wiki.phtml?title=This_one&action=edit&section=1"
> class='internal' title="This one">edit]

> This is a very long heading that might clash with the float

>
> i.e. transfer the float to the inline element small and make the heading
> a child of the div.
> Notice that I've also replaced the  element with an id on the
> header, which is much more efficient and avoids problems with headers
> accidentally inheriting styling intended for links in some browsers.
>
> More efficient still would be
>
[ href="/w/wiki.phtml?title=This_one&action=edit&section=1"
> class='internal' title="This one">edit]

> This is a very long heading that might clash with the float

>
> and then you can define
> .editheader small {float:right; margin-left:5px;}
> and skins can do groovy things like
> .editheader {outline:1px solid #ccc;}
>
> Richard (really looking forward to the day when users can specify their
> own stylesheets, stored locally)
>
Following up to myself:
I just discovered that if you add a border, the CSS margin-collapsing rules
come into play and add default 1em top-margin to the H2. So in any skin
where you wanted a border you would need to specify something like
.editheader H2, .editheader H3, .editheader H4 {margin-top:0;}
.editheader {border:1px solid #ccc; margin-top: 1em; padding: 2px 0.5em;}

--
Richard Grevers
Love is the triumph of imagination over intelligence


subject: [WikiEN-l] Over the weekend...

body:
James duffy wrote in part:

>Toby Bartels wrote:

>>Watch out that we don't develop a corps (or cabal?) of "senior figures"
>>that keep tabs on suspected bad guys without others' knowing what's going on.
>>We have [[meta:List of Michael's pseudonyms]] available to all;
>>any list of DW's pseudonyms should similarly be open to inspection.
>>To be sure, such lists should state up front that these are /suspected/.
>>(Michael's now does.)

I should have had a smiley after "cabal?" above.

>The reason why I suggested this method is to avoid mass troll hysteria
>breaking out as can happen, understandably given the behaviour of some
>trolls, everyone was spending their time watching the IPs and all ganging
>up on some new user, with each new user from those IPs being presumed
>guilty until proven innocent.

OK, I see where you're coming from now.

>What I was suggesting that a very small number of universally respected
>wikipedians (eg, Jimbo, Brion and Mav) would have access to a program that
>would give them the chance to spot suspicious activities by "new" users
>from the range of IPs associated with DW or Michael. [...]

>To call that some sort of elitist cabal is misleading.

Certainly; but I said /develop/, not /start with/.
Check out [[Wikipedia talk:Policy on permanent deletion of pages]]
to see how a power once restricted to
a very small number of universally respected Wikipedians
eventually came to be held by a large, but still elite, class: all admins.

Now, this isn't a problem, because the process is open,
and it's clear what the admins do and how to become one.
Your suggestion would be carried out in private, which is the risk.
There's also the matter of avoiding even the /appearance/ of impropriety --
providing that such appearance is reasonable of course
(I don't mean to satisfy every visiting ideologue).

>But having mass access to to such a program could cause more problems than
>it would solve and risk creating witchhunts.

Yes, I can understand this.
I guess that I just want the system be clear and above-board.
Even if only Jimbo, Brion, and mav (all of whom /I/ universally respect ^_^)
are the only people with access to the witch-huniting software,
I still think that any hunting that they do should be publicly logged.
Exactly what this entails would depend on the system, of course.
Maybe I don't grasp what you're thinking of in enough detail?

-- Toby


body:
Erik Moeller wrote in part:

>We need the numbers because some people have auto-numbering turned on, and
>the TOC numbers should correspond to the auto-generated numbers within the
>headings.

As a user of auto-numbered headers, I'd be quite happy with
ordered lists inside ordered lists, like so:

Header A

Subheader a

Subheader b

Header B

which generally appears along the lines of:

1  Header A
   1  Subheader a
   2  Subheader b
2  Header B

That seems pretty clear to me.

-- Toby


from_name: Christopher Mahan

body:
-- Adam von [name omitted for privacy reasons] <cddvdlenscleaner at yahoo.com> wrote (kindof):
> bla bla bla jimbo bla bla bla...

It hasn't yet dawned on you that Jimbo *pays* for the bandwidth?

=====
Christopher Mahan
chris_mahan at yahoo.com
818.943.1850 cell
http://www.christophermahan.com/

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


from_name: Mirko Thiessen

subject: [Wikipedia-l] Re: Please help test new features

body:
Erik Moeller wrote:
>
> Please help us test these features before we put them on the live server,
>
> otherwise, things might break unexpectably.
>

Everything works fine in Opera 7 and IE 6. Great new features. The TOC
below the introduction looks fine. IMO it is a better place than top right
or in the sidebar.

As for the EDIT links belonging to the sections, I would expect to be able
to edit an entire section including the sub-headings after clicking on such
an edit link. (see http://test.wikipedia.org/wiki/Donau-Ries - after
clicking on EDIT next to the HISTORY section the edit screen includes only
the heading "History" and not the sub-headings below) I don't know, if it
is possible to implement this, but you will probably know.

Thanks for the great work,

Mirko (Cordyph)


from_name: Tim Starling

subject: [Wikitech-l] Re: Dynamic dates

body:
>Actually, I looked at the code to make some changes to my private language
>file and didn't understand it. I know somehow what the code does but not
>how, because I didn't want to spend that much time decoding all those
>regexps that make the code pretty cryptic and hard to maintain - with the
>added bonus of not having /any/ documentation.

In case anyone's wondering, yes the code is in CVS now. But it's not
finished: there's still at least one more update to Language.php to come.
Sorry about that Jens but you'd probably be better off commenting the whole
section out for now. As for not having any documentation, I can fix that in
my next commit.

>Why not rearrange the code into two segments: Segment one would parse the
>linked date like present in the article into three numerical values: day,
>month, year. The second segment then would only have to concat those values
>(maybe with a converted month name) into the final form. This form could be
>given in the usual "$1 $2 $3 $4" syntax (with e.g. $4 being the month
>name). That also would take some load off the server that now has to
>interpret lots of regexp patterns, which isn't too cheap because these
>patterns normally first get converted into some form of a finite automaton
>that is eventually given the input string for processing. (At least the
>code by Tatu Ylonen proceeds in this way.)

No, I think your way would be slower, not faster. There's a "pre-analysis"
flag you're meant to use if you run the same regular expression many times,
but according to the PHP manual it only provides a speedup if the regular
expression starts with something other than a fixed character. So it sounds
like there's no compilation. Besides, if regular expressions were slow,
well, the rest of the parser would be in trouble.

By splitting the replacing from the parsing, you're just turning one job
into two. The same tasks are still required, there's just some extra
administrative overhead. Plus since PHP is an interpretive language, I'd
really rather have the O(N) code written in C.

As for your way being simpler, well, I would contest that too. You code it
your way, and we'll put them side by side. My way really is pretty simple if
you understand Perl regular expressions.

-- Tim Starling.

_________________________________________________________________
Hotmail is now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/signup.asp


subject: [Wikitech-l] Languages [was: Database design and interwiki links]

body:
Oualmakran Youssef wrote:

>Most data in years/months pages are very short sentences.
>For example, the deaths/births sections should fairly easily
>be translated by a program with human help.
>
Machines still only give a very rough first draft, and very brain dead
translation that can sometimes have us rolling in the aisles with laughter.

>For examples:
>*president of the United States--> Pr?sident des ?tats-Unis (French)
>*American actor--> acteur am?ricain.
>
>We should store that kind of data in a translation memory since the
>translation does not change with context.
>
And how do you account for the tendency for some to translate "actor" as
"com?dien" whether or not the acting is comedy as most of us would tend
to interpret that term at first glance.  Then there is the question of
what to do with the feminine of actor and president where the political
correctness can be a problem.

Translations are rarely so straightforward


from_name: David Friedland

subject: [Wikitech-l] Problems with Table of Contents and possible solution

body:
The Table of Contents feature could potentially suffer from the
following problems, as it is currently implemented:

1. An article with many short sections would inappropriately get a TOC
that would waste space.
2. An article with just two very long sections wouldn't get a TOC but
would be appreciably helped by one.
3. Sometimes a TOC would be best located not at the top of an article,
but after a short introductory paragraph. I think some dead tree
encyclopedias use this method.
4. If displaying TOCs is off by default, most users won't appreciate
their utility, as most users won't change preferences. It seems a TOC is
most useful to readers of an encyclopedia, and as many readers won't
even be logged in, they won't see the potentially helpful TOCs.

I propose that whether and and where a TOC appears should be specified
by each article using a wiki tag indicating where the TOC should appear.
This would allow articles with many short sections to not have a TOC,
long articles with just a few sections have a TOC, and allow article
authors/editors to specify the best location for the TOC without relying
upon the wiki software to presume the very top of an article is the best
place.

I think keeping the option of having automatically-generated TOCs as a
user preference is desirable, as at first, most articles won't have a
TOC. Maybe they should be a different color, so editors can easily
identify articles that would benefit from a TOC and insert the wiki tag
for one, and perhaps identify articles that suffer from a TOC and insert
a wiki tag to exclude one.

- David Friedland (Nohat)

(I'm not sure if this is more appropriate discussion for Wikipedia-l, as
it might involve policy, so I erred on the conservative side and have
posted on wikitech-l)


body:
This copied from my post to wikitech-l:

The Table of Contents feature could potentially suffer from the
following problems, as it is currently implemented:

1. An article with many short sections would inappropriately get a TOC
that would waste space.
2. An article with just two very long sections wouldn't get a TOC but
would be appreciably helped by one.
3. Sometimes a TOC would be best located not at the top of an article,
but after a short introductory paragraph. I think some dead tree
encyclopedias use this method.
4. If displaying TOCs is off by default, most users won't appreciate
their utility, as most users won't change preferences. It seems a TOC is
most useful to readers of an encyclopedia, and as many readers won't
even be logged in, they won't see the potentially helpful TOCs.

I propose that whether and and where a TOC appears should be specified
by each article using a wiki tag indicating where the TOC should appear.
This would allow articles with many short sections to not have a TOC,
long articles with just a few sections have a TOC, and allow article
authors/editors to specify the best location for the TOC without relying
upon the wiki software to presume the very top of an article is the best
place.

I think keeping the option of having automatically-generated TOCs as a
user preference is desirable, as at first, most articles won't have a
TOC. Maybe they should be a different color, so editors can easily
identify articles that would benefit from a TOC and insert the wiki tag
for one, and perhaps identify articles that suffer from a TOC and insert
a wiki tag to exclude one.

- David Friedland (Nohat)


in_reply_to: <8p8yDjESpVB@erik_moeller>; from erik_moeller@gmx.de on Thu, Jul 03, 2003 at 07:10:00PM +0200

body:
Erik Moeller wrote:
> Jimmy-
> > In any event, I'll gladly agree that you remain banned on my say-so,
>
> That is incorrect. Since several users have objected to banning Lir under
> his current incarnation ("Pizza Puzzle"), I have refrained from doing so
> for the time being, and will not ban him unless you explicitly ask me to
> override these objections.

I have a personal promise directly from Adam/Lir/Bridget or whatever
he or she prefers to be called that he will not edit the wikipedia
under any username.  So, as a courtesy, I do not believe that Pizza
Puzzle and Adam/Lir/Bridget are the same person.  I trust that,
whatever differences we may have, a direct violation of a personal
promise is not the sort of thing that he would do.

If I'm wrong about that, and Pizza Puzzle is Lir, then I will be
personally very disappointed.

Since 'Adam von [name omitted for privacy reasons]' is posting to this list, perhaps he could
clarify this for us.  Are you posting now under the alias that Erik
mentioned?

If so, I request that you stop immediately, as you are only further
damaging your credibility around here.

--Jimbo


body:
Erik Moeller wrote:

>>1. An article with many short sections would inappropriately get a TOC
>>that would waste space.
>>
>>
>
>Then remove some sections.
>
A growing article with many stub sections should have those stubs
removed then, so the TOC doesn't get in their way?

>>2. An article with just two very long sections wouldn't get a TOC but
>>would be appreciably helped by one.
>>
>>
>
>Then add some sections.
>
What if there is no good way to break up a few long sections into
shorter ones? Should such an article be doomed to suffer without a TOC?

I surmise you supporting the notion that some wiki-algorithm is better
at determining whether an article merits a TOC than each article's
author. I disagree, as it seems that an aspect of articles that is so
intimately married to the content as a TOC should be modifyable by
editors and not arbitrarily imposed by the wiki software.

I agree than in an ideal Wikipedia, every article would have exactly the
right number of sections of exactly the right length, and the TOC
algorithm would word perfectly. But in the meantime, with a non-ideal
Wikipedia, how can you defend the TOC feature's exacerbating the
situation by disallowing TOCs where they might be useful and forcing
them to be included where they are extraneous?

- David


from_name: webmaster

subject: [WikiEN-l] Turning on automated processes

body:
Recently, I have seen multiple requests for pages that were once autimatically updated, like Orphaned pages, to be updated.  It is my understanding, that the automatic updating of these pages was turned off because the server was running slowly.  Since then, we have gotten a second server.  So could someone please turn these services back on?
Thanks,
Michael Becker
aka Mbecker
aka MB


from_name: Timwi

subject: [Wikitech-l] Please help test new features

body:
Re the HTML for the TOC: Why don't you use ol and li? And why do you
need two nested tables?

Greetings,
Timwi


from_name: rvalles

body:
On Fri, Jun 20, 2003 at 09:18:00AM -0700, Jimmy Wales wrote:
> I'm pleased to announce the existence of the Wikimedia Foundation,
> Inc., a nonprofit corporation organized under the laws of Florida,
> United States.  I am transferring to this new corporation the assets
> that follow:
> ...

That's great. Now that this long-lasting issue has been solved, let's focus in the other ones that aren't, and that are really important:

- Unprivilegiation of the English wikipedia: The way it's setup now (http://www.wikipedia.org = english. others are ?.wikipedia.org) is totally discriminative , offensive and degrading for the other languages, that are placed into a not-as-important position.
- Migration of all wikipedias to the phase3 software. There are still many of them, like the catalan one, running Phase1. This one in particular does have really good traffic of changes laterly, but the old software is driving it into an everyday more chaotic situation.
- More openness in general, public discusion of decisions before them being made.
- Distribution of the servers all arround the world, allowing every one of them to mirror backups for all the others, and avoiding this way any kind of censorship originated by having a single server unther the US laws.

Until then, me and a lot of people have freezed any kind of contribution. Myself, I'm specially angry about the english-as-the-main-language-and-others-just-secoundary thing, and about it being not solved even after years listening to people asking so.

By the way, if you're interested in a spanish language free encyclopedia, we mantain http://enciclopedia.us.es/, that was a spanish wikipedia fork done because of a group of people not happy about those and other wikipedia issues. It is actually way bigger (does have near 15.000 articles) than the spanish wikipedia, and hopes to be able to re-merge with wikipedia someday, after all the issues are solved.
--
Because ten billion years' is so fragile, so ephemeral... it arouses such a bittersweet, almost heartbreaking fondness. ("Now and Then, Here and There"'s Opening)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030703/afce988d/attachment.pgp


from_name: tarquin

subject: [Wikipedia-l] Please help test new features

body:
Erik Moeller wrote:

>The following features are currently tested on
>        http://test.wikipedia.org :
>
>* Automatic table of contents. A TOC-table is added to pages that contain
>more than three headings. This table links to the individual sections
>within the article and hopefully makes navigation easier.
>
This should be a list, NOT a <table>


body:
Mirko-
> As for the EDIT links belonging to the sections, I would expect to be able
> to edit an entire section including the sub-headings after clicking on such
> an edit link. (see http://test.wikipedia.org/wiki/Donau-Ries - after
> clicking on EDIT next to the HISTORY section the edit screen includes only
> the heading "History" and not the sub-headings below)

This is a bit of a philosophical question. IMHO sections should not be as
short as they are in the Donau-Ries article. The text is only 6400 bytes,
yet there are 11 sections, that's 580 bytes per section. The whole history
section has

Early history
Ancient history
  Celtic and Roman peoples
  Germanic peoples
  Oettingen wars
Newer history

IMHO these subsections are unnecessary unless there's actually a
substantial amount of text in each one of them. Hopefully, the TOC and
edit links will help us find the right balance in terms of individual
section length. With longer sections, you don't want the [edit] link to
load all the text within that section and subsections, because you'll have
the same problem as before: too large blocks of text.

Regards,

Erik


body:
Timwi-

> Re the HTML for the TOC: Why don't you use ol and li?

Because we need to do manual numbering anyway, to keep the numbers
consistent with those used by the auto-numbering for headers (which is a
user preference). Also, it was easier to get all the margins right and
avoid unnecessary whitespace this way.

Feel free to play around this with Skin.php, but please realize these two
requirements. There should be no indentation on the first level, and no
margin above or below the list items; the numbers must be the same and in
the same format as in the headlines. I think that's a pointless exercise,
because the current solution works fine and probably takes less space.

>  And why do you need two nested tables?

That's an ugly hack to accomplish a thin border without using CSS. It
works in all browsers I've tested, though, since it relies on very basic
table properties. I've experimented with replacing the whole table with a
<DIV> yesterday, but that didn't work as desired; the border did not auto-
expand. I could either specify a min/max width, or it would take up 100%
of the screen. That's not acceptable. There's a commented version of my
last variant in Skin.php.

I've also played around with floating the table, but that takes a lot of
screen real estate, and will not work well with all but the highest
resolution when there's also an image. Given that not all users will
enable the toc, this would make testing if the image width is too high
quite tricky.

Regards,

Erik


subject: [Wikitech-l] Re: [Wikipedia-l] Please help test new features

body:
Richard-
> Does your current code ensure that anchor names only start with a letter a-
> z? names starting with a number are illegal, and hyphen and underscore are
> the only permissible punctuation.

I've tested with Mozilla, Opera, IE, lynx, links, w3m and noticed no
problems with anchors containing other punctuation or starting with
numbers. Keep in mind that these anchors are also used to link to
individual sections from elsewhere:

[[Popular songs#99 bottles of beer]]

This will no longer work as expected if we escape the anchor names to
satisfy a restriction that no browser seems to implement anyway. My
features don't depend on the anchor names, but the anchor linking feature
does, and so far I've seen no good alternatives to using the section title
as is to make this easy.

Regards,

Erik


body:
rvalles wrote:

>
>That's great. Now that this long-lasting issue has been solved, let's focus in the other ones that aren't, and that are really important:
>
>- Unprivilegiation of the English wikipedia: The way it's setup now (http://www.wikipedia.org = english. others are ?.wikipedia.org) is totally discriminative , offensive and degrading for the other languages, that are placed into a not-as-important position.
>
>
Yes. This would be good.

>- More openness in general, public discusion of decisions before them being made.
>
But this is what is preventing the request above.
The discussion goes round and round and round and round and round and
round and round and round and round............ then we all say "we're
not getting anywhere, let's leave it a while". Then someone brings it up
again, and STILL nothing gets done.

-- tarquin


subject: [WikiEN-l] A couple of links

body:
Someone posted these anonymously on my User_talk page.  I thought that
they were of sufficient interest to post to the mailing list.

http://www.wikipedia.org/w/wiki.phtml?title=Talk:Anti-Semitism&diff=1104682&oldid=1103906

http://www.wikipedia.org/w/wiki.phtml?title=Talk:Jew&diff=1104783&oldid=1104717

RK, you're a longtime contributor, highly valued, but I'd like to ask
you to tone it down a notch.  Referring to the contributions of others
as "Neo-Nazi-like revisionism" is not kind, and it causes people to
get very upset, and with good reason I think.

On the second link you wrote "You don't understand Wikipedia's NPOV
policy at all. It does ''not'' mean that everyone must agree with the
text."  I'm not sure what you meant by that, but I would say that NPOV
does require us to write the text in such a way that all reasonable
people can agree to it.

So, yeah, it's basically impossible to appeace every lunatic on the
face of the earth, but we do strive to write in such a fashion that
the only remaining objections _are_ lunatic.

Which means something very close to 'everyone must agree with the
text'.  (Certainly, your interlocutors in these debates are not
lunatic, although they may very well be wrong on a number of things.)

I do understand that anti-Semitism and Judiasm are intensely emotional
issues for many, nearly as controversial as bird naming conventions.
(Ha, ha, a little levity in a serious post, sorry.)

This means that on these topics, more than any others, we need to be
ready to work with kindness and to minimize combativeness.

Since this post is critical of RK, let me say this: I am only
criticizing his _style_, and on all of the _content_ issues that I
have looked at (a very small number compared to all that has been
written), I tend to agree with him completely, and I do share his
concerns about anti-Semitism slipping quietly into our articles.

--Jimbo


subject: [WikiEN-l] Ideas on a methodology

body:
My wife and daughter are going on vacation soon, and so for one week,
I'll be able to fully indulge my natural inclination to stay on the
net 18 hours a day.  :-) So I plan to do some things that I haven't
had time for.

Once upon a time, I did a study of our site and Britannica's,
comparing our articles to theirs.  As I recall, I used our 'random
article' feature to select ten topics, and then I compared theirs and
ours.  (But I seem to remember finding some subjects on which we
didn't have an article and they did, so I don't know how I could have
done that.)

What I'd like to do is sit and explore Britannica and Wikipedia,
comparing and contrasting our strengths and weaknesses, with an eye
towards my REAL project for the week, which is to put together a
"Roadmap to 1.0" for Wikipedia.

So far, we have put aside most talk of 'finalizing' articles for a 1.0
release because there was so much left to do.  But now I think that we
have a huge number of articles, nearly complete coverage in many
common areas, and that it would be wise to start thinking about how
and when we might produce a '1.0' version to make it easy for content
re-users to produce CD-ROMs, books, whatever.

One of the crucial components in deciding when to make a push for
something like that is our overall level of completion.  And measuring
against Britannica is a good way to assess that.

What methods should I use?  I obviously can't read both works cover to
cover in a week.  :-) So I have to randomly sample somehow, I guess.

And I might supplement my random sampling with some 'linear' checks
like: do we have an article on every leader of every nation?  Do we
have an article on every city in a list of the 100 most populus in the
US?  Things like that.

--Jimbo


in_reply_to: <8p8yG1KCpVB@erik_moeller>; from erik_moeller@gmx.de on Thu, Jul 03, 2003 at 11:55:00PM +0200

body:
Erik Moeller wrote:
> Jimmy-
> > I have a personal promise directly from Adam/Lir/Bridget or whatever
> > he or she prefers to be called that he will not edit the wikipedia
> > under any username.  So, as a courtesy, I do not believe that Pizza
> > Puzzle and Adam/Lir/Bridget are the same person.  I trust that,
> > whatever differences we may have, a direct violation of a personal
> > promise is not the sort of thing that he would do.
>
> You are a very funny person, Jimbo. :-)

:-)  I try.

--Jimbo


subject: [Wikitech-l] Server access

in_reply_to: <3F049C82.3090300@planetunreal.com>; from tarquin@planetunreal.com on Thu, Jul 03, 2003 at 10:13:38PM +0100

references: <8opxJEqCpVB@erik_moeller> <3F00B1EB.50201@gmx.net> <3F00A725.2040707@corell.dyndns.org> <3F045AB7.70103@gmx.net> <3F049C82.3090300@planetunreal.com>

body:
I'd like to approve Erik, Magnus, and Tarquin for server access, if
that is something they'd like to do, and if that's something that we
think would be useful.

There are probably others who I've overlooked, but if lack of people
with direct server access is a bottleneck, we should do something
about that.

In general, even developers don't really need direct server access.
As long as we have enough people to update the live site from CVS at
appropriate times, and enough people to give the machines a kick in
the pants when needed...

Direct server access is a matter of great trust, not just in terms of
character, either.  Lots and lots of people have excellent character
and I would trust them on those grounds with server access.  But there
is a 'technical' component to it, i.e. knowing how to get around in
Unix without breaking anything.

And I guess there's a personality component, since the server setup
isn't like a wiki where lots of people should be on there willy-nilly
reconfiguring things.  :-)

But it seems like this is sort of a bottleneck, and the solution is
pretty simple.

--Jimbo


body:
Hi,

03.07.2003 13:57:00, erik_moeller at gmx.de (Erik Moeller) wrote:

>> Re the HTML for the TOC: Why don't you use ol and li?
>
> Because we need to do manual numbering anyway, to keep the numbers
> consistent with those used by the auto-numbering for headers (which is
> a user preference).

Will this numbering ever be different from that of ol/li?

> Also, it was easier to get all the margins right and avoid unnecessary
> whitespace this way.

Not really. You are plugging a style="margin-bottom:0px;" on loads of
divs inside the table. It would suffice to give the table a class="toc"
and then specify in the stylesheet:
  .toc LI { margin: 0; }
and the left margins would be handled automatically by nested <ol>s.

The major reason I want to use <ol> is because if you have a really long
heading, it will render like this:

  1 This is a really
  long heading

I think it would do a *lot* to readability if it were rendered li-style:

  1. This is a really
     long heading

Of course you're going to tell me such long headings will never occur,
but take a look at http://test.wikipedia.org/wiki/Be for a near-
plausible example (switch to 800x600).

> Feel free to play around this with Skin.php

Unfortunately, the way this is constructed now (with Indent and Unindent
functions) already assumes unstructuredness (non-nestedness). I would
have to restructure that...

> the current solution works fine and probably takes less space.

"works fine" isn't always the best excuse hackishness ;-)

As for table vs. div: Ah, I see.

Please could you at least change it so that the number isn't part of the
link? Remember links should have meaningful and usable link text. I like
to follow links by typing the first few characters of their link text.
It is easier to type letters than numbers.

Greetings,
Timwi


from_name: Dreyer, Jason

subject:
[Wikitech-l] Problems with Table of Contents and possible sol
	ution

body:
David Friedland wrote:
>
> I propose that whether and and where a TOC appears should be specified
> by each article using a wiki tag indicating where the TOC should appear.
> This would allow articles with many short sections to not have a TOC,
> long articles with just a few sections have a TOC, and allow article
> authors/editors to specify the best location for the TOC without relying
> upon the wiki software to presume the very top of an article is the best
> place.

Some examples of an implementation like this can be found at IAwiki:
http://www.iawiki.net/IAwikiIA
http://www.iawiki.net/TextFormattingRules

-Jason Dreyer


from_name: Gareth Owen

body:
rvalles <rvalles at es.gnu.org> writes:

> - Unprivilegiation of the English wikipedia: The way it's setup now
>   (http://www.wikipedia.org = english. others are ?.wikipedia.org) is totally
>   discriminative , offensive and degrading for the other languages, that are
>   placed into a not-as-important position.

WWW stands for World Wide Web - three *english* words.
If other languages wish to replace there language codes with the equivalent
abbreviation in their own language, I'm sure no-one will mind.
(lwm.wikipedia.org for "le web mondial", peut-?tre?)

Until then, its fair for the *English* abbreviation to point to
*English* wiki, n'est-ce pas?
--
Gareth Owen
"It's not a human or civic right to edit wikipedia."
                                 -- kq cuts to the core of the banning debate


from_name: Thomas Luft

subject: [Wikitech-l] DE-Wikipedia slow

body:
Hi,

at the moment (17:00 CEST) the German Wikipedia is very slow, fr, too.
The English Wikipedia is running fine. Could someone have a look at this?
Thanks

Thomas aka Urbanus

--
Thomas Luft, Burgholzweg 97, D-72070 Tuebingen, GERMANY
Email: tluft at web.de   Phone: +49 7071 408908    Fax: 408909