I've broken the user interface functions for the edit page out of
Article.php into a separate EditPage class in (surprisingly)
EditPage.php. Minimal changes so far.
-- brion vibber (brion @ pobox.com)
A few messages back (on WikiEN-l) I sent some accented
characters that are found in Unicode/UTF-n but not in Latin-1
using Yahoo! Mail. These apparently appeared on Timwi's client
as HTML entities, but on my client they displayed properly.
Is this just a bug with Y!Mail?
Most other special characters cannot be easily displayed
in my browser. I get the digested form, and some messages
use different character sets than others - and Mozilla
autoguesses the character set as a third, in most cases.
In one digest with links to the Hindi Wikipedia and a UTF-8
apostrophe, the default character set was Chinese Simplified.
Is there something the software can do about this? We can't
assume everyone'll send in UTF-8 (which would have been nice),
and for those like me who receive digests, it's impossible to
get the browser to display two character sets on the same
page. Could the digesting software automatically convert all
e-mails to the same character set, preferably UTF-8?
--[[User:Geoffrey|]] Thomas
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
> Running the dump slows things down a lot.
> Partly because compressing the dump is expensive,
> and there's no disk space to keep an uncompressed dump.
Brion you mentioned disk space shortage before.
A 120GB Western Digital, IDE, U100, 7200rpm, 8MB cache disk is 135 euro
($ 145) here in Amsterdam. Right now about 15 *un*compressed backups of
all databases could be stored on it. So it will probably solve this
issue for another year. Compressing once a week (as is done now) for
download purposes would suffice.
When there are two hot synched servers one could be brought offline
daily to do the backup. The slower response times during that short
period, if properly announced on the site, are a minor issue compared to
major data loss.
Erik Zachte
Hello,
Has anyone thought of setting up a RSS feed for Wikipedia? I know that
there was one back in the early days but there doesn't seem to be one
now... (and from memory the old one wasn't an official feed).
How much work would be involved in setting up a feed with some daily
selected articles and a random topic?
Tobin Richard.
In Utf8Case.php we have this huge ~1450 item associative array (
$wikiUpperChars ). Is this really necessary? Is there a way we could
avoid having to load such a huge array into memory for every pageview by
a user in a language that needs it? This seems like it could pose to be
a problem in the future.. maybe keeping it in shared memory so we dont
have to go regenerating it and having all these instances of it for
every page view? I guess at the time its OK but as UTF8 wiki's gain more
and more popularity this might become a problem. Or am i completely wrong?
I'm noticing in setup.php that we are include()ing a whole lot of
stuff. Some of this stuff might never even be used, so why are we
include()ing it? We should probably include JUST what we need, this
would probably save a little tiny bit of memory and processor. I know
it's not much, but at the same time, why waste at all when we don't need
too? Same thing for Skins.php, it include()s all 3 skins. could we just
include() the one we need?
Is there a possibility of keeping the banlist in shared memory? Since
every single hit requires a query to that table, it might help if we
keep it cached in memory so we can avoid unnecessary querys and load on
the db.
I think the banlist cache and the limiting include()s are my most
reasonable proposals. I also think they would be the easist to
implement. thoughts? The ban list thing could be implemented fairly
quickly, and it might help with performance.
Lightning
Hi,
the past few days I've been experimenting a bit with Apache, mod_perl,
MySQL and creating an entire own website. I've never done that before,
and I think I've learnt a lot from this.
Now, for some reason, against all of your advice, I have started to
program a Wiki, and by now it's already become a suitable basis for a
Phase-IV Wikipedia software, including a database schema.
It really doesn't seem to be very difficult to re-program the current
software in Perl, this time taking all the problems into account and
designing everything right from the start (incl. single-login,
multi-language watchlists, a better translation system and skin system
(separated from the code), etc.) I've also made a lot of considerations
and decisions with respect to database design and performance.
Should I continue with this?
Greetings,
Timwi
Here are a couple of standard recommendations for improving DB
performance.
1) A second hard drive for the main database server. You will generally
see a significant performance improvement from having applications,
logs, and the OS on one drive, and only the DB on the other.
2) Make sure the firewalls on the servers are configured not to allow
random IPs to connect to the DB.
3) Move the remaining wiki's off of the DB server, and shut down
everything you can (PHP, Apache, etc).
4) Memory and (to a lesser extent) CPU upgrades can make a significant
impact on performance under the right conditions.
I don't know where the current bottlenecks are, but if it is anywhere in
the DB, the above might help significantly.
In Utf8Case.php we have this huge ~1450 item associative array (
$wikiUpperChars ). Is this really necessary? Is there a way we could
avoid having to load such a huge array into memory for every pageview by
a user in a language that needs it? This seems like it could pose to be
a problem in the future.. maybe keeping it in shared memory so we dont
have to go regenerating it and having all these instances of it for
every page view? I guess at the time its OK but as UTF8 wiki's gain more
and more popularity this might become a problem. Or am i completely wrong?
I'm noticing in setup.php that we are include()ing a whole lot of
stuff. Some of this stuff might never even be used, so why are we
include()ing it? We should probably include JUST what we need, this
would probably save a little tiny bit of memory and processor. I know
it's not much, but at the same time, why waste at all when we don't need
too? Same thing for Skins.php, it include()s all 3 skins. could we just
include() the one we need?
Is there a possibility of keeping the banlist in shared memory? Since
every single hit requires a query to that table, it might help if we
keep it cached in memory so we can avoid unnecessary querys and load on
the db.
I think the banlist cache and the limiting include()s are my most
reasonable proposals. I also think they would be the easist to
implement. thoughts? The ban list thing could be implemented fairly
quickly, and it might help with performance.
Lightning
Hi, folks.
I found out that the currently used checktrans.php script does only
check wgAllMessages. I changed the script to find missing translations
in more arrays and committed it to the CVS as checktrans-enhanced.php.
Bye!
Matthias
Hi, folks!
I'm currently wondering whether it makes any sense to include those
"sectionedit" and "commentedit" links in the printable version of a
page. To be honest, I doubt that, because only few users will want to
click on a link that's printed on a sheet of paper. :-)
If there are no objections, I'd try to change this behaviour.
Bye!
Matthias