subject:
[Wikipedia-l] "Move this page bug" -- do NOT use this feature
 until it's fixed!

body:
I wrote:
> The move page function seems to have a new and exciting bug which can
> damage the edit history of the page you move by combining it with the
> edit history of the associated talk page. (This makes diffs very
> interesting!)
>
> I'd recommend against using it for the time being.
>
> See bug report:
> http://sourceforge.net/tracker/index.php?func=detail&aid=584649&group_id=34373&atid=411192

A fix is now installed and online. Big thanks to Lee for his prompt
response!

You may now freely move/rename pages without fear. (But don't forget,
topic and talk pages need to be renamed separately.)

-- brion vibber (brion @ pobox.com)


list: wikitech-l

source: pipermail-mbox

from_name: Brion VIBBER

subject:
[Wikitech-l] Re: [Wikipedia-l] "Move this page bug" -- do NOT use this feature
 until it's fixed!


list: wikipedia-l

from_name: Jimmy Wales

subject: [Wikipedia-l] Possible heads-up

in_reply_to: <200207222030.g6MKU2h05494@ross.bomis.com>; from lcrocker@nupedia.com on Mon, Jul 22, 2002 at 01:30:02PM -0700

body:
It's probably a good thing to clear that list from time to time anyway.

lcrocker at nupedia.com wrote:

> Just a possible heads-up to the militia: the conversion process did
> not carry over the list of blocked IPs from the old site, so we are
> in fact running naked at the moment.  I imagine those we blocked have
> moved on, but I thought I'd give you a heads up so that if you see
> what looks like an old familiar vandal, it probably is an old
> familiar vandal, and we'll just have to block him again.
>
>
>
>
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikitech-l] Re: performance

in_reply_to: <200207140150.DAA21094@linde.uni-paderborn.de>; from axel@uni-paderborn.de on Sun, Jul 14, 2002 at 03:50:20AM +0200

body:
On Sun, Jul 14, 2002 at 03:50:20AM +0200, Axel Boldt wrote:
> > Some special pages are still moderately slow (particularly "wanted"
> > and "random page"), but the real time hogs now are very long pages
> > with lots of links.
>
> I looked at the random page code, and right now it fetches a complete
> list of all article IDs, in order to pick one out randomly. There must
> be a better way to do this. This should be an O(log n) operation, not O(n).

It can be. If you do a COUNT(*) without any conditions it looks it up in the
index, so that's very fast. Then you can guess a number n under this
upperbound and ask for the n'th record with LIMIT. MySQL will use the index
for that so it should be O(log n). If the record doesn't satisfy the
conditions (not the right namespace) then you simply guess again, but of
course it usually will be Ok the first time.

> The "wanted" special page will get a lot faster if we implement
> Jan's idea of a table recording the number of broken links to every
> unwritten article.

Well, I'm back from my short trip, so if Lee tells me how I can get
started I will. Actually, after that, if everybody agrees, I may begin to work
on the TeX extension.

> If long pages with lots of links cause trouble, maybe we should revive
> the caching idea of the current code: the cur table gets another
> column cur_cache where we store the rendered HTML. When displaying an
> article, we simply pump out the contents of cur_cache, or, if cur_cache
> is empty, we render, display and store in cur_cache. If a newly saved
> article necessitates the updating of links, we junk the cur_cache of
> all affected articles.

A good idea.

-- Jan Hidders


from_name: lcrocker at nupedia.com

subject: [Wikitech-l] Re: Re: [Wikipedia-l] Re: New server online?

body:
> Lee, what "many other things" will reassigning wikipedia.com affect?
>
> Fortunately, we have no wikipedia webmail, so that complication
> doesn't exist.
>
> I *think* I can change wikipedia.com, while leaving
> *.wikipedia.com to the old machine.  This is important until
> we move the Intl wikis over.

It was the Intl's I was thinking of.  If you can move "wikipedia.com"
without moving "*.", that's great.  I haven't studied BIND that much.
Don't forget to explicitly put in "old".

BTW, it seems like some of the history records got lost in the
conversion.  Fortunately, this can be repaired without a whole new
conversion process since we don't use the linked-list thing anymore.
This is just a heads up that I will need to get a new history-only
dump of the old database sometime soon.


subject: [Wikipedia-l] Possible heads-up

body:
Just a possible heads-up to the militia: the conversion process did
not carry over the list of blocked IPs from the old site, so we are
in fact running naked at the moment.  I imagine those we blocked have
moved on, but I thought I'd give you a heads up so that if you see
what looks like an old familiar vandal, it probably is an old
familiar vandal, and we'll just have to block him again.


subject: [Wikipedia-l] Re: New server online?

in_reply_to: <3D3A3EE9.3020506@pobox.com>; from brion@pobox.com on Sat, Jul 20, 2002 at 08:56:09PM -0800

body:
On Sat, Jul 20, 2002 at 08:56:09PM -0800, Brion VIBBER wrote:
> Toby Bartels wrote:
> > When I go to www.wikipedia.com using IE,
> > I get a snapshot that was apparently taken shortly after 10:48.
> [..]
> > But when I go to www.wikipedia.com using Netscape,
> > I get a new server, with all kinds of recent changes since 17:33:
> [..]
> > Well, I just deleted all of my temporary Internet files for IE.
> > Now it's working!  But I still wonder what was going on.
>
> To hazard a guess, IE was preserving the IP address for the former
> www.wikipedia.com (130.94.122.195) in some sort of cache. The new
> www.wikipedia.com (130.94.122.197) has the new live server.

Actually I still have quite some problems under Windows XP with IE6.0. Even
if I tell it to refresh pages on every visit. I only can get the most recent
changes if I delete all my chache files. Does anybody else have this
problem?

-- Jan Hidders


from_name: The Cunctator

subject: [Wikitech-l] Some stats for service times with the new server

body:
On 7/22/02 2:40 PM, "lcrocker at nupedia.com" <lcrocker at nupedia.com> wrote:

>
>>> The "Astronomer" page contains an extraordinary number of links,
>>> mostly to "year" pages.  Each link on a page requires a database
>>> lookup (a quick one, but still a lookup).  "Current events" had
>>> the same problem before I reorganized it.  I'm inclined to just
>>> remove the year links here.  They don't really serve much purpose.
>
>> Argh! I didn't notice that. Thanks for pointing that out.
>> Wouldn't page caching sort this, though?
>
> I have something of a love/hate relationship with caching. It
> solves some problems, and it creates others.  I'd like to avoid
> it if possible, and I think it is possible.  But I may be proven
> wrong about that if people create lots of other link-fest pages.
>
Some kind of page-caching is probably a good idea. We should definitely
allow for linkfest pages.


from_name: Pierre Abbat

subject: [Wikitech-l] Internal error trying to delete

body:
http://www.wikipedia.com/w/wiki.phtml?image=GP4_1.jpg&action=delete

I typed "Irrelevant junk and too big for an article." in the reason space,
checked the checkbox, and got a screen saying "Internal error" on top of
error messages saying that headers were output after text.

phma


from_name: Zoe Comnena

subject: [Wikipedia-l] Re: Wikipedia-l digest, Vol 1 #480 - 17 msgs

body:
 From: "Julie Hofmann Kemp"
Oh -- I also miss the link from the talk: page back to the related
article.

It's still there, but it's been renamed "Subject page".  Took me a while to find, too.  :-)
Zoe

---------------------------------
Do You Yahoo!?
Yahoo! Health - Feel better, live better
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020722/df016467/attachment.htm


from_name: Magnus Manske

subject: [Wikipedia-l] AW: Re: [Wikipedia-l] Re: New server online?

body:
>Actually I still have quite some problems under Windows XP with IE6.0.
Even
>if I tell it to refresh pages on every visit. I only can get the most recent
>changes if I delete all my chache files. Does anybody else have this
>problem?

I did. Turn off your proxy, then it works.

Don't worry, the same problem was on beta.wikipedia.com, and it was fixed
(somehow;)

Magnus

________________________________________
Online Fotoalben - jetzt kostenlos bei http://www.ePost.de


from_name: Lars Aronsson

subject: [Wikipedia-l] Years in review and the need for editorial judgement

body:
On Fri, 28 Jun 2002, Jimmy Wales wrote:
> One of our "discoveries" is that people of very diverse opinions can
> write encyclopedia articles together, using NPOV as a guideline to
> mediate conflict.  It works remarkably well.  It would not work for
> poetry, for political commentary, for fiction, etc.

Is this a discovery that is unique to Wikipedia?

Couldn't the same discovery be expressed: "it is possible (no matter who
does it) to write articles (in an encyclopedia or newspaper), using NPOV
as a guideline, so that no reader would care to protest against the
wording of the text".

I think that this is the same approach that has been used by every
encyclopedia and newspaper editor, ever.  Only they might have called it
"factualism and objectivity" rather than NPOV.

Or is this wrong?

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/  http://elektrosmog.nu/  http://susning.nu/


subject: [Wikitech-l] Re: New server online?

body:
Jimmy Wales wrote:
(re: changing DNS for "wikipedia.com" to point to the new server)
> Lee, what "many other things" will reassigning wikipedia.com affect?
>
> Fortunately, we have no wikipedia webmail, so that complication doesn't exist.
>
> I *think* I can change wikipedia.com, while leaving *.wikipedia.com to the old
> machine.

If you can, great!

 >  This is important until we move the Intl wikis over.
>
> We need a migration plan for those, too, of course.

I'd recommend converting the Esperanto, Polish, German, and French wikis
(those with message translations*) to the phase II software (what the
English wiki was running until this weekend) as soon as possible; then
work on adapting the message translations to phase III (what the English
wiki just upgraded to).

Once phase III is localized and tested, convert them again and start
looking into adapting the other languages.

Another possibility is waiting on _everything_ for direct adaption to
phase III, but that's just going to annoy a lot of people who've been
waiting months for an upgrade to phase II and put a lot of effort into
providing message translation files.

*(There's also a message file for the Spanish wiki; but I'm not sure
what the intended fate of that is. There have been murmurs from some
quarters that we should simply drop it, and treat enciclopedia.us.es as
if it were the Spanish Wikipedia insofar as linking is concerned.)

-- brion vibber (brion @ pobox.com)


from_name: Neil Harris

subject: [Wikitech-l] Attempt at making ergonomic groups, for review

body:
Ray Saintonge suggested that I should break up the 'top picks' into
page-related and others. Thanks, Ray.
I've also made some other changes.

OK, how's this for a recommended ordering of commands/options? I've
changed some sublists to alphabetical order, as there is not much
'gradient' in their frequencies, and there should always be some kind of
organising principle.

I have also re-named some of the special page labels to make them
uniform, eliminating the 'show' or 'list' prefixes which have got in the
way of recognition (the special page names themselves can be kept the
same, these are just link text labels).

Overall organising principles:

* Groups are organised by the scope of what they refer to (global, this
user, this page, etc.)
* Groups are organised from top to bottom by frequency.

