Hi,
We occassionally get a PNG file whose thumbnail is discolored:
ex:
http://www.wikihow.com/Template:Fair-Use
vs original image
http://www.wikihow.com/Image:Red_copyright_213.png
We're using libpng 1.2.8, I assume it's a libpng problem? This image
is an 8bit image it appears and when imagecreatetruecolor is used
instead of imagecreate, the result isn't correct either.
Any ideas?
Travis
There is a misunderstanding, our IP was blocked today as a "Remote Loader".
We DO NOT load wikipedia's pages live, we only CACHE the pages in our
server. We send a monthly request to update our cache for requested pages,
so I don't understand why our IP was blocked.
As you can check, we are still providing the cached pages FROM OUR SERVER:
http://www.ebaita.com/enciclopedia.asphttp://www.tiosam.com/enciclopedia/
I also make sure the license and link to wikipedia are in all pages.
Please remove the block so we can update the pages when necessary.
Thanks,
Tony
Webmaster TioSam.com and eBaita.com
Thanks to the continual help and expertise of User:Sanbeg, Labeled Section
Transclusion is now a full-fledged MediaWiki extension that has been put to use
at external sites.
This extension allows selective transclusion of marked-off sections of text on a
wiki-page. It is a great deal more flexible than <onlyinclude> and <noinclude>, and will allow for many unforseen future uses.
See: http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion
Every type of functionality that was requested for this extension has been
implemented, and various small issues have been ironed out over the past few
months.
Labeled Section Transclusion was originally requested as a feature for
Wikisource, and the current extension more than meets Wikisource's needs.
It would be great if it could be applied live at the Wikisource wikis.
Among other things, doing so would allow it to get some heavy-duty testing,
since the uses for this extension might eventually go beyond Wikisource.
Dovi Jacobs
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
Gentlemen, the challenge: how do I make a link to where the D's start
in Special:Categories?
Currently
http://radioscanningtw.jidanni.org/index.php?title=Special:Categories&offse…
is right, but it changes day to day.
"Sure, just use [[Special:Allpages/Category:D]], and you won't even
need to use {{fullurl}}" you say. However that would only work if each
category page had a body. None do, so they won't be in Allpages.
Does SpecialCategories.php need to take some lessons from
SpecialAllpages.php about allowing fancier arguments?
Dan Jacobson schrieb:
> php rebuildtextindex.php
> ALTER TABLE... 1142: ALTER command denied to user...
< You do not have the right MySQL permissions. Add to your wikiuser
< account the ALTER TABLE privilege and your problems should be fixed.
And indeed they were. Now let's try another script.
$ php updateSearchIndex.php
LOCK TABLES... 1044: Access denied for user...
And indeed, adding more privileges fixes that too.
My question is why doesn't update.php fix or at least warn about
these? E.g., "Bla lacks permissions to do ZZZ. Some maintenance
scripts won't run. Some daily tasks will be hindered."
By the way on
http://meta.wikimedia.org/wiki/Help:How_to_move_a_wiki_to_another_server
"SELECT, INSERT, UPDATE and DELETE permissions should suffice."
How could it be that not only for *.wikipedia.org, but also my
taizhongbus.jidanni.org, at our public library
(http://www.ntl.gov.tw/, where you take a number to get a seat before
the doors open), one can login fine, meaning HTTP POST works, but
"show preview" and "save page" cause their MSIE browser to timeout
waiting. Though they like to block things like port 22, etc. I can't
believe they are blocking outbound requests with "wpTextbox" in them
or something. What might be up their sleeve? The lady said she didn't
know, and it's far away so I can't experiment often, nor before, "time
up sir, there are other users waiting."
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19702).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
Per Brions request I split the isues into single pieces (although I wanted to
avoid having different parallel threads on related issues):
1)
Usually UI interface links (such as "MediaWiki:Mainpage" that defines the URL
of the main page) are not localisable by default (pages
like "MediaWiki:Mainpag/de" get ignored). However you can whitelist their
i18n with "$wgForceUIMsgAsContentMsg = array();" individually in
LocalSettings.php.
2)
In the past maintenance/update.php did copy every UI message from the default
language UI message file into the wiki database. On whitelisted UI interface
links it even did copy the default language link target into the language
sub pages in every language if there wasn't one created by hand before (for
example the content of MediaWiki:Mainpage was copied into
MediaWiki:Mainpage/de if it was empty). So if there was the link target
existing in the default language it was not possible to link people in other
languages into non-existant "localised" pages after running
maintenance/update.php (side note: this specific behaviour of
maintenance/update.php can't have been an accidential not intended side
effect).
Now maintenance/update.php was changed that way that it doesn't copy UI trings
anylonger into the wiki and even removes the old automatically added entries.
This is in principle a good thing as this allows for some other fixes (for
example in mutilingual wikis) and reduces problems with hidden message
strings.
However one important thing was forgotten: The special treatment of
whitelisted interface links. Now they point into the nowhere by default after
running maintenance/update.php (since the link definitions from the localised
message string files get used now).
How to solve that (I don't want the old copy behaviour back as this is a
hakish solution)?
Change for link target strings (all that now need whitelisting) the
interface string resolution order from:
Mediawiki:$Message/$language-code ->$language-code-UI-String-File-$Message
[further steps left out]
to
Mediawiki:$Message/$language-code -> Mediawiki:$Message (default language) ->
UI-String-File-$Message (default language)
That way people don't get linked into nowhere on whiletlisted link targets -
and of course you also could entirely remove the need for
$wgForceUIMsgAsContentMsg switch in Mediawiki (and you
would get rid of one Wikimedia server maintence issue that fills your
Bugzilla).
Arnomane
