Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts Tagged ‘deployment’

Adding guided tours to Wikipedia

One of the great strengths of Wikipedia is that community members can employ the same tool used to write the encyclopedia – a wiki – for collaborating on documentation about the project. The downside of this approach is that these pages, written by encyclopedists, tend to be broad and extremely detailed. New contributors to Wikipedia face a daunting list of thousands of help pages, policies, guidelines, and best practices that have developed over our 12-year history.

Today, we’re happy to announce interactive guided tours, a new software feature that will enable Wikipedia editors and readers to learn about the project in a way that is much easier to digest. Wiki-based documentation can now be complemented by concise, step-by-step instructions presented via tooltips. Instead of simply describing a process, we can show you how to complete it yourself, and when you’ve seen enough, you can dismiss a tour instantaneously.

Screen Shot 2013-01-31 at 2.58.10 PM

A step from our new tour introducing first time contributors to the mechanics of editing Wikipedia.

Our team, editor engagement experiments, has built two Wikipedia tours to go along with today’s launch. First, a meta-tour to show community members how they operate, and second, a tour associated with our experimental “getting started” workflow, which helps people who’ve just registered make their first edit to the encyclopedia. You can see the test tour for yourself, right now.

We’ll be adding more tours soon, including in languages other than English, but Wikipedians won’t need to wait for us. Using simple JavaScript, community members can build their own tours, empowering each Wikipedia to create content that fits their particular use case. For Wikipedians and developers interested in creating guided tours, be sure to check out our project page. Our implementation of guided tours uses a version of the open source Guiders.js, and we’re happy to say that we’ve contributed back upstream to the original library as we’ve adapted Guiders to our needs.

Today’s release is just the first step toward experimenting with guided tours. We hope that in the weeks to come, we can find more areas of the encyclopedia where these tours can provide simplicity and clarity to the process of learning how to contribute to Wikipedia.

Steven Walling, Associate Product Manager

Wikipedia Mobile gets a face lift

A growing number of visitors access the mobile site of Wikipedia and it is an area the engineering team is keen to improve. To do this, we are offering a more functional and polished experience adapted for mobile users, who operate in a much more confined world compared to those on the desktop.

This week we pushed several new and updated design changes to our beta. We hope these changes will provide a more professional look and a better experience for you. These include changes to the footer, a cleaner design for revealing and hiding sections, and a revamped full-screen search experience. The mechanism for toggling between desktop and mobile has also moved from the footer to the top navigation menu to the left of search to allow users to switch more effortlessly.

References can now be read in place

Full screen search

In addition to this we have also pushed an experimental feature which makes it easier to refer to references on articles without having to plunge to the bottom of the page. Now clicking on a reference will load an overlay which readers can consult without losing their place in the article.

We are keen to gather feedback to stabilise these additions and make these changes available by default to a much larger audience. In particular and as always, we are interested in any device-specific issues being brought to our attention as well as feedback on the new design. Let us know how you find the experience – good and bad and also the quirks that you discover.

We are also experimenting with animations when revealing references and would appreciate thoughts from the community on which is felt to work best. By default, references are revealed by a fade in/out effect but we would appreciate thoughts on whether a slide animation or no animation would be preferable.

Opt in to our beta and try them out today. We look forward to your feedback which can be provided either here or by your involvement in the design process.

– Jon Robson, Software Developer Mobile

The end of a slushed sprint

Consolidation was the name of the game for the past sprint for Wikimedia’s Localization team. A bug triage, testing, documentation and bug fixes were the activities designed to make our software more stable and more usable. When you read the bug triage report it becomes clear how much the devil is in the details; real native language expertise is needed to understand and assess the issues  we aim to solve. Read the report and you will see how much we rely on our community, on people like Srikanth and Nemo_bis.

Now that we are writing documentation in a central place, like here on the language statistics of the Translate extension, we are now able to provide you with a help text that is specific to the context. For the language statistics it is a help text about “statistics and reporting“. This functionality is ready but will become available in the deployment of January 30. You can help us and yourself by reading and understanding the text. Ask when you have questions and you can translate the text and make the text that much more your own.

Narayam is another extension that has been improved with user documentation. This documentation is completely new and it can effectively replace existing documentation. The existing documentation has the benefit of being written in the local language and we expect that what is written will be similar to the Narayam documentation. The language communities can then decide if they want to point to the local documentation. Like all our software, the Narayam documentation will be available for translation. Having the translation ready may be one of the considerations.

A lot of work is going into the description of the many input methods like the Inscipt layout for Assamese. These descriptions are “must have” help information when you do not know a particular keyboard layout by heart. They also provide a wonderful opportunity to verify if our implementation for a particular keyboard method is correct. This is yet another instance where native speakers can help us a lot.

