Yes, I think that a GSOC project related to Proofread Page is a very good idea. The things
to do would be:
1. Refactoring of the extension code by splitting the very big file ProofreadPage.body.php
that do too much things into specific classes what will be more easily testable. Write
unit tests for them.
compatible with the VisualEditor. This includes:
- for wikitext editing system a full rewrite in order to make the code readable and
testable. The tasks would be:
- move to server part of the extension things that can be done by it as it have been
done for Index: pages.
- use libraries packaged with MediaWiki like JQuery when possible.
- find and use a good free JS library for zooming into scans in order to improve the
current zoom feature that might be enhanced.
- work with the Visual Editor team in order to make the Visual Editor work with Page:
pages. The first step is to make the body of the page editable, then the proofreading
level and, if it's possible, header and footer.
3. Add modules to the Visual Editor to support specific tags used by Wikisource like
<pages>, <section> and <poem>.
4. Allows to edit using the Visual Editor textareas of the Index: pages form.
What do you think about it?
PS. I CC QGil and Sumanah who manage GSOC.
Date: Mon, 25 Mar 2013 15:05:46 +0100
Subject: Re: [Wikisource-l] Missing project ideas for GSOC
To: wikisource-l(a)lists.wikimedia.org; dacuetu(a)gmail.com; thomaspt(a)hotmail.fr
Do you think that working on the Proofread extensionfor making it compliant with the brand
new Visual Editorcould be feasible?I know that Tpt (in cc) was working on it,
maybe it would be a good (and useful) project.
On Sat, Mar 23, 2013 at 12:43 PM, Andrea Zanni <zanni.andrea84(a)gmail.com> wrote:
That is a really good opportunity. We also have
that we set up at Wikimania 2012.
Few of those thought are now in the Wikisource Grant proposal, too:
I would say that a proper metadata handling system is maybe the first priority, but maybe
we can accomplish that via Lua templates on WS andmetadata stored in Wikidata.
Another thing would be working with OKFN tools for seeking and integration (TEXTUS, for
Moreover, Djvu support/handling was an interest also of the
Well, there's a lot of stuff we can do :-)
On Sat, Mar 23, 2013 at 3:02 AM, billinghurst <billinghurst(a)gmail.com> wrote:
It was suggested to me that the Wikisources should be paying attention to
the opportunity available through WMF's participation in Google Summer of
I have started a discussion at
-------- Original Message --------
Subject: [Wikitech-l] Missing project ideas for GSOC
Date: Wed, 20 Mar 2013 16:43:23 -0700
From: Quim Gil <qgil(a)wikimedia.org>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Organization: Wikimedia Foundation
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
It's time to start defining what we want our Google Summer of Code to be
all about. Let's look at the ideas we are proposing to potential students:
Many of the ideas listed there are too generic ("Write an extension"),
improvements of existing features ("Improve Extension:CSS") or
work-in-progress tasks ("Fix Parsoid bugs"). Many others are not
directly related with development, and therefore not suitable either for
After this filtering, we seem to be left with:
* Article evolution playback tool idea
* An easy way to share wiki content on social media services
* Write an extension to support XML Sitemaps without using command line
* Add support for x3d 3D files to MediaWiki
* Allow smoother and easier Wikimedia Commons pictures discovery
* Build an interwiki notifications framework and implement it for
* Automatic category redirects
(If you think your project should also be considered here please speak
Most of these projects seem to be extension (and PHP?) centric. Can we
have more diversity? Maybe gadgets and templates are too simple for a
GSOC project? What about the mobile front? Do we have skin development
projects that could make it here? Anything in the DevOps area? Anything
the MediaWiki core maintainers would like to see happening?
It would be also nice to have more candidates benefiting specific
Wikimedia projects. Beyond Wikipedia, we have several proposals related
to Commons. Wikidata seems to be joining soon. What else? Could this be
a chance to help Wiktionary, Wikibooks or any other project with
specific needs craving for tech attention?
Also to the many students that have already showed their interest: feel
free pushing your project ideas now!
Technical Contributor Coordinator @ Wikimedia Foundation
Wikitech-l mailing list
Wikisource-l mailing list