> 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.
>>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.
> 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.
> 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.
lcrocker(a)nupedia.com accidentally selected reply instead of group
reply. Here is his message.
----- Forwarded message from lcrocker(a)nupedia.com -----
To: Tomasz Wegrzanowski <taw(a)users.sourceforge.net>
Subject: Re: [Wikitech-l] Serious problems with new software
From: lcrocker(a)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 -----
> 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.
> 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.
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.
This is feedback.
----- Forwarded message from "steven l. rubenstein" <rubenste(a)ohiou.edu> -----
From: "steven l. rubenstein" <rubenste(a)ohiou.edu>
Date: Tue, 23 Jul 2002 11:54:08 -0400
To: Jimmy Wales <jwales(a)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 -----
----- Forwarded message from Neil Harris <neil.harris(a)mediachannel.ltd.uk> -----
From: Neil Harris <neil.harris(a)mediachannel.ltd.uk>
Date: Tue, 23 Jul 2002 09:21:29 +0100
To: Jimmy Wales <jwales(a)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(a)mediachannel.ltd.uk>
Date: Mon, 22 Jul 2002 23:43:49 +0100
To: lcrocker(a)nupedia.com, wikitech-l(a)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 -----