Testing and coming to grips with the different tools was a major goal for this sprint. PHPunit and Qunit is what is used to test PHP and JavaScript and the tests developed are used in an environment called TestSwarm and Jenkins (respectively for PHP and JavaScript). As our team is so much into language support, we are learning what the limits are for testing for different languages and scripts.

All in all there may have been a slush and we have done a lot of code review, but we also managed to make sure that our functionality has gained stability for this and future releases. Additionally, work was done on grammar support for JavaScript, but the patch for that was stuffed in a bug report because of the slush, as the story was moved to the next sprint. Grammar support is what fills the gap in localization support between JavaScript and PHP and makes it available to any and all other developers.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

 

End of sprint 6; Translate and other goodies

Every two weeks a sprint and every week a deployment. The Localisation team aims to bring you new and updated functionality when we have it.

As you can see in the summary below, the focus this sprint has been very much on the Translate extension. Management of translations and the translation process is what we have worked on. When texts are translated in a Wiki, they often are only needed within a specific time frame; it is now possible to mark a text as no longer needing any effort. For many languages there are multiple people involved in the work flow for the creation of a document that is well written in translation. When they are to work well together, it helps when their work changes its state so that it is clear that for instance something has been proofread.

The person who manages the publication and distribution of a page needs work flow states to decide what more needs to be done and what is ready. To do this he can make use of states that already exist or define additional states. These states are available as local messages and are available for translation.

