Central Notice powers almost all of the banners that you see on Wikipedia and the sister projects. The recent fundraiser exposed some limitations in the interface that would we greatly alleviated by having a read-only API to query information such as:
which campaigns are enabled and where are they targeted?
what banners are associated with a campaign?
what are the banner allocations in a certain country/project/language?
In addition to providing resources for fundraising and other campaigns, the API would allow for mashups with services such as Google Earth enabling geographic visualizations of enabled campaigns and banners.
Note: Judy is busy during Chinese New Year's. Happy New Year!
Glanceable display for mobile & editorial tools for tablet UIEdit
Build on the existing Phonegap app, adding homescreen widgets that give people a glanceable display, make the content more browseable. Maybe add additional editorial tools for tablets. Start with Android, move on to Blackberry, Windows Phone 7, etc.
Created a standalone web app usable via any mobile or fixed device (desktop, laptop, smartphone, tablet, etc.), which can access the webpage and search for nearby Wikipedia articles within a radius of 5 miles (this is configurable). The articles are then mapped via Google maps with custom markers and clicking on the markers will direct the user to the respective Wikipedia article on the browser.
Demo'd and tested via smartphone (iPhone 4, HTC tablet, various laptops). Not tested with IE.
To setup and use as a standalone app:
Set up a LAMP stack - fire up your browser of choice
Get the php and image files from Github (see below)
Put them in the appropriate places in your LAMP setup
Go to "http://<your_localhost_ip>/<your_lamp_stack_path>/search_nearby.php".
Click on the big button and see the map with your current location and nearby Wikipedia articles.
Click on the article markers for summary information and click on the title to go the full Wikipedia article in the browser.
Note: Uses geonames.org API to retrieve nearby article information.
Acknowledgements: Roan (for providing API help for my first project - which got toasted on Saturday afternoon since it was already done), Yuvi (for telling me about geonames.org), Tomasz (for helping me debug XAMPP on my windoze laptop which was causing much network trouble).
Currently, in the process of being incorporated into the mediawiki open source repository with direction from RobLa and PReilly.
Rob Moen worked on a gadget to help inform users about the status of bugs they care about. It might be good for pages which use bug templates like mw:Template:Tracked. If you polish it, we might promote it to default gadget or site script.
It would be nice to have a link that opens a small pulldown list of the last pages the user edited. This is kind of like a ajax version of the user contributions page, but lists pages, not edits. -- Duesentrieb⇌ 22:41, 19 January 2012 (UTC)
It would be nice to have a link that opens a small pulldown list of the last users who edited a page (excluding minor edits and pots). This is kind of like a ajax version of the user history page, but lists users, not edits. -- Duesentrieb⇌ 22:41, 19 January 2012 (UTC)
Automatically categorize Wikipedia articles by first identifying candidate articles based on similarly categorized articles, then presenting these candidates to logged-in users by way of a Special page. These users can commit or reject the change without leaving the page. The target article's history reflects the change under that user's username. We do not plan to support automatic article modification.
Candidate article identification happens in a separate process (not an extension or Gadget) that tentatively uses data dumps to create a graph representation of articles and category trees. We search for anomalies in clusters while filtering out semantically inappropriate suggestions.
Project name, in-depth technology discussion, and Github repo are forthcoming.
We will build a tool to automatically evaluate the quality of an article, combining manual article assessment with other metrics. This tool should guide readers on improving articles, help educators understand the nature of collaboratively-created content, and illustrate the evolution of article quality from new perspectives.
Sites like Wikia, Occupy MediaWiki, WikiHow, and others have dozens or hundreds of MediaWiki installations running off the same databases. They'd like a wiki family management extension so they can store and load configuration sets in a database.
Visualize the effects of the January 18th blackout - TENTATIVEEdit
We blacked out English Wikipedia to protest SOPA and PIPA this week. Now we have an data set and would like to visualize it across the world.
Data we have: millions of entries with timestamp + ZIP code that was looked up, and possibly the timestamps of clicks on social media buttons (e.g. Facebook & Twitter).
We'd like to map out strong nodes of participation, visualizing what happened over the course of the day (changes). Perhaps we could add an ability to hover/click to get names of Representatives & Senators. Additional timelines it would be cool to cross-reference: other sites' protests starting and stopping, and the numbers of pro-PIPA Senators and pro-SOPA Representatives decreasing over the course of the blackout.
Short-term messaging is a feature missing in MediaWiki. There is a prototype of StatusNet integration with MediaWiki which was developed by Daniel Kinzler and Hallo Welt!. I'd like to discuss the usability of this prototype and figure out what's needed to make this a cool collaborative tool. Also, there are still some integration issues that need to be tackled :) .
Adding an API to the WorkingWiki extension would be very useful. That's what I'm here to start on - and moving on from there to giving it an attractive, extra-usable Ajax/jQuery interface for the 21st century. - Wonder 04:00, 21 January 2012 (UTC)
One proposal: Enhance revision ids to support version vector, initial goal will be to ease the 3-way merge bottleneck. Tolerate article text in an ambiguous state, meaning that unresolved conflicts will result in a fork which can be cleaned up later by the original poster or an editor.
This change to revision ids will also allow for asynchronous replication, in cases such as university collaborations or on unreliable networks. A rough analogy is that MediaWiki databases would act like a distributed version control system (git) such that people could clone and fork them.
Currently, the ProofreadPage extension (critical to the Wikisource project) doesn't have a maintainer, and is one of the more fragile components in our deployment chain. There's some work that's needed in order for this extension to be ready for Wikimedia's 1.19 deployment, and some testing that needs to happen before we can feel confident putting it out there. We plan to get a labs instance of this extension, and help a possible new maintainer get up-to-speed.
Walkthrough current extensions for input support using on-screen keymaps (Narayam) and font support for rendering non-Roman fonts using extension WebFonts. Identify open source fonts for Farsi/Persian (and other related languages such as Urdu and Kashmiri) as well as Korean for integration into WebFonts as well as develop keymaps for Narayam.