Following are a list of still-open bugs that have gotten new patches in
the past week. I need committers to these over and either provide
feedback if the patch needs improvement or commit them with a reference
to the bug and the person who supplied the patch.
The commit message should look something like this:
Fixes Bug 7 - Explain the wiki syntax in detailed EBNF
Author: Niklaus Wirth
Niklas Wirth writes: "I decided you to show you how it is done."
Your help in getting code donations from Bugzilla integrated into
MediaWiki is appreciated.
The Patches:
https://bugzilla.wikimedia.org/2700
Pre-save transform skips extensions using wikitext (gallery,
references, footnotes, Cite, pipe trick, subst, signatures)
https://bugzilla.wikimedia.org/10574
Export pages should allow to export all pages
https://bugzilla.wikimedia.org/30332
API spamblocklist error should provide *all* blocked URLs,
not just one
https://bugzilla.wikimedia.org/32626
Backlinks generated by <references/> shouldn't be visible in
printed version of pages
https://bugzilla.wikimedia.org/33537
RFE: Hook to change Enotif recipient list
https://bugzilla.wikimedia.org/33546
Serbian (sr-ec and sr-el) should support GRAMMAR parser
function
https://bugzilla.wikimedia.org/33582
Make it possible to automatically add pages to watchlist when
adding a new section
https://bugzilla.wikimedia.org/33595
mwdocgen.php: Add option to not create graphs
https://bugzilla.wikimedia.org/33606
SF_RunQuery.php: Argument 3 passed to Parser::parse() must be
an instance of ParserOptions, null given
Thanks!
Mark.
Why can't MediaWiki do like all major sites' software, and allow setting
the interface language without requiring the user to establish an account?
Observe the bottom of e.g.,
http://www.facebook.com/http://www.flickr.com/http://www.youtube.com/
Each has a language selector that doesn't require login.
http://www.couchsurfing.org/
even puts it right at top.
Yes, patient users can set their language preference in Preferences.
But what about read-only sites? I.e., What should one suggest on
http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_cre…
to say to users who wish to view in a different language?
Painfully suffix "?uselang=..." to the end of each URL they browse?
One might argue "users will confuse MediaWiki uselang= with
XX.wikipedia.org languages" ... well they haven't yet with the language
choice in Preferences.
I'm not saying rip it out of Preferences. I'm saying add an additional
way to set it for even non-logged in users, just like the aforementioned
"real websites" do.
Also consider the current accessibility up until the point the user has
managed to register an account and finally set his/her language
preference... all of which has to be somehow accomplished in the "dark"
of the default language, unless he/she knows to add the magic
uselang=... to MediaWiki URLs every step of the way.
Please don't suggest an add-on for such basic functionality.
OK, I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=33677
Hi all!
What is the best way to control load order of JS (or modules modules in
general)? We (WMDE) are developing WikiPraise, a gadget that can show directly
show who contributed which part of a given article revision, as shown to the user.
WikiPraise works by taking the wikitext annotated with authorship info (a "blame
map", currently provided by the CollaborativeTrust project), render it to html,
then note the offsets of the marker in the generated html (ignoring markup and
whitespace), and store them. When showing a page, the gadget fetches this
authorship info and applies it to the html DOM of the content of the page.
Thomas Schmidt (User:NetAction), who is developing WikiPraise for us, ran into a
problem with other user scripts manipulating the DOM. Since we modify the DOM
based on html offsets, any prior modification of the DOM will break the output.
Thus, WikiPraise must run before any other JS that may modify the DOM.
So, what would be the best way to achieve that? Perhaps we could write an
extension that does nothing but causing the WikiPraise JS code to be loaded
early enough?
We could of course do the entire Wikitext-to-HTML transform on every page view,
instead of trying to annotate the DOM based on a pre-generated, offset based
blame map. But that would a) also have to happen before any other user script
runs and b) would be prohibitively slow (try the WikiTrust plugin for firefox to
see what i mean).
Note that we plan to have this enabled per default even for anons. The idea is
to provide an easy way for fully compliant re-use citing all authors of some
section of an article, and also allowing readers to get a better idea who wrote
what, and what can be trusted.
Anyway: rendering the content based on the annotated wikitext on every page view
would likely melt the servers, so it's not an option. We need to be able to
apply some sort of pre-generated blame map to the DOM.
Or, of course, we could hook into the parser and do all this inside mediawiki.
We we'd need to call out to fetch or generate the blame map when parsing. If we
had a high performance blame implementation that could be tightly integrated
with mediawiki, this would work. I would prefer that, and we might work towards
that, but it would be nice to have a low-impact implementation first. And the
current approach works pretty well, except for other user scripts interfering.
To try WikiPraise, put this into your common.js:
$.holdReady(true);
mediaWiki.loader.load("https://toolserver.org/~netaction/wikitrust.js");
Note that this will disable all gadgets and custom scripts: $.holdReady(true) is
a hack to prevent other user scripts from running. That sucks of course.
Any ideas?
-- daniel
Hello all,
I’m really happy to announce that Fabrice Florin is joining the
Wikimedia Foundation as Product Manager for New Editor Engagement.
In this position, Fabrice will take the lead in articulating and
refining, in partnership with the community and the engineering team,
the requirements for some of our most important features: those which
will help us increase the engagement and retention of new contributors
to Wikimedia projects.
Fabrice has already been supporting us as a contractor on the Article
Feedback V5 project, and I’m really pleased that he’s joining us
full-time, starting next week.
Six years ago, Fabrice founded NewsTrust, a non-profit organization
dedicated to to helping people find quality journalism. As its
Executive Director, Fabrice built the organization and the product
from scratch, with a small team. NewsTrust is a fascinating community
in its own right, and Fabrice and I first met when we discussed what
lessons could be learned for Wikimedia’s own forays into
rating/assessment tools.
Before that, Fabrice had a long carreer in the tech and media
industry. He was VP of Online Entertainment at Macromedia, CEO of
Zenda, Executive Producer at Apple, and President of Videowest. Read
more in his online bio: http://bit.ly/fab-bio
Fabrice is perhaps the first WMF staffer with an IMDB entry. He
directed the 1984 documentary “Hackers” which featured early tech
luminaries like Bill Atkinson, Lee Felsenstein, Richard Stallman and
Steve Wozniak.
Please join me in giving him a big welcome to the Wikimedia movement. :-)
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
We've been getting great bug reports from our testers but can always use
more. If you have an Android phone then follow the link below to learn how
you can help
http://lists.wikimedia.org/pipermail/mobile-l/2012-January/005284.html
Were looking to start pushing to the major Android stores next week and
need your help to get there.
thanks!
--tomasz
Three new Subversion committers today:
Andrew Otto (otto, User:Ottomata) is a new Wikimedia Foundation
analytics guy. He now has core access.
Erek Dyskant (edyskant) is a new WMF contractor in the Community
Department doing community analytics. He now has extensions/tools access.
DrTrigon now has pywikipediabot access to work on pywikipediabot.
Welcome!
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
On Wed, Dec 14, 2011 at 9:00 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:
> We still want to do something about parser performance in the first
> half of 2012, so we're going to bring forward our other performance
> project, i.e. server-side scripting embedded in wikitext. That's a
> project which is still at an early stage of planning. We will need to
> define its scope, and to bite the bullet and make some tough design
> choices (such as Lua versus JavaScript), if it's going to progress
> from pipe dream to reality.
Let's resolve to have all of the big pieces nailed down by January 31.
In particular, it should be possible to make the WikiScript vs Lua vs
Javascript decision well before that time.
There already seems to be a credible starting point for Lua and
WikiScript, but not yet one for Javascript or any other language. Is
there anyone willing to put together a Javascript proof-of-concept?
Rob
We currently have a large number of file uploads with no licensing
data on MW wiki! And we should really start doing something about it,
As some people may have noticed last week(ish) I went though and tag
most (if not all) of the uploads from this year that didn't have the
licensing data. The current figures stand at:
* Tagged as being from this year : 182
* From "Cat:Files with unknown copyright status" : 28 (Minus this years)
* From "Cat:Images with unknown copyright status" : 66
TOTAL TAGGED : 276 Files
Now the question is where to head from now, Personally I would like to
use this as a warning message and start deleting them soon (We already
threaten to do this on the Upload page for files missing License &
Source data) starting at the oldest, But I didn't look at the
uploaders closely and I know a few of them are active when I was
tagging but I know a few of them have automatic license stalemates on
their user pages and don't put license statements on their uploads
unless nudged.
So the floor is open! What course of action should we take?
-Peachey