Translate extension features

  • Message work flow states help translator translate, review and making ready for publication
  • There is now a new message group for recent translations. This message group makes these states possible in translation
  • Special:MyLanguage can now be used with language sub pages to be used as the default fall-back instead of providing an untranslated version
  • Pages marked for translation can now be marked as “discouraged”. They will no longer show up in the usual places. This prevents translators from translating them needlessly.
  • Added {{#translationdialog:title}} for creating a link to the translation dialogue

Translate bug fixes

  • The flash of unstylized content effect is reduced
  • Made the extension work without legacy JavaScript globals
  • The summary row in Special:LanguageStats and Special:MessageGroupStats is no longer sorted with rest of the rows.
  • Fixes to the sizing of the translation editor dialogue
  • Fixed a fatal error that sometimes occured when translation page title used GRAMMAR and the page was viewed with English UI.

Miscelaneous changes

  • Parserfunctions ifexist magic word Italian translation fixed to ‘ifexist’
  • Narayam preference wording changes from disable to enable
  • The WebFonts icon no longer overlaps with the menu text
  • WebFonts preview allows you to preview a text with a font. You can download these freely licensed fonts to your system.
  • GENDER and PLURAL support are now available for use in JavaScript.
  • Consistence updates for grouppage-* messages, for LocalisationUpdate
  • Fixing be-tarask grammar forms

Changes deployed last week

  • WebFonts was deployed for the Bishnupria Manipuri language; it uses the Lohit Bengali font
  • Support for gendered name spaces was deployed for the Russian wikis.

As always, you are welcome to have a look at our sprint backlog (user:guest password: guest) and bug us in bugzilla with whatever needs fixing.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

The localisation team sprints into the new year..

WebFonts is the first extension that gets user documentation served from MediaWiki.org. At the time of writing, the documentation has been written, it does serve people with help text about WebFonts and it is ready for translation. People looking for help will be served help in the language of their user interface if there is a translation.

WebFonts drop down on or.wikipedia.org

In a way it seems like a minor thing but consider;

  • MediaWiki can serve help texts for its functionality
  • this help text may differ based on the language of the user
  • the help text can be translated
  • a new community for MediaWiki help text translation is needed
  • functionality like Narayam will surely get its user documentation in the near future

It will be a challenge to other developers and developer teams to adopt and refine the way assistance to our users is provided. We learned at translatewiki.net that documentation did improve the quality of the localisations. We hope that user documentation will reduce confusion and makes for happy editors and readers.

The WebFonts user documentation was deployed last Tuesday. This and some other changes can be found in the deploy list. As the holiday season is in full swing, sprint 6 has started; it will run into the new year.

In this sprint stories will be developed that will make “Translation review” feature complete. When this is implemented, it will help translators and localisers review each others work and assign a status to their work for further considerations. As you can imagine, the different statuses themselves will become available for translation; card 326 defines this and will make this possible. This is just one of many stories that make up this feature.

For the localisers of the MediaWiki software a long held ambition will be realised; card 206 will see “plural” support implemented for JavaScript. When this functionality is deployed, it will result in a long list of future changes that will see changes to the actual messages.

The new year will bring us many new challenges and opportunities to the many many language communities. The Wikimedia Localisation team will work hard to provide you with the tools to be efficient in any language to get our message out and provide information in any language. For some of us the new year starts at a different moment so it will be very much business as usual; we welcome you to have a look at our sprint backlog (user:guest password: guest) and bug us in bugzilla with whatever needs fixing.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

 

Localisation team sprint 5 update II

Probably the most interesting highlight of today’s i18n deployment is the configuration of the Translate extension on MediaWiki.org. We have observed that on some wikis special pages exist that explain in the language of the Wiki functionality like Narayam or WebFonts. Such documentation is welcome on all MediaWiki installations where the functionality is used by people using the same language for their user interface.

For writing the documentation MediaWiki.org is the obvious platform. With the deployment of Translate we have the basis for writing and translating user documentation in a structured and organised way.

Narayam and WebFonts have been updated to the latest versions that have been tested on translatewiki.net. As Narayam and WebFonts are still very much a work in progress, we invite anyone to continue their testing at translatewiki.net . The changes are:

  • menu appears only on click, not when hovering
  • menu positions are now correct for RTL languages and do not go off screen any more
  • Narayam and Webfonts support the Kannada script for the Tulu language on the Incubator

There are also some smaller fixes among them the change of the autonym for the Veps language to “Vepsän kel”.. The full details for all the changes is at revision 106667.

Thanks,
Gerard Meijssen
Internationalization / Localization outreach consultant

 

India Hackathon 2011

At the same time as the #WCI11 or the Wikiconference India, there will be a genuine MediaWiki hackathon. The focus of this event will be to crush the technical obstacles that prevent Wikipedia and its sister projects to thrive in India.

This hackathon will be the first held in Asia. Many seasoned developers will be coming to Mumbai to learn first hand what can be done and see what can be done there and then.

To make it a success, there is a Wiki page with our current ideas for the hackathon. The premisses will have rooms for break-out sessions, there will be plenty space, power, internet connectivity, coffee, tea and munchies.

Most important will be that we will be there to learn from you and to show you what we are working on. The Localisation team will be there, the off-line people will be there and the mobile team will be there. We need to meet the many people working on Open Source in India because we want to make sure that whatever we will do fits in with what is already there.

We hope to see you in Mumbai.

Thanks,

Gerard Meijssen
Internationalization / Localization outreach consultant

Filter preventing abusive edits comes to all wikis

The AbuseFilter extension for MediaWiki, which helps prevent vandalism on wikis, will be globally enabled on all Wikimedia projects later today.

AbuseFilter was developed by Andrew Garrett with support from the Wikimedia Foundation; it was first enabled on the English Wikipedia in March 2009.

Since then, many local wiki communities have asked individually for AbuseFilter to be turned on on their wiki. As of July 2011, AbuseFilter was already enabled on 66 wikis, out of the 843 wikis the Wikimedia Foundation hosts.

It recently appeared it would just be simpler to enable AbuseFilter by default on all wikis, rather than doing it on request.

When enabled, AbuseFilter comes with no built-in default filters, so no immediate change will be visible on wikis where it is enabled.

Contrary to other anti-vandalism tools, AbuseFilter works by analyzing edits before they’re saved, rather than trying to identify (and revert) them after the fact.

Filters, or “rules”, can be added to AbuseFilter to identify certain kinds of edits matching a pattern. Actions can be taken for these edits, like tagging the edit, preventing the user from saving the page, or even automatically blocking the user. The AbuseFilter documentation provides the format in which filters must be written.

A screenshot of the list of AbuseFilter rules on the English Wikipedia

AbuseFilter catches abusive edits matching defined patterns.

Because AbuseFilter has been in use on the English Wikipedia for more than two years, more details about how AbuseFilter works are available in their documentation; Instructions on how to create a filter are also available.

It is possible to export filters from a wiki, and to import them into another one.

AbuseFilter is an extremely powerful tool, with the potential of preventing edits, blocking users, and making a whole wiki unusable. Therefore, it must be used with extreme caution; filters should only be created and edited by administrators who understand their purpose and syntax.

AbuseFilter can also be used to identify edits that are not abusive, for tracking purposes. Tags can be automatically added to edits matching a certain pattern, thus giving editors and patrollers a heads-up about certain edits (see examples).

Because such tags can also be used to identify legit edits, AbuseFilter is sometimes referred to as “Edit filter”.

AbuseFilter offers the possibility for certain filters to be private, to prevent long-time abusers from knowing how their edits are being identified.

We hope this tool will prove useful to our community of editors and patrollers.

Guillaume Paumier
Technical communications manager