subject: [Wikipedia-l] Enhanced Recent Changes

body:
> Erik Moeller wrote:
>
> >Thanks for implementing this, but I'm having problems with Mozilla 1.2.1;
> >clicking the down arrow doesn't open the individual changeset (nothing
> >happens). Earlier versions on test.wikipedia.org worked.
> >
> >
> Weird; I'm using 1.2.1, and it works. Did you enable JavaScript? (just
> asking;-)

Sure. It appears that it doesn't work when the "Floating left" mode of the
standard skin is used. With "fixed left" or no quickbar it works.

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


list: wikitech-l

source: pipermail-mbox

from_name: Erik Moeller

subject: [Wikitech-l] behaviour of HTML entities in <nowiki>

body:
On Mon, 2003-01-06 at 14:28, tarquin wrote:
> has this been changed recently?
> look at the sections on special characters on
> http://www.wikipedia.org/wiki/Wikipedia%3AHow_does_one_edit_a_page
>
> Things like
>
> π <nowiki>π</nowiki>
>
> now shows the same thing twice -- so it's now not possible to
> demonstrate how to produce these charcaters.

This is probably not intentional, but you can work around it by typing
&pi; etc.

Regards,

Erik

--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de


list: wikipedia-l

from_name: Magnus Manske

subject: [Wikipedia-l] Enhanced Recent Changes

body:
Erik Moeller wrote:

>It appears that it doesn't work when the "Floating left" mode of the
>standard skin is used. With "fixed left" or no quickbar it works.
>
>
Oh. I'll work on that. Thanks.

Magnus


list: wikien-l

from_name: Anthere

subject: [WikiEN-l] Am I wasting my time?

body:
--- rednblack at alum.mit.edu wrote:
> To draw an analogy, consider a drunk (appropriate
> because the drunk is
> malicious, but not intentionally so, like people who
> do damage to articles but
> don't realize they're doing it): the drunk is
> wandering around, crashing into
> things. You can a) pick up after him, b) try and
> sober him up, c) steer him out
> the door, d) kill him. I think it's unreasonable to
> say, "Let's let him wander
> around for a while, and if he continues to be a
> drunk, let's kill him."
>
> Saurabh

e) Have a drink with him...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Daniel Mayer

subject: [Wikitech-l] Has Wikipedia dropped off Google?

body:
Is it my imagination or has Wikipedia articles lost
almost all Google page rank ratings? Check out and
test pages listed on:
http://www.wikipedia.org/wiki/Top_10_Google_hits

Every one I tested was no longer in the top 10. For
example, searching for <"Cartesian product"> doesn't
seem to find our Wikipedia article (which was the #1
hit) and more shocking is that < "Cartesian product"
Wikipedia> doesn't bring up the current .org article
either! See

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&as_qdr=all&q=%22Cartesian+product%22+Wikipedia

It is as if everything in www.wikipedia.org/wiki/ is
being totally ignored by Googlebot for some reason.

-- Daniel Mayer (aka mav)

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Tom Parmenter

subject: [WikiEN-l] Am I wasting my time?

in_reply_to:
<3E19E2CE.5080506@planetunreal.com> (message from tarquin on Mon,
	06 Jan 2003 20:10:54 +0000)

body:
Fwappler is (pick one), a suitable case for treatment, a troll, or the
most ineffable individual in history.  See [[User_Talk:Fwappler]] for
data.

Tom Parmenter, in my 60s and still a crabby young grouch,
Ortolan88

|From: tarquin <tarquin at planetunreal.com>
|Date: Mon, 06 Jan 2003 20:10:54 +0000
|
|Despite my reputation as a crabby old grouch (and me still in my 20s ...
|), I do try and be nice to new users.
|But with Fwappler I've got to that hair-tearing point.
|Take a look at these pages:
|
|http://www.wikipedia.org/wiki/Talk%3APluralis_Majestatis
|http://www.wikipedia.org/wiki/User_talk%3AFwappler
|
|This person seems to completely misunderstand ANY attempt an explaining.
|Axel has already picked out two of their contributions as possibly
|crank-science.
|Am I wasting my time?
|
|I mean, what ON EARTH do they mean by this exchange:
|
|Me:
| > I removed "[[Phil Hartman|Bill McNeal]]" because it was a hidden link
|I dind't understand. The reader sees one name but is taken to another.
|
|Fwappler:
|
|    I understand now that if the reader "looks up" one name but is taken
|    to another, then the distinction for instance between "[[Phil
|    Hartman:acting as|Bill McNeal]]" and "[[time:portrayed
|    by|duration]]" appears almost irretrievably concealed. Surely We
|    wouldn't want /that/ -- thanks for the lesson.
|
|gah???
|


from_name: Zoe

body:
It's been suggested that Vera Cruz may be Lir.  Has anyone compared IP addresses?
Zoe
 Tom Parmenter <tompar at world.std.com> wrote:Gee, I think Vera Cruz is worse. 172 has climbed down a bit from his
high horse, but Vera is still going whole hog. Both of them have made
many substantive contributions to the Wikipedia, but Vera's war with
172 in [[New Imperialism]] is my idea of hell.

Ed Poor would know what to do. I don't, but banning doesn't really
seem to be the right weapon here. I have been entirely caught by the
tarbaby of [[New Imperialism]] when all I wanted to know was what made
it "new".

Tom Parmenter
Ortolan88

|From: "james duffy"
|Date: Mon, 06 Jan 2003 03:29:20 +0000
|
|Hi Zoe,
|
|I'm not normally in favour of banning people, but from what I see of 172's
|contibutions, they are strikingly POV, and constantly reverting pages
|without explaining why is completely unacceptable. I think the time has come
|to ban 172.
|
|JT
|
|
|
|>From: Zoe
|>Reply-To: wikien-l at wikipedia.org
|>To: wikien-l at wikipedia.org
|>Subject: [WikiEN-l] It's time for 172 to be banned
|>Date: Thu, 2 Jan 2003 15:23:35 -0800 (PST)
|>
|>
|>He/she is making wholesale reversions to any changes made by anyone in
|>[[New Imperialism]], without comment.
|>
|>Zoe
|>
|>
|>
|>
|>
|>---------------------------------
|>Do you Yahoo!?
|>Yahoo! Mail Plus - Powerful. Affordable. Sign up now
|
|
|
|
|_________________________________________________________________
|The new MSN 8 is here: Try it free* for 2 months
|http://join.msn.com/?page=dept/dialup
|
|_______________________________________________
|WikiEN-l mailing list
|WikiEN-l at wikipedia.org
|http://www.wikipedia.org/mailman/listinfo/wikien-l
|

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030106/1fcb710d/attachment.htm


subject: [WikiEN-l] Am I wasting my time?

body:
Fwappler's own home page is unintelligible.  I don't understand what he's trying to do with all the curly brackets, pipes and square brackets.
Zoe
 tarquin <tarquin at planetunreal.com> wrote:Despite my reputation as a crabby old grouch (and me still in my 20s ...
), I do try and be nice to new users.
But with Fwappler I've got to that hair-tearing point.
Take a look at these pages:

http://www.wikipedia.org/wiki/Talk%3APluralis_Majestatis
http://www.wikipedia.org/wiki/User_talk%3AFwappler

This person seems to completely misunderstand ANY attempt an explaining.
Axel has already picked out two of their contributions as possibly
crank-science.
Am I wasting my time?

I mean, what ON EARTH do they mean by this exchange:

Me:
> I removed "[[Phil Hartman|Bill McNeal]]" because it was a hidden link
I dind't understand. The reader sees one name but is taken to another.

Fwappler:

I understand now that if the reader "looks up" one name but is taken
to another, then the distinction for instance between "[[Phil
Hartman:acting as|Bill McNeal]]" and "[[time:portrayed
by|duration]]" appears almost irretrievably concealed. Surely We
wouldn't want /that/ -- thanks for the lesson.

gah???

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030106/f57543b4/attachment.htm


subject: [Wikitech-l] Smarter backlinks in edit mode

body:
As discussed, there are now additional links in the default skin when
editing pages. These vary somewhat depending on whether the page is new
or whether it exists. For various reasons I have added a bold "New page"
text to the quickbar when creating a new page, this text is "newpage" in
Language.php, a German translation is provided.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de


from_name: The Cunctator

subject: [WikiEN-l] Am I wasting my time?

body:
On 1/6/03 3:26 PM, "Erik Moeller" <erik_moeller at gmx.de> wrote:

>> Despite my reputation as a crabby old grouch (and me still in my 20s ...
>> ), I do try and be nice to new users.
>> But with Fwappler I've got to that hair-tearing point.
>> Take a look at these pages:
>
> He seems to be relatively harmless. Let's keep an eye on his contributions
> and ban him if necessary.
>
Gah. All this talk of banning is so depressing.


from_name: tarquin

body:
Erik Moeller wrote:

>As discussed, there are now additional links in the default skin when
>editing pages. These vary somewhat depending on whether the page is new
>or whether it exists. For various reasons I have added a bold "New page"
>text to the quickbar when creating a new page, this text is "newpage" in
>Language.php, a German translation is provided.
>
>Regards,
>
>Erik
>
I can't see them -- do you have a link to the article's talk page in yet?

>
>


from_name: Brion Vibber

subject: [WikiEN-l] It's time for 172 to be banned

body:
On lun, 2003-01-06 at 16:19, Zoe wrote:
> It's been suggested that Vera Cruz may be Lir.  Has anyone compared IP addresses?

Vera Cruz's current IP address is not that used by Lir back in the day,
but that's meaningless as he would likely be connecting from home
instead of university during the holidays. Much more revealing is the
e-mail address specified in the account, a hotmail account which a
google search reveals to belong to one Adam [name omitted for privacy reasons], aka Lir.

-- brion vibber (brion @ pobox.com)


from_name: rednblack at alum.mit.edu

subject: [WikiEN-l] Am I wasting my time?

in_reply_to:
Your message of "Mon, 06 Jan 2003 16:46:47 EST."
             <BA3F6377.5EEE%cunctator@kband.com>

body:
In message <BA3F6377.5EEE%cunctator at kband.com>, The Cunctator said:
>On 1/6/03 3:26 PM, "Erik Moeller" <erik_moeller at gmx.de> wrote:
>> He seems to be relatively harmless. Let's keep an eye on his contributions
>> and ban him if necessary.
>>
>Gah. All this talk of banning is so depressing.
>

I agree... seems like people are proposing banning at the drop of a hat, now. I
think we're getting lazy. So much easier to shoot the bastards than to talk to
them, isn't it? Isn't banning supposed to be the -extreme-, last resort, not
something you use after three sentences of unintelligible conversation?

To draw an analogy, consider a drunk (appropriate because the drunk is
malicious, but not intentionally so, like people who do damage to articles but
don't realize they're doing it): the drunk is wandering around, crashing into
things. You can a) pick up after him, b) try and sober him up, c) steer him out
the door, d) kill him. I think it's unreasonable to say, "Let's let him wander
around for a while, and if he continues to be a drunk, let's kill him."

