Dear skin designer-developer(s),
Chinese characters have many many more strokes than Roman letters. So
the current MonoBook font size at Chinese WP is very hard on the eye.
Almost every single Chinese user who experienced the skin have pointed
out that the font size's difficult to read.
Please increase it to at least 11pt so ZH WP is ... minimally readable.
Xiexie,
Menchi
I just had a very disturbing experience on meta. I was
editing a section of "MediaWiki 1.3 comments and bug
reports." While I was editing, someone else apparently
added a new section above the one that I was editing.
When I saved my edits, it overwrote the section
previous to mine, and left unchanged the section that
I intended to edit. The results were a lost section,
and two sections in a row of the same title, with the
newer revision followed by the older revision.
The edit I made originally:
http://meta.wikipedia.org/w/wiki.phtml?title=MediaWiki_1.3_comments_and_bug…
(saved: 15:32, 3 Jun 2004)
-Rich Holton (User:Rholton)
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
define('NBSP', "\xA0"); // iso-8859-x non-breaking space.
I've never witnessed that this is causing any trouble, but shouldn't it cause
trouble on non-ISO Wikipedias? Shouldn't it be best that it is changed to
" " which would work everywhere?
It seems that as a by-product of being a bureaucrat on English
Wiktionary, I'm starting to be asked technical questions about the
operations of the new other language Wiktionaries. These are well beyond
my expertise.
Ronline from the Romanian Wiktionary has pointed out that the
((NUMBEROFARTICLES)) function on that Main Page gives only the number
"-1". That also seems to be the case in several other new Wiktionaries.
While checking this I also noticed that the list of all articles by
title in same projects also comes up blank.
Perhaps someone more capable might look at this.
Ec
Hi there,
Can I obtain the "sysop" privilege on zh-cfr/minnan.wikipedia.org so
that I can continue to coordinate the interface L10N? We have done some of
the translation but now the system message pages are locked, and we can't
continue the L10N work.
my username is pektiong
http://minnan.wikipedia.org/wiki/User:Pektiong
best
pektiong
I've created a page for testing and debugging our parser:
http://meta.wikipedia.org/wiki/Parser_testing
It's far from complete, but anyone with a knowledge of our syntax can add
to it and I hope it grows into something useful. So if you want to help
debugging the software but don't know how, please contribute here.
There should be one section for each test. A test can consist of a variety
of individual cases, all of which should be added first as <pre>..</pre>,
then verbatim, so that the difference between user input and parser output
can be seen.
One bug I noticed is that mixed lists seem to no longer work, unless I'm
missing something. I also think that we shouldn't use stuff like "left"
and "50px" as image alt text.
It's not always obvious what we *want* our behavior to be. Right now I'm
assuming that everything the parser does is correct unless the result is
really strange.
Kudos to Jens for the image caption parsing code, it seems to grok almost
anything.
Regards,
Erik
An update regarding Will (one of the new 1Us): due to previous
overheating problems, jeronim had shut down will yesterday. We suspected
a disconnected fan or other airflow problems. Earlier today, Jimbo
visited the colo and found that the fans were working very well, and
that there were no visible airflow issues. After he left, we continued
having temperature problems:
PU1: Temperature above threshold
CPU0: Temperature above threshold
CPU0: Running in modulated clock mode
CPU1: Running in modulated clock mode
The CPU was running at about 62 celsius, which while not horrible is not
temperature that we want to run a production server on. I suggested that
the machine be powered off until we can look at it further, and jeronim
did so at about 7:15PM EST. There's some consensus that the next most
likely problem is an unseated (or improperly seated) heatsink, while the
less likely option is a bad CPU.
Jimbo mentioned a person in Florida who might be able to come to the
colo and help us out, so that's our plan of action for the moment.
Cheers,
Ivan.
So, I mentioned the idea of doing 404-handler caching on this list a
while ago. There's a page about it on meta:
http://meta.wikipedia.org/wiki/404_handler_caching
I coded up a very simple Wiki engine that uses this technique, just to
prove to myself it would work. It does, and quite nicely. The code is
here for anyone who wants to take a peek:
http://wikitravel.org/~evan/wormwiki-0.1.tar.gz
I'm going to try to shoehorn this code into MediaWiki in the near
future. I think it should significantly reduce load on servers.
~ESP
--
Evan Prodromou <evan(a)wikitravel.org>
Wikitravel - http://wikitravel.org/en/
The free, complete, up-to-date and reliable world-wide travel guide
Tim asked me to write this mail some 10 hours ago. In a hurry,
I didn't press the "send" button and just found this open edit
window when returning home. So this is for documentation
purposes only.
Regards,
jens
----------------------------------8<--------------------------
Hello,
due to some changes, doBlockLevels() is called after unstrip().
This results in some trouble with <nowiki>, esp.
<nowiki>* this is a line that starts with an asterisk</nowiki>
Yesterday's fix to this broke other things:
*this is <nowiki>rendered as a line with a star!</nowiki>
instead of a bulleted line. Other text completely disappeared.
(SF BUG #964477)
I changed the code to insert the <nowiki> again when unstripping
and call strip() a second time inside of doBlockLevels. The
transclusion-strips will be unfolded, and <nowiki> is folded
again.
This has two downsides:
* illegal HTML-Tags are added (<nowiki> is still in the output)
* it's not that efficient to call strip twice
This is a workaround to address the current bugs and should be
looked at by someone with more than 20 minutes time.
Regards,
jeluf