On 28/03/07, aaron(a)svn.wikimedia.org <aaron(a)svn.wikimedia.org> wrote:
> Revision: 20765
> Author: aaron
> Date: 2007-03-27 23:28:21 -0800 (Tue, 27 Mar 2007)
>
> Log Message:
> -----------
> Don't show rev_deleted usernames
Please don't touch extension code again without checking with the
extension author. It's rude, and several of the extensions I've
written are intended to be backwards-compatible. Such changes often
break this.
Rob Church
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r20768).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 494 of 511 tests (96.67%)... 17 tests failed!
I am writing some code that should allow to upload multiple files (from an
archive), but for this to work properly showSuccess() should be called
always to show those files which succeeded and those that didn't (or
produced warnings)...
However, in the first case, ie. the last uploaded file didn't exist
previously, MediaWiki redirects? / shows the Image:... page of that last
file.
However, I cannot see that case (i.e. case 1.) from the code in
SpecialUpload.php:
In function processUpload() we have
function processUpload() {
[...]
if( $this->saveUploadedFile( $this->mUploadSaveName,
$this->mUploadTempName,
$hasBeenMunged ) ) {
/**
* Update the upload log and create the description
page
* if it's a new file.
*/
$img = Image::newFromName( $this->mUploadSaveName );
$success = $img->recordUpload(
$this->mUploadOldVersion,
$this->mUploadDescription,
$this->mLicense,
$this->mUploadCopyStatus,
$this->mUploadSource,
$this->mWatchthis );
if ( $success ) {
$this->showSuccess();
wfRunHooks( 'UploadComplete', array( &$img ) );
} else {
// Image::recordUpload() fails if the image
went missing, which is
// unlikely, hence the lack of a specialised
message
$wgOut->showFileNotFoundError(
$this->mUploadSaveName );
}
}
}
i.e. either we are successful and call showSuccess() or
showFileNotFoundError(..) on failure. I also looked at the called
functions, but didn't find any redirects.
So how can I force to save files and also that the output of showSuccess()
is always shown?
Any hints would be appreciated.
Regards,
Andreas
PS: it's a repost (now from gmane web interface) since the original posts
obviously didn't make it to the newsgroup, although the automatic registration
mail from gmane server said it would be automatically posted after verification
of the e-mail address.
http://meta.wikimedia.org/wiki/Wikitrans_(MediaWiki_Extension)
Wikitrans is a MediaWiki extension that enables full machine translation
support for MediaWiki during editing and PHP article generation.
Wikitrans converts and translates wikitext into a target language in
HTML output through MediaWiki, while retaining and saving the original
English text in the body of the Article. Wikitrans renders and
translates the wikitext dynamically into HTML when the article is saved
in the database.
Sample Pages at Wikigadugi:
(you can edit and test drive it with MediaWiki)
http://chr.wikigadugi.org/wiki/%E1%8F%97%E1%8E%A6%E1%8E%B4%E1%8F%B4%E1%8F%9…
I still have a lot of performance optimization to do, but the first cut
seems to work well with Cherokee.
Jeff
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r20732).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
17 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* Link containing double-single-quotes '' (bug 4598) [Has never passed]
* message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* HTML nested bullet list, open tags (bug 5497) [Has never passed]
* HTML nested ordered list, open tags (bug 5497) [Has never passed]
* Inline HTML vs wiki block nesting [Has never passed]
* Mixing markup for italics and bold [Has never passed]
* dt/dd/dl test [Has never passed]
* Images with the "|" character in the comment [Has never passed]
* Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 494 of 511 tests (96.67%)... 17 tests failed!
Hi Brion,
I have completed my analysis of the latest breakage in the XML Dumps
with importDump failing with the enwiki-20070206
XML Dump and it appears to be related to improper rendering of wiki text
markup titles (<sup></sup>) when the dumps are rendered
from sql to xml from the Wikimedia sites.
Here is an example of the article title in question that uses characters
outside of wgLegalTitleChars as they are defined by
default in MediaWiki 1.9.3:
Article Link:
http://en.wikipedia.org/wiki/P%C2%B2-irreducible
Wiki Text:
In [[mathematics]], a [[3-manifold]] is '''P<sup>2</sup>-irreducible'''
if it is [[irreducible (mathematics)|irreducible]] and contains no
[[2-sided]] <math>\mathbb RP^2</math> ([[real projective plane]]).
Article Title in enwiki-20070206 XML Dump File:
2698249:Image:Tripitaka storage2.jpg
2698250:Natalie Golda
2698251:Image:Big Passage outside Ampleforth College Library.jpg
2698252:Canine infectious hepatitis
2698253:P²-irreducible <-- article title
causes importDump.php to fail
2698254:Image:Zebra sideview.jpg
2698255:Amy Freed
2698256:El cubano libre
2698257:Aujezky's disease virus
2698258:Wikipedia:Administrators' noticeboard/IncidentArchive92
2698259:Aujezky's disease
I have corrected this by basically allowing any characters of any kind
to appear in titles.
i.e. $wgLegalTitleChars = "\\x0-\\xFF"
It may be a good idea to instrument a title filter and render these
characters not included in the default MediaWiki setup as utf8 strings
in the future and sidestep the perpetual breakage of importDump.php with
the standard dumps provided by the foundation.
I will update the pages on meta with this information on how to get
around all of the problems with importDump.php based on the current
state of the XML dumps. One good thing came out of it. I managed to
get some very comprehensive C based tools written that can analyze all
of these errors and determine where in the XML dumps the problems seem
to originate from.
Jeff
raymond(a)svn.wikimedia.org schrieb:
> Revision: 20616
> Author: raymond
> Date: 2007-03-22 01:22:24 -0800 (Thu, 22 Mar 2007)
>
> Log Message:
> -----------
> * (bug 4624) Namespace selection for Special:Whatlinkshere
> Found another bug: scrolling backwards at Special:Whatlinkshere was broken since ?
> 'previous' shows always the first page in reversed order but not the real previous page.
> Fixed now by changing backwards scrolling mechanism.
Ok, together with r20714 (removing unsed variable only) the backwards
scrolling isn't completely fixed :-(
The current version is a little bit better because it is possible to
scroll once back, the second click jumps to the beginning of the list in
correct order.
The previous version jumps at the first backwards click to the beginning
of the list, in reversed order.
I think we need a database request to figure out the offset for every
backwards scrolling in dependency of the current page and the limit. But
I do not know how to do this in the cheapest way, without melting the
servers :-(
If nobody has a quick idea to solve the problem I will open a new bug
for this issue.
Raymond.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
simetrical(a)svn.wikimedia.org wrote:
> + if( !isset($_SERVER['HTTP_ACCEPT']) ) {
> + $_SERVER['HTTP_ACCEPT'] = '';
> + }
Please don't mess with system variables!
Leave it be and only check when you read it.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGCAg3wRnhpk1wk44RAofUAKDPXZoU1/SDSBySttJsvlgUCwIT2ACeNbX5
wCC3WO+42n+PTWG5qcjx+d0=
=c4x6
-----END PGP SIGNATURE-----
On 26/03/07, raymond(a)svn.wikimedia.org <raymond(a)svn.wikimedia.org> wrote:
> Revision: 20709
> Author: raymond
> Date: 2007-03-26 09:46:13 -0800 (Mon, 26 Mar 2007)
> trunk/phase3/includes/SpecialLog.php
Hmm, I'm not sure that altering core code to refer to extension code
is the right means to go about dealing with this.
Rob Church