Saurabh


subject: [Wikipedia-l] Enhanced Recent Changes

body:
Erik Moeller wrote:

>It appears that it doesn't work when the "Floating left" mode of the
>standard skin is used. With "fixed left" or no quickbar it works.
>
>
Found it. Turned out there was a dot (.) missing in the Standard Skin
code. Not as bad as the comma which caused the loss of some NASA probe,
though ;-)

Fixed on test site, should work on en as well. Otherwise after the next
update...

Magnus


body:
> I can't see them -- do you have a link to the article's talk page in yet?

You can't unless you use CVS. I don't have shell access so I can't update
any of the live sites. Yes, a talk page is included.

Regards,

Erik


subject: [WikiEN-l] Re: A facelift for the Main Page: Wikipedia Day and 100,000 articles soon

body:
On Saturday 04 January 2003 04:00 am, Alexander Stephen Bradbury wrote:
> I think the new main page is looking pretty good, I wouldn't mind changing
> the current one for it. I think going live with it on Wikipedia Day (if
> people agree, obviously) would be great. ... We definitely need a
> press release though. Some statistics (like in the PG newsletters) would
> be nice, what we've achieved, what we need to do. Has anyone drafted
> anything yet?
>
> ASB [[User:Smelialichu]]

Our first press release from a year ago is here:
http://meta.wikipedia.org/wiki/Wikipedia's_first_press_release--draft_for_comment

We can simply rewrite that to serve as this years version.

--Daniel Mayer (aka mav)

WikiKarma Payment. Have you had you Wiki today?
http://www.wikipedia.org/w/wiki.phtml?title=January_6&diff=563902&oldid=563596
I also updated various pages linked from that page


subject: [Wikipedia-l] Re: A facelift for the Main Page: Wikipedia Day and 100,000 articles soon


from_name: Eric Demolli

body:
172 seems to have disapeared.
He has a strange ego problem he refuse any form of critic.
Eric Demolli
Ericd

----- Original Message -----
From: "Tom Parmenter" <tompar at world.std.com>
To: <wikien-l at wikipedia.org>
Cc: <wikien-l at wikipedia.org>
Sent: Monday, January 06, 2003 6:05 AM
Subject: Re: [WikiEN-l] It's time for 172 to be banned

> Gee, I think Vera Cruz is worse.  172 has climbed down a bit from his
> high horse, but Vera is still going whole hog.  Both of them have made
> many substantive contributions to the Wikipedia, but Vera's war with
> 172 in [[New Imperialism]] is my idea of hell.
>
> Ed Poor would know what to do.  I don't, but banning doesn't really
> seem to be the right weapon here.  I have been entirely caught by the
> tarbaby of [[New Imperialism]] when all I wanted to know was what made
> it "new".
>
> Tom Parmenter
> Ortolan88
>
> |From: "james duffy" <jtdirl at hotmail.com>
> |Date: Mon, 06 Jan 2003 03:29:20 +0000
> |
> |Hi Zoe,
> |
> |I'm not normally in favour of banning people, but from what I see of
172's
> |contibutions, they are strikingly POV, and constantly reverting pages
> |without explaining why is completely unacceptable. I think the time has
come
> |to ban 172.
> |
> |JT
> |
> |
> |
> |>From: Zoe <zoecomnena at yahoo.com>
> |>Reply-To: wikien-l at wikipedia.org
> |>To: wikien-l at wikipedia.org
> |>Subject: [WikiEN-l] It's time for 172 to be banned
> |>Date: Thu, 2 Jan 2003 15:23:35 -0800 (PST)
> |>
> |>
> |>He/she is making wholesale reversions to any changes made by anyone in
> |>[[New Imperialism]], without comment.
> |>
> |>Zoe
> |>
> |>
> |>
> |>
> |>
> |>---------------------------------
> |>Do you Yahoo!?
> |>Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> |
> |
> |
> |
> |_________________________________________________________________
> |The new MSN 8 is here: Try it free* for 2 months
> |http://join.msn.com/?page=dept/dialup
> |
> |_______________________________________________
> |WikiEN-l mailing list
> |WikiEN-l at wikipedia.org
> |http://www.wikipedia.org/mailman/listinfo/wikien-l
> |
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Krzysztof P. Jasiutowicz

subject: [Wikitech-l] wikisearch broken

body:
Hello all,

I looked at the http://www.wikipedia.org/tools/wikisearch.php
and it seems to be broken as far as Polish Wikipedia search goes.

Can someone fix it, please ?

Regards,
Kpjas.


subject: [WikiEN-l] Am I wasting my time?

body:
Despite my reputation as a crabby old grouch (and me still in my 20s ...
), I do try and be nice to new users.
But with Fwappler I've got to that hair-tearing point.
Take a look at these pages:

http://www.wikipedia.org/wiki/Talk%3APluralis_Majestatis
http://www.wikipedia.org/wiki/User_talk%3AFwappler

This person seems to completely misunderstand ANY attempt an explaining.
Axel has already picked out two of their contributions as possibly
crank-science.
Am I wasting my time?

I mean, what ON EARTH do they mean by this exchange:

Me:
 > I removed "[[Phil Hartman|Bill McNeal]]" because it was a hidden link
I dind't understand. The reader sees one name but is taken to another.

Fwappler:

    I understand now that if the reader "looks up" one name but is taken
    to another, then the distinction for instance between "[[Phil
    Hartman:acting as|Bill McNeal]]" and "[[time:portrayed
    by|duration]]" appears almost irretrievably concealed. Surely We
    wouldn't want /that/ -- thanks for the lesson.

gah???


subject: [WikiEN-l] Am I wasting my time?

body:
> Despite my reputation as a crabby old grouch (and me still in my 20s ...
> ), I do try and be nice to new users.
> But with Fwappler I've got to that hair-tearing point.
> Take a look at these pages:

He seems to be relatively harmless. Let's keep an eye on his contributions
and ban him if necessary.

Regards,

Erik


from_name: Giskart

subject: [Wikitech-l] Re: New Features: Was: New feature: Backlink when editing a page

body:
Especily for things like that I have done a attempt to get support for
Announce-l

http://www.wikipedia.org/pipermail/announce-l/2002-November/thread.html

Because nobody was interested it has not become anything. So do not
complain now.

--
Contact: giskart AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


subject: [Wikipedia-l] Enhanced Recent Changes, another try

body:
I'm posting this to wikipedia-l rather than wikitech-l, so nobody can
accuse me of secret implement-and-install action again ;-)

I have installed another version of the "Enhanced Recent Changes" at
http://test.wikipedia.org
It features a better alignment of entries, and a "user summary", among
other things.  The look might be a little more "technical", though.

Please, have a look, tell me if you like it better than the current one
(or if not;-)

Magnus

P.S.: The speed can be improved, I'm still in debugging phase.


from_name: Tomasz Wegrzanowski

body:
On Mon, Jan 06, 2003 at 03:09:54PM -0800, Daniel Mayer wrote:
> Is it my imagination or has Wikipedia articles lost
> almost all Google page rank ratings? Check out and
> test pages listed on:
> http://www.wikipedia.org/wiki/Top_10_Google_hits
>
> Every one I tested was no longer in the top 10. For
> example, searching for <"Cartesian product"> doesn't
> seem to find our Wikipedia article (which was the #1
> hit) and more shocking is that < "Cartesian product"
> Wikipedia> doesn't bring up the current .org article
> either! See
>
> http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&as_qdr=all&q=%22Cartesian+product%22+Wikipedia
>
> It is as if everything in www.wikipedia.org/wiki/ is
> being totally ignored by Googlebot for some reason.

As far as I understand how google works,
www.wikipedia.com had high page rank and lot of links to it.
Now almost all of these links go to www.wikipedia.org, so:
* www.wikipedia.org has links but low page rank
* www.wikipedia.com has high page rank but few links

So neither will get good scores at google.

It will improve when google will refresh their cache.


subject: [Wikitech-l] SVG image support w/ auto rasterization

body:
...would be awfully nice. Comments and suggestions to
http://meta.wikipedia.org/wiki/SVG_image_support , if you please.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] "Go" button

body:
On mar, 2003-01-07 at 02:53, Erik Moeller wrote:
> The "Go" button that is now visible on en.wikipedia.org is my nefarious
> creation. It allows you to visit a page directly by typing its name, e.g. "Main
> Page"->Go will put you directly on Main Page.

Consider this surprise beta testing; it appears to have been installed
by accident on the English wiki only. I will be happy to remove it if
anyone complains, as I consider it unnecessary and cluttery. :)

> The currently active version is not the latest one.

(grudgingly updated)

> What's the use? Well, if you have certain pages you visit frequently, or
> jump back and forth a lot, this makes navigation easier. Anyone who has in the
> past run a search just to visit a particular page should appreciate this
> change.

Are there no URL input bars? Are there no poorhouses?

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Cookie expiration time much too short

body:
Please make it significantly longer.
There have been lot of complaints on Polish Wikipedia.


subject: [Wikipedia-l] en is broken

body:
--- Magnus Manske <magnus.manske at epost.de> wrote:
> Someone installed a "diff" version of Skin.php on
> en. Please revert that.
>
> Magnus

Maybe this belongs to the english list ?

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikitech-l] Wikipedia in Google

body:
On mar, 2003-01-07 at 05:25, Erik Moeller wrote:
> As of last weekend, all Wikipedia articles seem to have disappeared from
> the Google index. Wikipedia article URLs look like this:
>
> 	http://www.wikipedia.org/wiki/<article-name>
>
> We are not aware of an outage that might have caused the Google spider
> to miss the pages. I would much appreciate it if you could shed some
> light on the issue.

Upon noticing that the main pages and mailing list archives _are_
indexed, I have my suspicions about our robots.txt file; the line:

  Disallow: /w

perhaps should be:

  Disallow: /w/

The former may be accidentally blocking /wiki/<arcticle-name> paths
-- which of course form the bulk of our content! -- in addition to the
scripted pages via direct access to the /w subdirectory that it's
intended to block.

I have updated the robots.txt file; if indeed this is how the googlebot
was interpreting the line, I hope we can be respidered soon...

-- brion vibber (brion at pobox.com / brion at wikipedia.org)


subject: [WikiEN-l] Am I wasting my time?

body:
On 1/7/03 3:58 AM, "Erik Moeller" <erik_moeller at gmx.de> wrote:
> Terrible analogy. Nobody has advocated banning Frank if he continues doing
> what he's doing now. Besides, comparing banning to killing is preposterous.
>
> Of course Cunctator gets a Pavlovian reaction as soon as someone merely
> mentions the word "banning" ..
>
I don't salivate. Maybe you should try being less dismissive.