*Where there are significant differences in frequency, entries within a
group are listed in order of frequency.
*otherwise, entries within groups are ordered alphabetically.

Top picks: (in frequency order: there is a real gradient here)
 Main Page <---- bold
 Recent changes
 Random page
 Current events
 Special pages
 Statistics

This page: (in frequency order: there is a real gradient here)
 Edit this page <--- bold
 History
 What links here

Login area: (in frequency order)
 Preferences
 User login
 Log out

User pages only:
 This user's contributions

Special pages in general - these are all global: (and now in
alphabetical order)
 All pages
 All users
 Blocked IP addresses
 Images
 Long pages
 Most wanted pages
 New pages
 Orphan pages
 Popular pages
 Short pages
 Upload image files
 Unused images

Page-related, but less common: (in frequency/alphabetical order)
 Print this page
 Recent changes in linked pages

Logged-in user page-related features: (in alphabetical order)
 Stop watching this page
 Watch list
 Watch this page

'power user commands':
 Move this page
 Delete this page


subject:
[Wikitech-l] Some stats for service times with the new server
 under real loads,

body:
lcrocker at nupedia.com wrote:

>>20020721000038  0194.499        /wiki/Astronomer
>>20020721001207  0018.859        /wiki/Astronomer
>>20020721002017  0122.170        /wiki/Astronomer
>>20020721002354  0171.431        /wiki/Astronomer
>>20020721002825  0110.615        /wiki/Astronomer
>>20020721003134  0068.176        /wiki/Astronomer
>>20020721003758  0159.654        /wiki/Astronomer
>>
>>**Most** accesses to this particular page seem to have taken
>>**over 1 minute**, and yet there appears to be nothing
>>pathological about the contents of the page. This is interesting!
>>
>>
>
>The "Astronomer" page contains an extraordinary number of links,
>mostly to "year" pages.  Each link on a page requires a database
>lookup (a quick one, but still a lookup).  "Current events" had
>the same problem before I reorganized it.  I'm inclined to just
>remove the year links here.  They don't really serve much purpose.
>
Argh! I didn't notice that. Thanks for pointing that out.
Wouldn't page caching sort this, though?

Neil


body:
lcrocker at nupedia.com wrote:

>>>The "Astronomer" page contains an extraordinary number of links,
>>>mostly to "year" pages.  Each link on a page requires a database
>>>lookup (a quick one, but still a lookup).  "Current events" had
>>>the same problem before I reorganized it.  I'm inclined to just
>>>remove the year links here.  They don't really serve much purpose.
>>>
>>>
>
>
>
>>Argh! I didn't notice that. Thanks for pointing that out.
>>Wouldn't page caching sort this, though?
>>
>>
>
>I have something of a love/hate relationship with caching. It
>solves some problems, and it creates others.  I'd like to avoid
>it if possible, and I think it is possible.  But I may be proven
>wrong about that if people create lots of other link-fest pages.
>
Lee,

I haven't read the code, but do you do the lookups as lots of individual
SQL calls per link, or do you gather up a list of them and do a single
SQL call? This might improve performance, as possibly might doing the
lookups in batches, if the latency/pipelining hit would be too much for
a single call?

Neil


body:
I already filed it under "bug report" a few hours ago.

Pierre Abbat wrote:

>http://www.wikipedia.com/w/wiki.phtml?image=GP4_1.jpg&action=delete
>
>I typed "Irrelevant junk and too big for an article." in the reason space,
>checked the checkbox, and got a screen saying "Internal error" on top of
>error messages saying that headers were output after text.
>
>phma
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at ross.bomis.com
>http://ross.bomis.com/mailman/listinfo/wikitech-l
>
>
>


subject: [Wikipedia-l] [Fwd: [ wikipedia-Bugs-584804 ] URL followed by punctuation->broken link]

in_reply_to: <3D3C52C8.40204@pobox.com>; from brion@pobox.com on Mon, Jul 22, 2002 at 10:45:28AM -0800

body:
On Mon, Jul 22, 2002 at 10:45:28AM -0800, Brion VIBBER wrote:
> The old software knew that 99.9% of the time humans don't _really_ mean
> it when they put a comma, period, or other such item of punctuation
> immediately after a URL, but that these are rather intended as, well,
> punctuation.
>
> The new phase III software trusts us more; URLs that are followed
> immediately by punctuation (period, comma, paren, semicolon, etc) now
> include this punctuation in the hyperlink, which leads to a lot of
> broken external links where URLs are put casually into text,
> particularly on talk pages.
>
> Bug or feature? You decide!

I would say feature. The parsing rules should be as simple as possible and
have as little exceptions as possible. This makes them easier to explain to
users, keeps the software simple, and gives less headaches when in the
future we want to adapt mark-up or export to other formats such as XML.

-- Jan Hidders


body:
While on the subject of DNS and server names; could we make it so that
en.wikipedia.com (.org, whatever) actually points directly to the
English wiki? At the moment it's a separate usemodwiki which a sarcastic
note and a link to www.wikipedia.com.

(Also, I'm currently in the process of adding the rest of the languages
which have wikis or potential wikis to the list for inter-language
links. There's a lot of them...)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] LWN: A new, remotely exploitable PHP vulnerability

body:
This is nasty. The new server is running PHP 4.2.1, which according to
this is potentially vulnerable unless someone installs the patch, or
does the workaround.

Neil

http://lwn.net/Articles/5263/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20020722/5a43d05b/attachment.html>


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Topology of Wikipedia

body:
Topology of Wikipedias is very interesting.

First question is: what is distribution of number of hops needed to
reach an article from the Main page.

Attached script gives aproximate answer to this question.
It requires PHP database, and libmysql-ruby.

Data for Polish Wikipedia:

-1 602 (12.75964392%)
0 1 (0.02119542179%)
1 113 (2.395082662%)
2 886 (18.7791437%)
3 2367 (50.16956337%)
4 600 (12.71725307%)
5 126 (2.670623145%)
6 16 (0.3391267486%)
7 5 (0.1059771089%)
8 2 (0.04239084358%)
Total 4718

Results:
* It's yet to be found how much the fact that empty pages, redirects,
  user and talk pages are treated like normal pages affects the results.
* Number of pages that are not reachable at all is very high.
* If page is reachable, it's usually reachable in just a few hops
* Adding more links to pages linked from Main page seems to be best
  way of improving results.

I'm especially interested in results from English (which is the
biggest) and Esperanto (which has different linking philosophy)
Wikipedias. Information from Spanish, German and others would
also be interesting, but I don't expect it to differ a lot from Polish
results.
-------------- next part --------------
#!/usr/bin/ruby

require "mysql.so"

host = nil
user = nil
passwd = "***"
db = "wikipedia"

my = Mysql.new(host, user, passwd)
my.select_db db

res = my.query("select cur_title from cur")

order = {}
linked={}

while row = res.fetch_row
    order[row[0]] = -1
    linked[row[0]] = []
end

res = my.query("select * from linked")

rows=[]
while row = res.fetch_row
    rows.push row
end
rows.uniq!
rows.each {|t,f|
    linked[f].push t
}

cur_order = 0
cur_set = ["Polska_Wikipedia"]
begin
    cur_linked = []
    cur_set.each {|title|
	order[title] = cur_order
	cur_linked += linked[title]
    }
    cur_linked.uniq!
    new_set = []
    cur_linked.each {|title|
	if order[title] == -1
	    new_set.push title
	    order[title] = cur_order
        end
    }
    cur_set = new_set
    cur_order += 1
end while cur_set.size != 0

group_by_order = {}
order.each {|k,v|
    group_by_order[v] = [] unless group_by_order[v]
    group_by_order[v].push k
}
group_by_order.sort.each {|k,v|
    print k," ",v.size," (#{v.size*100.0/order.size}%)\n"
}
print "Total #{order.size}\n"


subject: [Wikitech-l] Topology of Wikipedia

body:
Tomasz Wegrzanowski wrote:

>Topology of Wikipedias is very interesting.
>
>First question is: what is distribution of number of hops needed to
>reach an article from the Main page.
>
>Attached script gives aproximate answer to this question.
>It requires PHP database, and libmysql-ruby.
>
>Data for Polish Wikipedia:
>
>-1 602 (12.75964392%)
>0 1 (0.02119542179%)
>1 113 (2.395082662%)
>2 886 (18.7791437%)
>3 2367 (50.16956337%)
>4 600 (12.71725307%)
>5 126 (2.670623145%)
>6 16 (0.3391267486%)
>7 5 (0.1059771089%)
>8 2 (0.04239084358%)
>Total 4718
>
>
>
Interesting. The English-language Wikipedia claims only 313 orphans (<
1%) out of 34457 articles, not counting redirects or non-comma articles.
Maybe there is a 'closure' effect as the encyclopedia gets bigger? Or
maybe 'real' articles are more likely to be linked?

Neil


from_name: tarquin

subject: [Wikipedia-l] Recent Changes doesn't group?

body:
Recent Changes no longer gathers up edits to a page in a single line
with "n changes".
Is this desirable behaviour?
It means we have to load an even longer page to see all the edits since
we last visited, and it's harder to scan the list for interesting
articles because the same names keep popping up.

tarquin


subject: [Wikipedia-l] Re: Cologne Blue

body:
lcrocker at nupedia.com wrote:

>>Could someone perhaps design a CologneBlue Mk2, with the
>>following changes:
>>* serif font
>>* clearer toolbar
>>* key links along the top
>>* include the wikipedia logo
>>
>It's pretty straightforward to write a new skin now--check out
>the files "SkinCologneBlue.php" and "cologneblue.css" from the
>code.  I tend to agree that we need one that looks clean like
>Cologne Blue but that's more usable.
>
I''ll have a go at trying a redesign -- but a few questions:
* do I need permission of the original designer, or are template designs
GFDL/GPL too?
* is the code open? Do I need to be given access?
* last dumb question (honest!): where do I get it from?

tarquin


subject: [Wikitech-l] Topology of Wikipedia

body:
Tomasz Wegrzanowski wrote:

> On Mon, Jul 22, 2002 at 11:56:58PM +0100, Neil Harris wrote:
>
>
>>Tomasz Wegrzanowski wrote:
>>
>>
>>
>>>Topology of Wikipedias is very interesting.
>>>
>>>First question is: what is distribution of number of hops needed to
>>>reach an article from the Main page.
>>>
>>>Attached script gives aproximate answer to this question.
>>>It requires PHP database, and libmysql-ruby.
>>>
>>>Data for Polish Wikipedia:
>>>
>>>-1 602 (12.75964392%)
>>>0 1 (0.02119542179%)
>>>1 113 (2.395082662%)
>>>2 886 (18.7791437%)
>>>3 2367 (50.16956337%)
>>>4 600 (12.71725307%)
>>>5 126 (2.670623145%)
>>>6 16 (0.3391267486%)
>>>7 5 (0.1059771089%)
>>>8 2 (0.04239084358%)
>>>Total 4718
>>>
>>>
>>>
>>>
>>>
>>Interesting. The English-language Wikipedia claims only 313 orphans (<
>>1%) out of 34457 articles, not counting redirects or non-comma articles.
>>Maybe there is a 'closure' effect as the encyclopedia gets bigger? Or
>>maybe 'real' articles are more likely to be linked?
>>
>>
>
>Orphans count is different. Orphans count is 175 on Polish Wikipedia.
>
>Orphans count doesn't include redirects, empty, user and talk pages.
>That's good.
>
>But if some group of articles link to each other but are not linked
>from any article outside of the group, then orphan count doesn't
>include them. But they're also not accesible, so it should.
>

