Hi everyone,
I'm working on a MediaWiki installation. The initial installation tasks are
complete.
In testing the Upload part, I uploaded an image with a resolution of 1,280 ×
853 pixels. It uploads fine. However, when I view the image, I get the
following error in the preview area:
"Error creating thumbnail: /usr/bin/convert: Unrecognized option
(-thumbnail)."
Any ideas? Thanks.
Gerard
brion(a)svn.wikimedia.org schreef:
> Revision: 37009
> Author: brion
> Date: 2008-07-03 21:25:20 +0000 (Thu, 03 Jul 2008)
>
> Log Message:
> -----------
> Have been playing with custom API modules and been a bit frustrated with the XML output mode...
> Adding pseudo-element _attribs alongside _element for XML output. There doesn't seem to be a good way currently to specify both attributes *and* subelements
That works just perfectly with stuff like array('foo' => 'bar',
array('*' => 'stuff')) which will translate to
<tag foo="bar">
<tag>stuff</tag>
</tag>
I really don't see the point in this commit, and I'd rather see it reverted.
Roan Kattouw (Catrope)
greg(a)svn.wikimedia.org wrote:
> Revision: 37062
> Author: greg
> Date: 2008-07-04 15:57:44 +0000 (Fri, 04 Jul 2008)
>
> Log Message:
> -----------
> Properly handle the 'IGNORE' option passed to the insert funtion:
> rather than just turning off errors, do some savepoint trickery
> so we end at the same state as when we started, to emulate
> MySQL's INSERT...IGNORE. Bug 14708.
I'm not sure, but the impression I get from this code is that the query
will be aborted and rolled back when it reaches a key conflict. This
sounds like it will behave the same as MySQL's INSERT IGNORE only for
the special case where a single row is being inserted.
When inserting multiple rows, the end state should be that all
non-conflicting rows are successfully inserted, while conflicting rows
are silently dropped.
When we ask for the number of affected rows after the query, we should
get a count of the rows which were inserted.
-- brion vibber (brion @ wikimedia.org)
(cc'd to mediawiki-i18n mailing list too)
In r30349, Raymond fixed bug 10365 (
https://bugzilla.wikimedia.org/show_bug.cgi?id=10365), allowing
Special:Version to be localized. However, I am not sure how smart an idea
that was, since nowadays almost every extension has a description message.
Why so?
Firstly, let's have a look at WikiTextLoggedInOut extension (
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/WikiTextLoggedIn…).
It is a simple parser hook extension from Wikia I added on 30th of June to
the SVN repository. It adds two parser hooks that show different output to
the user depending on his/her login status. How simple is that? Well, it has
a description message too. It is a simple parser hook tag that does not need
i18n at all, unlike special page extensions and such do.
Secondly, some extensions, such as the above-mentioned WikiTextLoggedInOut
have only one message... the description message. Now, with the i18n file
being added, the extension's i18n gets loaded on every pageload if the page
has the extension tag. I am relatively sure that it slows things down. Maybe
only a few milliseconds, but the point is that it can be avoided.
Thirdly, what if the original developer wants or needs to change the
extension description, upon adding or removing some features? That's right,
some languages would see old messages with incorrect information while some
other languages might have correct info. And users might end up trying to
use a removed feature, which would obviously cause them frustration. After
all, you cannot demand that volunteer translators do translations 24 hours
per day. In fact, we already have several developers continuously working on
i18n, desperately trying to keep them in sync - resources that would be much
better spent on developing new functionality and fixing bugs.
I have heard an interesting argument in favor of description messages: that
they allow the wiki users to know what features are installed and what they
can use. Now, I don't think that's true. The local help pages are for
documentation and so are the extension pages on MediaWiki.org. If something
should be done, the local admins/sysadmins should create a help page about
the feature or announce it and maybe point the users to MediaWiki.org for
more information if they don't create a help page or such.
I have spoken to several fellow MediaWiki / extension developers, some
native English speakers and some are not, but most of them seem to agree
that the localization of Special:Version is "i18n gone bad". I have to agree
with them, as description messages do not provide anything useful for users
or developers - having, for example, the words "MWSearch plugin" in 39
different languages (
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MWSearch/MWSearc…)
is probably one of the most pathological examples. These extension
description messages just cause extra stress for MediaWiki and the servers
running MediaWiki. In the past, you could always find at least one English
page on the wiki, no matter what its content language was - Special:Version.
Now you have to add ?uselang=en to see the 'correct' version of the page.
Another interesting and related point is the addition of core 'blank' page
in r36856 (http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=36856)
by Domas. He added the blank special page as a baseline to profile startup
times. He used to use Special:Version for profiling, but since it's
overloaded with useless i18n crap now, it is no longer effective.
If there is something that should be translated in Special:Version, it most
certainly is not extension descriptions. It is the license text. And to
avoid legal issues, it should have a hardcoded English string, for example,
"The English version of the license can be found here" or something. As a
user, I would like to know my legal rights rather than of what parts the
software is made of.
I believe that the description message / localization of Special:Version
does more harm than it does good, plus it is pointless (as Rob Church
correctly pointed out in his initial reaction:
https://bugzilla.wikimedia.org/show_bug.cgi?id=10365#c1). I would request
that this would be removed from core.
--
Jack Phoenix
btongminh(a)svn.wikimedia.org schreef:
> Revision: 37050
> Author: btongminh
> Date: 2008-07-04 13:36:21 +0000 (Fri, 04 Jul 2008)
>
> Log Message:
> -----------
> Force index; Use straight_join
>
> Modified Paths:
> --------------
> trunk/extensions/GlobalUsage/GlobalUsageDaemon.php
>
> Modified: trunk/extensions/GlobalUsage/GlobalUsageDaemon.php
> ===================================================================
> --- trunk/extensions/GlobalUsage/GlobalUsageDaemon.php 2008-07-04 13:04:03 UTC (rev 37049)
> +++ trunk/extensions/GlobalUsage/GlobalUsageDaemon.php 2008-07-04 13:36:21 UTC (rev 37050)
> @@ -77,11 +77,15 @@
> do {
> $loopStart = microtime(true);
>
> - $sql = 'SELECT '.
> + $sql =
> + // Join order is important for sorting
> + 'SELECT STRAIGHT_JOIN '.
> 'page_id, page_namespace, page_title, il_to, img_name IS NOT NULL AS is_local '.
> 'FROM '.$dbr->tableName('imagelinks').' '.
> + // MySQL will choose the il_to index from il_to > 'O'
> + // TODO: Doesn't work on the Toolserver
> + 'FORCE INDEX(il_from) '.
> 'LEFT JOIN '.$dbr->tableName('image').' ON il_to = img_name '.
> - // Note the following JOIN should be after the LEFT JOIN
> 'JOIN '.$dbr->tableName('page').' ON page_id = il_from '.
> 'WHERE il_from >= '.$prevPage.' AND il_to > '.$dbr->addQuotes($prevImage).
> 'ORDER BY il_from, il_to ';
Holy hell... can't this extension use the Database class to clear up
*some* of this mess? AFAIK, STRAIGHT_JOIN is a MySQL extension and will
therefore break on other database engines.
Roan Kattouw (Catrope)
Hoi.
The Babel templates are widely used on the Wikimedia Foundation's wikis.
Implementing them is a lot of work; you need more then 1000 templates just
to cover the languages that the Wikimedia Foundation supports in its
projects. Several Wikis have templates to support additional languages. For
the bigger projects this is no longer an issue as the templates have already
been created, but for many of the smaller projects getting the Babel
information implemented is a lot of work. It would be great if the time
could be saved to do something that is really useful like writing articles.
At Betawiki we have been working hard to create a Babel extension. The great
news of an extension is, that there is no need to do anything but implement
the extension. We currently think that the software is at a state where we
would like to invite the last comments leading to the implementation on all
the WMF wikis.
Thanks,
Gerard
midom(a)svn.wikimedia.org wrote:
> Revision: 37047
> Author: midom
> Date: 2008-07-04 12:20:45 +0000 (Fri, 04 Jul 2008)
>
> Log Message:
> -----------
> adding explanations break the feature, page is supposed to be blank! kind of! revert r36902
>
Why do the explanations "break the feature"? The page is anyway not really blank
if you add this message; but if the you already add this message, it should
probably briefly explain what the page is, to avoid unnecessary confusion of
MediaWiki users. Few more words won't slow down the page, will they?
Hi,
We're having some intermittent problems with memecached, and thought someone
might have a suggestion for us.
We have a single memcached server using 2GB of the 4GB of system memory.
Lately we've been occasionally seeing on the site <mediawiki_messge_key>
instead of the contents of the message. I'm running mctest.php a few times
from each of our Apache servers, and the 'get' returned is occasionally 0,
but I can't seem to reproduce this problem reliably. The load on the server
running memcached is very low, and the number of connections to the
memcached server fall usually between 5 and 15, and we have 6 Apache
servers.
Could we need more memory, or could it be a network issue? Does memcached
have any commands to tell how much of the allocated memory it is using, or
are there any other diagnostics I can run to shed light on the issue?
Thanks.
Travis
Hi,
I'm getting complaints from users using my Widgets and HeaderTabs
extensions' parser functions that their output is mangled with <p> tags.
Looking into the issues I identified two separate problems and I'll be very
happy if you can confirm that I'm correct and help me resolve them.
First issue: Output of all parser functions is preceded with "\n\n" in
Parser.php line 2975 (on current stable 1.12 branch) which purposefully
forces closing </p><p> combination which contradicts with users expectations
that it will actually be inline if they put parser function inline. Here's
the code:
# Replace raw HTML by a placeholder
# Add a blank line preceding, to prevent it from mucking up
# immediately preceding headings
if ( $isHTML ) {
$text = "\n\n" . $this->insertStripItem( $text );
}
This is quite distracting since there is no way to work around this in
extensions or page text.
Second issue: If output of the function has line breaks in it, it gets
populated by lots of <p> tags which might not be desirable if extension is
supposed to preserve HTML structure (e.g. Widgets extension). I found a
piece of instruction on how to avoid it by using unique markers and
'ParserAfterTidy' hook:
http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modific…
please let me know if this is still going to work correctly with new
parser implementation.
I'll greatly appreciate your help with the matter.
Thank you,
Sergey
--
Sergey Chernyshev
http://www.sergeychernyshev.com/