body:
> I'm posting this to wikipedia-l rather than wikitech-l, so nobody can
> accuse me of secret implement-and-install action again ;-)
>
> I have installed another version of the "Enhanced Recent Changes" at
> http://test.wikipedia.org
> It features a better alignment of entries, and a "user summary", among
> other things.  The look might be a little more "technical", though.
>

Great! A lot better than the previous version. The user summary is exactly
what was missing.

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


subject: [WikiEN-l] Am I wasting my time?

body:
> I agree... seems like people are proposing banning at the drop of a hat,
> now. I
> think we're getting lazy. So much easier to shoot the bastards than to
> talk to
> them, isn't it?

Several people have tried to talk to Frank, but he is just blathering
incomprehensibly.

> Isn't banning supposed to be the -extreme-, last resort,
> not
> something you use after three sentences of unintelligible conversation?

If only there were sentences ..

> To draw an analogy, consider a drunk (appropriate because the drunk is
> malicious, but not intentionally so, like people who do damage to articles
> but
> don't realize they're doing it): the drunk is wandering around, crashing
> into
> things. You can a) pick up after him, b) try and sober him up, c) steer
> him out
> the door, d) kill him. I think it's unreasonable to say, "Let's let him
> wander
> around for a while, and if he continues to be a drunk, let's kill him."

Terrible analogy. Nobody has advocated banning Frank if he continues doing
what he's doing now. Besides, comparing banning to killing is preposterous.

Of course Cunctator gets a Pavlovian reaction as soon as someone merely
mentions the word "banning" ..

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


subject: [Wikipedia-l] "Go" button

body:
The "Go" button that is now visible on en.wikipedia.org is my nefarious
creation. It allows you to visit a page directly by typing its name, e.g. "Main
Page"->Go will put you directly on Main Page.

The currently active version is not the latest one. I have recently changed
the behavior of the button to try some capitalization variants, so "main
page" and "MAIN PAGE" work just as well, and to run a normal search if no direct
hit can be found. That improved version should be activated shortly.

What's the use? Well, if you have certain pages you visit frequently, or
jump back and forth a lot, this makes navigation easier. Anyone who has in the
past run a search just to visit a particular page should appreciate this
change.

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


subject: [Wikipedia-l] en is broken

body:
Someone installed a "diff" version of Skin.php on en. Please revert that.

Magnus


subject: [Wikipedia-l] en is broken

body:
I installed the old one for now; just make sure the CVS is clean.

Magnus


subject: [Wikitech-l] Image handling redesign proposal

body:
On mar, 2003-01-07 at 10:37, Magnus Manske wrote:
> Erik Moeller wrote:
> >2) Smaller versions of images should be auto-generated in a separate
> >directory similar to the math/ directory used for texvc's images. The
> >small versions would be viewed on the article where the [[Image]] tag is
> >included, whereas the image would link to the original size version.
> >
> Two items with this one:
> 1. A thumbnail should be generated upon upload, so we don't have to wade
> through thaton every page display,

Note that this dovetails nicely with automatic rasterization of SVG
images at both screen and printer-friendly resolutions. Comments,
please: http://meta.wikipedia.org/wiki/SVG_image_support

> >3) The image page content should be included by default below the image
...
> That will break almost every layout!
> Try a 100-pixel-image, aligned in a table or a div, and put "<br>This is
> a very long description that will break every damned layout on
> wikipedia!" behind the image...

Better yet, try http://www.wikipedia.org/wiki/Shavian_alphabet ...

> >- It is somewhat counter-intuitive to have the caption rendered
> >implicitly on a page that includes an [[Image:foo.jpg]] tag. The
> >alternative would be to do away with image pages as regular
> >content-pages altogether. (Realistically, having a separate image
> >namespace may have been a bad idea in the first place.)

I'm not clear on what this means. The suggestion appears to be to make
captions more intuitive by eliminating the ability to edit image
captions? I don't think I'm reading you right. :)

> We'll have to think about what image to use on "printable
> version" - the thumbnail to keep layout, or the large one for resolution?

The large one, obviously. We can give pixel-width and height of the
thumbnail so the browser lays it out at the same logical size.

> >I'd be willing to give the
> >autogeneration a try, if no one else volunteers.
> >
> For an alternative mechanism of handling images, see
> http://nupedia.com/article/long/Polymerase+Chain+Reaction/  (RIP), which
> I hacked some centuries ago ;-)

I generally find tiny tiny tiny tiny thumbnails of diagrams to be simply
_annoying_. They're like end-notes that contain vital information,
forcing you to go off on a wild goose chase to see what should have been
presented to you immediately.

Rather, I'd prefer that the small inline versions still be large enough
to be useful and informative.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Talk pages redesign proposal

body:
On mar, 2003-01-07 at 09:13, Tomasz Wegrzanowski wrote:
> Current talk pages are extremely unfriendly.
> I think they should be abandoned and replaced by
> more "natural" system of posting.

You mean, not a wiki?

I think not.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Re: [Wikitech-l] Talk pages redesign proposal

body:
This is an issue for wikipedia-l, not wikitech-l.
There's no need to give sysops the ability to delete posts. Either everyone
should be able to delete posts, or noone.

On 1/7/03 12:13 PM, "Tomasz Wegrzanowski" <taw at users.sourceforge.net> wrote:

> Current talk pages are extremely unfriendly.
> I think they should be abandoned and replaced by
> more "natural" system of posting.
>
> Article would contain: "Comment this article" and "View comments"
> links, with second present only if there are any.
> Occasional readers would be more willing to comment articles that way,
> with interface they are more familiar with.
>
> Every comment would contain posting user name (or "Anonymous"), date,
> and "Reply" post.
>
> Unlike K5, we don't want to keep posts forever, so
> some magic would be necessary to take care of old posts.
> Automatic expiration wouldn't be any good - some issues are
> resolved very quickly, others may stay for months.
>
> I think that posts should have 3 states: current, old and deleted.
> Everyone should be able to move posts between current and old status,
> and sysops should be able to delete and undelete posts.
> Old posts should not be displayed in defalt "View comments",
> (some "Show also old comments" link should be provided), and
> deleted posts should be visible only to sysops.
>
> Markup should be interpretted normally in posts, but
> some extra care should be taken that no formatting bomb
> will be placed in them.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Kurt Jansson

body:
> As far as I understand how google works,
> www.wikipedia.com had high page rank and lot of links to it.
> Now almost all of these links go to www.wikipedia.org, so:
> * www.wikipedia.org has links but low page rank
> * www.wikipedia.com has high page rank but few links
>
> So neither will get good scores at google.
>
> It will improve when google will refresh their cache.

No, please look at
http://www.google.com/search?&q=+site:www.wikipedia.org+wikipedia
as mentioned on
http://www.wikipedia.org/wiki/Wikipedia_talk%3ATop_10_Google_hits

It seems to be another problem.

BTW, while playing with google's news search I found
http://www.theregister.co.uk/content/6/28723.html
But I don't really understand what "In time, each publication could
become a mini-Wikipedia entry." means. I guess the licences are not
compatible.

Kurt


subject: [Wikitech-l] Re: Image handling redesign proposal

body:
Magnus wrote:
>Erik Moeller wrote:
>>I propose the following changes:
>>--------------------------------
>>
>>1) As suggested earlier, an image page should always

>>display the image it refers to.
>>
>Makes sense.

See my earlier post on this. IMO the only time an
image should be single-click through is when an image
is intentionally displayed on the image description
page. Otherwise a user should have to click twice to
get to the image description page (alt text should
work in both cases though).

>>2) Smaller versions of images should be
auto->>generated in a separate directory similar to
the >>math/ directory used for texvc's images. The
small >>versions would be viewed on the article where
the
>>[[Image]] tag is included, whereas the image would
>>link to the original size version.
>
>Two items with this one:
>1. A thumbnail should be generated upon upload, so we
>don't have to wade through thaton every page display,
>2. *if* and *only if* that is necessary. The images
>DW uploaded lately to replace mine don't really need
>a thumbnail ;-)

IMO this isn't the best way to do things. As described
below smaller images should be created on-the-fly by
using markup to specify desired width (and deleted
after a specified period of not being used). Then if
the [[Image:foo.jpg width=100px]] syntax is used
/then/ the thumbnail can be clicked once to get to the
image description page (which contains the full-sized
displayed image). If there is no image displayed on
the image description page then the user would have to
click twice to get there (with no changing of the
mouse pointer to the little hand). This would give
users the greatest amount of control and flexibility.
Doing things automatically upon upload would be a
nightmare (esp. for images that are inserted in
tables; often a very precise image width is needed).

>>However, auto-determining thumbnail sizes is
>>problematic because a useful size often depends on
>>context. A proper way to handle this may be to
>>support the following variants of the
>>[[Image]] tag:
>>
>>		 [[Image:foo.jpg width=100 height=100]]
>>
>>		 [[Image:foo.jpg width=100]]
>>		 [[Image:foo.jpg height=100]]
>>		 -> height or width autocalculated as >>per aspect
ratio
>>
>>		 [[Image:foo.jpg size=10%]]
>
>Why not say: *If* we need a thumbnail, it has a width
>of, say, 150 pixel (just to have a number).
>Width is the "problematic" factor, on smaller
>screens. So, for every image wider than this, a
>thumbnail is used, otherwise the original
>image.

Again, doing this automatically will cause a great
deal of trouble. There are many cases where images
larger than even 250 pixels are used and appropriate
especially if the images are centered or otherwise do
not have text flowing around them. (the optimal range
of widths for images /with/ text flowing around them
is 150-250 pixels with image detail and type usually
playing the deciding factor for the resulting width).

>>....
>...

>>- It is somewhat counter-intuitive to have the
>>caption rendered implicitly on a page that includes
>>an [[Image:foo.jpg]] tag. The alternative would be
>>to do away with image pages as regular content-pages
>>altogether.
>>(Realistically, having a separate image
>>namespace may have been a bad idea in the first
>>place.)
>>
>How about the alt tag thingy I installed at the test
>site?

IMO alt tags are needed for images with and without
larger versions displayed on the image description
page. But please to not get rid of the image
description pages. Very often wiki markup is used
along with external links. These links are not usable
in the form of mouse over text. However, for whatever
reason, if at least one image is /not/ displayed on an
image description page then the image displayed in the
article should have to be clicked twice in order to
get to the image description page (with no display of
the little hand when the mouse pointer is over the
image; just the display of the alt text).

>>However, having lots of redundant (and often
>>neglected) content is clearly the least preferable
>>choice.
>>
>>There would, in my opinion, be massive advantages to

>>having auto-generated small versions of images. This

>>would greatly increase the usability on many pages,
>>and make the traditional "click to view larger
>>version" approach be usable almost anywhere.
>
>I agree. We'll have to think about what image to use
>on "printable version" - the thumbnail to keep
>layout, or the large one for resolution?

