Wikipedia:Wikipedia Signpost/2010-08-16/Technology report
Bugs, Repairs and Internal Operational News
What would the ideal WYSIWYG editor for MediaWiki look like?
Following on from discussions last week around an enhanced in-built wikitext editor, discussion on the wikitech-l developers' mailing list this week concerned existing and new external editors for the MediaWiki software Wikimedia sites are based on. WYSIWYG ("What you see is what you get") editors of this type "would allow easy editing to newbies, while still allowing to use the full wikisyntax to power users" (as stated by User:Platonides). However, given the complexity of wikitext, WYSIWYGism is notoriously difficult to achieve fully. A list of attempts is given on MediaWiki.org.
This week's discussion started with an external, cross-platform local (rather than web-based)
application. It moved onto another, web-based attempt, the "Myrilion" editor (example). It rewrites the main wikitext parser to OCaml, which can then be turned into a fairly hefty chunk of JavaScript. A number of problems with WYSIWYG editors were discussed, including the inability of many to differentiate between two wikitext elements that give the same HTML output (e.g. [[Foo|Foo]]
and [[Foo]]
) and inadvertently convert between the two. The projects are similar to the Wikimedia User Experience team's attempts to improve the in-built ease of editing MediaWiki projects. The hope is that shared code and experience could be useful in building new attempts to solve the usability question.
In related news, Dutch developer Jan Paul Posma has published a mock-up of what a web-based MediaWiki editor might look like in the future.
Google Summer of Code
The "coding" phase of Google Summer of Code (GSoC) projects has now ended and the "evaluation" phase has begun. Each year, Google sponsors student developers to work on open source projects under the guidance of mentors. This year, six such students were selected to work on the MediaWiki software which underpins all Wikimedia sites:
- Jeroen De Dauw ("Extension management platform")
- Brian Wolff ("Improve [file] metadata support")
- Samuel Lampa ("General RDF export/import in Semantic MediaWiki")
- Sanyam Goyal ("Javascript overhaul of Semantic MediaWiki")
- Stephen LaPorte ("Wikisource Legal Tool")
- Peter Potrowl ("Reasonably efficient interwiki template transclusion")
A full list containing more information (including mentors) on each is also available. The Signpost hopes to catch up with the students in the coming weeks and to establish the success of each project and what it might mean for Wikimedia.
In brief
Note: not all fixes may have gone live on WMF sites at the time of writing; some may not be scheduled to go live for many weeks.
- Colour profiles of images are finally preserved when generating thumbnails of the original image, after a new version of the image scaling software ImageMagick was deployed on the servers last week (bug #19960). The same change also fixed thumbnailing of files with question marks in their names (virtually all had previously been renamed anyway).
- Relocation of servers internally in the datacentre caused a temporary loss of search snippets, "did you mean..." and interwiki searches (wikitech-l mailing list). The transfer is now complete.
- With the resolution of bug #2257, from four years ago, extensions can now access template-style parameters.
- noc.wikimedia.org has a new homepage giving an overview of what it's used for (bug #19191).
- The WMF's CTO Danese Cooper noted on Twitter last week that she was "listening to [a] pitch for [a] possible analytics solution to track traffic at Wikimedia" [1], but that Wikimedians should "[b]e assured we're looking at Privacy. [We are l]ooking for better data in areas we already track (and already publish)." [2].
- Researcher Luca de Alfaro from the "Wikitrust" project has announced a publicly available API which for a given revision of the English Wikipedia gives a score indicating the likelihood that it is vandalized.
Discuss this story
With the resolution of bug #2257, from four years ago, extensions can now access template-style parameters.
I don't think anything has happened recently in that area. Support for {{#tag:}} as a work around for the issue happened ages ago (in 2008), and more recently (one year ago minus about a week), an option was added that allows tag extensions to optionally expand template parameters (rev:55682). I don't see anything new that has happened on that front recently (or really that anything else remains to be done, except for maybe PST in tag extensions). Bawolff (talk) 16:40, 17 August 2010 (UTC)[reply]