Hello,
before reinventing the wheel, I want to ask,
whether someone has a *tool *with which we can
* "filter" a list of bugzilla urls
* so that all those urls where the bugzilla page shows status
"resolved" are *removed *from the list.
Tom
On Thu, Aug 29, 2013 at 6:36 AM, Ryan Kaldari <rkaldari(a)wikimedia.org>wrote:
> Just for fun, I added some license-parsing logic to Template:Extension on
> mediawiki.org. I think the job queue is still updating the categories, but
> so far we have:
> Extensions with no license specified: 596
> Extensions with an unknown license: 779
> GPL licensed extensions: 667
> MIT licensed extensions: 44
> BSD licensed extensions: 23
> AGPL licensed extensions: 10
> MPL licensed extensions: 1
>
> I was actually surprised to see how few MIT and BSD extensions we have
> considering how much animosity there is towards the GPL, but I suppose most
> people just want to match the licensing of MediaWiki.
>
> If you haven't specified the license of your extension, now would be a good
> time to do so :)
>
> Ryan Kaldari
(Separating this into it's own discussion)
A while ago I went though the first ~two pages of [[Cat:Extensions with an
unknown license]][1] and cleaned up a lot of the usages to use a template I
whipped up quickly where the license text directly matched a license I had
listed (T:EL)[2]
Although I didn't ever fix up logic in the infobox for the categories, so
if someone was still interested and fixed that up so they are still sitting
in unknown, but they should also be in their respective categories as well
now for people that want fuller numbers.
[1]. https://www.mediawiki.org/wiki/Category:Extensions_with_unknown_license
[2]. https://www.mediawiki.org/wiki/Template:ExtensionLicense
Dear all,
Thanks to the feedback from the Wikimedia developers list (wikitech-l), version 2.0-beta2 of the Memento time travel extension for Mediawiki is now available for testing and feedback. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3].
The extension is fully compliant with the Memento specification [4], soon to be released as an RFC. The effort is generously funded by the Andrew W. Mellon Foundation and is a collaboration between Old Dominion University and the Los Alamos National Laboratory.
The Memento team is appreciative of all of the feedback from the Wikimedia team and is eager to get additional input on the extension in order to guide its further development to a state that fully meets the MediaWiki community's needs. Feedback on all issues is greatly appreciated as we work to improve the code base.
Shawn M. Jones on behalf of the Memento Team
http://www.cs.odu.edu/~sjone/
[1] https://github.com/hariharshankar/mediawiki/releases/tag/2.0-beta2
[2] https://www.mediawiki.org/wiki/Extension:Memento
[3] http://ws-dl-05.cs.odu.edu/demo-302-recommended-relations/
[4] http://www.mementoweb.org/guide/rfc/ID/
I've uploaded an SSE/Comet demo extension for anyone who's interested:
https://github.com/worden-lee/cometdemo
For demo purposes, it creates a notification bubble on your page in
which you get an ongoing feed of the contents of your wiki's
$wgDebugLogFile.
Since that file may contain sensitive information, I don't recommend
this extension for public-readable wikis.
Of course the code can be adapted to stream information from a file,
from memcached, from the database, etc.
The extension seems to work in at least MW 1.21+. If you're curious but
don't want to run it yourself, tell me and I'll let you look it over on
my test wiki.
LW
On 11/19/2013 07:50 PM, wikitech-l-request(a)lists.wikimedia.org wrote:
> I have an early version of this working now, that watches a file and
> spools it out in an SSE event stream (by violently hijacking the
> ApiBase logic and seizing low-level control of the HTTP response - I'm
> sure it could be integrated into the output options in the Api class
> hierarchy if there's interest). This seems to work pretty well so far.
Hi folks,
We're happy to let you know that the first version of Beta Features (1) has now been deployed worldwide on all wikis.
Beta Features is a new program that lets you test new features on Wikipedia and other Wikimedia sites before they are released widely. Think of it as a digital laboratory where community members can preview upcoming changes and help designers and engineers make improvements based on their feedback.
This first worldwide release includes these features:
* Media Viewer — view images in large size (2) (7)
* Typography Refresh — make text more readable (3)
* Near this page — see what other pages are nearby (4)
* VisualEditor Opt-in — edit pages without having to learn wiki code (5 - see below)
* VisualEditor Formulæ — edit algebra or equations on your pages (6 - see below)
(Note that Visual Editor Opt-in is only on a couple hundred sites where it was already available, but not enabled by default.)
We invite you to test these new features on your sites and let us know what you think. You can share your feedback about this Beta Features program on its discussion page (8) -- or about individual features on their respective discussion pages (see links 2-6 below). And if you find any technical bugs, please report them on Bugzilla (9).
We also invite you to join tomorrow's office hours IRC chat, this Friday, 22 November, 2013 at 18:00 UTC. (10)
Many thanks to all the community and team members who made this program possible! We hope it can help us improve Wikipedia together and provide a better experience for all our users around the world.
Enjoy,
Fabrice -- on behalf of the Multimedia, Visual Editor and Design teams
(1) About Beta Features:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
(2) About Media Viewer v0.1:
https://www.mediawiki.org/wiki/Multimedia/About_Media_Viewer
(3) About Typography Refresh:
https://www.mediawiki.org/wiki/Typography_Update
(4) About Nearby Pages:
https://www.mediawiki.org/wiki/Beta_Features/Nearby_Pages
(5) About Visual Editor Opt-in:
https://www.mediawiki.org/wiki/VisualEditor/Beta_Features/General
(6) About VisualEditor Formulæ:
https://www.mediawiki.org/wiki/VisualEditor/Beta_Features/Formulae
(7) Media Viewer - New Version 0.2:
https://www.mediawiki.org/wiki/Lightbox_demo
(This new version displays larger images, for a more immersive experience. It is now on MediaWiki.org only and will be released to all wikis in early December.)
(8) Discuss Beta Features:
https://www.mediawiki.org/wiki/Talk:About_Beta_Features
(9) Report a Bug:
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
(10) Office hours IRC chat - Friday, 22 November at 18:00 UTC:
https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
P.S.: If any community member would like to hide the 'Beta' link in their personal menu, they can easily remove it by going to their personal style page [[Special:MyPage/common.css]] and pasting in this CSS rule on a line by itself: "#pt-betafeatures { display: none; }" (do not include the quotes).
____________________________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Hi,
Is there some effective way to retrieve a list of namespaces for a
wiki? In huggle we have that hardcoded now, but that kind of suck,
because every wiki can have some custom NS.
Example: https://github.com/huggle/huggle3-qt-lx/blob/master/huggle/wikipage.hpp
//! Namespaces
enum MediaWikiNS
{
MediaWikiNS_Main,
MediaWikiNS_Talk,
MediaWikiNS_Project,
MediaWikiNS_ProjectTalk,
MediaWikiNS_User,
MediaWikiNS_UserTalk,
MediaWikiNS_Help,
MediaWikiNS_HelpTalk,
MediaWikiNS_Category,
MediaWikiNS_CategoryTalk,
MediaWikiNS_Mediawiki,
MediaWikiNS_MediawikiTalk,
MediaWikiNS_File,
MediaWikiNS_FileTalk,
MediaWikiNS_Portal,
MediaWikiNS_PortalTalk,
MediaWikiNS_Special
};
Is there a way to retrieve:
* Namespace original name (the english one which can be used on any
language wiki, like User or Talk) and its talk id
* Namespace localized name and its talk id (User talk for User)
* Namespace ID
for every namespace that is known by a wiki?
Heya,
I am trying to write an extension to create magic words/parser functions via a SpecialPage, which then queries
windows computers via WMI. There are too many class/column combinations in WMI to create a function for every
single one of it, so I want to create a generic handler function which is called with class and column as
function arguments.
When trying to do that I run into 2 problems:
1) The code of the callback gets executed, but the return value is not displayed on the wiki page; the space
where the result of the parser function should be just stays blank (the magic word is removed). I tried setting
a non-anonymous callback function which worked fine.
2) Whenever I try to add a new magic word via my special page I get "internal error: invalid magic word",
whenever I try to access any page of the wiki, until I run maintenance/rebuildLanguageCache.php --force.
Can I in some way "enforce" just rebuild the language used for magic words? Or make it available in any other way?
========
Code Problem #1:
<?php
[... some more extension stuff...]
$wgHooks['ParserFirstCallInit'][] = 'setupWMIMagic';
$wgExtensionMessagesFiles['AddWMIProp'] = dirname( __FILE__ ) . '/newmagic.i18n.php';
$wgExtensionMessagesFiles['AddWMIPropAlias'] = dirname( __FILE__ ) . '/newmagic.alias.php';
require_once( dirname( __FILE__ ) . '/MagicWordHandler.inc.php' );
$hookFunctions = array();
function setupWMIMagic( &$parser ) {
// Load magic words from datafile
// This will return an array of arrays of the form:
// array(
// 'mword' => 'someword',
// 'class' => 'Class name',
// 'column' => 'Column name'
$mwh = new MagicWordHandler();
$mymagicwords = $mwh->loadMagicWords();
$magicWords = array();
// if there are no Magic Words in our datafile, we just return
if( !$mymagicwords ) {
return true;
}
foreach( $mymagicwords as $word ) {
// create an anonymous function for each word and set it as a hook
$hookFunctions[ $word['mword'] ] = function() use ( $word, $parser ) {
processWMIMagic( $parser, $word['class'], $word['column'] );
};
//setFunctionHook( WORDID, CALLBACK, FLAGS ) - SFH_NO_HASH creates {{MAGICWORD}} instead of {{#MAGICWORD}}
$parser->setFunctionHook( $word['mword'], $hookFunctions[ $word['mword'] ], SFH_NO_HASH );
}
return true;
}
function processWMIMagic( $parser, $class, $column ) {
$title = $parser->getTitle();
// this appears in the apache's error log
error_log( "GOT: $class, $column, $title" );
$output = "TITLE: $title CLASS: $class COLUMN: $column";
// this seems to be ignored. I also tried it with noparse => true and several other options
return $output;
}
========
Code Problem #2 (newmagic.i18n.php):
[... some other lang stuff...]
require_once( dirname( __FILE__ ) . '/MagicWordHandler.inc.php' );
$mwh = new MagicWordHandler();
$mymagicwords = $mwh->loadMagicWords();
$magicWords = array();
if( $mymagicwords ) {
foreach( $mymagicwords as $word ) {
// Define the magic words
$magicWords['en'][$word['mword']] = array( 0, $word['mword'] );
}
}
So, are there any mistakes in the code? Is there anything I am missing?
How can I debug this further? I am kind of lost here ;)
Thanks in advance.
Greetings
Sven