Don't forget WYSIWYG. The person should be given the
same article layout they see in regular article as
with the print version. Using the larger version in
the print version would destroy the layout of tables
that have images in them (not to mention that the
larger versions of images with text flowing around
them would result in pages with two word lines next to
huge images). IMO on the image description pages we
should have "Printable version: [Small image] [Large
image]"

-- Daniel Mayer (aka mav)

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Axel Boldt

subject: [Wikipedia-l] Britannica

body:
--- Robert Graham Merkel <rgmerk at mira.net> wrote:

> In any case, when discussing the 1911 EB when it first became
> available
> on the net, it quickly became clear that the material from it is
> totally unsuited for cut-and-paste into Wikipedia anyway.  Obviously
> much of it is totally out-of-date (read the article on "Calculating
> machines" for amusing speculation on the possibility of a completed
> Analytical Engine), the style is archaic, and even the stuff on
> historical figures has been invalidated by later research.
>
> Use it for source material (with a good deal of care), but I would
> strongly argue *not* to cut-and-paste it in.

I very much agree with this. I have seen several dozen-paragraph
articles that were imported from EB and then nobody dared to touch them
anymore (except for wikification). The text is well-written in an
authorative style, and people shy away from modifying it, and don't
feel the need to check the facts. Even though much of it is outdated or
even wrong. I believe the natural evolution of a Wikipedia article is
actually held up by a large scale EB cut-and-past job.

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikipedia-l] "Go" button

body:
Brion Vibber wrote:

>>What's the use? Well, if you have certain pages you visit frequently, or
>>jump back and forth a lot, this makes navigation easier. Anyone who has in the
>>past run a search just to visit a particular page should appreciate this
>>change.
>>
>>
>
>Are there no URL input bars? Are there no poorhouses?
>
>
>
Mmmmmmmmm bookmarks :-)
Seriously -- for titles of more than one word, it's quicker doing a
search on a significant word. Or keeping bookmarks either in a browser
or on one's user page (like mav does)

>
>


subject: [Wikitech-l] Wikipedia in Google

body:
Dear Sirs,

Wikipedia is a large, collaborative project to produce a free
encyclopedia. There are currently nearly 100,000 articles, and about
200,000 page impressions per day.

As of last weekend, all Wikipedia articles seem to have disappeared from
the Google index. Wikipedia article URLs look like this:

	http://www.wikipedia.org/wiki/<article-name>

We are not aware of an outage that might have caused the Google spider
to miss the pages. I would much appreciate it if you could shed some
light on the issue.

Sincerely,

Erik Moeller
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de


subject: [Wikitech-l] Postgres

body:
On mar, 2003-01-07 at 14:40, Tomasz Wegrzanowski wrote:
> I played a bit with database.
>
> Here is something that looks like Wikipedia database schema but
> compiles in Posgres (and no, Wikipedia script won't be able to use
> that yet):

:)))) Yay!!!!!!  I *like* it when suggestions come with actual attempts
at preliminary code.

> Of course, this isn't "real" code, and many changes will be necessary
> to make it any useful. Anyway:
> * user and old are reserved keywords in Postgres

Grrr! Well, 'user' can become 'users' easily enough. ;)

I'm also considering whether 'cur' and 'old' should be split up
differently, into 'pageinfo' (title, restrictions, counter, redirect)
and 'revisions' (text, comment, date, user, minor). This would perhaps
be less radical than Jonathan's suggestion of a raw title<->numeric id
table, but should simplify operations that work on both current and old
revisions. (May need a shortcut for grabbing the current revision,
perhaps a key from the pageinfo.)

> * why are we using tinyblob(1) instead of bool for boolean data ?

Good question.

> * why are we creating so many indexes ? are all of them necessary ?

On cur and old, we need indexes on title (to look up individual pages),
timestamp (for sorting), and user (for contribs). Fulltext indexes for
searching on the special index fields. Namespace presumably helps along
with title?

On link tables, we're keying to indexed fields, and have a *lot* of rows
which we may search from either end (whatlinkshere, orphan checks,
wantedpages, etc etc).

Indexes on ipblocks table are probably useless, as it's very small.

User table has index on user name; helps with sorting the big user list.
(What about lookup of options on every page view by logged in user? Is
this number or name?)

Size, name, and timestamp fields in the image table may be used for
sorting the huge and growing list o' files.

> * shouldn't we use database-provided timestamps instead of varchar(14) ?

As long as we know how to manipulate them programmatically and format
them for the selected language and time zone...

> * rights and restrictions don't seem to be represented very efficiently.
>     using integer flag for that seems like a better idea to me

Maybe. It's not really a bottleneck, though, and legibility isn't
something to be hated.

> * it might be good idea to consider making our own searching system
>     instead of relying on something provided by database

Hell, why rely on a database? Why not write our own storage system? And
filesystem... and virtual memory... and process manager... :)

We shouldn't have to be a wheel factory; if a good, fast, flexible
search mechanism is available in our database we should use it.

-- brion vibber (brion @ pobox.com)


from_name: Mark Christensen

body:
> > Current talk pages are extremely unfriendly.
> > I think they should be abandoned and replaced by
> > more "natural" system of posting.
>
> You mean, not a wiki?
> I think not.

I agree talk pages must remain wiki style for three reasons.

First, adding another system for talk pages makes users learn another
system and that makes things inherently more complex.

Second, talk pages are intended to help people make articles, and
therefore the requirement to learn wiki syntax to post on talk pages
just keeps out those who wouldn't take time to learn to contribute to
actual articles.

Ever since Ward's Wiki is that there is some minimum requirement to
participate -- namely the ability to figure out wiki syntax.  This is
not hard, but it does require a little effort.  And many have argued
that this is one of the reasons that wiki's can maintain a higher level
of discourse than newsgroups and web based discussion groups.

Third, an important part of the "wiki way" is refactoring, I have
refactored a number of large talk pages removing the dross, keeping
sustentative contributions, and putting it all together to flow more
naturally.  This is only possible because of the flexibility of the wiki
system.


subject:
[Wikitech-l] Re: Alternative proposal for interlanguage links
	redesign and a few other issues

body:
On mar, 2003-01-07 at 15:06, Tomasz Wegrzanowski wrote:
> On Tue, Jan 07, 2003 at 11:40:10PM +0100, Paul Ebermann wrote:
> > So for each new language a new table. Why?
> > Doesn't a language field in one article table would be enough?
>
> It should be faster that way, because locking issues on English tables
> won't cause any problems for us.
>
> And too many English articles won't cause selects to be any slower
> for other languages that way.

I think a better approach is to make the system work more smoothly so
that neither the other languages _nor_ the English section have to
suffer from the English section's large number of articles.

Separate tables in the same database won't be any better than separate
databases on the same server, which presently causes problems because
the English tables will get locked up and additional requests get backed
up until the server hits its open connection limit -- then other
languages can't connect either, and you just have to wait it out.

If we can iron out the locks, I believe a combined table system will be
both more flexible and easier to program against.

-- brion vibber (brion @ pobox.com)


from_name: Erik Moeller

body:
I think the current image handling is slightly messed up, for the
following reasons:

1) There are too many different ways to link small/large versions.

   a) There are usability problems with Brion's suggested approach of
      including the larger version of an image on the image page:

	- The headline may say something like image_small.jpg whereas
	  the actual image displayed is large
	- Clicking through a second time leads to another (usually
 	  empty) page
	- Captions effectively have to be entered up to three times

2) Users have to go to too much effort in order to create small versions
of images. This is not something that researchers and authors should
have to waste time with. It also impedes uploading of high resolution
images, which can really hurt us when we start thinking about a printed
edition of Wikipedia.

3) Content of image pages is neglected because it is "hidden" most of
the time. Many people treat image descriptions like changelog entries
(relatively carelessly).

The fact that it even took me a while to understand the current handling
of images doesn't bode well for the usability of the concept.

I propose the following changes:
--------------------------------

1) As suggested earlier, an image page should always display the image
it refers to.

2) Smaller versions of images should be auto-generated in a separate
directory similar to the math/ directory used for texvc's images. The
small versions would be viewed on the article where the [[Image]] tag is
included, whereas the image would link to the original size version.

We could use the GD library functions for creating thumbnails. See, for
example:
http://www.onlinetools.org/articles/creating_thumbnails_all.php

However, auto-determining thumbnail sizes is problematic because a
useful size often depends on context. A proper way to handle this may be
to support the following variants of the [[Image]] tag:

	[[Image:foo.jpg width=100 height=100]]

	[[Image:foo.jpg width=100]]
	[[Image:foo.jpg height=100]]
	-> height or width autocalculated as per aspect ratio

	[[Image:foo.jpg size=10%]]

The smaller versions would be generated as necessary and stored in a
temporary directory. The matching original image information (date,
size) would be stored in a table so that they can be updated on demand.

3) The image page content should be included by default below the image
(preceded by a
). That way when you type

	[[Image:foo.jpg]]

You get

	This is an ugly photo!

To suppress this and type a manual caption, you would have to do
something like:

	[[Image:foo.jpg notext]]

That way, you can have
- the standard case: image with a simple caption; no need to update
twice
- the extended case: image with a short caption on the page where it is
embedded and a longer discussion on its image page.

Discussion
----------
The approach discussed above has almost no obvious disadvantages. The
following problems may ensue, though:

- Existing image pages will have to be re-edited to remove now redundant
image content. Existing thumbnail images can be deleted.

- It is somewhat counter-intuitive to have the caption rendered
implicitly on a page that includes an [[Image:foo.jpg]] tag. The
alternative would be to do away with image pages as regular
content-pages altogether. (Realistically, having a separate image
namespace may have been a bad idea in the first place.)

However, having lots of redundant (and often neglected) content is
clearly the least preferable choice.

There would, in my opinion, be massive advantages to having
auto-generated small versions of images. This would greatly increase the
usability on many pages, and make the traditional "click to view larger
version" approach be usable almost anywhere.

Is the GD library installed on Wikipedia's server?

I would appreciate feedback on this proposal. I'd be willing to give the
autogeneration a try, if no one else volunteers.

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de


body:
On mar, 2003-01-07 at 16:08, Tomasz Wegrzanowski wrote:
> Separate tables in single database is completely equivalent to separate
> tables in separate databases (databases aren't real, tables are real).
> I simply don't see any point in changing that.

That was my point -- your suggestion (separate tables, one db) will be
no faster than the present situation (separate tables, separate dbs),
and little faster than Paul's suggestion (combined tables, one db), as
logjams on the English wiki will continue to affect both the many
anglophone users and the users on other languages in all three cases.

> Having only 'interwiki' and 'users' common is enough, we can merge the rest
> later if it won't result in any performance problems.

True enough.

-- brion vibber (brion @ pobox.com)


from_name: Bryan Derksen

subject: [Wikipedia-l] Re: Getting rid of protected pages

body:
At 10:37 PM 07/01/03 +0000, Giskart wrote:
>Very good idea. Something like this can also be usefull to reduce vandalism
>by anonymous users. But that is mayby for when there is more vandalism. At
>least, vandalism is not yet a problem on my wikipedia.

It would also save me from the embarrassment of realizing, minutes after
clicking "save page", that there's a typo or other silly mistake that I
need to go back and fix. In those minutes there could be dozens of people
reading the page and imagining what a twit I must be to make those silly
mistakes! :)