Oh, I see. They're disconnected sub-graphs not reachable from the root.
That's interesting.

I wonder what the equivalent figures are for the English-language Wikipedia?

Neil


subject: [Wikipedia-l] Orphan junk pictures

body:
I noted some images that I think should be deleted. Would someone else like
to look at them and delete them if he agrees?

phma


subject: [Wikitech-l] Topology of Wikipedia

body:
 On Mon, Jul 22, 2002 at 11:56:58PM +0100, Neil Harris wrote:
> Tomasz Wegrzanowski wrote:
>
> >Topology of Wikipedias is very interesting.
> >
> >First question is: what is distribution of number of hops needed to
> >reach an article from the Main page.
> >
> >Attached script gives aproximate answer to this question.
> >It requires PHP database, and libmysql-ruby.
> >
> >Data for Polish Wikipedia:
> >
> >-1 602 (12.75964392%)
> >0 1 (0.02119542179%)
> >1 113 (2.395082662%)
> >2 886 (18.7791437%)
> >3 2367 (50.16956337%)
> >4 600 (12.71725307%)
> >5 126 (2.670623145%)
> >6 16 (0.3391267486%)
> >7 5 (0.1059771089%)
> >8 2 (0.04239084358%)
> >Total 4718
> >
> >
> >
> Interesting. The English-language Wikipedia claims only 313 orphans (<
> 1%) out of 34457 articles, not counting redirects or non-comma articles.
> Maybe there is a 'closure' effect as the encyclopedia gets bigger? Or
> maybe 'real' articles are more likely to be linked?

Orphans count is different. Orphans count is 175 on Polish Wikipedia.

Orphans count doesn't include redirects, empty, user and talk pages.
That's good.

But if some group of articles link to each other but are not linked
from any article outside of the group, then orphan count doesn't
include them. But they're also not accesible, so it should.


from_name: Daniel Mayer

subject: [Wikipedia-l] Re: Too much entries in recent changes

body:
On Monday 22 July 2002 04:04 pm, you wrote on sourceforge:
> Initial Comment:
> I don't really like the new recent changes page, with
> each change (even of the same article) showing up as
> one row. It's cluttering the page, and makes it more
> difficult to track the changes for me.
>
> J. Heijmans

I agree tottally -- it is no longer possible for me to review all changes
made in the 12 to 18 hour a day stretches of time when I'm not on wikipedia
at all. I knew this would happen eventually as more and more contributors
made more and more contributions each day but I wasn't prepared to
drastically change the way I contribute just yet (thank goodness for the
Watch List).

I for one didn't have any problem with the the previous layout of Recent
Changes -- next to each diff was a short statement of the number of changes
made to that page during the period selected (last 100, 500.. edits or last
14, 30.. days). All that was needed was a quick check of the the history
(which was also linked from the entry in Recent Changes) to see all the
activity that has occurred with that article. Now when I leave my computer to
eat dinner and come back in an hour I am greeted with four to five times the
number of entries as before. I really don't care if it took user X 15 edits
to bring an article to their liking and all those entries in Recent Changes
really does clutter the page.

It furthermore doesn't make any sense to have an active link to the most
current diff next too an entry in Recent Changes that is 3 or 4 times removed
from being the most recent change to /that/ article. This will only lead to
misunderstandings as to who has done what among newbies (and headaches for
may old timers).  At the very least, only the most recent change to each
article should have an active diff link.

Wikiware gurus, please bring back the option for users to turn off the
display of each and every single edit made to one particular article (in the
same way we are now able to turn off the display of minor edits). I really do
prefer the executive summary format of before.

PS - Was I the only one who used the table format for displaying Recent
Changes before? I really don't care for the standard display which doesn't
organize user names and comments in columns... For me, this is another thing
that makes reading the new Recent Changes more difficult.

--maveric149


body:
> >>> The "Astronomer" page contains an extraordinary number of links,
> >>> mostly to "year" pages.  Each link on a page requires a database
> >>> lookup (a quick one, but still a lookup).  "Current events" had

If this is true, I think the code should be rewritten to use an in-core
hash table that contains (as keys) the names of all existing pages.  It
would only be used to determine whether a [[link]] should be underlined or
a ?-link.  This in-core data structures would not be shared between
threads of a PHP application (at least not if load balancing over multiple
hosts), but it could be recreated from the database (select name from cur)
every few minutes or so (and whenever a reload or post is served).  Pages
that are created between these intervals will falsely have ?-links for a
short while, big deal.  Or hits would be read from the hash, but misses
would force a read from the database.  Avoiding a roundtrip down to the
database sounds like a great saving to me.

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/  http://elektrosmog.nu/  http://susning.nu/


body:
On Mon, 22 Jul 2002, Brion VIBBER wrote:
> The difference is "every encyclopedia and newspaper *editor*". We're
> giving every crank off the street his own shot at the presses and
> politely asking him to clean up after the mess the last crank left.

I agree that this is a big difference.  Here everybody is an editor, with
very little room for training.  (Like throwing people into the water,
hoping they will learn to swim.)

But I think the need for objectivity (NPOV) is universal, no matter who
the editor is.

We could learn a lot from the experience of traditional encyclopedia
editors over the last few centuries, but very few of us would take the
time to do so.  I've read a biography of Denis Diderot, and "The
Professor and the Madman", and have a small collection of old (Swedish)
encyclopedia and dictionaries, but that's about all.  One conclusion that
I've drawn is that they all used to borrow facts and ideas from each
other, without too much worry for copyright infringement.

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/  http://elektrosmog.nu/  http://susning.nu/


subject: [Wikipedia-l] forgotten history

body:
This bug is affecting a great many articles so I was wondering if the lost
histories of articles will be restorable en masse or will each and every
article's history will have to be restored manually?

Also, is there an ETA when this bug will be fixed? Its pretty sad when users
have to use Google to view old versions of articles or else manually edit the
URL to get to the read-only version of the old database and software (which
is a non-obvious work-around only known by a select few).

--mav


subject: [Wikitech-l] [neil.harris@mediachannel.ltd.uk: [Fwd: LWN: A new, remotely exploitable PHP vulnerability]]

body:
----- Forwarded message from Neil Harris <neil.harris at mediachannel.ltd.uk> -----

From: Neil Harris <neil.harris at mediachannel.ltd.uk>
Date: Tue, 23 Jul 2002 09:21:29 +0100
To: Jimmy Wales <jwales at bomis.com>
Subject: [Fwd: LWN: A new, remotely exploitable PHP vulnerability]

Jimbo,

I got delivery failure reports trying to send this to Lee and the
wikitech-l list: perhaps you have a non-Wikipedia E-mail address for Lee?

Regards,

Neil

From: Neil Harris <neil.harris at mediachannel.ltd.uk>
Date: Mon, 22 Jul 2002 23:43:49 +0100
To:  lcrocker at nupedia.com,  wikitech-l at nupedia.com
Subject: LWN: A new, remotely exploitable PHP vulnerability

This is nasty. The new server is running PHP 4.2.1, which according to
this is potentially vulnerable unless someone installs the patch, or
does the workaround.

Neil

http://lwn.net/Articles/5263/

----- End forwarded message -----


subject: [Wikitech-l] [rubenste@ohiou.edu: Re: help?]

body:
This is feedback.

----- Forwarded message from "steven l. rubenstein" <rubenste at ohiou.edu> -----

From: "steven l. rubenstein" <rubenste at ohiou.edu>
Date: Tue, 23 Jul 2002 11:54:08 -0400
To: Jimmy Wales <jwales at bomis.com>
Subject: Re: help?

Hi Jim,

I notice a change in the WIkipedia "Recent Changes" page format, which is
causing me some difficulties.  I hope you can at least explain the change.

First, the "view the last..." line only allows me to look at the last 500
entries.  I used to be able to look at the last 1000 or 2500 entries.  What
happened?  What do I have to do to see the last 1000 entries?

Second, I ask because the same line give me a choice of looking at entries
from the past 1, 3, 7, 14, or 30 days.  This is especially important to me
as I may not check Wikipedia for several days at a time.  But this option
is effectively inoperative, because there seldom seems to be fewer than 500
changes per day.  Thus, even if I ask for the last 30 days, I never get to
see all changes from the last 30 days -- I only get to see changes from the
last six hours (500 changes)!

In other words, is there any way to see changes beyond the last six hours?

Finally, there used to be an option to see all new changes since the last
time I checked, but I cannot find this common anymore.  What happened?

I know that managing something as complex as Wikipedia must be very
hard.  For what it is worth, it used to take so long to call up any
Wikipedia article that my computer timed out.  I have not had this problem
in the past couple of days and appreciate it -- a major improvement.  But
it seems to me that these other changes have created new problems....

Thanks for your attention,

Steve

----- End forwarded message -----


from_name: Marian Steinbach

subject: [Wikitech-l] Idea for a statistics-based main menu

body:
Hi Lars!

Lars Aronsson wrote:
> What if the main menu was entirely based on statistics, with the most
> frequently requested URL at the top.

Would you allow for any popular URL to be in the main menu? Let's say
the article "Current events" became the second most popular. Would it be
in the menu? What if "Israeli-Palestinian conflict" became most popular.
Would it go into them menu? And what would have to move out?

 > I bet Recent Changes would be at the
> top, and the "diff for this page" in 2nd place and "edit this page" 3rd.
> Maybe it would be very useful.

The diff for a specific page is most likely less requested than the page
itself and a lot less than the most popular articles. What you would
need is a priorization in the context of a certain article in order to
balance this out.

> Before you collect the statistics, you would have to substitute all the
> page names with something like "%s" that can later be substituted back
> with the actual page name.

I think it's not at all that simple.

Menus ordered by use are a widely discussed topic in the HCI (human
computer interaction) community. But when it comes to implementation,
all sorts of problems arrise.

For example: How does a user know when and why a menu topic appears or
disappears or repositions? Which criteria are relevant? Is the absolute
number of pageviews for a certain page enough? Or should it be the mean
average number of page views during a certain period? Which period would
be appropriate?

What if Wikipedia had only two users, and they both had very different
interests? Both had to live with each other's "bookmarks" in the menu.

Even if all users had the same interest, which is not a good assumption
to make, wouldn't a menu ordered by frequence of use mean that the most
popular functions or pages would become even more popular?

So far,

Marian

--
Marian Steinbach
http://www.ds.fh-koeln.de/~marian/
ICQ# 9790691


