Hi,
I am trying to strip out the categories of an article to display them
in a separate inputbox below the edit page inputbox (see
http://www.mediawiki.org/wiki/Extension:CategorySuggest). I use
parser->parse() and then parseroutput->getCategories() to get the
categories. I would then like to have wikitext without the category
links in the edit window. I got nice html without the category links
from the parser and of course I still have the original wikitext with
the category links. But I don't have wikitext without category links.
How can I
a) strip out the categories (while observing nowiki tags) from the wikitext or
b) convert the html to wiki text or
c) any other ideas?
Thanks,
Andi
Earlier today, I added [1] the long-awaited action=edit module to the API.
Currently, all WMF wikis have $wgEnableWriteAPI = false; , so
action=edit won't be available on them (along with delete, move, etc.),
which is probably a good thing as long as these modules haven't been
tested extensively. However, I suggest this setting be enabled on
Testwiki [2] so it can be, well, tested. Maintainers of JS scripts that
use the API (like Twinkle, maintained by Carl Fürstenberg AKA AzaTht
whose repetitive bugging sped up the development of this module) could
probably help here: they'll need to modify their code to use the API
edit features at some point and will be able to use TestWiki for
testing, and in turn their requests will help testing at TestWiki.
If anyone runs into any issues with the API edit modules, feel free to
bug me at #mediawiki (where I'm known as RoanKattouw), file a bug report
at BugZilla (be sure to set component=API and assign it to
roan.kattouw(a)home.nl ) or send an e-mail to the mediawiki-api list [3].
Roan Kattouw (Catrope)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31514
[2] http://test.wikipedia.org/
[3] mediawiki-api(a)lists.wikimedia.org
We're planning to set up 4 data displays in the Wikimedia Foundation
office - I'm thinking at least 19" screens, maybe larger. The intent
here is not to appear "hip", but to make the office environment more
interesting for visitors, such as potential donors. This creates
conversation pieces and memorable moments - which is important for
cultivating relationships.
I'd like to request your comments on what kinds of displays we could
set up. Some initial ideas:
- Real-time recent changes. This should be relatively straightforward
using the IRC feeds. Most effort here will go into prettification, I
think. What would be a good IRC client to show multiple channels at
once?
- Show random articles. Not particularly creative, but should also be
fairly easy to do using some scripting. Would be nice to show stuff
from projects beyond WP.
- Show articles matching to current searches. How difficult would it
be to capture search data for this?
- Show the actual search strings. I don't love this one, because
Google already does this, but it might be interesting content-wise.
- Show traffic data. What would be interesting displays here? Can we
show bandwidth usage in real-time?
- Show images as they are being uploaded. Do we have anything like
that already? If not, how hard would it be to implement?
- Data displays of developmental indicators - e.g. Gapminder data on
Internet access, literacy, etc. Is there anything like this that we
could do with relatively little effort? Any volunteers to put
something together?
- Geomapping of access - some visualization of the primary clusters
where traffic is coming from, based on sampling. I imagine this could
be quite tricky - but might be a cool long-term project for a
volunteer?
- Visualization of edit patterns, similar to:
http://abeautifulwww.com/2007/05/20/visualizing-the-power-struggle-in-wikip…
Other ideas / comments?
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Wed, Mar 5, 2008 at 10:44 AM, <raymond(a)svn.wikimedia.org> wrote:
> + # Look for 'special:' in the line
> + $pos = strpos( $line, 'special:' );
Eek, case-sensitive?
> + $canonical = strtolower( trim( substr( $line, $pos + 8 ) ) );
Don't use magic numbers. $pos + strlen( 'special:' ) is more comprehensible.
> + return '<p style="float:' . $align . ';" class="mw-specialspecialpages-edit">' . $link . '</p>';
Why not put the float style in the class definition?
> +== Allgemeine Listen ==
> +:special:Allpages
> +: special:Prefixindex
> +;special:Categories
> +* special:Disambiguations
> +* special:Listredirects
> +
> +== Wartungslisten ==
> +* special:Mostcategories
> . . .
If you're going to use messages, wouldn't it be better to have a
single cross-language message for this, and have the titles be indexes
into other messages the way Sidebar does it? Like
== specialpages-generalpagelists ==
:special:Allpages
...
with MediaWiki:Specialpages-generalpagelists = "General page lists",
"Allgemeine Listen", or whatever else? Having a separate message used
for every language duplicates a ton of info and will be a big
maintenance headache if anyone wants to adjust the display, either in
the software or locally on a multilingual wiki.
Also, currently there would be serious problems if you wanted to
include the string "special:" in any of the descriptive text, it looks
like. Using message keys means this isn't a problem, unless you have
"special:" in the message key (which is technically not prohibited,
but not conventional and certainly never useful).
There are other problems with using a message altogether, though.
Every time a new special page is added to the software, it will appear
at the end in any wiki that's customized this message. Every time an
extension adds a special page, it will appear at the end in any wiki
until an admin picks some arbitrary place to put it. Also, if various
wikis decide to use this functionality to sort the pages in all
different ways, it will become very confusing for anyone who uses
multiple wikis to use the page, since it will be completely different
on every wiki. On the other hand, is there any real downside to
hardcoding the categories and orderings, having a fixed set of
categories and allowing each special page to insert itself into the
category it likes best? Does anyone really need this extra
flexibility?
But this is definitely a nice change in principle. It's something
that I've wanted to see for some time. Special:Specialpages has long
since gotten out of hand.
On Tue, Mar 4, 2008 at 4:27 PM, <ialex(a)svn.wikimedia.org> wrote:
> - 'wgRestrictionEdit' => $wgTitle->getRestrictions( 'edit' ),
> - 'wgRestrictionMove' => $wgTitle->getRestrictions( 'move' ),
> . . .
> + foreach( $wgRestrictionTypes as $type )
> + $vars['wgRestriction' . ucfirst( $type )] = $wgTitle->getRestrictions( $type );
Wouldn't this be better implemented as a client-side array, with the
old two variable names kept for a while for backward compatibility?
There's no guarantee that all action types will always be suitable for
use in C-style variables. In principle (say for extension-generated
actions) they could be arbitrary Unicode strings. It's perfectly
plausible that they might contain hyphens, say, which would
immediately cause a fatal error here.
Besides, generating one variable for each member of an arbitrary list
is just wrong. That's what arrays are *for*.
Hi,
I would like (have to) to turn off the self-link function (link rendered as bold link text without href).
Is there another solution than editing the makeSelfLinkObj()-function in Linker.php?
(I'm needing the real links for an extension.)
Thanks very much.
Chris
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.web.de/de/entertainment/games/free
Hi,
[I'm resending the message, the original one didn't appear
on the list. Maybe because of incomplete bits of XML in
the content, which I've removed in this version.]
I'm conducting a research on content from all 250+ language
versions of Wikipedia. I'm primarily concenred with the page,
langlinks, redirect, pagelinks and categorylinks tables for
each language version.
I've noticed that SQL dumps of the redirect tables often
contain less entries than they should. The problem applies
to both large and small wikis.
For a concrete, easy-to-reproduce example, take a small wiki,
like the Zulu language version, and compare the contents of
XML dump with the contents of SQL dump:
$ bzcat zuwiki-20080206-pages-articles.xml.bz2 | grep '#REDIRECT' \
| sed 's/<[^>]*>//g'
#REDIRECT [[Wikipedia:Sandbox]]
#REDIRECT [[IRiphabliki yaseNingizimu Afrika]]
#REDIRECT [[eThekwini]]
#REDIRECT [[IsiHolandi]]
#REDIRECT [[IGoli]]
#REDIRECT [[UBudha]]
#REDIRECT [[iShayina]]
#REDIRECT [[UJesu Krestu]]
#REDIRECT [[Ikhasi Elikhulu]]
#REDIRECT [[KwaXhosa]]
#REDIRECT [[iGauteng]]
#REDIRECT [[KwaXhosa]]
#REDIRECT[[Mošovce]]
#REDIRECT [[iJapani]]
#REDIRECT [[IsItalian]]
#REDIRECT [[ITheku]]
$ zcat zuwiki-20080206-redirect.sql.gz | grep ^INSERT
INSERT INTO `redirect` VALUES
(1720,0,'EThekwini'),(2105,0,'IJapani'),(2376,0,'ITheku'),
(2334,0,'IsItalian'),(2157,0,'Medmaacher_Klaaf:Purodha'),
(2096,0,'Mošovce'),(2120,0,'User:CommonsDelinker'),
(2213,3,'Multichill');
Take a look at the XML dump to confirm that redirects
like zu:Isi-Dutch -> zu:IsiHolandi do exist.
Beside the obvious "Can you fix it?" question, could
you tell me how the SQL dumps of redirect tables are
generated? Maybe the tables are OK, and I'm missing
something.
Currently I'm processing the XML dumps to generate
the correct SQL dumps for redirect tables (an easy
modification of mwdumper introducing a new subclass
of SqlWriter solves the problem).
Regards,
Lukasz
I applied what was requested on
https://bugzilla.wikimedia.org/show_bug.cgi?id=13214 having read (as far as
I could) the discussions taken place previously about this feature (and the
vice versa). My general understanding was that the opposite (forcing a scale
up) was somehow turned down previously, although it has been practiced
lately.
I had my own reasonings in support of stopping images less than 120*120 to
scale up. Duesentrieb materialized my idea in few words excellently while we
were chatting over IRC: "scaling up generally doesn't make sense. maybe it
would be nice to be able to force it in some cases, not sure. if that should
be allowed, it might be best to leave it to the client". If you ever use a
slow internet connection and browse one of the galleries of small icons on
Commons, you will notice how page load is extended merely because the images
are being downloaded in a larger (in KB) scaled-up (thus no more nice
looking) sizes.
However, I'm sending this email, not to insist on my reasoning, but to say
that I didn't apply that change because of my own desire, but I did it
because I thought there has been a (shadow) agreement about this.
Certainly, I'm open to comments and suggestions. Maybe we can reach a final
solution which satisfies both sides this time.
Cheers,
Hojjat (aka Huji)
brion(a)svn.wikimedia.org schreef:
> Revision: 31519
> Author: brion
> Date: 2008-03-03 19:54:22 +0000 (Mon, 03 Mar 2008)
>
> Log Message:
> -----------
> Revert r31505, r31510 (secureAndSplit hook).
> This hook doesn't seem well thought out; a hook isn't given clean access to the various possible fields it's likely to want to manipulate, and generally feels a bit rushed.
Care to improve this rather than just taking it back out?
Roan Kattouw (Catrope)