L.S.,
As the subject says these columns have now been removed from the database
schema and all the code that used them has been replaced by code that uses
the new (un)linked tables. This completes a major change in the database
scheme, so I will now wait until Jimbo has installed the latest CVS version,
and see what bugs/problems appear.
There is still a lot I can do in terms of speeding certain pages up, such as
the short-pages page, the long-pages page, the orphans page and the
most-wanted page. But for this I would again have to extend the database
scheme, so I first suggest we freeze the scheme and after the bugs have been
ironed out, I suggest we determine what would be the special page we want to
speed-up first.
-- Jan Hidders
L.S.,
The code donated by Dan Keshet has been integrated. You can find it in the
Quick bar under the name ''watch page links". Not a very good name, but I
couldn't think of a better one that would fit.
I have also optimzed the SQL for the what-links-here page for the new
linked/unlinked tables.
Finally, I added some code to the watchlist page to deal with pages on the
watch-list that no longer exist. A remaining problem is that users cannot
delete such pages from their watch list.
-- Jan Hidders
Hi Wikitechers,
I've had this itch for a while, and I've finally scratched it: being
able to display the recent changes of all pages that are linked to
from a particular page. You can see the function I wrote at work
here:
http://www.projectmosaic.org/pwiki/wiki.phtml?title=Main_Page&action=recent…
You could use this feature to get an overview of the activity in a
given section (say, "Mathematics") without having to load/unload the
entire section into your watch list. Alternately, you could use this
to build group or public watch lists, the wiki way.
Would you like this feature in the php script? Should I send someone
the diff?
-- Dan Keshet
PS: (Please to: or cc: me; I'm not on the list.)
PPS: Great job everybody who's worked on the script. Wikipedia's
looking really great. :)
Highly esteemed colleagues, :-)
I've optimzed the database access of the lonely-pages-page and committed it
to CVS. You can now actually wait for the result to appear. :-)
-- Jan Hidders
----- Original Message -----
From: "Magnus Manske" <Magnus.Manske(a)epost.de>
To: "Jan Hidders" <hidders(a)uia.ua.ac.be>
Sent: Friday, February 22, 2002 3:48 PM
Subject: RE: [Wikitech-l] recent changes linked
> I checked the online example, and it would be great to have such a thing
in
> the sidebar!
>
> Jan, as you are working on the link table, could you get the code and try
to
> integrate it, if you have time?
But of course. Send me the code and I'll adapt it and add it to the sidebar.
-- Jan Hidders
I just committed some changes so each namespace can get its own background
color. The colors are stored in wikiTextEn.php as an array.
For the sake of our eyesight, please, help me change the colors to something
nice but distinguishable!
Magnus
Dear sirs :)
I just committed a change enabling sysops to block IPs for edit. This was a
request from Larry.
Sysops (and only those!) will have a "Block this IP" link next to each IP on
the history page of an article. That seemed like the logical place to put
it, since IP blocking will result from some form of editing.
NOTE: Currently, there is no way to block a logged-in user that way; not a
pressing issue at the time, though.
That blocked IP will go to "Wikipedia:Blocked IPs".
NOTE: That page should be protected, otherwise a troll could just go there
and remove his IP from the list!
NOTE: Currently, the only way to set an IP free again is to manually delete
the line on "Wikipedia:Blocked IPs". There's a timestamp so we can implement
time-based removal later.
Even blocked IPs can go to the edit page, but on pressing "Save", blocked
IPs will get a message ("Your IP has been blocked..."). This will even work
if the troll signs up with a user name after getting the block as an IP.
Sneaky, eh? ;)
Let's get Larry his sysop rights back ASAP!
Magnus
(I set the reply-to for wikitech-l(a)nupedia.com, since that's the appropriate
place for technical discussions.)
Tomasz Wegrzanowski wrote:
> Easiest distributed editing architecture:
> There is main server and other servers
>
> Every server handle read request itself.
> On all servers 'edit this page' links point to main server.
> Main server sends all changes to all subscribed servers,
> so they are always up to date.
>
> This won't require many changes in design, while
> may allow reasonable distribution of load.
But, there's no problem with load right now, and I stand ready to
supply whatever hardware we need here. In this way, we don't have to
deal with complex distribution schemes.
--Jimbo
On mer, 2002-02-20 at 11:33, lcrocker(a)nupedia.com wrote:
> No! No! The text stored in the database is _always_ single-byte
> ISO-8859-1, no exceptions, even for the foreign wikis. Some of
> those ISO-8859-1 characters may spell out HTML entity references
> to Unicode characters outside the set, but the database should not
> know or care about that.
I'm sorry you feel that way, but that is in fact NOT TRUE. Please take a
look at the non-English non-ISO-8859-1 wikipedias sometime.
Hundreds of pages, with correct charset headers:
ISO-8859-2:
http://pl.wikipedia.com/
UTF-8 with a custom conversion function for certain character
sequences:
http://eo.wikipedia.com/
Stubs:
CP-1251
http://ru.wikipedia.com/
Shift-JIS
http://ja.wikipedia.com/
GB-2312 with a few character references thrown in:
http://zh.wikipedia.com/
Not sure which encodings, but certainly not ISO-8859-1:
http://ar.wikipedia.com/http://he.wikipedia.com/
Now, if you honestly think that people are going to edit text that
consists *entirely* of HTML character entity references, you're
obviously not concerned about anything like "ease of use".
On top of which, the consensus seems to be to not allow &s (and thus
character entities) into page titles, which would effectively require
all page titles to be in ASCIIized roman characters. Can you imagine
this being acceptable on, say, the Chinese wiki if anyone actually used
it?
Gee, maybe someone *would* use it if they could use an appropriate
character set for their language!
> This policy might have to be changed for the Asian wikis if something
> like shift-JIS is universal enough and dealing with HTML entities
> problematic enough to make working with it difficult,
The mind boggles that you might imagine the situation to be otherwise.
> but in that
> case we'll still standardize on one and only one internal character
> representation for that particular wiki. For all others, that
> internal representation (and also the encoding which is served via
> HTTP) is ISO-8859-1.
Bullshit. Ask the Poles if they'd like to convert their wikipedia to
ISO-8859-1 with HTML character entities.
> If you need to "uppercase" words in titles (as our consensus on
> canonization of titles specifies), go ahead and hard-code the
> function to deal with ISO-8859-1.
Gee, that would be great if such a function would do anything at all for
anything other than ISO-8859-1 characters. But, somehow I can't quite
see a function hardcoded to deal with ISO-8859-1 being the slightest bit
useful for anything else.
-- brion vibber (brion @ pobox.com)
> You Wrote:
> >I've noticed that the traditional locale-based case conversion
> functions
> >(ucfirst(), strtolower(), etc) aren't too reliable for anything but
> >English. Even when they do work, it's very dependant on the system
> >configuaration, and thus isn't really transparently portable.
> >
> >So, I've added new case conversion functions ucfirstIntl(),
> >strtoupperIntl(), and strtolowerIntl() which can more or less
> properly
> >convert cases in a system-independent manner. For single-byte
> character
> >encodings this is very simple, based on the PHP strtr() function;
> just
> >define strings $wikiUpperChars containing all the uppercase
> characters
> >and $wikiLowerChars containing all the lowercase chars. (See example
> for
> >iso-8859-1 in wikiTextEn.php)
> >
> >For multibyte character sets it's a little more complex, using the
> same
> >function in an array mode that associates byte sequences. Most
> multibyte
> >character sets are for Asian languages which don't have a case
> >distinction, so it's not likely to come up often except for those
> using
> >UTF-8. I've included conversion arrays for UTF-8 in utf8Case.php
> which
> >should cover just about everything, so any future 'pedias that may
> use
> >UTF-8 need just include that (as does wikiTextEo.php).
> >
> >Also, it should be possible to extend ucfirstIntl() a bit to allow
> for
> >multiple-character first letter sequences (for instance treating ij-
> >IJ
> >as one letter, which I believe is the officially correct behavior for
> >Dutch).
> >
> >-- brion vibber (brion @ pobox.com)
> >
> >_______________________________________________
> >Wikitech-l mailing list
> >Wikitech-l(a)ross.bomis.com
> >http://ross.bomis.com/mailman/listinfo/wikitech-l
> >0
I've noticed that the traditional locale-based case conversion functions
(ucfirst(), strtolower(), etc) aren't too reliable for anything but
English. Even when they do work, it's very dependant on the system
configuaration, and thus isn't really transparently portable.
So, I've added new case conversion functions ucfirstIntl(),
strtoupperIntl(), and strtolowerIntl() which can more or less properly
convert cases in a system-independent manner. For single-byte character
encodings this is very simple, based on the PHP strtr() function; just
define strings $wikiUpperChars containing all the uppercase characters
and $wikiLowerChars containing all the lowercase chars. (See example for
iso-8859-1 in wikiTextEn.php)
For multibyte character sets it's a little more complex, using the same
function in an array mode that associates byte sequences. Most multibyte
character sets are for Asian languages which don't have a case
distinction, so it's not likely to come up often except for those using
UTF-8. I've included conversion arrays for UTF-8 in utf8Case.php which
should cover just about everything, so any future 'pedias that may use
UTF-8 need just include that (as does wikiTextEo.php).
Also, it should be possible to extend ucfirstIntl() a bit to allow for
multiple-character first letter sequences (for instance treating ij->IJ
as one letter, which I believe is the officially correct behavior for
Dutch).
-- brion vibber (brion @ pobox.com)