subject: [Wikitech-l] Tarballs for non-English Wikipedias

body:
Using bzip2 instead of gzip for tarballs would save us a bit of
downloading.

Size of Polish tarball falls from 19.3m to 17.2m this way.


subject: [Wikipedia-l] forgotten history

in_reply_to: <20020723094344.MAAO24728.rwcrmhc51.attbi.com@there>; from maveric149@yahoo.com on Tue, Jul 23, 2002 at 02:40:12AM -0700

body:
Lee is working on it.  I did a new database dump for him.  I imagine the history will
be back by tomorrow.

Daniel Mayer wrote:

> This bug is affecting a great many articles so I was wondering if the lost
> histories of articles will be restorable en masse or will each and every
> article's history will have to be restored manually?
>
> Also, is there an ETA when this bug will be fixed? Its pretty sad when users
> have to use Google to view old versions of articles or else manually edit the
> URL to get to the read-only version of the old database and software (which
> is a non-obvious work-around only known by a select few).
>
> --mav
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] I just noticed that 'vote for this page' has disappeared

body:
Karen AKA Kajikit wrote:
> It's something that I found quite handy because a) it gave you somewhere
> to stow pages away for future reference, and b) it was a place to bring
> them to other's attention if they really needed something done and you
> didn't know enough to do it.

Lee arbitrarily took out the voting system; if we clamor loud enough, he
promises to put it back.

Which reminds me... everybody, don't forget the bug & feature request-
tracking system at the Wikipedia project page on Sourceforge:
   http://sourceforge.net/tracker/?group_id=34373

Wiki pages get cluttered with this kind of thing, and mailing list
messages get quickly forgotten, but the tracker won't leave us poor
programmers alone until we do something about it...

<snip>
> But I like the list of orphaned images,

Aha! I was looking for that up next to "Upload images" and "List
images"; on another look it turns out to be way down by "List orphaned
articles".

Note that there are still some limitations; it doesn't know about images
and other files that are indirectly linked via a clickable URL within
the English wiki, or from the various non-English wikipedias.

> PS. I miss having my shortcut bar on the righthand side of the page too,
> but I'm getting used to the change. I realised WHY I liked it there - I
> use the random page button a lot and it was that much closer to the
> scrollbar on the righthand side of the page so it saved a little extra
> movement when I was browsing.

You can set it back to the righthand side in your user preferences.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: [neil.harris@mediachannel.ltd.uk: [Fwd: LWN: A new, remotely exploitable PHP vulnerability]]

body:
> This is nasty. The new server is running PHP 4.2.1, which
> according to this is potentially vulnerable unless someone
> installs the patch, or does the workaround.

On the x86 architecture, this bug will cause PHP to crash
rather than being a security hole, but yes, I will upgrade soon,
probably tonight.

P.S., if you couldn't find my real e-mail address, you weren't
looking very hard.  It's on my wiki page, in my signature, and my
home site is the first page returned by Google for my name.


subject: [Wikipedia-l] Re: Cologne Blue

in_reply_to: <3D3C906F.9050707@planetunreal.com>; from tarquin@planetunreal.com on Tue, Jul 23, 2002 at 12:08:31AM +0100

body:
Everything is GPL.  Someone other than me could best explain where to get
the code.

tarquin wrote:

> lcrocker at nupedia.com wrote:
>
> >>Could someone perhaps design a CologneBlue Mk2, with the
> >>following changes:
> >>* serif font
> >>* clearer toolbar
> >>* key links along the top
> >>* include the wikipedia logo
> >>
> >It's pretty straightforward to write a new skin now--check out
> >the files "SkinCologneBlue.php" and "cologneblue.css" from the
> >code.  I tend to agree that we need one that looks clean like
> >Cologne Blue but that's more usable.
> >
> I''ll have a go at trying a redesign -- but a few questions:
> * do I need permission of the original designer, or are template designs
> GFDL/GPL too?
> * is the code open? Do I need to be given access?
> * last dumb question (honest!): where do I get it from?
>
> tarquin
>
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Recent changes page

body:
This is a general reply to a couple of mails relating to the new
software's Recent Changes page.

It was a guiding principle of my new design that it be *fast*.  I
think the performance of this page is critical to usability.  Speed
is a feature too.  So if you're going to suggest features, make sure
they are either (1) not hindrances to performance, or (2) really,
truly, vitally necessary.

1) If you wan't 1000, 2500, or more changes, you can do that by
editing the URL directly.  They are removed as links from the page so
that robots won't spider them, putting a load on the server.  The
occasional human use shouldn't be a problem.  If enough people
complain, I might consider putting 1000 back, though the need for it
might be supplanted by other features mentioned below.

I'd also be happy to put in some shorter time limits: currently the
shortest is "1 day", but I can see that it might be useful to have,
say, "3 hours", "6 hours", and "12 hours".  This would make it
possible to extend the limit to a bigger number and still have a
reasonably fast query, because the time limit really trims down the
result set and makes things fast.

Along those lines, I've had enough requests to restore the "show only
new changes" feature, and that feature can actually speed up the
database query, so I plan to put that back.

Yes, it is confusing that the "diff" link on early edits shows a
recent diff.  I agree that this is a bug, and I will fix it as soon
as I can figure out a good method.  This one just happens to be
trickier than it looks, but it's not a performance issue, so I'm all
in favor of doing it right.

Any other desired feature that limits the set of pages returned is
also likely to get a favorable hearing.  Maybe a feature that shows
only pages beginning with a certain letter or string, pages edited by
certain people, etc.  If we can design a reasonable interface for it,
these kinds of changes must meet a lower burden of acceptance because
they will generally be fast.

The tricky one is consolidating multiple edits to a page into one
entry on the Recent Changes page, the way UseMod and Phase II did.
This is a big performance hit.  Perhaps a later redesign of the
database would make it more reasonable, or perhaps a new
implementation will come to mind that cures the problem, but for now
I just don't want to burden the server with extra work for what is,
to me, a cosmetic change that doesn't add functionality.


from_name: Ray Saintonge

subject: [Wikipedia-l] Copyright Question - Catholic encyclopedia

body:
Fred Bauder wrote:

>At 09:48 PM 7/23/02 +0200, jens wrote:
>
>>Hello,
>>
>>how do we treat the Catholic Encyclopedia? (www.newadvent.org)
>>
>>The articles are from a 1912 encyclopedia and should therefore be free,
>>but the website does claim a 1999 copyright for the online edition.
>>
>>As it might be in many cases difficult to prove that someone copied from
>>newadvent.org, it is rather obvious if typos are preserved.
>>
>>Can we use such an article as basis for copyediting?
>>
>
>I looked at this. I think the information on this page might be helpful:
>
>http://www.newadvent.org/cathen/00002a.htm
>
>
>Bottom line is I would not copy the source code but I would say the text
>can be copied without substantial risk.  I don't think typos count anyway.
>
>Fred Bauder
>
I've looked at the site which Fred referenced, and it includes the
following: "Knight chose the 1913 15-volume set because the later
editions are still under copyright protection."  Clearly Knight was
aware of the copyright issues when he was making his effort.  Copyright
depends on contributing some measure of original work.  Leaving scanning
bugs or even intentional bugs to trick the unwary is not original work,
nor is cleaning them up.

The frames and other environment written and supplied by New Advent are
of course copyrightable,  Simply putting a blanket copyright notice on
something means to me nothing more than "Copyright to the extent that it
can be copyright".  No person uploading such a page can be reasonably
expected to detail which parts of a page are copyright and which are
not.  For the reader, he has to use his own common sense in making his
determination.

Eclecticology


body:
> It's something that I found quite handy because a) it gave you
> somewhere to stow pages away for future reference, and b) it was a
> place to bring them to other's attention if they really needed
> something done and you didn't know enough to do it.

