Here's a patch that I think should be applied on all Wikipedias (after some testing).
It changes only Cologne Blue skin.
* no OK buttons for search. Every browser that exists allow submiting
a form by pressing enter.
* group headings in quickbar are centered
* only "important" links in quickbar are in bold
* removed link to main page from quickbar - already 3 other on page
* link to special pages moved up
* quick login for non-logged-in users (as Cologne Blue is default only on eo. now,
it won't affect other Wikipedias at all, but I hope some day all wikis will go
away from that ugly standard toward something nicer, like for example Cologne Blue)
* | separator in topbar replaced by -, | looked too much like I and was not
aligned well (the same problem on Konq, Moz and Opera, so it's not just browser
problem). More readable now.
Changes visible on screen shot but not in patch:
* anything related to underlining, font sizes and line heights changes
Patch applied to test.wikipedia.org. Have fun :)
The new locale for Chinese Wikipedia has completed, and can be found at
Please install the new locale in the server.
It is now fully localised(in simplified Chinese), but namespaces are
still in English, for the convenience of traditional Chinese users.
I am not sure if it is possible to have two locales for Chinese
Wikipedia, one in traditional Chinese and the other in simplified
Chinese, so that users can choose in their preferences which interface
they want to use.(Currently there is discussion about having both
traditional and simplified characters together in the interface, but I
think that would be very ugly)
It has not been tested, and may have errors.
some of these are really gross.
* tiny headers.
with the amount of junk above the page header, it's even harder for the
casual reader to *find the article title*. This must be made bigger
UNTIL we redesign the skin (any news on this? I've more or less given up
due to a) lack of interest and b) the threat of a vote. should I do more
work on this?)
everyone here seems to hate underlined links. Fair enough. But it would
be nice to add an underline on the hover pseudoclass.
I'll make these changes unless people object.
Another thing I would like to change is this:
Our code currently puts
for system pages.
It would be more elegant (and more compliant) to do this:
and then put two rules in the stylesheet.
This would also allow skins to make other changes to distinguish between
article & meta -- someone suggested italic headers for meta a long time ago.
I can *probably* work out how to do this in PHP. But if someone is
available to help me with this, please let me know!
Please update LanguageHe.php from meta. I have asked this before, but it
probably went unnoticed. It is important because it sets the defaults
for TeX to always display as PNG. That will fix the incorrectly
displayed formulas (when rendered as HTML, probably due to RTL issues)
problem I have reported earlier. (See thread about "Hebrew wikipedia
The amount of activity on the Hebrew wikipedia has jumped enormously
since it got the press article on Ynet yesterday. Current status: 215
articles (However, many of them are used as "placeholders" and contain
only links), 71 registered users, 8254 pageviews since 8 July 2003.
Having started to put links between articles in different language
wikis, I wonder if it would be possible to create a process (a bot?) to
occasionally search through all the interlanguage links to make sure
that there is a reverse link back to the original wiki e.g.
If we have [[cy:Yr_Ariannin]] linking to [[en:Argentina]]
[[es:Argentina]] [[pt:Argentina]] [[pl:Argentyna]] and so on, the
process would check if there's a link in each of those wikis back to
[[cy:Yr_Ariannin]] and if not, automatically create a link. I think it
would help to tie the different wikis together into one overall
Anyone think this is a reasonable idea, or how to do it?
I suggested on the German list to turn off our page counter, like the
English Wp did long ago. I hope we can gain a bit more performance, and
maybe some of the other "big" 'pedias will follow.
Everybody on the list agreed, though some disliked to see another
(partly) useful function go for performance's sake.
P.S.: Maybe the data can be archived for the archeologists somehow ...
[Sorry if this message came twice : I'm not sure I've correctly configured
I was wondering if it would not be possible to update the search system
that any Wikipedia page uses by adding a dropdown list allowing to seek in
other Wikipedias; one could thus be able not only to search in the
Wikipedia he's reading, but also in other ones. For instance, the search
combo box, button and list would be like that :
<input type=text name="search" size=19 value="">
Try also in another Wikipedia : <select name="interwiki">
<input type=submit name="go" value="OK">
<input type=submit value="Search">
For example, someone searching in the French Wikipedia could also try and
see what the German one has to offer with the same topic (granted that he
actually knows how to spell it in the target language) without having to
switch manually to the German Wikipedia. This way, including interwikipedia
links would also be easier for editors.
I have written a PERL script that parses the SQL dumps (cur & old) and
generates a html file, containing for each month since the project
1 = number of wikipedians who contributed at least 10 edits
2 = increase in (1) in the past month
3 = wikipedians who contributed > 5 edits in the past month, idem > 100
4 = total number of articles according to new (link) counting system
5 = mean number of revisions per article
6 = mean size of article in bytes
7 = total edits in past month
8 = combined size of all articles
9 = total number of links
The reports also list most active wikipedians, ordered by # edits
Please note that the script produces historical growth figures per
Wikipedia based on the >> new (link) counting system << right from the
See results for de: fr: nl: eo: (and Perl script itself) at
Feedback is appreciated
I propose to run this script weekly on the new SQL dumps for all WP's
and put the resulting html files in a public folder.
I'd like to test the script with the huge English SQL dumps, but I can't
download a 1600Mb file without transmission errors. Could someone please
split the file in 50 Mb chuncks, generate MD5 checksums, put all in a
temp folder (public!) and inform me? Thanks! xxx(a)chello.nl
D. Open issues: unicode support, possibly further optimization for
English version (e.g. sort)
The English version will run for a while, but at least it will not tie
up the live database. I expect it will take under an hour, the German
files (650 Mb) were processed in 4.5 minutes on my 1.2 GHz PC.
As a test I downloaded the same 100Mb TomeRaider file eight times, four
times the checksum failed, FTP is too unreliable for huge files.
I am starting to work on designing (and creating) a completely new,
professional layout engine for all wikimedia websites that should be
launched with phase IV of the software.
First, from what I understand, the main idea for phase IV is that all
wikipedias sit on a single software installation (and that's great!), I
will add: (Just to give the general direction to tease you up)
* Layout should be separated completely from the PHP code. I will check
out a template engine like smarty (http://smarty.php.net/) to see how to
do that effectively.
* Site look will be redesigned to fit the 21st century (new "kick-ass"
look, yes that's its name :) ). The main problem with all current
designs is that they basically still think in terms of "UseModWiki". ie.
sooooo 95' single content HTML with no color, dynamics, and no usability
features and even GodDamnHorribleCamelCase.
I think more in terms of making a Content Management System, dynamic
content type layout, which means:
* Boxes, structure and order. Everything on the page is structured
dynamically. (every editable box can have a cute "edit" and "print"
button on the top right corner, for example)
* Graphics, color, icons, friendliness, [put a cool thing here], ... (of
course not too much stickyness .. :-))
* A page can present more than just the article. Additional content may
be: TOC on the side box. Previous versions. Recent changes,
announcements, news, etc. (whatever we'll choose, or the user will
* No more dedicated stand-alone "special pages". These are important
features that deserve to be integrated (somehow) into the engine itself.
ie. forget those yellow backgrounds etc. etc.
* Discussions can be integrated into the layout. ie. they may sit after
the article itself like blogs do, and may or may not be a wiki. (just an
* Interface can change to whatever language the user specifies in their
preferences. A side effect of the single installation, a user will able
to work, say on an article in Swedish with the English interface..
(don't flame me for this, I don't know if technically it would be
viable, just giving a direction...)
* W3C XHTML 1.0 Transitional/CSS. A really basic one for a modern site
(I even use the strict XHTML 1.1 on my site). And yes, I will make sure
it uses features that are compatible with browsers from IE 4.0+ and
Netscape 6. See http://www.w3.org/ and http://www.w3schools.com/
* etc. etc. etc..
for a little inspiration of what I'm talking about. (I basically ripped
the vorbis site, pasted the seinfeld article and made some changes to
the text, there's still junk on the bottom and side).
This is an enormous task. But I really think this encyclopedia deserves
to look like a modern site. I predict it will take about 2-3 months to
formulate the main targets and to understand what I'm dealing with. (and
to have a small working version of the engine)
I have enough PHP skills (but not too much free time as I'm a full-time
student) to make a basic version of a content system. I was employed for
about about a year in a software company (a couple of years ago) and
worked with ASP and SQL a lot so I know a bit about dynamic content. (I
think I'm getting the PHP thing..)
If anyone is interested in working on this or a similar project, please
let me know. Also, please give me a complete list of the Phase IV design
targets so I can generally understand how exactly the new website would
P.S: please don't start coming with specific suggestions on how this and
that feature should/shouldn't be/look/behave. The time spent on
discussions should be put in actually writing the PHP/XML code (and
applying some common sense). Replying to long messages on mailing lists
is really time consuming for me. I would just rather work on a preview
version/design etc. get feedback, work, get feedback etc..