Seriously, though, I think this is a good idea too. A lag of an hour or two
before an edit becomes "official" is nothing in the grand scheme of things,
and it may make Wikipedia look a little less unreliable to some of the
doubters.


subject: [Wikitech-l] Interlanguage links redesign proposal

body:
I think the current handling of interlanguage links is problematic and
not very scalable. If we have n copies of an article, we need need n*n-1
interlanguage links. For 10 languages, that would be 90 links! All of
these links have to be added to separate pages, by people speaking
different languages, who often don't even have an account on the
Wikipedia in question.

As should be obvious, we are already missing interlanguage links for
many, if not most, of the translations we have.

The scalable solution requires us to have a meta-table for interlanguage
links that can be accessed by all Wikipedias. This table could look like
this:

	language1	article1	language1	article2
	------------------------------------------------------------
	en		Main Page	de 		Hauptseite
	fr		Accueil		en		Main Page
	fr		Accueil		es		Portada
	...

Let's call it shared.ilinks for the moment.

Instead of adding interlanguage links on top of articles, we would have
a separate text line below article bodies:

	Interlanguage links (syntax: [[<code>:<article name>]])

The syntax would remain the same so that the link line can be cut and
pasted from the body. But this line would not be stored in that form in
the database.

Display of interlanguage links
------------------------------
Say I visit [[Main Page]] on en.wikipedia.org. Now, in order to show the
list of links, the shared.ilinks table is queried:

SELECT * from shared.ilinks where (language1=en and article1="Main
Page") or (language2=en and article2="Main Page")

That is, a single SELECT allows us to find all translations of the word
"Main Page". But don't we only save relatively little time, as we still
have to tell *every* Wikipedia that homepage means "Main Page" in
English? No, because we can now leave this to the code.

When a user edits a page, the same list of links is generated, but this
time in the wiki syntax ([[fr:Accueil]] [[de:Hauptseite]] and so on).
This can be edited by anyone. When the list has been edited, and the
page is saved, the following is done:

1)
The same SELECT as above is run:
SELECT * from shared.ilinks where (language1=en and article1="Main
Page") or (language2=en and article2="Main Page")

2)
Now, for each translation we get, another similar SELECT is run, so that
we find further translations into other languages.

3)
Every new translation we discover is stored in a new English (in our
example)/<new translation> table row, so that we can do the quick,
one-time SELECT to display the interlanguage links.

The result: If we have a page in 10 translations, the minimum effort we
have to go to is to add exactly one translation on every language
Wikipedia. That is, a minimum of 9 as opposed to 90 links! The other
translations are automatically discovered.