Magnus added the "vote" features on a whim fairly recently, so I
didn't feel too bad about removing them on a whim.  I think there
needs to be more discussion and consensus about what to do along
these lines before actually implementing something.  I have some
ideas I will detail soon...but in short, I'd like to see a link
something like "review this page", which gives the user a form in
which he can make all kinds of recommendations (including "I think
this should be deleted"), and that information can be stored and used
in various ways (not merely appended to a page).


from_name: Fred Bauder

body:
At 09:48 PM 7/23/02 +0200, jens wrote:
>Hello,
>
>how do we treat the Catholic Encyclopedia? (www.newadvent.org)
>
>The articles are from a 1912 encyclopedia and should therefore be free,
>but the website does claim a 1999 copyright for the online edition.
>
>As it might be in many cases difficult to prove that someone copied from
>newadvent.org, it is rather obvious if typos are preserved.
>
>Can we use such an article as basis for copyediting?

I looked at this. I think the information on this page might be helpful:

http://www.newadvent.org/cathen/00002a.htm

I looked at one article, St. Peter Claver and then wrote a stub and used
the newadvent page as an external link (I actually know quite a bit about
him, as I visited Cartagena once and had a nice experience at his shrine
there.) In the article there are links. As written with the links included
I would say the articles are copyrighted. Certainly the pages of individual
letter links are. It does say that the articles were transcribed rather
than revised from the 1913 edition which is in the public domain. Direct
copying of those articles either from a written source or from that web
page should be alright. I notice down at the bottom of the article it gives
a name of the person who "transcribed" the article. No mention is made of a
revision.

Bottom line is I would not copy the source code but I would say the text
can be copied without substantial risk.  I don't think typos count anyway.

Fred Bauder

BTW:

http://dogbert.abebooks.com/abe/BookSearch?tn=catholic+encyclopedia&pn=encyc
lopedia


subject: [Wikitech-l] Re: New server online?

body:
> Another possibility is waiting on _everything_ for direct
> adaptation to phase III, but that's just going to annoy a lot of
> people who've been waiting months for an upgrade to phase II and
> put a lot of effort into providing message translation files.

But there's a great benefit of having less overall work to do
(even for the translators in the long run) and ending up with a
better product.  The work involved in internationalizing the
Phase III software is minimal: Magnus produced a German version
in about two days (it's running now at
http://www.piclab.com/wikitest/wiki.phtml if you want to look).
If there are existing Phase II translations, it would not be hard
to use those as a starting point for the Phase III translation
to shave a little more time off the work.

I'm a big fan of skipping intermediate steps whenever possible.


subject: [Wikipedia-l] Recent changes page

body:
lcrocker at nupedia.com wrote:

>It was a guiding principle of my new design that it be *fast*.  I
>think the performance of this page is critical to usability.  Speed
>is a feature too.  So if you're going to suggest features, make sure
>they are either (1) not hindrances to performance, or (2) really,
>truly, vitally necessary.
>
>1) If you wan't 1000, 2500, or more changes, you can do that by
>editing the URL directly.  They are removed as links from the page so
>that robots won't spider them, putting a load on the server.  The
>occasional human use shouldn't be a problem.  If enough people
>complain, I might consider putting 1000 back, though the need for it
>might be supplanted by other features mentioned below.
>
>Any other desired feature that limits the set of pages returned is
>also likely to get a favorable hearing.
>
I was quick to read how more than 500 pages could be listed when higher
number page links were removed from the Recent Changes page, but I
didn't need this feature as much with the old system as with the new.  I
suppose some people would like to track all the multiple changes on
Recent Pages, and I know that when I reread some of my own work it often
needs changes, but making them kills the explanatory note that went with
my substantive changes.

What I really miss is not being able to use the back button to get back
to where I was.  It now forces a reload whenever I do so.  I've noticed
it most with Recent Changes, but I've also had it come up while editing
a page.  My habit has been to use search to go to verify a page name
when I'm trying to create a link from the page I'm editing.  Now when I
back-button from the search results I get a brand new edit page with my
partial edits deleted.

Simply being able to alter personal preferences to choose between a
reload or personal cache when using the back and forward buttons would
be a great advantage.

    Eclecticology


subject: [Wikipedia-l] Re: Cologne Blue

body:
>> I''ll have a go at trying a redesign -- but a few questions:
>> * do I need permission of the original designer, or are
>> template designs GFDL/GPL too?
>> * is the code open? Do I need to be given access?
>> * last dumb question (honest!): where do I get it from?

Everything is either GPL/GFDL or public domain, so there
shouldn't be any ownership issues.  If you want to create a
new design, I'd suggest mocking it up first and pointing us to
the samples to get feedback, and only coding after that.
If it's a really good design, I suspect you'll get a lot of
help coding.  But if you do want to look at the code, go to
http://wikipedia.sourceforge.net


subject: [Wikitech-l] Some stats for service times with the new server

body:
Lars Aronsson wrote:
>>>>>The "Astronomer" page contains an extraordinary number of links,
>>>>>mostly to "year" pages.  Each link on a page requires a database
>>>>>lookup (a quick one, but still a lookup).  "Current events" had
>
> If this is true, I think the code should be rewritten to use an in-core
> hash table that contains (as keys) the names of all existing pages.  It
> would only be used to determine whether a [[link]] should be underlined or
> a ?-link.  This in-core data structures would not be shared between
> threads of a PHP application (at least not if load balancing over multiple
> hosts), but it could be recreated from the database (select name from cur)
> every few minutes or so (and whenever a reload or post is served).  Pages
> that are created between these intervals will falsely have ?-links for a
> short while, big deal.

Hmm, maybe.

 >  Or hits would be read from the hash, but misses
> would force a read from the database.  Avoiding a roundtrip down to the
> database sounds like a great saving to me.

As Neil suggested, couldn't these checks be done in just one big query
rather than a lot of separate ones? ie, something like:

SELECT cur_title
   FROM cur
  WHERE cur_title
     IN ('Scientist','Research','Astronomy','Astrophysics',[...])

or would that just get more complicated?

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Re: Cologne Blue

body:
tarquin wrote:
> lcrocker at nupedia.com wrote:
>> It's pretty straightforward to write a new skin now--check out
>> the files "SkinCologneBlue.php" and "cologneblue.css" from the
>> code.  I tend to agree that we need one that looks clean like
>> Cologne Blue but that's more usable.
>>
> I''ll have a go at trying a redesign -- but a few questions:
> * do I need permission of the original designer, or are template designs
> GFDL/GPL too?

The code is all GPL. Which technically means you can't put the code into
Wikipedia articles, as the licenses are incompatible. ;)

> * is the code open? Do I need to be given access?
> * last dumb question (honest!): where do I get it from?

The whole thing is available by anonymous CVS hosted at Sourceforge:
http://sourceforge.net/projects/wikipedia, click on "CVS". You want
module "phpwiki", the current stuff is in the "newcodebase" subdirectory.

If you want to submit changes, you can send a diff to the Wikitech list
(wikitech-l at nupedia.com), or sign up for a Sourceforge account if you
don't have one and ask Magnus to give you developer access to the CVS
repository.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Orphan junk pictures

body:
Pierre Abbat wrote:
> I noted some images that I think should be deleted. Would someone else like
> to look at them and delete them if he agrees?

Sure. Which ones are they?

-- brion vibber (brion @ pobox.com)


body:
> As Neil suggested, couldn't these checks be done in just one big
> query rather than a lot of separate ones? ie, something like:
>
>SELECT cur_title
>   FROM cur
>  WHERE cur_title
>     IN ('Scientist','Research','Astronomy','Astrophysics',[...])
>
> or would that just get more complicated?

It would actually be more like:

 SELECT cur_id,cur_namespace,cur_title FROM cur WHERE
 (cur_namespace=0 AND cur_title='Scientist') OR
 (cur_namespace=0 AND cur_title='Research') OR
 (cur_namespace=1 AND cur_title='Scientist')

etc.  I'm not sure how well that would optimize.


subject: [Wikipedia-l] Recent changes page

body:
>> The tricky one is consolidating multiple edits to a page into
>> one entry on the Recent Changes page, the way UseMod and Phase II
>> did.  This is a big performance hit.

> Do we have some measurements on this? Would it be worth the effort
> if I tried to come up with some SQL that did this for the new
> script?

