Brion Vibber | 3 Mar 2003 09:28
Picon
Favicon
Gravatar

Date formats (in generated output)

I've added a site-wide configuration option for whether an
English-language wiki should display dates in American (Mar 3, 2003) or
International format (3 Mar 2003).

Set "$wgAmericanDates = true;" in LocalSettings to use the American
format. English Wikipedia has been set to use American dates for now to
maintain the status quo, as I have no interest in arguments about the
desirability of one or other other style. However the new option may be
of interest for third-party sites.

The date & time code needs some general overhauling... timezone data can
be gotten from the browser via JavaScript (but it's roundabout, as we
can't talk to it directly, and of course not always available), and we
need to support half-hour timezones (parts of Australia, India,
elsewhere).

Display of dates in YYYY-MM-DD format should also be an available
option, and we will certainly want user-selectability on these things,
as well as sensible ways of setting defaults and sniffing locale info
from browsers where possible and appropriate.

The generation of date/timestamps in ~~~~ sigs is also currently a mess;
it uses a locale-based function and doesn't integrate with our language
files.

-- brion vibber (brion  <at>  pobox.com)
Leonard Tulipan | 3 Mar 2003 12:12
Picon

Install problem

Hi there!
So I am currently installing the third wikipedia. The first two installs
(inhouse) worked flawlessly.
I wanted to setup a third wiki on an external server:
Apache: 1.3.20
PHP: 4.0.6
MySQL: 3.23.44

I am guessing my problems relate to the PHP Version, since the INSTALL
Document mentions 4.2
The problem seems to be with saving to the DB. It is actually able to
access the DB. I verified this, by deliberately mistyping the username
and getting and error, and by changing the start-text in the "cur"
table.
Are there any quick suggestions, or do I need to bother my provider to
try to get this shared server updated.
If the latter is the only options, maybe someone could point me to
potential security problems with any of the above older software
versions.

Cheers
Leonard
Brion Vibber | 3 Mar 2003 20:53
Picon

Re: Install problem

It would help to diagnose the problem if you can provide a more detailed
description of the problem. If there are any error messages (in the page
or in the logs), please copy them in their entirety...

-- brion vibber (brion  <at>  pobox.com)

On Mon, 3 Mar 2003, Leonard Tulipan wrote:

> Hi there!
> So I am currently installing the third wikipedia. The first two installs
> (inhouse) worked flawlessly.
> I wanted to setup a third wiki on an external server:
> Apache: 1.3.20
> PHP: 4.0.6
> MySQL: 3.23.44
>
> I am guessing my problems relate to the PHP Version, since the INSTALL
> Document mentions 4.2
> The problem seems to be with saving to the DB. It is actually able to
> access the DB. I verified this, by deliberately mistyping the username
> and getting and error, and by changing the start-text in the "cur"
> table.
> Are there any quick suggestions, or do I need to bother my provider to
> try to get this shared server updated.
> If the latter is the only options, maybe someone could point me to
> potential security problems with any of the above older software
> versions.
>
> Cheers
> Leonard
(Continue reading)

Lee Daniel Crocker | 4 Mar 2003 23:41
Gravatar

Test suite initial pass


After looking at tools like Apache's Latka and Canoo webtest,
I concluded that they were a bit to high-level and underpowered
for what I had in mind for the wiki software test suite.  So I
started a basic test suite in Java using the Httpunit classes,
which seem to work quite well and give me all I need.

I checked in a first pass to CVS in the "testsuite" directory--
right now the suite just loads the main page, follows a couple
of links, fetches an edit form, and extracts the source of a
page to a file.  Eventually of course this will be a full suite
that loads up an empty database with web actions, does lots of
modifications, exercises all the functions, and validates all
the output.

Let me now ask for guidance about what the next pressing step
is: I believe we are already in a performance crunch, and we
already have some ideas about how to fix some of those problems,
so I think I should make that the short-term driver for further
development of the suite.  For example, I have the wikipedia
code installed on a machine on my network at home, and I can
use the suite to time it, make a database change or something,
then time that to get us good numbers about what to tweak.

What would be a good mix of functions for timing?  I'm thinking
heavy on regular page loads, heavy on recent changes, lighter
on things like edits.  Any other ideas?

--

-- 
Lee Daniel Crocker <lee@...> <http://www.piclab.com/lee/>
(Continue reading)

The Cunctator | 4 Mar 2003 23:53
Favicon

Re: Test suite initial pass

On Tue, 2003-03-04 at 17:41, Lee Daniel Crocker wrote:
> What would be a good mix of functions for timing?  I'm thinking
> heavy on regular page loads, heavy on recent changes, lighter
> on things like edits.  Any other ideas?

I suspect you'd also want to have some frequent edits on large
pages--I'm thinking of pages like current events, and talk pages that
get large. Maybe modeled that the edit rate is somewhat proportional to
page size, until the page hits the 32K limit, at which time edit rate
slows down or the page size goes down.

In other words, I'd model the Current Events page and random Talk page
heated discussion.
Toby Bartels | 5 Mar 2003 04:45
Favicon

Fatal error

When I connect to

 http://www.wikipedia.org/w/wiki.phtml?title=Wikipedia:Most_active_Wikipedians&diff=0&oldid=479388

I get

 Fatal error: Maximum execution time of 30 seconds exceeded in
/usr/local/apache/htdocs/w/DifferenceEngine.php on line 377

(The exact line varies.)

OK, I don't really need to see this diff,
but I thought that the developers should at least know
that diffing two 200-line tables apparently crashes.
(Smaller diffs on this page work just fine.)

-- Toby
Magnus Manske | 6 Mar 2003 12:37
Picon

Interlanguage links at test site

I have reinstalled my interlanguage management at test.wikipedia.org. 
For those interested, I have also committed the code to the CVS. It is 
turned off by default; to turn it on, set
    $wgUseNewInterlanguage = true ;
in your LocalSettings.php

For your local installation, you'll need to create a "wiki-intl" 
database, with tables "ilinks" and "recentchanges":

CREATE TABLE ilinks (
  lang_from varchar(5) default NULL,
  lang_to varchar(5) default NULL,
  title_from tinyblob,
  title_to tinyblob,
  target_exists tinyint(1) default NULL
) TYPE=MyISAM;

CREATE TABLE recentchanges (
  user_name tinyblob,
  user_lang varchar(5) default NULL,
  date timestamp(14) NOT NULL,
  message tinyblob
) TYPE=MyISAM;

Happy hacking!

Magnus
Tomasz Wegrzanowski | 6 Mar 2003 18:35
Picon

Javascript RC and Konqueror

It doesn't work with Konqueror well.
It opens list a few lines above the link,
instead of exactly below it.
Brion Vibber | 7 Mar 2003 08:06
Picon
Favicon
Gravatar

Re: Interlanguage links at test site

On Thu, 2003-03-06 at 03:37, Magnus Manske wrote:
> I have reinstalled my interlanguage management at test.wikipedia.org. 

I haven't yet had a chance to check out the updated code, but may I make
a quick suggestion?

"International issues" seems a strange title for the link & the page --
it makes me think of a stern Kofi Annan shaking his head as Hans Blix
examines our link integrity. ;)