Example:
Someone creates a new page about Phil Collins on fr.wikipedia.org. This
person knows that there's already an English page about him on
en.wikipedia.org, so they type [[en:]] (suggested short syntax for "same
name as here"). "fr:Phil Collins->en:Phil Collins" is inserted into the
shared.ilinks table. This already means that the link is also shown on
en.wikipedia.org. But it gets better: Now someone on de.wikipedia.org
creates a Phil Collins page as well. He links to en.wikipedia.org's
[[en:]] entry. Zap!, after saving the entry, the French translation is
automatically discovered. Now the French translation has a link to the
German page and vice versa as well.

Editing links
-------------
What happens if the folks on fr.wikipedia.org move one of their pages?
The "Move this page" command now needs to automatically change every
instance of the page to something else (e.g. Accueil->Homepage) in the
shared.ilinks table.

What happens if someone on en.wikipedia.org decides that they do not
want to link to a page on nl.wikipedia.org because it contains obsolete
information, or because of "link-vandalism"? To unilaterally remove a
link to one translation, there would have to be a special interlanguage
link, like [[nl::]]. When saved, the link would be cleared and not
"rediscovered" until someone removed the [[nl::]] link. Such empty links
would not be copied.

If [[nl:Hoofdpagina]] is deleted, all instances of it in the
shared.ilinks table are removed as well.

What about links where there is no 1:1 relationship? Say I have a page
about "evolution" and "theory of evolution" on one wiki (English) and
only a page about "evolution" on another (French). So I add the
following to en.wikipedia.org on both pages:

	[[fr:Th?orie de l'?volution]]

In the shared.ilinks table, I therefore get entries:

	Evolution		Th?orie de l'?volution
	Theory of Evolution	Th?orie de l'?volution

When I visit the "Evolution" page, I get a clear match: Th?orie de
l'?volution. But when I visit the "Th?orie de l'?volution", I get two
matches. In this case, we could actually show both links on the French
page:

	English: [1],[2]

Or in edit mode:

	[[en:Evolution]][[en:Theory of Evolution]]

It may not be desirable to autocopy these duplicate links. So, if we
cannot discover an exact match, we may want to wait until someone
specifies a precise translation.

Discussion
----------
The process described above is complex from a technical perspective,
because it has to be respected during all changes to articles (move,
delete, edit etc.) It also requires us to run a separate database server
specifically for this shared information. There may be scenarios that I
have not yet covered in the above proposal, although I am sure solutions
can be found for every problem.

There are numerous advantages to this approach. Compared with the
current handling, we should quickly get an accurate representation of
interlanguage links on all wikis. We do not have to pick a single
language as "key" language, which would require a key entry in that
language to exist for all pages. [1]

There may be simpler solutions that I cannot see - if so, I would love
to hear about them. But I really think we should consider redesigning
the interlanguage links before the problem grows out of control.

Regards,

Erik

[1] Although that would expose us to charges of anglocentrism, I am open
to discussing this alternative.
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de


body:
Current talk pages are extremely unfriendly.
I think they should be abandoned and replaced by
more "natural" system of posting.

Article would contain: "Comment this article" and "View comments"
links, with second present only if there are any.
Occasional readers would be more willing to comment articles that way,
with interface they are more familiar with.

Every comment would contain posting user name (or "Anonymous"), date,
and "Reply" post.

Unlike K5, we don't want to keep posts forever, so
some magic would be necessary to take care of old posts.
Automatic expiration wouldn't be any good - some issues are
resolved very quickly, others may stay for months.

I think that posts should have 3 states: current, old and deleted.
Everyone should be able to move posts between current and old status,
and sysops should be able to delete and undelete posts.
Old posts should not be displayed in defalt "View comments",
(some "Show also old comments" link should be provided), and
deleted posts should be visible only to sysops.

Markup should be interpretted normally in posts, but
some extra care should be taken that no formatting bomb
will be placed in them.


from_name: Andre Engels

in_reply_to:
<1041957601.1283.133.camel@chesoo.fokus.gmd.de> from Erik Moeller
 at "Jan 7, 2003 05:40:01 pm"

body:
> I think the current handling of interlanguage links is problematic and
> not very scalable. If we have n copies of an article, we need need n*n-1
> interlanguage links. For 10 languages, that would be 90 links! All of
> these links have to be added to separate pages, by people speaking
> different languages, who often don't even have an account on the
> Wikipedia in question.

It's not as bad as you make it appear here, those go to 10, not 90 different
pages. Still, the person who added the tenth language would, if (s)he did it
the 'proper' way, have to add a total of 19 links on a total of 10 different
pages. Not a desirable situation.

> As should be obvious, we are already missing interlanguage links for
> many, if not most, of the translations we have.

There's certainly already a wealth of missing back- and through-links
available, as well as a number of interlanguage links to non-existing pages.

> The scalable solution requires us to have a meta-table for interlanguage
> links that can be accessed by all Wikipedias. This table could look like
> this:
>
>
> 	language1	article1	language1	article2
>	------------------------------------------------------------
>	en		Main Page	de 		Hauptseite
>	fr		Accueil		en		Main Page
>	fr		Accueil		es		Portada
>	...

My preference would be to have a different type of metatable, namely one
where each subject gets an indication (an English name, another name, or
just a number), and the articles are then stored by these (the 'key language
approach' as you call it). Your above case would then look:

	1	en	Main Page
	1	de	Hauptseite
	1	fr	Accueil
	1	es	Portada

or even:
	1	[[en:Main Page]][[de:Hauptseite]][[fr:Accueil]][[es:Portada]]

The reason I prefer this is for what you mention below:

> What about links where there is no 1:1 relationship? Say I have a page
> about "evolution" and "theory of evolution" on one wiki (English) and
> only a page about "evolution" on another (French). So I add the
> following to en.wikipedia.org on both pages:
>
>	[[fr:Th?orie de l'?volution]]
>
> In the shared.ilinks table, I therefore get entries:
>
>	Evolution		Th?orie de l'?volution
>	Theory of Evolution	Th?orie de l'?volution
>
> When I visit the "Evolution" page, I get a clear match: Th?orie de
> l'?volution. But when I visit the "Th?orie de l'?volution", I get two
> matches. In this case, we could actually show both links on the French
> page:
>
>	English: [1],[2]
>
> Or in edit mode:
>
>	[[en:Evolution]][[en:Theory of Evolution]]
>
> It may not be desirable to autocopy these duplicate links. So, if we
> cannot discover an exact match, we may want to wait until someone
> specifies a precise translation.

In the alternative method, it will be possible to have one page connected
to multiple 'interlanguage rings'. For example, some Wikipedias have a page
'astronomy and astrophysics', while others have a page 'astronomy' and a
page 'astrophysics'. In my proposed way of working, the 'astronomy and
astrophysics' pages could be linked to both rings, so that they are linked
(in both directions) to 'astronomy' and 'astrophysics' pages without
'astronomy' pages being linked to 'astrophysics' pages.

> There may be scenarios that I have not yet covered in the above proposal,
> although I am sure solutions can be found for every problem.

The main problem I have found, is the one you try to solve with the [[nl::
links - when a page is linked in a way it should not, removing all
inappropriate links will nevertheless get the links back because the
appropriately linked pages will also be linked.

> There are numerous advantages to this approach. Compared with the
> current handling, we should quickly get an accurate representation of
> interlanguage links on all wikis. We do not have to pick a single
> language as "key" language, which would require a key entry in that
> language to exist for all pages. [1]

My preference would be to have a 'neutral' key language, for example simply
a numbering of all link groups that exist. Disadvantage of that method is
that inappropriate links can still come into existence (something one could
hope to avoid by using a real key language, which however increases the risk
of several 'rings' coming into existence around the same subject). They would
however be easier to repair than in your proposal.

My proposal would look something like this:

A table of terms with their pages in various languages, as described above.
There are no interlanguage links in the box below the page, instead there is
a table number or list of table numbers. However, there is an option for
users to specify that a page should be connected to a specific page in another
language. If that is done, the following can be the case:

1. Both pages are not language-connected yet. In that case a new ring would
   be formed with the two pages in it.
2. Both pages are already in a ring. Then the user gets a new screen, where
   the two rings are given, with the pages in the two rings. The user has
   the following options:
   * Melt the rings together into one ring
   * Add the first page to the second ring
   * Add the second page to the first ring

In the latter two cases, this will cause the added page to become part of
two rings.

3. One page is in more than one ring. Then the user again gets to see all
   the rings with the pages in them; he can select one ring, causing the
   other page to be added to that ring, or two rings, causing those two
   rings to be melted together.

When a page already has interlanguage links, a user has a third option to
change its international links (apart from adding as specified above and
changing the ring memberships by hand), namely specifying that a link should
not exist. He then gets to see all pages (in the various languages) that
are part of the ring, and creates two rings, ring A and ring B, from them.
For each page in the ring, he specifies whether it should belong to ring A,
ring B or both.

The advantage of my system (compared to yours) is that it makes the handling
of multiple-subject pages and the correction of unwanted links easier. The
disadvantages are that it is probably even harder to implement and that it
is less wiki-like, using form-like entities rather than markup language.

Andre Engels


subject: [Wikitech-l] Alternative proposal for interlanguage links redesign and a few other issues

body:
1. move everything to Postgres
2. move everything to common database, with tables foo_cur, foo_old etc.,
    where foo are language names
3. make single user table (needs some tweaking to allow slightly different
    preferences), single logging system, single recent changes, and all other
    nice things we can do with that
4. move everything to UTF-8, so we don't have to use %escapes in English Wikipedia
5. create table interwiki (source_lang, target_lang, source_title, target_title)
6. convert all cur_text by removing interwiki links from page tops,
    and add apropriate entries to interwiki.
7. compute transitive symmetric closure of foo_interwiki, and display that
    as interwiki links. If there will be many articles of the same language
    in it display it like: "English (Astronomy), English (Astrophysics), German"
    In practive it shouldn't be such a big problem.
8. when editing add interwiki links on top of page or in separate box.
    add Javascript button to add all from links from transitive symmetric closure
    of interwiki
9. add some magic functionality that allows changing many interwiki links at time.
    It is needed as transitive symmetric closure often contains many
    copies of the same. "delete all interwiki links to this page" and
    "change all interwiki links from X to Y" would probably be enough.

Computing symmetric transitive closure will require a bit of magic.
I think we should keep results in database and change only - editing
may be a bit slower, as long as viewing is not any worse than now.


from_name: Magnus Manske

body:
Erik Moeller wrote:

>I propose the following changes:
>--------------------------------
>
>1) As suggested earlier, an image page should always display the image
>it refers to.
>
Makes sense.

>2) Smaller versions of images should be auto-generated in a separate
>directory similar to the math/ directory used for texvc's images. The
>small versions would be viewed on the article where the [[Image]] tag is
>included, whereas the image would link to the original size version.
>
Two items with this one:
1. A thumbnail should be generated upon upload, so we don't have to wade
through thaton every page display,
2. *if* and *only if* that is necessary. The images DW uploaded lately
to replace mine don't really need a thumbnail ;-)

>However, auto-determining thumbnail sizes is problematic because a
>useful size often depends on context. A proper way to handle this may be
>to support the following variants of the [[Image]] tag:
>
>	[[Image:foo.jpg width=100 height=100]]
>
>	[[Image:foo.jpg width=100]]
>	[[Image:foo.jpg height=100]]
>	-> height or width autocalculated as per aspect ratio
>
>	[[Image:foo.jpg size=10%]]
>
Why not say: *If* we need a thumbnail, it has a width of, say, 150 pixel
(just to have a number).
Width is the "problematic" factor, on smaller screens. So, for every
image wider than this, a thumbnail is used, otherwise the original image.

>3) The image page content should be included by default below the image
>(preceded by a
). That way when you type
>
>	[[Image:foo.jpg]]
>
>You get
>
>

>	This is an ugly photo!
>
>To suppress this and type a manual caption, you would have to do
>something like:
>
>	[[Image:foo.jpg notext]]
>
That will break almost every layout!
Try a 100-pixel-image, aligned in a table or a div, and put "
This is
a very long description that will break every damned layout on
wikipedia!" behind the image...

>Discussion
>----------
>The approach discussed above has almost no obvious disadvantages.
>
Well...

> The following problems may ensue, though:
>
>- Existing image pages will have to be re-edited to remove now redundant
>image content. Existing thumbnail images can be deleted.
>
Image: pages with tumbnail/full image are rare. No problem there.
Tumbnails can be found with the "orphaned images" function, provided we
actually start using it ;-)

>- It is somewhat counter-intuitive to have the caption rendered
>implicitly on a page that includes an [[Image:foo.jpg]] tag. The
>alternative would be to do away with image pages as regular
>content-pages altogether. (Realistically, having a separate image
>namespace may have been a bad idea in the first place.)
>
How about the alt tag thingy I installed at the test site?

>However, having lots of redundant (and often neglected) content is
>clearly the least preferable choice.
>
>There would, in my opinion, be massive advantages to having
>auto-generated small versions of images. This would greatly increase the
>usability on many pages, and make the traditional "click to view larger
>version" approach be usable almost anywhere.
>
I agree. We'll have to think about what image to use on "printable
version" - the thumbnail to keep layout, or the large one for resolution?

>I'd be willing to give the
>autogeneration a try, if no one else volunteers.
>
For an alternative mechanism of handling images, see
http://nupedia.com/article/long/Polymerase+Chain+Reaction/  (RIP), which
I hacked some centuries ago ;-)

Magnus


body:
I proposed enhanced interlanguage link manipulation/storage several
times before (check the archive;-), and gave that some thought.

I propose a new, independent *database*, instead of just a table. We'll
have to access another database from all but one wikis, anyway (we can't
store a complete consistent copy of that table in all databases, now can
we?).

That database could also hold other information, mainly a central user
database, so multi-language users won't have to create new user accounts
in every language.

Later, it could also be a place for the translations that are currently
in the LanguageXX.php files.

Magnus


body:
On Tue, Jan 07, 2003 at 07:44:55PM +0100, Magnus Manske wrote:
> Later, it could also be a place for the translations that are currently
> in the LanguageXX.php files.

Please, don't put things that are static into database.
It is slow enough now.


body:
Tomasz Wegrzanowski wrote:

>On Tue, Jan 07, 2003 at 07:44:55PM +0100, Magnus Manske wrote:
>
>
>>Later, it could also be a place for the translations that are currently
>>in the LanguageXX.php files.
>>
>>
>
>Please, don't put things that are static into database.
>It is slow enough now.
>
>
I thought of an online interface for translators to add/change items,
then an "update" button that creates a new LanguageXX.php file for the
edited language.

Magnus


subject: [Wikitech-l] Special pages cache?

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> > Some of the special pages, like Most Wanted, have been deactivated
> > during busy times. Would it be a good idea to store the results of
> > the last generated version as a "regular" article?
> > Example: I request "Special:Most Wanted" when it is available. The
> > link list I get is written into "Wikipedia:Most Wanted".
>
> Good idea. Should the cached copy perhaps be in the Special:
> namespace,
> too, and uneditable? Otherwise people might be surprised when their
> edits are overwritten.
>
> Having Talk: for the special pages might also be useful.

Yes, call it [[Special:Most Wanted (cached)]] and put a note at the top
about when it was cached. During busy hours, the message at
[[Special:Most Wanted]] would have a link to the cached version.

By the way, performance has become much better recently. Probably the
busy hour block?

Axel

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: daniwo59 at aol.com

subject: [WikiEN-l] Micronations

body:
We now have an extensive and linked list of imaginary countries, including my
personal favorite, "Purple Bunny" (I kid you not). Another link is to the
Confederate Online States. Will we have an article for each state in the
"confederacy" too? I think this is getting a tad excessive. Anyone else think
so too?

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030107/0224bef9/attachment.htm


body:
On Tue, Jan 07, 2003 at 12:23:11PM -0800, Brion Vibber wrote:
> On mar, 2003-01-07 at 09:13, Tomasz Wegrzanowski wrote:
> > Current talk pages are extremely unfriendly.
> > I think they should be abandoned and replaced by
> > more "natural" system of posting.
>
> You mean, not a wiki?

Exactly.

> I think not.

Wiki is not any good for discussion.
There have been many complaints from people who know Wiki well
that talking that way is bizarre, and that it's hard to find out
to whom and to what which reply refers.

It must be a lot harder for people who don't know Wiki.


from_name: Zoe

subject: [WikiEN-l] Micronations

body:
I strongly agree with this.  By allowing nonsense like this to exist in the Wikipedia, it taints the entire project.
Zoe
 daniwo59 at aol.com wrote:In a message dated 1/7/2003 10:01:05 PM Eastern Standard Time, cunctator at kband.com writes:

On Tue, 2003-01-07 at 21:20, daniwo59 at aol.com wrote:
>We now have an extensive and linked list of imaginary countries, including my
>personal favorite, "Purple Bunny" (I kid you not). Another link is to the
>Confederate Online States. Will we have an article for each state in the
>"confederacy" too? I think this is getting a tad excessive. Anyone else think
>so too?
>
My question is, so what? Wikipedia is not paper. If you think it's
excessive, then don't contribute to it.

The real problem is that most of the entries are being written in CIA
World Factbook style, not Wikipedia style.

I would like to think that we are trying to put together a serious encyclopedia. It has nothing to do with whether we are paper or not.

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030107/01ee839c/attachment.htm


subject: [WikiEN-l] Micronations

body:
Micronations are not a subculture.  They are figments of rather fevered imaginations.  And none of your examples is anywhere in the same category.
Zoe
 The Cunctator <cunctator at kband.com> wrote:On Tue, 2003-01-07 at 22:06, daniwo59 at aol.com wrote:

> I would like to think that we are trying to put together a serious
> encyclopedia. It has nothing to do with whether we are paper or not.

We are. We have entries on [[Dyavaprthivi]], [[Georges Clemenceau]],
[[Post Falls, Idaho]], [[Shanghai solitaire]], [[SPAM]], [[existentialism]],
etc. Which entries are "serious", and which are not?

The micronations fit right in. Micronationalism is a legitimate and
interesting subculture that most likely presages large-scale
sociopolitical dynamics in the coming decades. (As are [[MMORPG]]s, by
the way. We're sadly lacking a [[The Sims Online]] entry. Terrible!)

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030107/cfc5f931/attachment.htm


from_name: The Cunctator

subject: [WikiEN-l] Micronations

body:
On Tue, 2003-01-07 at 21:20, daniwo59 at aol.com wrote:
> We now have an extensive and linked list of imaginary countries, including my
> personal favorite, "Purple Bunny" (I kid you not). Another link is to the
> Confederate Online States. Will we have an article for each state in the
> "confederacy" too? I think this is getting a tad excessive. Anyone else think
> so too?
>
My question is, so what? Wikipedia is not paper. If you think it's
excessive, then don't contribute to it.

The real problem is that most of the entries are being written in CIA
World Factbook style, not Wikipedia style.


subject: [WikiEN-l] Micronations

body:
In a message dated 1/7/2003 10:01:05 PM Eastern Standard Time,
cunctator at kband.com writes:

> On Tue, 2003-01-07 at 21:20, daniwo59 at aol.com wrote:
> >We now have an extensive and linked list of imaginary countries, including
> my
> >personal favorite, "Purple Bunny" (I kid you not). Another link is to the
> >Confederate Online States. Will we have an article for each state in the
> >"confederacy" too? I think this is getting a tad excessive. Anyone else
> think
> >so too?
> >
> My question is, so what? Wikipedia is not paper. If you think it's
> excessive, then don't contribute to it.
>
> The real problem is that most of the entries are being written in CIA
> World Factbook style, not Wikipedia style.
>

I would like to think that we are trying to put together a serious
encyclopedia. It has nothing to do with whether we are paper or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030107/ad51ed72/attachment.htm


from_name: Aldie

subject: [WikiEN-l] Admin rights

body:
Hi all,

I would like to able to move pages properly, edit the Main Page when
necessary and help clean up the 'experiments' left by various people. I
therefore request admin rights.

Cheers,
Aldie


body:
On Tue, Jan 07, 2003 at 03:41:53PM -0500, Mark Christensen wrote:
> > > Current talk pages are extremely unfriendly.
> > > I think they should be abandoned and replaced by
> > > more "natural" system of posting.
> >
> > You mean, not a wiki?
> > I think not.
>
> I agree talk pages must remain wiki style for three reasons.

And I do not. There is nothing sacred about wiki.
We're already doing many things in "not a wiki way".

> First, adding another system for talk pages makes users learn another
> system and that makes things inherently more complex.

Not at all.
Almost every Net user knows posts-based discusion systems:
things will get simpler, much simpler, not more difficult.

And such system will be more powerful too.

> Second, talk pages are intended to help people make articles, and
> therefore the requirement to learn wiki syntax to post on talk pages
> just keeps out those who wouldn't take time to learn to contribute to
> actual articles.

I disagree very strongly with that.
First, it's system not syntax that's a problem.
Posts will still use current syntax.

There should be a way for readers to comment about articles without
having to learn how Wiki system works. I know many Wiki readers
who told me on external communications channels that "this is wrong"
or "that is not clear", but asked why don't they say that on Wikipedia,
they answered that they don't understand this system.

> Ever since Ward's Wiki is that there is some minimum requirement to
> participate -- namely the ability to figure out wiki syntax.  This is
> not hard, but it does require a little effort.  And many have argued
> that this is one of the reasons that wiki's can maintain a higher level
> of discourse than newsgroups and web based discussion groups.

It's not syntax that's difficult. It's concept that's difficult.
"Talking by editing" is something not used anywhere else than
Wikipedia. And it's much inferior to "talking by posting".

> Third, an important part of the "wiki way" is refactoring, I have
> refactored a number of large talk pages removing the dross, keeping
> sustentative contributions, and putting it all together to flow more
> naturally.  This is only possible because of the flexibility of the wiki
> system.

Current/old/deleted magic will do that.
Flow fixes are only necessary because of using system that isn't
meant for discussion at all.

----

If you find that too heretic to accept, there is less radical option:
add an "Add a comment" link to every article page, where user can write a post
that will be appended to contents of Talk page (Talk page will be created
if it doesn't exist yet).

Also, if user is not logged in, "Username" field should also be provided in
"Add a comment" page. Being identified is more important in discussion than
in article writing. If that field is left empty, message should say
'From: Anonymous'.


body:
erik_moeller=Mmb7MZpHnFY at public.gmane.org (Erik Moeller) wrote in
news:8dOHqdUCpVB at erik_moeller:

[cut]
> Using this system we could get rid of traditional page protection for
> all  pages, including [[Main Page]] and the sensitive policy pages. As

Not all Wikipedias protect there main page.

[cut]
> What do you think? With the possible exception of the timer part, I
> believe this would be relatively simple to implement.

Very good idea. Something like this can also be usefull to reduce vandalism
by anonymous users. But that is mayby for when there is more vandalism. At
least, vandalism is not yet a problem on my wikipedia.

--
Contact: giskart AT wikipedia.be
Ook een artikeltje schrijven? WikipediaNL, de vrije GNU/FDL encyclopedie
http://www.wikipedia.be


subject: [WikiEN-l] Micronations

body:
On Tue, 2003-01-07 at 22:06, daniwo59 at aol.com wrote:

> I would like to think that we are trying to put together a serious
> encyclopedia. It has nothing to do with whether we are paper or not.

We are. We have entries on [[Dyavaprthivi]], [[Georges Clemenceau]],
[[Post Falls, Idaho]], [[Shanghai solitaire]], [[SPAM]], [[existentialism]],
etc. Which entries are "serious", and which are not?

The micronations fit right in. Micronationalism is a legitimate and
interesting subculture that most likely presages large-scale
sociopolitical dynamics in the coming decades. (As are [[MMORPG]]s, by
the way. We're sadly lacking a [[The Sims Online]] entry. Terrible!)


subject: [Wikitech-l] Special pages cache?

body:
Some of the special pages, like Most Wanted, have been deactivated
during busy times. Would it be a good idea to store the results of the
last generated version as a "regular" article?
Example: I request "Special:Most Wanted" when it is available. The link
list I get is written into "Wikipedia:Most Wanted".


subject: [Wikipedia-l] Getting rid of protected pages

body:
Because Cunctator would forward it to wikipedia-l anyway, I'm posting this
here directly instead of to wikitech-l (help! he's conditioning me!).
There is a discussion on [[Wikipedia talk:Neutral point of view]] about
whether this particular page should be protected or not. Actually nobody
seems to argue strongly that it should be protected, but right now it
still is.

Brion has brought up an idea from the good folks at MeatballWiki:
http://www.usemod.com/cgi-bin/mb.pl?FileReplacement

The gist of it, as I think it *should* be implemented, is this:

1) Protected pages have a link called "Editable copy" or something
similar. This is simply a copy of the page, perhaps with some flag in the
database or a modifier in the page title like "(COPY)".

2) This page can be edited freely. After every edit, a timer is reset. The
timer counts down to, say, 2 hours (we may want to define this on a per-
site or per-page basis). Once the time has elapsed, the original version
of the page is replaced with the COPY.

Because the timer is reset any time someone edits the page, regular users
can prevent the page from being substituted with vandalism if no sysop is
near. Similarly, edit wars are given time to "cool" before the page in
question changes.

3) Sysops have the additional privileges of being able to directly replace
the original page with the COPY (so as to say, "this version is good,
gimme this NOW"), and of course, of being able to edit the original page
directly.

Using this system we could get rid of traditional page protection for all
pages, including [[Main Page]] and the sensitive policy pages. As an added
feature, we could wipe the history of the COPY whenever it is copied; this
would save some disk space when we use this mechanism to prevent edit wars
(every "revert" is a full copy of the page in the DB).

The Main Page of all language wikis would benefit greatly from this, as it
could now be updated by everyone without the risk of the goat-man suddenly
appearing on our frontpage.

What do you think? With the possible exception of the timer part, I
believe this would be relatively simple to implement.

Regards,

Erik


body:
> Current talk pages are extremely unfriendly.
> I think they should be abandoned and replaced by
> more "natural" system of posting.

Tomasz,

please read my post

http://www.wikipedia.org/pipermail/wikitech-l/2002-December/001758.html

for some problems with this approach, and for the alternative, which still
allows us to use the wiki-advantages (of which there are plenty!) while
having "reply" links and reducing edit conflicts. The relevant portion of
the above post on what I think we should do:

- Auto-merge after edit conflicts. Do a paragraph-wise comparison, merge
when paras are the same or new, trigger conflict when paras are
different. Show warning when another user has recently started editing a
page.
- Make better use of existing comment demarcation. When a user inserts a
sig --~~~ this could be used to also render a "reply to this comment"
link. This link could lead to a blank edit form, the content of which
would be automatically inserted in indented form after the comment in
question.
- Have better context-sensitive help. Our current editing screen is nice
and all, but it could use some refinements to direct users to pertinent
information.

[New: As for the last point, if we use the comment demarcation approach
described above, we need to make sure that everyone understands the ~~~
syntax, and possibly change it. Right now this is a bit of a "secret" that
every newbie discovers at some point.]

Regards,

Erik


subject: [Wikitech-l] Special pages cache?

body:
> Some of the special pages, like Most Wanted, have been deactivated
> during busy times. Would it be a good idea to store the results of the
> last generated version as a "regular" article?
> Example: I request "Special:Most Wanted" when it is available. The link
> list I get is written into "Wikipedia:Most Wanted".

Good idea. Should the cached copy perhaps be in the Special: namespace,
too, and uneditable? Otherwise people might be surprised when their edits
are overwritten.

Having Talk: for the special pages might also be useful.

Regards,

Erik


from_name: tarquin

body:
Brion Vibber wrote:

>On mar, 2003-01-07 at 09:13, Tomasz Wegrzanowski wrote:
>
>
>>Current talk pages are extremely unfriendly.
>>I think they should be abandoned and replaced by
>>more "natural" system of posting.
>>
>>
>
>You mean, not a wiki?
>
>I think not.
>
>
>
Agreed. For the reasons Mark Christensen gave.

>
>


body:
Two further requests for images:

1.
The ability to rename images *and* update all the references to them.
Far too many people upload "Washington.jpg" or something cryptic like
"HghHfnr1.jpeg"

2.
don't use the file extension as part of the identifier.
In other words -- allow an upload of "foo.PNG" to replace "foo.JPG"
this would mean using
[[image:foo]] only for links.

We've done it like this on UnrealWiki, it's handy for when people use
the wrong format (eg JPEG for a line diagram)

Lastly -- is the idea to have a common image space across all languages
still on the cards?


subject: [Wikitech-l] Postgres

body:
I played a bit with database.

Here is something that looks like Wikipedia database schema but
compiles in Posgres (and no, Wikipedia script won't be able to use
that yet):

CREATE TABLE user_table (
  user_id serial NOT NULL PRIMARY KEY,
  user_name varchar(255) NOT NULL default '',
  user_rights varchar(255) NOT NULL default '',
  user_password varchar(255) NOT NULL default '',
  user_newpassword varchar(255) NOT NULL default '',
  user_email varchar(255) NOT NULL default '',
  user_options varchar(65535) NOT NULL default '',
  user_newtalk smallint NOT NULL default '1'
);

CREATE TABLE cur (
  cur_id serial NOT NULL PRIMARY KEY,
  cur_namespace smallint NOT NULL default '0',
  cur_title varchar(255) NOT NULL default '',
  cur_text text NOT NULL default '',
  cur_comment varchar(255) NOT NULL default '',
  cur_user int NOT NULL default '0',
  cur_user_text varchar(255) NOT NULL default '',
  cur_timestamp char(14) NOT NULL default '',
  cur_restrictions varchar(255) NOT NULL default '',
  cur_counter bigint NOT NULL default '0',
  cur_ind_title varchar(255) NOT NULL default '',
  cur_ind_text text NOT NULL default '',
  cur_is_redirect boolean NOT NULL default 'f',
  cur_minor_edit boolean NOT NULL default 'f',
  cur_is_new  boolean NOT NULL default 'f'
);

CREATE TABLE old_table (
  old_id serial NOT NULL PRIMARY KEY,
  old_namespace smallint NOT NULL default '0',
  old_title varchar(255) NOT NULL default '',
  old_text text NOT NULL default '',
  old_comment varchar(255) NOT NULL default '',
  old_user int NOT NULL default '0',
  old_user_text varchar(255) NOT NULL,
  old_timestamp char(14) NOT NULL default '',
  old_minor_edit boolean NOT NULL default 'f',
  old_flags varchar(255) NOT NULL default ''
);

CREATE TABLE archive (
  ar_namespace smallint NOT NULL default '0',
  ar_title varchar(255) NOT NULL default '',
  ar_text text NOT NULL default '',
  ar_comment varchar(255) NOT NULL default '',
  ar_user int NOT NULL default '0',
  ar_user_text varchar(255) NOT NULL,
  ar_timestamp char(14) NOT NULL default '',
  ar_minor_edit boolean NOT NULL default 'f',
  ar_flags varchar(255) NOT NULL default ''
);

CREATE TABLE links (
  l_from varchar(255) NOT NULL default '',
  l_to int NOT NULL default '0'
);

CREATE TABLE brokenlinks (
  bl_from int NOT NULL default '0',
  bl_to varchar(255) NOT NULL default ''
);

CREATE TABLE imagelinks (
  il_from varchar(255) NOT NULL default '',
  il_to varchar(255) NOT NULL default ''
);

CREATE TABLE site_stats (
  ss_row_id int NOT NULL PRIMARY KEY,
  ss_total_views bigint default '0',
  ss_total_edits bigint default '0',
  ss_good_articles bigint default '0'
);

CREATE TABLE ipblocks (
  ipb_address varchar(40) NOT NULL default '',
  ipb_user int NOT NULL default '0',
  ipb_by int NOT NULL default '0',
  ipb_reason varchar(255) NOT NULL default '',
  ipb_timestamp char(14) NOT NULL default ''
);

CREATE TABLE image (
  img_name varchar(255) NOT NULL default '',
  img_size int NOT NULL default '0',
  img_description varchar(255) NOT NULL default '',
  img_user int NOT NULL default '0',
  img_user_text varchar(255) NOT NULL default '',
  img_timestamp char(14) NOT NULL default ''
);

CREATE TABLE oldimage (
  oi_name varchar(255) NOT NULL default '',
  oi_archive_name varchar(255) NOT NULL default '',
  oi_size int NOT NULL default 0,
  oi_description varchar(255) NOT NULL default '',
  oi_user int NOT NULL default '0',
  oi_user_text varchar(255) NOT NULL default '',
  oi_timestamp char(14) NOT NULL default ''
);

CREATE TABLE random (
  ra_current smallint NOT NULL default 0,
  ra_title varchar(255) NOT NULL default ''
);

CREATE TABLE recentchanges (
  rc_timestamp varchar(14) NOT NULL default '',
  rc_cur_time varchar(14) NOT NULL default '',
  rc_user int NOT NULL default '0',
  rc_user_text varchar(255) NOT NULL default '',
  rc_namespace smallint NOT NULL default '0',
  rc_title varchar(255) NOT NULL default '',
  rc_comment varchar(255) NOT NULL default '',
  rc_minor boolean NOT NULL default 'f',
  rc_bot boolean NOT NULL default 'f',
  rc_new boolean NOT NULL default 'f',
  rc_cur_id int NOT NULL default '0',
  rc_this_oldid int NOT NULL default '0',
  rc_last_oldid int NOT NULL default '0'
);

CREATE TABLE watchlist (
  wl_user int NOT NULL,
  wl_namespace smallint NOT NULL default '0',
  wl_title varchar(255) NOT NULL default ''
);

CREATE TABLE math (
  math_inputhash char(16) NOT NULL PRIMARY KEY,
  math_outputhash char(16) NOT NULL,
  math_conservative bool NOT NULL,
  math_html text NOT NULL
);

Of course, this isn't "real" code, and many changes will be necessary
to make it any useful. Anyway:
* user and old are reserved keywords in Postgres
* why are we using tinyblob(1) instead of bool for boolean data ?
* why are we creating so many indexes ? are all of them necessary ?
* shouldn't we use database-provided timestamps instead of varchar(14) ?
* rights and restrictions don't seem to be represented very efficiently.
    using integer flag for that seems like a better idea to me
* it might be good idea to consider making our own searching system
    instead of relying on something provided by database


from_name: Paul Ebermann

subject: [Wikitech-l] Re: Alternative proposal for interlanguage links redesign and a few other issues

body:
"Tomasz Wegrzanowski" skribis:

> 1. move everything to Postgres
> 2. move everything to common database, with tables foo_cur, foo_old etc.,
>     where foo are language names

[eo]
Do por cxiu lingvo alia tabelo.
Kial?
Cxu ne atributo por la lingvo en komuna
tabelo suficxus?

[en]
So for each new language a new table.
Why?
Doesn't a language field in one
article table would be enough?

Pauxlo


body:
On Tue, Jan 07, 2003 at 11:40:10PM +0100, Paul Ebermann wrote:
> [eo]
> Do por cxiu lingvo alia tabelo.
> Kial?
> Cxu ne atributo por la lingvo en komuna
> tabelo suficxus?
>
> [en]
> So for each new language a new table.
> Why?
> Doesn't a language field in one
> article table would be enough?

It should be faster that way, because locking issues on English tables
won't cause any problems for us.

And too many English articles won't cause selects to be any slower
for other languages that way.


subject: [Wikitech-l] Postgres

body:
On Tue, Jan 07, 2003 at 03:38:09PM -0800, Brion Vibber wrote:
> On mar, 2003-01-07 at 14:40, Tomasz Wegrzanowski wrote:
> > * it might be good idea to consider making our own searching system
> >     instead of relying on something provided by database
>
> Hell, why rely on a database? Why not write our own storage system? And
> filesystem... and virtual memory... and process manager... :)
>
> We shouldn't have to be a wheel factory; if a good, fast, flexible
> search mechanism is available in our database we should use it.

Searching doesn't seem like something "general",
it's almost always specific to given usage.

Examples of magic that would be nice to have (nothing urgent):
1. On Polish Wikipedia, if someone tries a query and no hits are
   generated, and it didn't contain any diactrics,
   try to search undiactricized version of whole database.
   Some people for some reason write ASCII Polish while on Internet.
2. Dictionary searches would also need more magic. See:
   http://wiktionary.org/wiki/Wiktionary:Alternative_vision_of_multilingual_dictionary


from_name: Tom Parmenter

subject: [WikiEN-l] Micronations

body:
|From: The Cunctator <cunctator at kband.com>
|Sender: wikien-l-admin at wikipedia.org
|Reply-To: wikien-l at wikipedia.org
|Date: 07 Jan 2003 21:59:54 -0500
|
|On Tue, 2003-01-07 at 21:20, daniwo59 at aol.com wrote:
|> We now have an extensive and linked list of imaginary countries, including my
|> personal favorite, "Purple Bunny" (I kid you not). Another link is to the
|> Confederate Online States. Will we have an article for each state in the
|> "confederacy" too? I think this is getting a tad excessive. Anyone else think
|> so too?
|>
|My question is, so what? Wikipedia is not paper. If you think it's
|excessive, then don't contribute to it.
|
|The real problem is that most of the entries are being written in CIA
|World Factbook style, not Wikipedia style.
|
|_______________________________________________

Redondan nationalists loyal to King Leo removed all signs of King
Bob's rival Redondan regime, charging ahistoricism and POV.

But hey, they're only web pages, so I put King Bob back on the page.

Tom Parmenter
Ortolan88


body:
On Tue, Jan 07, 2003 at 03:58:35PM -0800, Brion Vibber wrote:
> On mar, 2003-01-07 at 15:06, Tomasz Wegrzanowski wrote:
> > On Tue, Jan 07, 2003 at 11:40:10PM +0100, Paul Ebermann wrote:
> > > So for each new language a new table. Why?
> > > Doesn't a language field in one article table would be enough?
> >
> > It should be faster that way, because locking issues on English tables
> > won't cause any problems for us.
> >
> > And too many English articles won't cause selects to be any slower
> > for other languages that way.
>
> I think a better approach is to make the system work more smoothly so
> that neither the other languages _nor_ the English section have to
> suffer from the English section's large number of articles.
>
> Separate tables in the same database won't be any better than separate
> databases on the same server, which presently causes problems because
> the English tables will get locked up and additional requests get backed
> up until the server hits its open connection limit -- then other
> languages can't connect either, and you just have to wait it out.

Separate tables in single database is completely equivalent to separate
tables in separate databases (databases aren't real, tables are real).
I simply don't see any point in changing that.

Some "fair" system would be nice, with "other" languages having higher
priorities than English ...

> If we can iron out the locks, I believe a combined table system will be
> both more flexible and easier to program against.

That would be nice, but we should rather try to make minimal number of
changes necessary for given goal.

Having only 'interwiki' and 'users' common is enough, we can merge the rest
later if it won't result in any performance problems.


body:
On Tue, Jan 07, 2003 at 04:36:32PM -0800, Brion Vibber wrote:
> On mar, 2003-01-07 at 16:08, Tomasz Wegrzanowski wrote:
> > Separate tables in single database is completely equivalent to separate
> > tables in separate databases (databases aren't real, tables are real).
> > I simply don't see any point in changing that.
>
> That was my point -- your suggestion (separate tables, one db) will be
> no faster than the present situation (separate tables, separate dbs),
> and little faster than Paul's suggestion (combined tables, one db), as
> logjams on the English wiki will continue to affect both the many
> anglophone users and the users on other languages in all three cases.

It wasn't about performance but about common interwiki and users.

Having script open 2 databases would required two connections, wouldn't it ?
Now that would be slower.


from_name: Brion Vibber

subject: [Wikitech-l] Postgres

body:
On mar, 2003-01-07 at 19:28, Pieter Suurmond wrote:
[a bunch of stuff beyond my ken]
[...]
> Does anyone know if there are C or C++, CGI or standalone-server versions
> of WikiSource?

There are quite a few different implementations of the wiki concept in
various languages and with various backends, including some standalone
servers. See the big list at: http://c2.com/cgi/wiki?WikiEngines

-- brion vibber (brion @ pobox.com)