Archive for category mediawiki
Usability Beta Enhancements
New watch/unwatch and cascading tabs
Thanks for trying out the usability beta. Close to 280,000 people tried out the usability beta and about 220,000 people continue using it. One of the most-frequently reported frustration about the beta was that (1) watch/unwatch was hidden under the drop-down menu and (2) tabs overlaps when the browser is scaled down or the resolution is low. Tab issues were more significant for language communities whose words tend to be long such as German. We are also simplifying the search box to simplify the interface and in order to minimize the overlapping side-effect. Those new features are currently staged on the prototype wikis in English, German, Japanese, Arabic, Serbian, Russian, and Sinhala. You need to log-in in order to see watch/unwatch tabs. The screenshot on the right is the shot when the browser window is scaled down to 640×480. “View History” is moved to drop down menu in order to keep “Read” and “Edit” tabs visible. Let us know your feedback here.
- Naoko
Update on November 18th: Thank you for your support and feedback. These features are now available in the usability beta across all Wikimedia projects.
Babaco is ready for tasting
Preview of the second set of usability features, Babaco, are available through user preferences. The first feature is the article outline in the right hand side of the editing area. The outline updates itself in real-time as you type the headers in the articles and provides links which when clicked will jump you to the start of each section in the article. The second feature is the assisted way to insert links and tables. Instead of inserting wiki syntax, a dialogue box pops up when you hit the link icon in the toolbar. For internal links, link suggest features offers auto-complete options and validate the existence of articles. A click of the table icon in the toolbar will also assist define the number of rows and columns without modifying table rows and columns in the wiki syntax. Thirdly, new search and replace dialogue is added to the advanced toolbar. These features are released in the stealth mode, which means users need to turn them on by going to user preferences. To enable these features, please go to “My Preferences”, select ‘Editing’ tab and enable the features listed under ‘Experimental features’. We, the usability team, is still refining look and feel, but we wanted to invite active users to start using these features and provide us feedback.
Known Issues: Accuracy of cursor positions using the article outline feature (aka Navigable Table of Contents) degrades in long articles and significant so if you use Firefox. We are also still working on the display issue of NTOC in Firefox2 on Vista. Bug 20669
The release details and discussion can be found in the Babaco discussion page of the usability project wiki. Looking forward to receiving your feedback.
- Naoko
Navigable Table of Contents
Inserting link using link dialogue
MediaWiki’s new discussion system in testing on Wikimedia Labs
Posted by andrew in mediawiki, software, summer of code, wikimedia on October 1st, 2009
I’m very excited to announce that LiquidThreads, the next-generation discussion system that I’ve spent the last few months developing for the Wikimedia Foundation, is now in beta testing on liquidthreads.labs.wikimedia.org.
Sample of the LiquidThreads interface
Supporting translatewiki.net
Translatewiki.net is a core part of the MediaWiki ecosystem. While not a Wikimedia Foundation project, it’s used by hundreds of volunteers to improve the localization of MediaWiki and its extensions, alongside other open source projects, which has led to MediaWiki being one of the most internationalized software packages available.
We’re very pleased to be able to recognize the incredible volunteer efforts behind translatewiki.net at least in a small way. Starting tomorrow, Siebrand Mazeland will be able to devote one day a week to the support of the project on a contract with the Wikimedia Foundation. We’ve identified core priorities for the next year as an increase in the number of volunteer developers supporting the translatewiki.net infrastructure, and the number of volunteer translators working on localization for the most widely spoken languages.
Welcome, Siebrand, and a big thank you to the entire translatewiki.net community for their work. :-)
Erik Moeller
Deputy Director, Wikimedia Foundation
FlaggedRevs test wiki awaits you!
Apparently due to some miscommunications, a lot of people didn’t realize that the FlaggedRevs labs test wiki has been active and waiting for people to poke at it for a month, since just before Wikimania!
We need interested people to be get up as local administrators to try out the the per-page stabilization settings (accessed via the ‘protect’ tab); by default most pages do not activate FlaggedRevs in the configuration we’re testing for English Wikipedia.
I’ve added a couple quick notes to this affect on the main page.
Update: We’re collecting some folks to be bureaucrats and help set up more test admins so we can get things going quick!
LocalisationUpdate in testing
Ok, we still need to complete automation of update runs for LocalisationUpdate, but it seems to be working!
It’s not the most glamorous of extensions, but you can see here an updated message (”Den här sidan” where the current deployed message file says “Denna sidan har”)!
– brion
LocalisationUpdate and ProofreadPage second try tomorrow; Collection too
Updates are coming back for LocalisationUpdate and ProofreadPage extensions, which we tested then pulled Tuesday due to performance problems.
Roan’s redone LU to store the message updates in serialized files instead of the database, which we can sync locally to web servers and should perform much better; I’ll also do a more gradual test rollout so we can scale it back more gracefully if we have problems again.
ThomasV has fixed up some bad queries in ProofreadPage, and it should be ready to go again; the updated version has much more advanced index support and looks pretty spiffy. :)
And if we’ve got time between other things, I’ll roll out the updated Collection as well — this makes big improvements to the UI for building a multi-page book, and leaves the sidebar much less cluttered when you’re not using it.
– brion
Commonist, CommonsHelper fixed
I’ve put in a fix for uploader tools and bots that have been broken since the last update — these bot tools didn’t expect the upload form to change, so they don’t pass in new required fields such as the edit token which was added to the form in the latest update.
Since the edit token isn’t actually required for web uploads (it’s a protection against a class of attacks which, as it happens, can’t forge file uploads) I’ve relaxed the check. I’ve confirmed that it fixes Commonist and have a report that CommonsHelper is also fixed.
Most other bots and tools that were affected are probably also fixed; please test them and let us know if anything’s still broken!
LocalisationUpdate deployment delayed
Problem #1 — causes huge increase in CPU load on web servers
Problem #2 — completely kills THE ENTIRE SITE when you DISABLE it because serialized LUDependency objects in the message cache can’t be reinstantiated.
Sigh… Why can’t life be easy :)
Update 2009-09-23 16:30: Roan is starting work on replacing the database storage layer with a flat-file which should be more efficient for our use case.
Feature deployment updates
Quick note for those who have been asking — we’re starting to maintain a list of feature & extension deployments that we’re rolling out in the very near future and their status on the Wikitech wiki.
Note that some things like the English Wikipedia FlaggedRevs deployment aren’t on there yet; we’ll start prepping something for these in the next round in a couple weeks.
– brion
Help us make Commons work better
It’s come to my attention that Commons has had some more problems than we saw on the other wikis… I want to make sure we get that cleaned up!
Andrew has just deployed some more fixes which should eliminate the ‘file already exists on Commons’ bug. It would be a huge help if folks who’ve been reporting problems can go through the lists on the Village Pump and collect just the problems that are still current:
- Uploads via Commonist — fixed or do we still have problems?
- (Who’s the best person to contact about debugging or developing fixes for Commonist?)
- Missing description page immediately after edit — is this still happening?
- Anything else?
Please add info about confirmed problems or fixes at the Commons Village Pump. Thanks to everybody — your feedback is important; we need to know which bugs are affecting you guys the most!
– brion
Update 2009-09-22 23:49 UTC: I’ve fixed the problem with Commonist by relaxing the edit token check in the form handler (this is safe for uploads via the web, which can’t be injected in a CSRF attack; we still enforce it for upload-by-URL). This probably fixes most of the other client-side upload tools and bots as well — please test!
File renaming enabled for admins
Renaming of uploaded files has been disabled for the last couple of months pending software updates; as of today it is now re-enabled for admins on all Wikimedia sites.
Local admins can now rename files as well as deleting them; this makes it easier to track history for images and other media that need to be moved to another name.
– brion
Update 00:49 UTC 22 Sep: We’ve tracked down a bug which at least on en.wikipedia would cause the redirected old name to stop working for 24 hours. Now fixed; notes for cause and workaround on enwp Village Pump.
Beta edit toolbar disabled temporarily
Due to compatibility problems on Internet Explorer after yesterday’s code update, I’ve temporarily disabled the Usability Initiative’s beta advanced toolbar. If you’ve had it enabled, you’ll just get the regular old edit toolbar until we re-enable it.
Hopefully we should have this resolved within a day or so, and it’ll be back on for all our happy testers!
– brion
Update Sep 18 14:13 UTC: the bug has been fixed, and the toolbar has been reenabled.
Babaco Preview
Screenshot of Navigable Table of Contents
As brion’s earlier post stated, the new set of usability features (nickname: Babaco)are integrate into the source code but disabled until these features are stable. New features include, navigable table of contents and content generation dialogues for links, tables, search and replace. These features are currently staged on the usability prototype environment, and you are welcome to check them out and encouraged to push them hard to find bugs. :-)
We are also hoping to integrate add-media-wizard created by Michael Dale in Babaco. While API to extend the toolbar is being worked on, media import functionality can be played at the usability sandbox environment. Click the “Edit” tab and click an image gallery icon in the toolbar. You will see a nice media import function there. Feel free to create an article and import image from Commons using this neat feature.
Browser compatibility matrix for Babaco is found here. As always, share your thoughts and experience through the usability wiki. Feedback on Babaco goes this discussion page.
- Naoko
Software updates Wednesday morning
I’ve been spending much of the last few work days tidying up an update to our deployed codebase, which has been several weeks behind development for most components.
I’ll want to start deploying this in the morning (Pacific time), so we’ll have most of the day to poke around and fix up any problems on the sites… it’s gonna be fun!
This’ll primarily bring a lot of under-the-hood improvements, which’ll let us start rolling out other fun things over the coming days/weeks including:
- Daily updates of interface translations (LocalisationUpdate)
- Updated PDF collection/book UI
- major cleanup of maintenance scripts
- foundation work for improved uploading support
- foundation work for new UI stuff (JS2 / add media wizard / cool stuff from Usability team)
For those of you poking at the code, I’ve got the pre-deployment code currently sitting in the wmf-deployment-work branch; this’ll get folded back over wmf-deployment when we’re ready to go.
I believe all custom hacks from the current wmf-deployment branch have been either copied over or generalized and merged via trunk… Note I’ve held back updates on ProofreadPage and OggHandler for the moment, and we won’t deploy the new JS2 code yet until we’ve shaken things down some more.
If there are any *critical* trunk fixes from the last few days (since r55160 trunk branch point) that need to be forward-ported before we start, or any other surprises, let’s make sure we know about it soon. :)
– brion
Update 1:30 UTC Sep 17: Most problems have now been shaken out. Probably a few more minor glitches to go, then we can worry about prepping the fun stuff! :)
Full TIFF Support is Coming!
Today I had the first milestone meeting with the folks of Hallo Welt about the TIFF support they are implementing for MediaWiki. This is one of the projects Wikimedia Germany was offering contracts for a while back. Now we are starting to see the first results, cool!
So, what will full TIFF support give us? Nothing spectacular, but something quite useful. TIFF is an image format widely used by museums and in scientific research. It’s also the de-facto standard used in print/reproduction. It is however rarely seen on the web, and browsers generally are not able to display TIFF images. However, the need to deal with TIFF files has increased lately, as we get more and more media from museums and archives. Especially for the people who work on image restauration, it is important to be able to have the original digital version of the image around – which is usually a TIFF file. So, TIFF uploads had been enabled on Commons a few months ago. But MediWiki can’t render them, and nither can browsers. They can’t be used as images on the wiki.
So, what Hallo Welt is doing now is implementing rendering support for TIFF files – which is not so easy, because TIFF files may contain multiple images or pages, similar to PDF files, or the DjVu files we use to represent scanned books. But the project is coming along pretty well, and it looks like it will bring some small improvements also to the existing support for PDF and DjVu files. We are also experimenting with automatic user interface testing using the Selenium framework. If this works out well, we may well use it for more things on MediaWiki in the future.
The project is scheduled to be completed in November, and I hope we will be testing it on the live sites soon after. So, look out for more pretty pictures!
Squashing the Bugs
Posted by Trevor Parscal in mediawiki, wikimedia on August 18th, 2009
Fresh off the whiteboard of the Wikipedia Usability Initiative
Over 40,000 users are now participating in the beta testing of new features for Wikipedia, and other Wikimedia projects. These users have been helping the Wikipedia Usability Initiative to find bugs, of which we are doing our best to squash quickly.
If you are a Firefox 3 user, your experience with the new features has most likely been without issue, but we have found some older browsers such as Internet Explorer 6 to be less stable, especially for projects which use a right-to-left language. After collecting information on browser compatibility and evaluating each browser’s capabilities against the technologies we are using to achieve a better editing experience, we’ve designed a map of which browsers support the new editing tools well enough to ensure a quality user experience, and which do not. Where users’ browsers do not support the new editing tools the old editing tools are provided instead.
While we hope that we can extend support to some of the currently unsupported browsers, we are focusing our efforts on developing a richer browsing and editing experience for users of more modern browsers. Thank you to everyone who has been participated so far in our beta testing process!
– Trevor Parscal (trevor @ wikimedia.org)
Software Developer, Wikimedia Foundation
Try the usability beta!
Have you noticed the “Try Beta” link on the top of Wikimedia project sites? The usability team is proud to introduce the new skin, Vector, and the enhanced toolbar. Well, they have been available from user preferences over a month now, but we wanted to reach out to anonymous users. Please check it out and let us know your thought, if you haven’t tried already. We deployed a bunch of bug fixes since the release on July 1st. Right-to-left languages are fully supported, and you will see integrated special characters in the tool bar. If you are a administrator of Wikimedia project sites, we would like to ask you a favor. Please consider removing the special character menu below the editing dialogue box in edit page. As special characters are easily accessible from the toolbar, it will be good to reduce the duplication to make the page simplified. The special character in the toolbar has generic universal set. If you find missing character sets or have a request, please let us know through the project page or file an enhancement request via bugzilla under User Interface.
Arigato!
Naoko Komura
Usability Initiative
"Try Beta" screenshot
Special Characters screenshot
SVG for all… with Flash?
Posted by brion in mediawiki, open-source on July 29th, 2009
For several years, we’ve supported uploading SVG vector images to Wikimedia sites… with the limitation that they would be rendered to static PNG raster images when actually used inline.
This gives our editors great flexibility in editing, customizing, and translating maps and diagrams using cross-platform free tools like Inkscape, but we’re missing out on some of the big potential in SVG — high-quality scaling for zoomed displays and printing, and animation and scripted interactivity.
In large part we can blame Internet Explorer — the most widely used browser has never supported SVG graphics natively, and Adobe isn’t even maintaining their plug-in anymore! With the majority of users cut out, we’ve had little incentive to move forward with new capabilities that would be closed to most visitors.
But that may be changing, thanks to… Flash??
svgweb implements a highly capable SVG renderer in JavaScript and Flash, bringing high-quality, scriptable SVG support to the ~95% of web users who have either Flash or a naitvely SVG-capable browser.
I love to see Flash’s near-ubiquity used for good — implementing support for modern, open web standards on older and less capable browsers.
One of the chief drivers of the project is Google open standards evangelist Brad Neuberg; we had a great talk today along with Trevor on our Usability team and Michael of Metavid/Kaltura/video awesomeness, and we’re all very excited at the possibilities.
We’re going to see if we can whip together some basic integration in time to show at the SVG Open conference in October, starting with a basic zoom-and-pan view for SVG images which can make use of native or emulated SVG support.
Future ideas that have us really excited include:
- Live previewing of parameterized images at insert time (localized text, highlighted map segments, charts, etc)
- On-web basic vector image editing? Sometimes you just need to make an adjustment and installing Inkscape is kind of heavyweight.
Pure SVG + Javascript should be able to provide for selecting, moving, adding, and altering objects, which we could then save back to a new version of the file… svgweb’s powerful scripting support should be able to extend this to Internet Explorer users too!
Use of SVG originals inline in article pages is more dependent on file size issues. We have a lot of files that are just plain huge, especially detailed maps, and the SVG version ends up being a lot slower to download and display.
A project which can help with that is Scour, a tool to optimize SVG source by stripping out unneeded verbosity and rearranging style bits to keep size down.
With further work to strip out detail that will never be visible, a filter like this could let us produce output files that are more suitable for on-screen viewing while still scaling up nicely on zoomed displays and printed output.
OER Search Discovery – not just another TLA
Posted by brion in mediawiki, open-source, software on July 10th, 2009
I’ve spent today in sunny Cambridge, MA attending the OER Search Discovery 2009 workshop at Harvard’s Berkman Center. But what’s it all about?
First off, what’s OER?
Open Educational Resources are a litle tough to really define to everyone’s satisfaction, but we can defer the details. :) We’re generally talking about pedagogical materials (something that could be put to use in the classroom to teach students) available under some sort of open content license.
Secondly, what’s OER search?
Creative Commons’ ccLearn project has put together DiscoverEd, a prototype search engine which includes some relevant metadata (subject matter, language, target age range, license) as well as metadata about which collection of resource links it came from. This is rather clever, allowing teachers or students to limit their searches to what’s relevant as well as what’s trusted.
Third, what’s OER search discovery?
Traditionally, most electronic educational resource collections have been walled silos. Even if the materials themselves are open and redistributable, the collections’ searches are separate, and often there’s been confusion over the openness of the metadata as well which has held back federated searches on a larger scale.
With major search engines like Google and Yahoo now starting to index metadata embedded in web pages (RDFa and/or microformats) and make them available for searches, this a great time to start pushing more active and integrated semantic search data. (Note: here we’re talking about metadata about the actual materials, not about the subject of the materials. That’s a matter for another day!) Content creators — if enabled by content management tool developers — can start actually getting some concrete benefit from embedding semantic data into their web sites. These’ll be picked up by the general search crawlers, but will also be available to targeted repositories collecting links and metadata about educational materials on the web.
How can we benefit?
There are two sides of this which Wikimedia can work at:
- On the content creation side, we can provide more ways to add useful metadata to our pages, making it easier for teachers and students searching through educatinoal-themed portals to find them. MediaWiki already provides basic language and license information, but projects like WikiBooks and Wikiversity (as well as other MediaWiki users like WikiEducator) could definitely benefit from a consistent way to specify the subject and target audience of lesson modules.
- On the consumer side, we want to be able to find and use free/open media resources from elsewhere on the web to supplement the ones we already have on Wikimedia Commons. The in-development Add Media Wizard can currently search and fetch from a few hardcoded repositories like Archive.org and Flickr, but editors could benefit a lot from having either broader (whole internet search like Google Images with license limits) or narrower sources (a particular educational resource repository desired by a given site or community).
How can we help?
- We’ll want to find a good, clean, maintainable, and easy to use way for wiki page authors to add resource metadata to their pages, which can be exposed to spiders and repository crawlers. RDFa vs microformats vs XHTML vs HTML 5 needs some resolution on the output format, but more interesting is making sure we have a clean user interface/workflow in the edit window without cluttering up the wiki markup.
- If/when folks standardize on a search query format as well, we can make it absurdly easy to add specific repositories to the MediaWiki media picker. In the meantime, we can target some whole-net search engines that index license and subject metadata such as Yahoo’s SearchMonkey, which will provide relevant indexing of web sites which have provided for metadata autodiscovery with embedded RDFa etc.
- We might also think about acting as a repository ourself — Wikipedia and our sister projects are full of references to excellent resources both online and off. Can we record what we know about them and make that searchable internally and externally?
Folks at the workshop are also hoping we can agitate for similar moves in other tools… I know I would benefit from a free media picker for WordPress!
Improving Wikimedia’s Discussion System
Hi all,
Some of you might have already seen my blog posts about LiquidThreads, Wikimedia’s in-development discussion system.
For those who haven’t, this is a quick primer on what LiquidThreads is, and what it’s going to do for Wikimedia’s communities.
Currently, Wikimedia’s discussion system sucks. Here’s why:
- It’s not easily usable by the average user. It isn’t obvious how to leave a comment on a talk page, or how to reply to a comment. The indenting we use now is ad-hoc and unsustainable for long discussions.
- Signatures are done manually and we have to jump on poor unsuspecting newbies who don’t know this (or write bots…)
- Archiving is done unevenly by bots, which are maintained by users and therefore of very uneven quality. Archives are something of a black hole — they aren’t searchable, easily maintainable or easily accessible. You can’t resurrect an archived discussion easily, nor can you view its history.
- It’s stored as plain wikitext, which is opaque to any sort of automated process.
- You can’t move a thread to a different discussion page and preserve its history.
- There’s no encouragement, mechanism or incentive for quoted, point by point inline replies like we’re all used to with e-mail.
Imagine being a new user and trying to figure out how to add your comment to this.
Enter LiquidThreads. LiquidThreads is a system that makes MediaWiki’s discussion system behave like a forum or comments thread, while still maintaining the unique refinements that make wikis work. It was originally designed by a Google Summer of Code student, David McCabe, and I’ve been making incremental improvements to make it work for Wikimedia.
Overview of the new LiquidThreads interface
So, what’s changed?
- Comments are separated from each other in the wikitext, so there are no more edit conflicts in discussions, and the usability is vastly improved.
- Instead of indenting, each comment is in its own box, along with its replies. It makes it much easier to follow each post and its replies, and it’s much nicer on the horizontal whitespace. Hopefully, it will be the death of the ‘arbitrary section break’!
- Each post has its own history page, making it easy to see what’s going on with individual threads without trying to navigate the history of a whole page.
- It’s easy to move threads between pages, preserving the page history.
- Discussions are never ‘archived’. Instead, older discussions fall to the bottom of the page, and eventually they drop off entirely, to hit a new page. If you missed the chance to have your say, just reply to a discussion and it’ll be bumped right up to the top of the page again!
- Discussions with recent changes are at the top of the page. Discussions that have fallen dormant fall to the bottom. It’s easy to find out what’s happening!
- You can watch individual threads of a discussion, and even get an email when they’re replied to.
- It’s easy to link to a discussion, and the links are permanent unless the discussion is deleted. There’s no need to point to an archive or to an old revision ID.
If you’re interested, I’ve put together a test setup for you to play with it.
As always, questions, comments and suggestions are more than welcome, in the comments or elsewhere.
First usability release, Acai, is now available.
Posted by Naoko in mediawiki, open-source, software, wikimedia on July 2nd, 2009
The first usability release, Acai, hit Wikipedia and sister projects this afternoon. The new skin, Vector, and the enhanced toolbar can be turned on from the user preference under “Appearance” and “Editing”. Search result page now has a new layout with less daunting information. Vector is only available for left-to-right languages at a moment due to IE6 incompatibility. However, the enhanced toolbar can be selected from all languages and the new search result page is enabled globally. We could not roll out two features we had planned. First, warning messages for unsaved changes when a user switches away from the edit tab did not work properly thus they are disabled. So please be careful when you switch away from the edit tab. Secondly importing language specific configuration for special characters were not graceful, so we disabled special character function from the toolbar. We are working on the fixes and plan to roll them out as soon as we have stable solutions. The usability project wiki has Vector and the new toolbar as a default, so if you prefer to check them out without changing your preferences it is a good place to visit first. Let us know what you think. We would love to hear from you.
Best,
Naoko
On templates and programming languages
As many folks have noted, our current templating system works ok for simple things, but doesn’t scale well — even moderately complex conditionals or text-munging will quickly turn your template source into what appears to be line noise…
<includeonly><span style="white-space: nowrap;">{{#if:{{{3|}}}|
{{coord|{{{1|0}}}|{{{2|0}}}|{{{3|0}}}|{{{4|N}}}|{{{5|0}}}|{{{6|0}}}|{{{7|0}}}|{{{8|E}}}|{{{9|type:other}}}|format={{{format|dms}}}|display={{#if:{{{title|}}}|inline,title|inline}} }}| {{#if:{{{2|}}}|
{{coord|{{{1|0}}}|{{{2|0}}}|{{{4|N}}}|{{{5|0}}}|{{{6|0}}}|{{{8|E}}}|{{{9|type:other}}}|format={{{format|dms}}}|display={{#if:{{{title|}}}|inline,title|inline}}}}| {{#if:{{{4|}}}|
{{coord|{{{1|0}}}|{{{4|N}}}|{{{5|0}}}|{{{8|E}}}|{{{9|type:other}}}|format={{{format|dec}}}|display={{#if:{{{title|}}}|inline,title|inline}}}}| {{#if:{{{1|}}}|
{{coord|{{{1|0}}}|{{{5|0}}}|{{{9|type:other}}}|format={{{format|dec}}}|display={{#if:{{{title|}}}|inline,title|inline}}}}}}}}}}}}</span></includeonly><noinclude>
{{pp-template|small=yes}}
{{documentation}}
</noinclude>
And we all thought Perl was bad! ;)
Lua
There’s been talk of Lua as an embedded templating language for a while, and there’s even an extension implementation.
One advantage of Lua over other languages is that its implementation is optimized for use as an embedded language, and it looks kind of pretty.
An inherent disadvantage is that it’s a fairly rarely-used language, so still requires special learning on potential template programmers’ part.
An implementation disadvantage is that it currently is dependent on an external Lua binary installation — something that probably won’t be present on third-party installs, meaning Lua templates couldn’t be easily copied to non-Wikimedia wikis.
There are perhaps three primary alternative contenders that don’t involve making up our own scripting language (something I’d dearly like to avoid):
PHP
- Advantage: Lots of webbish people have some experience with PHP or can easily find references.
- Advantage: we’re pretty much guaranteed to have a PHP interpreter available. :)
- Disadvantage: PHP is difficult to lock down for secure execution.
JavaScript
- Advantage: Even more folks have been exposed to JavaScript programming, including Wikipedia power-users.
- Disadvantage: Server-side interpreter not guaranteed to be present. Like Lua, would either restrict our portability or would require an interpreter reimplementation. :P
Python
- Advantage: A Python interpreter will be present on most web servers, though not necessarily all. (Windows-based servers especially.)
- Wash: Python is probably better known than Lua, but not as well as PHP or JS.
- Disadvantage: Like PHP, Python is difficult to lock down securely.
Any thoughts? Does anybody happen to have a PHP implementation of a Lua or JavaScript interpreter? ;)
– brion
Update:
Hampton reminds me that Ruby has some sandboxing features and may also be a contender.
Chinese-language search fixes for MediaWiki
Search is an important part of any web app like a wiki, but search is harder than it looks — especially in a multilingual environment. MediaWiki has to support not just your standard Western languages like English and Spanish, but many more with special requirements:
- Some can be written in multiple scripts (such as Serbian in Cyrillic or Latin), and searches should match text written either way.
- Some languages don’t use word spacing, like Chinese and Japanese. To let the search index know where word boundaries are, we have to internally insert spaces between some characters:
维基百科 -> 维 基 百 科
Then to add insult to injury, we need to fudge the Unicode characters to ensure things work reliably with older and newer versions of MySQL:
维 基 百 科 -> u8e7bbb4 u8e59fba u8e799be u8e7a791
For a long time, this word segmentation wasn’t being handled correctly for Chinese in our default MySQL search backend, so searching for a multi-character word often gave false matches where the characters were all present, but not together.
This is now fixed for MediaWiki 1.16; the intermediate query representation passed to the search backend now internally treats your multi-character Chinese input as a phrase, which will only match actual adjacent characters:
维基百科 -> +”u8e7bbb4 u8e59fba u8e799be u8e7a791″
Note that Wikimedia’s sites such as Wikipedia run on a fancier, but more demanding, search backend with a separate Java-based engine built around Apache Lucene. Sometimes we have to remind ourselves that third-party users will mostly be using the MySQL-based default, and oh boy it still needs some lovin’! :)
The Wikipedia Usability Initiative is still hiring.
Posted by Naoko in mediawiki, open-source, software, wikimedia on May 20th, 2009
The Wikipedia Usability Initiative has extended the application deadline for the Software Developer position till May 30th. We are recruiting two candidates for this position. Both local applicants to the San Francisco Bay Area and remote applicants are encouraged to apply. Please help spread the word.
http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_(project)
Naoko Komura
Wikipedia Usability Initiative