"Other languages" or "Language connections" might be a better way to go.
(Or, heck, "Interlanguage links"!)

-- brion vibber (brion  <at>  pobox.com)
Daniel Mayer | 7 Mar 2003 10:39
Picon
Favicon

demystifying Image description pages ... well maybe

I think I've already mentioned this on sourceforge but...

There is weirdness going on with how image description pages work. 

There are two delete links on them; one for the media file and one for the 
image description page. To properly delete a media file and it's description 
page ''both'' delete links have to be used. This confused the hell out of me 
the first time and also just caught Zoe (there are probably other sysops who 
/thought/ they deleted images but who really just deleted the image 
description pages).

IMO a much better design would treat the actual media file in the same way as 
text is treated on normal pages: When the page it is on is deleted the 
content (text and media file and their history) is deleted as well. When the 
image page is moved then the media file is renamed. Which brings me to; 

Another thing: there is no way to rename an media file or its corresponding 
image description page. Using the 'Move this page' feature brings up an 
error.

Also, the time and dates of uploads are not displayed and the different 
versions are listed in a separate history-like table (minus the dates and 
times). Since the media file is content on the page it would make sense for 
changes in that content to be properly logged. 

IMO the whole thing is a bit confusing and may need to be redesigned. 
Conceptually the media files can simply be thought of as another piece of 
content on a page and therefore treated accordingly (with one history, one 
delete link, and the ability to move the page). 

(Continue reading)


Gmane