Kinda offtopic, but when somebody that's a channel op in #mediawiki
wakes up, could you please unlock the topic or at least update it to
mention the 1.2.4 release? Thanks.
-- brion vibber (brion @ pobox.com)
Hi,
I'd like to use Mediawiki 1.2.4 for an internal documentation system.
The text "Main Page - From SoftCultureWiki, the free encyclopedia" is
not *really* targeting the content. And the footnote "... under GNU
Free Documentation License" is wrong, too.
How can I change these texts? I found them in Language.php and changed
them but nothing happened after reloading the site.
Regards
Götz
I installed mediawiki with the web-interface. Now I want to change the
wiki's language subsequently from german to english. Therefore, I changed
the line
$wgLanguageCode = "de";
in LocalSettings.php to
$wgLanguageCode = "en";
no effect.
As far as I understand, the persistence of $wgLang is the troublemaker. I
cannot restart the webserver on the target host, for I don't have the
rights...
any ideas?
thanks in advance,
Alex Barth
I know it's only a few megabytes, but I just thought I'd point out that
for three months the list hasn't been getting compressed. Probably some
config file that was changed around that date, I'm not familiar with the
list server software.
http://mail.wikipedia.org/pipermail/wikipedia-l/
I know that hard-drive space has been very tight lately...
--
Mikhail / http://MikeCapone.blogspot.com
On our internal MediaWiki (currently 1.1.0) here at Gartner, which we have recently put on a production Linux box, everything works fine except image uploads.
I uploaded several image files onto the development box successfully, and copied them over to the production box, and they display fine.
I am trying to upload a 150K image (nowhere near the hard limit of 1MB) and get the following error:
Internal error
Could not copy file "/tmp/php5ZpRoX" to "/srv/www/htdocs/wiki/upload/3/31/Cyclone.jpg".
These are the current versions of the software:
* Apache 2.0.48
* MySQL Ver 11.18 Distrib 3.23.54
* PHP 4.3.3
* Mediawiki 1.1.0
LocalSettings.php has uploads enabled i.e. $wgDisableUploads = false;
I tried it with the Powered by Mediawiki image from the Test Wikipedia and get a similar error:
Could not copy file "/tmp/phpvyu88k" to "/srv/www/htdocs/wiki/upload/d/d4/Poweredby_mediawiki_88x31.png".
Do you know what might be causing this error? It is consistent and repeatable (except of course the tmp filename changes each time).
Thanks,
Michael Richards
PS
This error is now happening on both the production and development boxes, so
* something must have changed during the migration
* I can't compare one with the other to determine how to fix it
On Wednesday, April 14, 2004 12:30 PM Gabriel Wicke wrote:
> Are the image dirs writeable to the apache user (often www-data)?
Duh! Of course. Why didn't I think of that?
The upload directory itself was fine, but half the subdirectories were missing write privileges.
Works fine now. Thanks Gabriel.
Michael
Changes since 1.2.2:
* Fixed an in-place install bug with non-root MySQL user
* Fixed history diff checkboxes bug on titles with ampersands
* Fixed printable link bug on special pages with parameters
* Fixed bug that broke IP blocking w/o memcached
* Turns off E_NOTICE warnings if PHP settings have them on
(you can grope in and turn this off if you like to debug)
There are no database format changes. The proxy blocker hasn't yet been
merged, I'll try to get that in sometime...
Release notes:
https://sourceforge.net/project/shownotes.php?release_id=228178
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.2.3.tar.gz?
download
If you encounter a problem in the installation process, please include
*all* of the output under the 'Checking environment' heading with your
report!
-- brion vibber (brion @ pobox.com)
I was just looking whether math support is working or not now.
Well it does. Partially :-)
http://glassdoc.org/index.php/Diskussion:Hauptseite#Test_und_Demonstration_…
Anybody could give me a possible reason why it cannot convert {matrix} for
example?
I mean some it does render, some it doesn't.
Or is it just still in developement?
I'm running that mediawiki 1.2.3 on a woody machine with php 4.3.4 (not
woody of course :-) )
btw that sofware you're developing there's way cool :)
Thank you
"Tim Starling" <ts4294967296(a)hotmail.com> schrieb:
>
> Timwi wrote:
> > Evan Prodromou wrote:
> >
> > >>>>>>"T" == Timwi <timwi(a)gmx.net> writes:
> > >
> > > T> No matter what throttling you choose, I will hit the limit at
> > > T> some point, I'm sure...
> > >
> > > Well, y'know, I'd question whether you could do a sustained 2 edits
> > > per second, like the zh flooding bot. If so, you need to get some
> > > other hobbies. B-)
> >
> > Do you know that browsers have the capability of opening several windows
> > or (often) tabs?
> >
> > If I need to add, say, a {{msg:}} to a range of pages, or remove it from
> > them, or anything like that, then yes, I will probably hit about 2 edits
> > per second.
>
> I've done similar batch jobs, and I haven't been able to hit 2 per second.
> Maybe one every 2-3 seconds. But say if you can do two per second. Can you
> do 10 per second? 20? 50? 100? We've got to put a limit in somewhere, or
> else improved Wikimedia hardware will leave us vulnerable to extremely high
> edit rate attacks.
There's another side to that coin though. When dealing with the previous
bot attacks, I have done like 20 edits within 2 or 3 seconds while reverting.
It would be rather wry irony if measures against vandalism would slow down
the fighting against vandalism...
Apart from that occasion, I have never had sustained rates over 1 per 2-3
seconds. That number was got doing a particularly easy disambiguation using
a human-interfaced bot.
If the throttle is really a throttle - that is, the edit is only delayed,
I would say that even a throttle of 1 per second would not give undue
problems. Sure, people sometimes hit the 'submit' button faster when working
in multiple screens/tabs, but I don't think that waiting 10 seconds for the
last one to get through when doing 10 edits at once should bother too much -
especially since the first one will come without delay, and the next 3
within 3 seconds. Still, there is the vandalism fight problem mentioned
above. So perhaps we should switch off throttling for sysop rollbacks?
Andre Engels
I've set up a hacked squid on each of the apaches that returns ICP_HIT on
any icp request. The squids are running on the apache machines at nice 19,
taking up <1% cpu. The apache to receive the next request is now
determined by the icp response time, basically the first icp reply from
the apache machines gets the request. High load -> slow icp response -> no
request this time.
Load distribution is more even than with the round-robin setup, especially
if something else is running on one of the apaches (or if the apaches are
not identical machines).
--
Gabriel Wicke