Sorry, I don't understand. If you look at
http://cs.wikipedia.org/wiki/Speciální:Recentchanges, you'll see
Ukázat nové změny, počínaje od 16:56, 5. Srp 2004
5. Srp 2004 etc.
I can change it some other way than changing this?
'jan' => "Led",
'feb' => "Úno",
'mar' => "Bře",
'apr' => "Dub",
'may' => "Kvě",
'jun' => "Čer",
'jul' => "Črv",
'aug' => "Srp",
'sep' => "Zář",
'oct' => "Říj",
'nov' => "Lis",
'dec' => "Pro",
And as I said, why should LanguageCs.php contain these
"abbreviations" which are contrary to Czech language?
We currently stand at 188 open bugs out of 1102 total. That's down 11
open bugs from yesterday; we're slightly behind schedule. Would be
easier if there weren't new bugs to deal with too. ;)
Tomorrow's goal is 184-15 = 169 open bugs.
-- brion vibber (brion @ pobox.com)
Seems to be due to this postParseLinkColour thing:
title ="Special:Categories">Categories</a>: <!--LINK 14 Crap Crap-->
I'll leave the fix to those familiar with this new code.
-- brion vibber (brion @ pobox.com)
Camille Constans wrote:
>As de.wikipedia is now in utf-8, can we have some reports how it's working now ? and pbs de.wiki had ?
>Wikitech-l mailing list
The nl:wiktionary went to UTF-8 a few days earlier. The only thing I found were some existing Romanian words that did not finish with a ";" as a consequence they were not translated. This was to be expected obviously.
An other effect was the promissed explosion of new words; we are now at 1900 words, we were at some 1200. This was to thank Shaihulud and Anthere for making the change to UTF-8 happen.
Magnus Manske wrote:
> # Run full parser on the included text
> ! $text = $this->internalParse( $text, $newline, $assocArgs );
> ! # I replaced the line below with the line above, as it former seems to cause several bugs
> ! #$text = $this->stripParse( $text, $newline, $assocArgs );
What is the general opinion on the usefulness of such comments? In my
mind, it would seem that having CVS archive the old versions is
sufficient to document any change. Personally, I object to leaving
commented-out code in the files. (But then again, maybe I'm just copying
this tradition from LiveJournal.)
Of course, it would also be helpful if the commit message explained why
this change actually fixes the bug. I understand that you may not know;
you may have just experimented and found that this change happens to fix
one or more bugs. But I'm pretty sure that any information you can
supply about the effects of this change on the bug in question will be
helpful to other developers (especially people like myself who don't
know the code very well yet).
Erik complained here about 2 weeks ago that his EasyTimeline function
wasn't working. It still hasn't been fixed! The cached timelines are
shown, but de.wikipedia has been converted to utf-8, so every timeline
will have to be re-rendered there, which is not happening.
Stephan.Walter(a)epfl.ch -- http://lart.info/~stw/ -- PGP: B2421799
I have ordered some new servers. I believe that they will resolve
several significant issues.
1. NFS Fileserver -- for now, only 1 of these, as I was told that
gwicke wants to do some tests before we buy 2 of them.
Dual Opteron 242
1 Gb ram (2x512), leaving 6 slots available
3Ware 9500S-8 8 port RAID controller
6x250GB drives (750GB HW RAID 10)
Sony 52x CDROM IDE
460W hotswap redundant power supplies
Fedora Core 2 for AMD64
2. Search DB server --
same machine as above, except...
6x200GB drives (600GB HW RAID 10)
4 GB ram (4x1gb), leaving 4 slots available
3. Apaches --
In what may be a slightly controversial decision, but supported by
Shaihulud and Jeronim in the irc room, and probably a tossup to most
people, I went with a "known quantity" and ordered 8 1U Pentium 4
P4 3.0GHZ - 1 MB Cache - HT - 800FSB
512MB (2x256) - leaving 2 slots available
80GB ATA100 hard drive
My thinking here is that this will roughly *double* our apache
capacity, thus definitively solving (for now) what has been a
longstanding issue. This may expose something else as a bottleneck,
we don't know yet.
There was a lot of talk about going with dual opterons in this
capacity, and it was once decided. But lately there has been some
concern about the performance of suda, and some difficulties
(possibly) with having a non-homegenous group of apaches.
I have seen arguments back and forth, and did not find any of them
definitive. So, I made a decision. That's what I have to do, and I
hope no one is mad about it. :-)
es.wikibooks.orgs has recently been launched. Some users are moving the
articles from their former location on www.wikibooks.org
For better compliance of the GNU FDL, some of us are wondering whether
there is a way to move the page along with its history to the new site.
I know the Special:Export feature, but is there an import feature to be
used in the target site?