I have only compared the actual query used in Phase II (with that
ugly LEFT OUTER JOIN and GROUP BY) with my present query (actually
two queries, because MySQL doesn't have UNION yet).  If you want
to try other queries on the new database schema that might work with
comparable speed to the present one, I can try those out on my server
and time them using a version of Neil's bot.


subject:
[Wikipedia-l] A mock-up revised Cologne Blue layout: request
 for comments

body:
Neil Harris wrote:
> This is a hacked version of Marian's Cologne Blue layout.
[..]
> Notes/disclaimers:
[..]
> *It still uses tables for layout.

Yeah, we'll have to fix that...

> Please let me know if you like the layout.
>
> Does it:
> * preserve what you like about Cologne Blue's looks?

Yes! Most importantly, it still feels softer and calmer than the default
skin. Less sharp and mechanistic.

Minor points: It might be nice to leave the browser default font _size_
intact for the body text, as well. 10pt is uncomfortably small for me
when using Times New Roman (my browser's default font), though it looked
good with the sans-serif Verdana.

> * have the menu items in roughly logical and familiar positions?

"My options" is still too low, I have to scroll down to get there. In
particular, "my settings" (or preferences or whatever it's to be called)
should be **way up top** so that a frightened unfamiliar newbie can go
right to it.

(I just noticed that there's a new PREFERENCES link up on the topbar --
good! But the fact that I didn't even notice it the first time over
might indicate a problem. Also, it might be good to have a consistent
terminology -- are they my "preferences" or "settings"?)

I'd prefer to move the Special pages section to the bottom; if nothing
else, it's less dangerous to have the bottom portion of that list off
the screen than two entire sections of "Page options" and "My options"
which you might never even see.

Also I can't find "watch this page" at all, it appears to be missing.

> * work on your browser?

Lovely in Mozilla!

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Orphan junk pictures

body:
Pierre Abbat wrote:
> On Tuesday 23 July 2002 20:04, Brion VIBBER wrote:
>>Pierre Abbat wrote:
>>>I noted some images that I think should be deleted. Would someone else
>>>like to look at them and delete them if he agrees?
>>
>>Sure. Which ones are they?
>
> Argh! There's no voting, and there appears to be no way to search the text of
> images. Just look at the orphaned images, and if the name of one looks
> enigmatic or out of place, look at the picture.

Ah, take a look at your User contributions page:
http://www.wikipedia.com/w/wiki.phtml?title=Special:Contributions&target=PierreAbbat

Lists the onces you've commented on right there.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Recent changes page

body:
Pierre Abbat wrote:
>>On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker at nupedia.com wrote:
>>>The tricky one is consolidating multiple edits to a page into one
>>>entry on the Recent Changes page, the way UseMod and Phase II did.
>>>This is a big performance hit.
>
> I prefer not consolidating, as that lets me see if there's a vandal about,
> even if most of the vandalisms have been overwritten. (I still put the IP
> address of the vandal/newbie in the comment when fixing.) If you must
> consolidate, at least don't consolidate major edits with minor ones.

I'd prefer to group edits together by page if we can figure out a way to
do it efficiently, but I do like seeing all edits in the list.

-- brion vibber (brion @ pobox.com)


body:
> You can get all the links with one simple SQL statement from
> the table 'links' except when doing a preview.
>-- Jan Hidders

Now there's an idea.  I'm generally not relying on the links
table for anything important, because I don't really consider it
part of the "real" information.  But there's no reason I can't
use it for performance.  I'll think about that.


subject: [Wikipedia-l] Recent changes page

body:
On Tuesday 23 July 2002 03:41 pm, LDC wrote:
> Along those lines, I've had enough requests to restore the "show only
> new changes" feature, and that feature can actually speed up the
> database query, so I plan to put that back.

Coolness -- much thanks!

> The tricky one is consolidating multiple edits to a page into one
> entry on the Recent Changes page, the way UseMod and Phase II did. ?
> This is a big performance hit. ?Perhaps a later redesign of the
> database would make it more reasonable, or perhaps a new
> implementation will come to mind that cures the problem, but for now
> I just don't want to burden the server with extra work for what is,
> to me, a cosmetic change that doesn't add functionality.

Please don't significantly compromise performance for cosmetics no matter
what anybody says or pressures you to do (including me). I know I offered
this idea as a feature request but my intent was to gain some of the article
edit organization that the previous software had and I hadn't a clue about
the performance hit you mention. But since you are going to reimplement "show
only new changes to articles" I don't think the grouping feature would be
worth any significant performance hit.

--mav


subject: [Wikipedia-l] A mock-up revised Cologne Blue layout: request for comments

body:
On Tuesday 23 July 2002 04:12 pm, you wrote:
> Does it:
> * preserve what you like about Cologne Blue's looks?
> * have the menu items in roughly logical and familiar positions?
> * work on your browser?
>
> Please feel free to suggest changes: this is a work in progress.
>
> Regards,
>
> Neil

I like it - very logical sidebar layout. I couldn't find the talk link but I
think that it would be best to group it along with everything currently under
"edit" and under "page options" under a single heading called "this page" or
even reuse "page options". This way 'what links here' will be grouped with
'watch links' which I think is more logical than having them separate.

I can't say much about the rest of the layout because it is badly broken in
Konqueror 2.2.2 and Mozilla 0.9.8 but this is probably my fault so don't
consider this a bug just yet.

--mav


subject: [Wikipedia-l] Recent changes page

body:
Pierre Abbat wrote:

>On Tuesday 23 July 2002 18:45, Ray Saintonge wrote:
>
>>What I really miss is not being able to use the back button to get back
>>to where I was.  It now forces a reload whenever I do so.  I've noticed
>>it most with Recent Changes, but I've also had it come up while editing
>>a page.  My habit has been to use search to go to verify a page name
>>when I'm trying to create a link from the page I'm editing.  Now when I
>>back-button from the search results I get a brand new edit page with my
>>partial edits deleted.
>>
>
>Back works fine for me in Konqueror, unless I've viewed more than ten pages
>since. What browser are you using?
>
Netscape 6


subject: [Wikipedia-l] Links to sound

body:
Pierre Abbat wrote:
> How do I make a link to a sound? I just uploaded a recording of a morepork
> (Ninox boobook) (No copyright on birdsong) and tried to link to it and it
> didn't work.

Try: [[Media:Morepork.ra|Sound of a morepork]]

Which reminds me, I should stop by the grocery store...

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Orphan junk pictures

body:
On Tuesday 23 July 2002 20:04, Brion VIBBER wrote:
> Pierre Abbat wrote:
> > I noted some images that I think should be deleted. Would someone else
> > like to look at them and delete them if he agrees?
>
> Sure. Which ones are they?

Argh! There's no voting, and there appears to be no way to search the text of
images. Just look at the orphaned images, and if the name of one looks
enigmatic or out of place, look at the picture.

phma


subject: [Wikipedia-l] Recent changes page

body:
On Tuesday 23 July 2002 19:23, Jan.Hidders wrote:
> On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker at nupedia.com wrote:
> > The tricky one is consolidating multiple edits to a page into one
> > entry on the Recent Changes page, the way UseMod and Phase II did.
> > This is a big performance hit.
>
> Do we have some measurements on this? Would it be worth the effort if I
> tried to come up with some SQL that did this for the new script?

I prefer not consolidating, as that lets me see if there's a vandal about,
even if most of the vandalisms have been overwritten. (I still put the IP
address of the vandal/newbie in the comment when fixing.) If you must
consolidate, at least don't consolidate major edits with minor ones.

phma


subject: [Wikipedia-l] Restored history

body:
I think the article histories are restored now.  Let me know if there
are still problems.


subject: [Wikipedia-l] Links to sound

body:
This fell off the mailing list:

lcrocker at nupedia.com wrote:
>>Try: [[Media:Morepork.ra|Sound of a morepork]]
>
>
> I don't think it's appropriate to put Realaudio on Wikipedia.
> The only sound format that is readily usable by freely-available
> software on multiple platforms and that is compressed for Web
> transfer is Ogg Vorbis.  Especially now that they've released
> 1.0, I see no reason to use anything else.
>
> The software already semi-enforces this by accepting ".ogg"
> files without complaint while it warns about other extensions.
>
> That's also one reason I haven't chosen to document the "media:"
> feature yet--I wanted to get some consensus about its appropriate
> use, and maybe do it differently.


subject: [Wikipedia-l] Recent changes page

body:
On Tuesday 23 July 2002 18:45, Ray Saintonge wrote:
> What I really miss is not being able to use the back button to get back
> to where I was.  It now forces a reload whenever I do so.  I've noticed
> it most with Recent Changes, but I've also had it come up while editing
> a page.  My habit has been to use search to go to verify a page name
> when I'm trying to create a link from the page I'm editing.  Now when I
> back-button from the search results I get a brand new edit page with my
> partial edits deleted.

Back works fine for me in Konqueror, unless I've viewed more than ten pages
since. What browser are you using?

phma


subject: [Wikitech-l] Serious problems with new software

body:
I uploaded africa.jpg for article on Polish Wikipedia.

Minor issue 1:
I had to jump many times before software would give me an url.
URL should be given as soon as possible.

Minor issue 2:
There was a warning that image sizes should be kept below 100k.
100k is not very big value for maps. I don't like this warning.

Minor issue 3:
Why the hell server changed case in file name
from africa.jpg to Africa.jpg ?

Very serious problem:
Software didn't tell me that file africa.jpg was already uploaded,
so I overwrited it.
(Well, it wasn't really africa.jpg what was uploaded but Africa.jpg)
Anyway article Africa on English Wikipedia has wrong image now.

Now that's something that would need at least a warning.


from_name: Jens Frank

body:
Hello,

how do we treat the Catholic Encyclopedia? (www.newadvent.org)

The articles are from a 1912 encyclopedia and should therefore be free,
but the website does claim a 1999 copyright for the online edition.

As it might be in many cases difficult to prove that someone copied from
newadvent.org, it is rather obvious if typos are preserved.

Can we use such an article as basis for copyediting?

Best regards,

    jens


subject: [Wikipedia-l] Links to sound

body:
How do I make a link to a sound? I just uploaded a recording of a morepork
(Ninox boobook) (No copyright on birdsong) and tried to link to it and it
didn't work.

phma


subject: [Wikipedia-l] Links to sound

body:
On Tuesday 23 July 2002 23:13, Brion VIBBER wrote:
> Pierre Abbat wrote:
> > How do I make a link to a sound? I just uploaded a recording of a
> > morepork (Ninox boobook) (No copyright on birdsong) and tried to link to
> > it and it didn't work.
>
> Try: [[Media:Morepork.ra|Sound of a morepork]]
>
> Which reminds me, I should stop by the grocery store...

For what? Morepork isn't edible.

phma


subject: [Wikipedia-l] Links to sound

body:
On Tuesday 23 July 2002 23:13, Brion VIBBER wrote:
> Pierre Abbat wrote:
> > How do I make a link to a sound? I just uploaded a recording of a
> > morepork (Ninox boobook) (No copyright on birdsong) and tried to link to
> > it and it didn't work.
>
> Try: [[Media:Morepork.ra|Sound of a morepork]]

Thanks. That worked.

phma


from_name: Karen AKA Kajikit

body:
It's something that I found quite handy because a) it gave you somewhere
to stow pages away for future reference, and b) it was a place to bring
them to other's attention if they really needed something done and you
didn't know enough to do it.

I also kind of miss the convenience of having a 'delete' button next to
each page on the stub list... it made the cleaning up process a lot
faster and a lot less tedious because you didn't have to keep
backtracking quite so much.

And finally I miss the list of 'reciprocal links' on the 'what links
here' pages.

But I like the list of orphaned images, and I REALLY like how blindingly
fast it is to upload a photo and to link it into an article! And now the
wikipedia keeps working all the time instead of only 12 hours a day :)

PS. I miss having my shortcut bar on the righthand side of the page too,
but I'm getting used to the change. I realised WHY I liked it there - I
use the random page button a lot and it was that much closer to the
scrollbar on the righthand side of the page so it saved a little extra
movement when I was browsing.

--

Karen AKA Kajikit

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

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

Love and huggles to all!


body:
This is a hacked version of Marian's Cologne Blue layout. I've tried to
address some of the criticisms of Cologne Blue as a default skin, whilst
preserving as much of the niceness as I can.

It is intended to
* use the browser's native font settings for text and menu link items
* show my proposed "ergonomic" layout of side menu items based on
analysis of the stats from the new server
* otherwise preserve the "clean" feel of Cologne Blue.

The principles for the menu item ordering are:

* Menu item groups are organised by the scope of what they refer to
(global, this user, this page, etc.)
* Menu groups are organised from top to bottom by frequency of overall use.

*Where there are significant differences in frequency within a group,
entries within that group are listed in order of frequency of use.
*otherwise, entries within groups are ordered alphabetically.

Notes/disclaimers:
*This is a visual mock-up only.
*The links don't work, and are generally wrong or nonsense.
*This was hacked together in Mozilla's Composer module, which is a poor
tool for editing complex HTML.
*It still uses tables for layout.
*The HTML is tag soup, and probably won't validate.
*I've only looked at this layout in Mozilla 1.1beta and Internet
Explorer  5.5.

If anone likes this, I can extract the design, and write some valid HTML
+ CSS that can be used as a template for a new server skin.

Please let me know if you like the layout.

Does it:
* preserve what you like about Cologne Blue's looks?
* have the menu items in roughly logical and familiar positions?
* work on your browser?

Please feel free to suggest changes: this is a work in progress.

Regards,

Neil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020723/81581e8c/attachment.html


subject: [Wikipedia-l] Genome: encyclopedia article from Wikipedia

body:
  Oops. This version should link correctly to Marian's original logo
image on her server.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020723/7f71672c/attachment.html


body:
Brion VIBBER wrote:

> Lars Aronsson wrote:
>
>>>>>> The "Astronomer" page contains an extraordinary number of links,
>>>>>> mostly to "year" pages.  Each link on a page requires a database
>>>>>> lookup (a quick one, but still a lookup).  "Current events" had
>>>>>
>>
>> If this is true, I think the code should be rewritten to use an in-core
>> hash table that contains (as keys) the names of all existing pages.  It
>> would only be used to determine whether a [[link]] should be
>> underlined or
>> a ?-link.  This in-core data structures would not be shared between
>> threads of a PHP application (at least not if load balancing over
>> multiple
>> hosts), but it could be recreated from the database (select name from
>> cur)
>> every few minutes or so (and whenever a reload or post is served).
>> Pages
>> that are created between these intervals will falsely have ?-links for a
>> short while, big deal.
>
>
> Hmm, maybe.
>
> >  Or hits would be read from the hash, but misses
>
>> would force a read from the database.  Avoiding a roundtrip down to the
>> database sounds like a great saving to me.
>
>
> As Neil suggested, couldn't these checks be done in just one big query
> rather than a lot of separate ones? ie, something like:
>
> SELECT cur_title
>   FROM cur
>  WHERE cur_title
>     IN ('Scientist','Research','Astronomy','Astrophysics',[...])
>
> or would that just get more complicated?
>
I agree. Roll-your-own hash tables are hard to scale, and a bad idea
unless nothing else works. Keeping everything SQL will make things much
easier to go to a 3-tier Wikipedia (with a separate database
server/server cluster  and multiple page servers) at a later date.

I _think_ that the big-query approach should be _lots_ faster: for say,
300 links, it will do only one lot of query-round-trip and parsing
overhead, instead of 300 lots.

Neil


subject: [lcrocker@nupedia.com: Re: [Wikitech-l] Serious problems with new software]

body:
lcrocker at nupedia.com accidentally selected reply instead of group
reply. Here is his message.

----- Forwarded message from lcrocker at nupedia.com -----

To:	Tomasz Wegrzanowski <taw at users.sourceforge.net>
Subject: Re: [Wikitech-l] Serious problems with new software
From:	lcrocker at nupedia.com

>Minor issue 1:
>I had to jump many times before software would give me an url.
>URL should be given as soon as possible.

That's a reasonable idea.

>Minor issue 2:
>There was a warning that image sizes should be kept below 100k.
>100k is not very big value for maps. I don't like this warning.

I plan to supplement that with a client-side check, but I think
100k is about right.  We shouldn't be using images that big
except in rare cases, and it's not a hard limit, just a strong
suggestion.  Any JPG or PNG larger than that is probably either
encoded incorrectly or is too large for an article.

>Minor issue 3:
>Why the hell server changed case in file name
>from africa.jpg to Africa.jpg ?

This won't change.  In the new software, article titles, user
names, and uploaded files all have the same naming rules, mainly
because each user and file also creates an article.  But just
like links to articles, the link [[image:africa.jpg]] will find
the image "Africa.jpg" (and again just like articles, the other
letters are case-sensitive).  One consistent set of rules.

>Very serious problem:
>Software didn't tell me that file africa.jpg was already uploaded,
>so I overwrited it.
>(Well, it wasn't really africa.jpg what was uploaded but Africa.jpg)
>Anyway article Africa on English Wikipedia has wrong image now.

Two things: (1) there's a bug that's making it not show the old
version correctly; otherwise you'd be able to reupload with a new
name and restore the old one.  The old version is still here--it
didn't get deleted or anything, it's just that the bug is hiding it.
I plan to fix this right away.  (2) This is a problem inherent in
the nature of HTTP.  I can't do anything at all with an image until
after it's all been uploaded.  I don't even get to know the name
before it's already here.  So I really have little choice but to put
it where it goes, saving any existing ones as previous versions.
If, after the upload, it is found that it doesn't follow some rule,
I give a warning and give the user the option to back out or to
ignore the warning.  "Overwrote and earlier version" isn't one of the
warning rules, because that's a normal function.  But maybe it should
be, and those who know what they are doing can choose to ignore the
warning an go ahead.

----- End forwarded message -----


subject: [Wikipedia-l] Recent changes page

body:
lcrocker at nupedia.com wrote:

>>>The tricky one is consolidating multiple edits to a page into
>>>one entry on the Recent Changes page, the way UseMod and Phase II
>>>did.  This is a big performance hit.
>>>
>>>
>
>
>
>>Do we have some measurements on this? Would it be worth the effort
>>if I tried to come up with some SQL that did this for the new
>>script?
>>
>>
>
>I have only compared the actual query used in Phase II (with that
>ugly LEFT OUTER JOIN and GROUP BY) with my present query (actually
>two queries, because MySQL doesn't have UNION yet).  If you want
>to try other queries on the new database schema that might work with
>comparable speed to the present one, I can try those out on my server
>and time them using a version of Neil's bot.
>
>
>
...and I actually _prefer_ the presentation of the new software, without
the filtering.

Neil


subject: [Wikipedia-l] Recent changes page

in_reply_to: <200207232148.g6NLmCJ23896@ross.bomis.com>; from lcrocker@nupedia.com on Tue, Jul 23, 2002 at 02:48:12PM -0700

body:
On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker at nupedia.com wrote:
>
> The tricky one is consolidating multiple edits to a page into one
> entry on the Recent Changes page, the way UseMod and Phase II did.
> This is a big performance hit.

Do we have some measurements on this? Would it be worth the effort if I
tried to come up with some SQL that did this for the new script?

-- Jan Hidders


in_reply_to: <200207232311.g6NNBEL02217@ross.bomis.com>; from lcrocker@nupedia.com on Tue, Jul 23, 2002 at 04:11:14PM -0700

body:
On Tue, Jul 23, 2002 at 04:11:14PM -0700, lcrocker at nupedia.com wrote:
>
> > As Neil suggested, couldn't these checks be done in just one big
> > query rather than a lot of separate ones? ie, something like:
> >
> >SELECT cur_title
> >   FROM cur
> >  WHERE cur_title
> >     IN ('Scientist','Research','Astronomy','Astrophysics',[...])
> >
> > or would that just get more complicated?
>
> It would actually be more like:
>
>  SELECT cur_id,cur_namespace,cur_title FROM cur WHERE
>  (cur_namespace=0 AND cur_title='Scientist') OR
>  (cur_namespace=0 AND cur_title='Research') OR
>  (cur_namespace=1 AND cur_title='Scientist')
>
> etc.  I'm not sure how well that would optimize.

You can get all the links with one simple SQL statement from the table
'links' except when doing a preview.

-- Jan Hidders


subject: [Wikipedia-l] Recent changes page

in_reply_to: <20020724002837.IFSL19639.sccrmhc02.attbi.com@there>; from maveric149@yahoo.com on Tue, Jul 23, 2002 at 05:24:58PM -0700

body:
On Tue, Jul 23, 2002 at 05:24:58PM -0700, Daniel Mayer wrote:
>
> [...] But since you are going to
> reimplement "show only new changes to articles" I don't think the grouping
> feature would be worth any significant performance hit.

My estimate would be that even if I tried really hard it would still be 3 to
5 times slower than what we have now. I personally don't mind seeing the
edits ungrouped as long as I have an option to hide the minor edits. So
unless a lot of other people start asking for grouping I don't think it
would be useful for me to think about implementing it.

-- Jan Hidders


from_name: Stephen Gilbert

subject: [Wikipedia-l] Years in review and the need for editorial judgement

body:
--- Lars Aronsson <lars at aronsson.se> wrote:
> On Fri, 28 Jun 2002, Jimmy Wales wrote:
> > One of our "discoveries" is that people of very
> diverse opinions can
> > write encyclopedia articles together, using NPOV
> as a guideline to
> > mediate conflict.  It works remarkably well.  It
> would not work for
> > poetry, for political commentary, for fiction,
> etc.
>
> Is this a discovery that is unique to Wikipedia?
>
> Couldn't the same discovery be expressed: "it is
> possible (no matter who
> does it) to write articles (in an encyclopedia or
> newspaper), using NPOV
> as a guideline, so that no reader would care to
> protest against the
> wording of the text".
>
> I think that this is the same approach that has been
> used by every
> encyclopedia and newspaper editor, ever.  Only they
> might have called it
> "factualism and objectivity" rather than NPOV.
>
> Or is this wrong?

Such articles are usually written by one person and
edited by another. The editor is then roundly cursed
by the author.

Wikipedia articles often have no individual author,
but are worked on by people of (sometimes wildly)
differing views and opinions. I think what Jimmy is
getting at is that a project like this *can* work
without breaking down into flame wars. Since everyone
who has heard of the project has raised the flame war
criticism, it certainly *seems* like a discovery.

-- Stephen Gilbert

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


subject: [Wikipedia-l] Huge apologies!!!

body:
And apologiesfrom the rest of the list for missing
your first mention of the problem. :)

- Stephen G.

--- Julie Hofmann Kemp <juleskemp at yahoo.com> wrote:
>
> D'oh --
>
> Looked at the history page in more detail and saw
> the improved
> functionality.  Please ignore, disregard, and accept
> my humblest
> apologies for the last letter!
>
> Jules
>
>

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


from_name: Jimmy Wales

in_reply_to: <3D3DD0BC.4080606@telus.net>; from saintonge@telus.net on Tue, Jul 23, 2002 at 02:55:08PM -0700

body:
I agree with Ray.  I'm not uncomfortable with using this as a source.

However, it would also be nice to drop them a note asking permission,
and pointing out to them (kindly, in a friendly manner, of course!)
the tenuousness of their copyright claim.  If they want to make a stink
about it, this will give them the opportunity to do so now, before we've
used much of this material.  If they don't care, then possibly we'll get
an email from them saying that it's fine anyway, thus eliminating any
worries.

Ray Saintonge wrote:
> I've looked at the site which Fred referenced, and it includes the
> following: "Knight chose the 1913 15-volume set because the later
> editions are still under copyright protection."  Clearly Knight was
> aware of the copyright issues when he was making his effort.  Copyright
> depends on contributing some measure of original work.  Leaving scanning
> bugs or even intentional bugs to trick the unwary is not original work,
> nor is cleaning them up.
>
> The frames and other environment written and supplied by New Advent are
> of course copyrightable,  Simply putting a blanket copyright notice on
> something means to me nothing more than "Copyright to the extent that it
> can be copyright".  No person uploading such a page can be reasonably
> expected to detail which parts of a page are copyright and which are
> not.  For the reader, he has to use his own common sense in making his
> determination.
>
> Eclecticology
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Recent changes page

body:
Stephen Gilbert wrote:
> It used to be an option on the user preferences page.
> That's what I would like to see.

Stephen's talking here about the ability to see all the edits, or to see them
consolidated by article.

I, too, prefer to see this as an option on the user preferences page.  Both
are useful, and I've used both, and I used to switch back and forth pretty
often depending on what I was trying to do.

Efficiency, of course, is crucial, more important than most other features, because
all the fancy features in the world won't create joy for humankind if the server is
so bogged down that we can't even use the site.  :-(

--Jimbo


subject: [Wikipedia-l] Links to sound

body:
Brion VIBBER wrote:
> I don't think it's appropriate to put Realaudio on Wikipedia.
> The only sound format that is readily usable by freely-available
> software on multiple platforms and that is compressed for Web
> transfer is Ogg Vorbis.  Especially now that they've released
> 1.0, I see no reason to use anything else.

Can ordinary Windows users, i.e. users who aren't into music and file
sharing and the like, use Ogg Vorbis with relative ease?

For example, could my mom, running Windows 2000 or Windows XP, click
on an Ogg Vorbis sound and end up happy?

I'm totally in agreement with pushing free software and open standards
wherever we can.  But I think we at least have to use stuff that Windows
people can use.

--Jimbo


subject: [Wikipedia-l] Recent changes page

body:
--- lcrocker at nupedia.com wrote:
> The tricky one is consolidating multiple edits to a
> page into one
> entry on the Recent Changes page, the way UseMod and
> Phase II did.
> This is a big performance hit.  Perhaps a later
> redesign of the
> database would make it more reasonable, or perhaps a
> new
> implementation will come to mind that cures the
> problem, but for now
> I just don't want to burden the server with extra
> work for what is,
> to me, a cosmetic change that doesn't add
> functionality.

It's not a cosmetic change for me. Having the changes
on the same article consolidated makes Recent Changes
usable. The current setup makes it impossible for me
to quickly scan the page for changes I might be
interested in; my eyes trip over the seventeen changes
in a row made to one particular article.

-- Stephen Gilbert

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


subject: [Wikipedia-l] Recent changes page

body:
--- Pierre Abbat <phma at webjockey.net> wrote:
> On Tuesday 23 July 2002 19:23, Jan.Hidders wrote:
> > On Tue, Jul 23, 2002 at 02:48:12PM -0700,
> lcrocker at nupedia.com wrote:
> > > The tricky one is consolidating multiple edits
> to a page into one
> > > entry on the Recent Changes page, the way UseMod
> and Phase II did.
> > > This is a big performance hit.
> >
> > Do we have some measurements on this? Would it be
> worth the effort if I
> > tried to come up with some SQL that did this for
> the new script?
>
> I prefer not consolidating, as that lets me see if
> there's a vandal about,
> even if most of the vandalisms have been
> overwritten. (I still put the IP
> address of the vandal/newbie in the comment when
> fixing.) If you must
> consolidate, at least don't consolidate major edits
> with minor ones.

It used to be an option on the user preferences page.
That's what I would like to see.

-- Stephen G.

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


subject: [Wikipedia-l] Auto-save in your browser editor

body:
--- Lars Aronsson <lars at aronsson.se> wrote:
>
> I'm using my normal web browser to edit Wikipedia
> articles, and
> it wasn't really designed to be an editor.  Several
> times I have
> lost my work because either the browser crashed or
> the website
> wasn't responding when I was done and wanted to save
> my article.
> Real text editors or word processors have an
> auto-save function
> that allows me to recover and continue work after a
> crash, so
> why shouldn't a web browser?  Of course I could
> write my article
> in a real text editor, and submit it using
> cut-n-paste to the
> browser, but I'm too lazy to switch back and forth.
>
> If you know a web browser that supports offline
> writing or has an
> auto-save function, please enlighten me.  Do you use
> Emacs Wiki?
>
> If you're using the free software Mozilla 1.x
> browser, you might
> be interested in this new bug report/feature request
> by me,
> http://bugzilla.mozilla.org/show_bug.cgi?id=158258

Lars,

You might try poking around EmacsWiki
(http://www.emacswiki.org/cgi-bin/wiki.pl?SiteMap). If
anyone knows how to set up what you want, it would be
them.

If you do get something working, be sure to share the
setup with me. ;-)

-- Stephen Gilbert

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


subject: [Wikipedia-l] Links to sound

in_reply_to: <200207241548.g6OFmmW16886@ross.bomis.com>; from lcrocker@nupedia.com on Wed, Jul 24, 2002 at 08:48:48AM -0700

body:
lcrocker at nupedia.com wrote:
> But the big benefit is that unlike RA, she won't have to install
> software that takes over her machine, sends her spam, and was
> written by a company that has proven it can't be trusted.  As
> much as people complain about MS, Real.com is ten times worse.
> I personally refuse to use any software from them--I value my
> computer, and won't risk it.  So I simply can't use RA at all.
> It's a one-company format, so if I don't use their software,
> there's no alternative.

I think this is a good argument for avoiding RealAudio completely.

> I'm not quite as opposed to MP3--there are some patent problems,
> but at least it's not a one-company format and there are players
> for all platforms, and players are more likely to support it
> without pugins.  But most software supporting MP3 is also
> supporting OGG these days or has promised to.

Right, MP3 is pretty ubiquitous.

--Jimbo


from_name: lcrocker at nupedia.com

subject: [Wikipedia-l] Links to sound

body:
>> I don't think it's appropriate to put Realaudio on Wikipedia.
>> The only sound format that is readily usable by freely-available
>> software on multiple platforms and that is compressed for Web
>> transfer is Ogg Vorbis.  Especially now that they've released
>> 1.0, I see no reason to use anything else.

> Can ordinary Windows users, i.e. users who aren't into music and
> file sharing and the like, use Ogg Vorbis with relative ease?
> For example, could my mom, running Windows 2000 or Windows XP,
> click on an Ogg Vorbis sound and end up happy?

She probably doesn't have the software installed already, but it's
not that difficult.  Some players like Sonique come with OGG support
out-of-the-box; others like WinAmp require you to install a plugin.
It's likely that Mozilla will add native support.  I.E. will
likely always launch the external player.

But the big benefit is that unlike RA, she won't have to install
software that takes over her machine, sends her spam, and was
written by a company that has proven it can't be trusted.  As
much as people complain about MS, Real.com is ten times worse.
I personally refuse to use any software from them--I value my
computer, and won't risk it.  So I simply can't use RA at all.
It's a one-company format, so if I don't use their software,
there's no alternative.

I'm not quite as opposed to MP3--there are some patent problems,
but at least it's not a one-company format and there are players
for all platforms, and players are more likely to support it
without pugins.  But most software supporting MP3 is also
supporting OGG these days or has promised to.


body:
On Wed, 24 Jul 2002, Neil Harris wrote:
> I agree. Roll-your-own hash tables are hard to scale, and a bad idea

Hash tables or associative arrays are built into Perl, and I guess into
PHP as well.

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/  http://elektrosmog.nu/  http://susning.nu/


from_name: Brion VIBBER

subject: [Wikipedia-l] Links to sound

body:
lcrocker at nupedia.com wrote:
 >Jimmy Wales wrote:
>>Can ordinary Windows users, i.e. users who aren't into music and
>>file sharing and the like, use Ogg Vorbis with relative ease?
>>For example, could my mom, running Windows 2000 or Windows XP,
>>click on an Ogg Vorbis sound and end up happy?
>
> She probably doesn't have the software installed already, but it's
> not that difficult.  Some players like Sonique come with OGG support
> out-of-the-box; others like WinAmp require you to install a plugin.
> It's likely that Mozilla will add native support.  I.E. will
> likely always launch the external player.

WinAmp currently includes the OGG Vorbis plugin in the default install
package. (Unless you install the "lite" version, which doesn't include
it... much to your own surprise, as there's no mention of ogg in the
list of features that the various download options include/don't include.)

Basically, next to any Ogg file you'd want to include a link to a page
explaining where to download an ogg player for your OS.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Image link to larger image

body:
Pierre Abbat wrote:
> I just added the picture to [[Cornish Rex]] but it's not behaving right. The
> code I used is
>

> [[Image:CornishRexRopey-small.jpg|Image:CornishRexRopey.jpg]]
>

> which should show one image, and link to the other. Instead it shows one
> image, and links to the image page of the same one. How is it done? There's
> no explanation on editing help on how to do this.

The simplest way is just to put the big image into the image page for
the thumbnail.

 > Also the text should flow
> around the image, and it doesn't.

'align="right"' makes tables and images float, but not other things like
paragraphs and div tags; it just changes the text alignment inside that
section. This will do the job you want:

-- brion vibber (brion @ pobox.com)


body:
I'm using my normal web browser to edit Wikipedia articles, and
it wasn't really designed to be an editor.  Several times I have
lost my work because either the browser crashed or the website
wasn't responding when I was done and wanted to save my article.
Real text editors or word processors have an auto-save function
that allows me to recover and continue work after a crash, so
why shouldn't a web browser?  Of course I could write my article
in a real text editor, and submit it using cut-n-paste to the
browser, but I'm too lazy to switch back and forth.

If you know a web browser that supports offline writing or has an
auto-save function, please enlighten me.  Do you use Emacs Wiki?

If you're using the free software Mozilla 1.x browser, you might
be interested in this new bug report/feature request by me,
http://bugzilla.mozilla.org/show_bug.cgi?id=158258

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  http://aronsson.se/  http://elektrosmog.nu/  http://susning.nu/


subject: [Intlwiki-l] Re: [Wikitech-l] Re: New server online?

in_reply_to: <3D3F09CC.5050700@pobox.com>; from brion@pobox.com on Wed, Jul 24, 2002 at 12:10:52PM -0800

body:
Brion VIBBER wrote:
> Yeah, you're probably right. I just don't want another period of
> "testing" with an indefinite end...
>
> I'll get to work on adapting the Esperanto and French message translations.

The cool thing is that now the developers have access to the physical
machine where wikipedia runs, including root access in limited cases.
So I think that we're going to be much closer to the ideal of "release
early, release often" without me as the bottleneck in the process.

--Jimbo


subject: [Wikipedia-l] Restored history

in_reply_to: <3D3F0BC0.9090603@pobox.com>; from brion@pobox.com on Wed, Jul 24, 2002 at 12:19:12PM -0800

body:
I still have the old UseMod files around.  Maybe someday, we'll open it back up
some year on Brigadoon day.

Brion VIBBER wrote:

> lcrocker at nupedia.com wrote:
> >>Which reminds me: do we still want to restore the edit histories
> >>from the usemod wiki days?
> >
> > That can certainly be done without much difficulty.  Jimbo, do you
> > have the old UseMod files still around somewhere?
>
> (I sure hope so!)
>
> It shouldn't be too hard to adapt the old convertWiki2SQL.php to talk to
> the new database format; might want to double-check how it handles pages
> that don't exist anymore, though. (Deletions, administrative renames
> performed since January)
>
> -- brion vibber (brion @ pobox.com)
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Pierre Abbat

subject: [Wikipedia-l] Mh hammer |1

body:
Someone recently uploaded that picture of two tents (or the same tent, with
and without a cover) and has not used it in an article. Should it be deleted?

phma


subject: [Wikipedia-l] Restored history

body:
lcrocker at nupedia.com wrote:
> I think the article histories are restored now.  Let me know if there
> are still problems.

Which reminds me: do we still want to restore the edit histories from
the usemod wiki days?

-- brion vibber (brion @ pobox.com)


body:
lcrocker at nupedia.com wrote:
>>Another possibility is waiting on _everything_ for direct
>>adaptation to phase III, but that's just going to annoy a lot of
>>people who've been waiting months for an upgrade to phase II and
>>put a lot of effort into providing message translation files.
>
> But there's a great benefit of having less overall work to do
> (even for the translators in the long run) and ending up with a
> better product.  The work involved in internationalizing the
> Phase III software is minimal: Magnus produced a German version
> in about two days (it's running now at
> http://www.piclab.com/wikitest/wiki.phtml if you want to look).
> If there are existing Phase II translations, it would not be hard
> to use those as a starting point for the Phase III translation
> to shave a little more time off the work.
>
> I'm a big fan of skipping intermediate steps whenever possible.

Yeah, you're probably right. I just don't want another period of
"testing" with an indefinite end...

I'll get to work on adapting the Esperanto and French message translations.

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Restored history

body:
lcrocker at nupedia.com wrote:
>>Which reminds me: do we still want to restore the edit histories
>>from the usemod wiki days?
>
> That can certainly be done without much difficulty.  Jimbo, do you
> have the old UseMod files still around somewhere?

(I sure hope so!)

It shouldn't be too hard to adapt the old convertWiki2SQL.php to talk to
the new database format; might want to double-check how it handles pages
that don't exist anymore, though. (Deletions, administrative renames
performed since January)

-- brion vibber (brion @ pobox.com)


body:
I just added the picture to [[Cornish Rex]] but it's not behaving right. The
code I used is
<div align="right">
[[Image:CornishRexRopey-small.jpg|Image:CornishRexRopey.jpg]]
</div>
which should show one image, and link to the other. Instead it shows one
image, and links to the image page of the same one. How is it done? There's
no explanation on editing help on how to do this. Also the text should flow
around the image, and it doesn't.

phma


subject:
[Wikipedia-l] [Fwd: [ wikipedia-Bugs-584804 ] URL followed by
 punctuation->broken link]

body:
Brion VIBBER wrote:
> The old software knew that 99.9% of the time humans don't _really_ mean
> it when they put a comma, period, or other such item of punctuation
> immediately after a URL, but that these are rather intended as, well,
> punctuation.
>
> The new phase III software trusts us more; URLs that are followed
> immediately by punctuation (period, comma, paren, semicolon, etc) now
> include this punctuation in the hyperlink, which leads to a lot of
> broken external links where URLs are put casually into text,
> particularly on talk pages.
>
> Bug or feature? You decide!
[...]
 > You can respond by visiting:
 >http://sourceforge.net/tracker/?func=detail&atid=411192&aid=584804&group_id=34373

So far the votes are tied 2-2:

Crop final punctuation from links: Brion, Tony
Include final punctuation in links: Lee, Jan

-- brion vibber (brion @ pobox.com)