Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Features

VisualEditor gadgets

This post was written by two recipients of Individual Engagement Grants. These grants are awarded by the Wikimedia Foundation and aim to support Wikimedians in completing projects that benefit the Wikimedia movement. The grantees of this project work independently from the Foundation in the creation of their project.

Directionality tool. An example for useful site specific additional button to VE, which adds RTL mark

Many gadgets and scripts have been created by volunteers across Wikimedia projects. Many of them are intended for an improved editing experience. For the past few months there has been a new VisualEditor interface for editing articles. The interface is still in “beta,” so Wikipedians have not yet adapted it in a large scale. We believe there are many missing features, that if incorporated, can expand the VisualEditor user base. The known non-supported features are core features and extension features (such as timelines), but there are many unknown non-supported features – gadgets. Gadgets can extend and customize the visual editor and introduce new functionalities: to let more advanced users use more features (such as timeline), to introduce work-flows that are project specific (such as deletion proposals), or to easily insert popular templates such as those for citing sources. Since there is no central repository for gadgets, there is no easy way to tell what gadgets exist across all wikis.

Our project aims to organize this mess: improve gadgets sharing among communities and help push gadgets improvements for edit interface to VisualEditor. As part of this project we already:

  • Mapped all the gadgets (in any language) and created a list of all the gadgets in various projects, with popularity rating across projects.
  • Based on this list we selected key gadgets, and rewrote them to support the new VisualEditor:
    • Spell checker (Rechtschreibpruefung) – Spell checking for common errors. Spelling mistakes are highlighted in red while writing!
    • Reftoolbar – helps editors add citation templates to articles.
    • Directionality tool – Adds button to add RTL mark useful in RTL languages such as Arabic and Hebrew.
    • Common summaries – Added two new drop-down boxes below the edit summary box in save dialog with some useful default summaries.
  • Based on our experience with writing VE gadgets, we created a guide for VE gadgets writers, which should help them extend the VisualEditor with custom features. We hope it helps develop support for Visual Editor by making it more integrated with existing tools.

 

(more…)

Remembering Adrianne Wadewitz

Portrait of Adrianne Wadewitz at Wikimania 2012 in Washington, DC.

Each of us on the Wikipedia Education Program team is saddened today by the news of Adrianne Wadewitz’s passing. We know we share this sadness with everyone at the Wikimedia Foundation and so many in the Wikimedia and education communities. Our hearts go out to all of you, her family and friends. Today is a time for mourning and remembering.

Adrianne served as one of the first Campus Ambassadors for the Wikipedia Education Program (then known as the Public Policy Initiative). In this role, she consulted with professors, demonstrated Wikipedia editing and helped students collaborate with Wikipedia community members to successfully write articles. As an Educational Curriculum Advisor to the team, Adrianne blended her unique Wikipedia insight and teaching experience to help us develop Wikipedia assignments, lesson plans and our initial sample syllabus. Her work served as a base for helping university professors throughout the United States, and the world, use Wikipedia effectively in their classes.

Adrianne was also one of the very active voices in the Wikimedia community urging participation and awareness among women to tackle the project’s well-known gender gap. She was an articulate, kind, and energetic face for Wikipedia, and many know that her work helped bring new Wikipedians to the project. The Foundation produced a video exploring Adrianne’s work within the Wikipedia community in 2012.

Many in the Wikimedia community knew her from her exceptional and varied contributions, especially in the areas of gender and 18th-century British literature – in which she received a PhD last year from Indiana University, before becoming a Mellon Digital Scholarship Fellow at Occidental College. Since July of 2004, she had written 36 featured articles (the highest honor for quality on Wikipedia) and started over 100 articles – the latest being on rock climber Steph Davis.

Adrianne touched many lives as she freely shared her knowledge, expertise and passions with Wikipedia, her students, colleagues, friends and family. She will be deeply missed by all of us. Our condolences go out to her family during these very difficult times.

Rod Dunican
Director, Global Education

Wikipedia Education Program

  • See Adrianne’s user page on the English Wikipedia, her Twitter account, her home page and her blog at HASTAC (Humanities, Arts, Science and Technology Alliance and Collaboratory)
  • Wikipedians have begun to share their memories and condolences about Adrianne on her user talk page.
  • The leadership of the Wiki Education Foundation, where Adrianne was a board member, have also expressed their condolences.
  • Memorial post from HASTAC Co-founder Cathy Davidson.
  • Wikinews story on the passing of Adrianne Wadewitz.

MediaWiki localization file format changed from PHP to JSON

Translations of MediaWiki’s user interface are now stored in a new file format—JSON. This change won’t have a direct effect on readers and editors of Wikimedia projects, but it makes MediaWiki more robust and open to change and reuse.

MediaWiki is one of the most internationalized open source projects. MediaWiki localization includes translating over 3,000 messages (interface strings) for MediaWiki core and an additional 20,000 messages for MediaWiki extensions and related mobile applications.

User interface messages originally in English and their translations have been historically stored in PHP files along with MediaWiki code. New messages and documentation were added in English and these messages were translated on translatewiki.net to over 300 languages. These translations were then pulled from MediaWiki websites using LocalisationUpdate, an extension MediaWiki sites use to receive translation updates.

So why change the file format?

The motivation to change the file format was driven by the need to provide more security, reduce localization file sizes and support interoperability.

Security: PHP files are executable code, so the risk of malicious code being injected is significant. In contrast, JSON files are only data which minimizes this risk.

Reducing file size: Some of the larger extensions have had multi-megabyte data files. Editing those files was becoming a management nightmare for developers, so these were reduced to one file per language instead of storing all languages in large sized files.

Interoperability: The new format increases interoperability by allowing features like VisualEditor and Universal Language Selector to be decoupled from MediaWiki because it allows using JSON formats without MediaWiki. This was earlier demonstrated for the jquery.18n library. This library, developed by Wikimedia’s Language Engineering team in 2012, had internationalization features that are very similar to what MediaWiki offers, but it was written fully in JavaScript, and stored messages and message translations using JSON format. With LocalisationUpdate’s modernization, MediaWiki localization files are now compatible with those used by jquery.i18n.

An RFC on this topic was compiled and accepted by the developer community. In late 2013, developers from the Language Engineering and VisualEditor teams at Wikimedia collaborated to figure out how MediaWiki could best be able to process messages from JSON files. They wrote a script for converting PHP to JSON, made sure that MediaWiki’s localization cache worked with JSON, updated the LocalisationUpdate extension for JSON support.

Siebrand Mazeland converted all the extensions to the new format. This project was completed in early April 2014, when MediaWiki core switched over to processing JSON, creating the largest MediaWiki patch ever in terms of lines of code. The localization formats are documented in mediawiki.org, and MediaWiki’s general localization guidelines have been updated as well.

As a side effect, code analyzers like Ohloh no longer report skewed numbers for lines of PHP code, making metrics like comment ratio comparable with other projects.

Work is in progress on migrating other localized strings, such as namespace names and MediaWiki magic words. These will be addressed in a future RFC.

This migration project exemplifies collaboration at its best between many MediaWiki engineers contributing to this project. I would like to specially mention Adam Wight, Antoine Musso, David Chan, Ed Sanders, Federico Leva, James Forrester, Jon Robson, Kartik Mistry, Niklas Laxström, Raimond Spekking, Roan Kattouw, Rob Moen, Sam Reed, Santhosh Thottingal, Siebrand Mazeland and Timo Tijhof.

Amir Aharoni, Interim PO and Software Engineer, Wikimedia Language Engineering Team

Modernising MediaWiki’s Localisation Update

Interface messages on MediaWiki and its many extensions are translated into more than 350 languages on translatewiki.net. Thousands of translations are created or updated each day. Usually, users of a wiki would have to wait until a new version of MediaWiki or of an extension is released to see these updated translations. However, webmasters can use the LocalisationUpdate extension to fetch and apply these translations daily without having to update the source code.

LocalisationUpdate provides a command line script to fetch updated translations. It can be run manually, but usually it is configured to run automatically using cron jobs. The sequence of events that the script follows is:

  1. Gather a list of all localisation files that are in use on the wiki.
  2. Fetch the latest localisation files from either:
    • an online source code repository, using https, or
    • clones of the repositories in the local file system.
  3. Check whether English strings have changed to skip incompatible updates.
  4. Compare all translations in all languages to find updated and new translations.
  5. Store the translations in separate localisation files.

MediaWiki’s localisation cache will automatically find the new translations via a hook subscribed by the LocalisationUpdate extension.

Until very recently the localisation files existed in PHP format. These are now converted to JSON format. This update required changes to be made in LocalisationUpdate to handle JSON files. Extending the code piecemeal over the years had made the code base tough to maintain. The code has been rewritten with extensibility to support future development as well as to retain adequate support for older MediaWiki versions that use this extension.

The rewrite did not add any new features except support for JSON format. The code for the existing functionality was refactored using modern development patterns such as separation of concerns and dependency injection. Unit tests were added as well.

The configuration format for the update scripts changed, but most webmasters won’t need to change anything, and will be able to use the default settings. Changes will be needed only on sites that for some reason don’t use the default repositories.

New features are being planned for future versions that would optimise LocalisationUpdate to run faster and without any manual configuration. Currently, the client downloads the latest translations for all extensions in all languages and then compares which translations can be updated. By moving some of the complex processing to a separate web service, the client can save bandwidth by downloading only updated messages for specific updated languages used by the reader.

There are still more things to improve in LocalisationUpdate. If you are a developer or a webmaster of a MediaWiki site, please join us in shaping the future of this tool.

Niklas Laxström and Runa Bhattacharjee, Language Engineering, Wikimedia Foundation

Hovercards now available as a Beta Feature on all Wikimedia wikis

File:Hovercards feature in action on a wiki.png

Hovercards presents a summary of an article when you hover a link.

Have you ever quickly looked up an article on Wikipedia, gotten all caught up in the fun of reading, then suddenly realized that three hours had passed and you’re now reading a series of articles about totally different topics? The folks at xkcd certainly have. And now, we’ve got just the feature for you.

Hovercards provides the casual reader with a streamlined browsing experience. Whenever you hover over a link to another article, a short summary of the article and a relevant image is provided to you so you can make the decision about whether you want to read the full article. And, as of today, the feature is live for testing as a Beta Feature on all Wikimedia wikis.

Inspired by the Navigation Popups (NavPopups) gadget used by many of our experienced editors, Hovercards take the idea of NavPopups and modifies it to be suitable to casual readers. The design is minimalistic, presenting only the information which interests casual readers: the lead paragraph and first image of the article they’re interested in browsing to.

To enable Hovercards, simply log in, click the “Beta” link at the top right of your page and tick the box next to Hovercards. As its placement in the Beta tab suggests, the feature is still under active development, so we’d appreciate any feedback you have. You can give us feedback by writing on the talk page of the feature.

We hope you like using Hovercards!

Vibha Bamba, Dan Garry, Prateek Saxena, Nick Wilson
Wikimedia Foundation

For Rexford Nkansah, Wikipedia represents the future of education for his country

Despite its growing economy, Ghana is not the first place one would associate with technology, but for 20-year-old native Rexford Nkansah, it’s second nature.

Wikipedians attending WikiAfrica’s Open Africa 2014 course in Cape Town in February of 2014. From left: Abel Asrat, Rexford Nkansah, Michael Phoya, Cyriac Gbogou, and Erina Mukuta.

“In Ghana you don’t have hobbies like skiing or going to restaurants,” he says. “So these are the little things I do to keep myself busy.” The youngest of five, Rexford is now spearheading a campaign to form a Wikimedia Chapter in Ghana. “I’m actually considered to be Ghana’s Wikimedia person,” he explains.

He first stumbled upon Wikipedia in 2006, and like many, at first did not realize what made it so special. It wasn’t until five years later that he began contributing himself. “I thought – how can anyone, anywhere on the planet put in anything just like that? So I decided to read about it, to learn the rules for editing, and that’s how it all started.”

A biography on Ashesi University founder Patrick Awuah was his first foray into writing, an article that took him six hours of non-stop work. “I took my time to write it. I sat down, researched, did everything, put it all together, added photos… I just dedicated that time to do it. I said, this guy – I need to do something to say thank you to him, for how he’s helping Ghana grow.”

Nkansah is a passionate web developer, and is keen on emphasizing the value of open source software. “Not all of us have access to credit cards, buying something online is like going a million miles to fetch something,” he says, “so when you get free software, you get happy about it. Because software that is not free… it’s hard to pay for it even if you have the money.”

(more…)

Celebrating Women’s Day, the Wiki way

Participants editing articles about women in science.

How many Indian women scientists can you name? Go on! Think about this one. Think really hard. How many can you name, now? One? Two? Three?

I wrote this blog post at a co-working space for tech startups in the Southern Indian city of Kochi. I was surrounded by science students. None of them could think of a single woman scientist from India. Pretty shameful, isn’t it? And, there was nobody to burst our sexist bubble, except, Wikipedia. This page lists 15 women scientists from India. While I am grateful for this archive, it is hardly comprehensive. 15 women scientists from a country of 1.2 billion people.

India is currently Asia’s third largest economy and it prides itself on making many ancient discoveries. Given this context, it is unbefitting for us to come up with such a tiny list. (By the way, If you know of a more detailed website on this subject, please send me the link on Twitter – which you can find at the bottom of this page). Could there be women whose contribution to science have slipped out of popular culture?

Wikipedia has organized edit-a-thons for the entire month of March to address these glaring gaps in our knowledge. The goal of these edit-a-thons is to celebrate International’s Women’s Day that fell on March 8. During this month, we would like to enhance the quantity and quality of Wikipedia articles on gender and sexuality and translate English articles into other Indic languages. Anyone can join the celebrations as editors, translators, bloggers, event managers or enthusiasts.

We encourage more South Asian women to use this opportunity- right now 9 out of 10 Wikipedians are men. There are many subjects that may be of interest or value to women that are not covered in traditional encyclopaedias because the majority of knowledge-producers are men. Let us make sure that Wikipedia is diverse and voices from all sections of  society are represented.

We have kick-started the event with weekend edit-a-thons. We will provide specific topics and links to editors to write or expand upon. This month the focus is on women parliamentarians and scientists.

So come on over, put your editing skills to use, make some new friends and last but not the least, learn more about women scientist from India!

- Diksha Madhok, Wikipedian

Webfonts: Making Wikimedia projects readable for everyone

Wikimedia wikis are available in nearly 300 languages, with some of them having pages with mixed-script content. An example is the page on the writing systems of India on the English Wikipedia. We expect users to be able to view this page in full and not see meaningless squares also known as tofu. These tofu squares represent letters written in the language, but cannot be rendered by the web browser on the reader’s computer. This may happen due to several reasons:

  • The device does not have the font for the particular script;
  • The operating system or the web browser do not support the technology to render the character;
  • The operating system or the browser support the script partially. For instance, due to gradual addition of characters in recent Unicode versions for several scripts, the existing older fonts may not be able to support the new characters.

Fonts for most languages written in the Latin script are widely available on a variety of devices. However, languages written in other scripts often face obstacles when fonts on operating systems are unavailable, outdated, bug-ridden or aesthetically sub-optimal for reading content.

Using Webfonts with MediaWiki

To alleviate these shortcomings, the WebFonts extension was first developed and deployed to some wikis in December 2011. The underlying technology provides the ability to download fonts automatically to the user if they are not present on the reader’s device, similar to how images in web pages are downloaded.

The old WebFonts extension was converted to the jquery.webfonts library, which was included in the Universal Language Selectorthe extension that replaced the old WebFonts extension. Webfonts are applied using the jquery.webfonts library, and on Wikimedia wikis it is configured to use the fonts in the MediaWiki repository. The two important questions we need answered before this can be done are:

  1. Will the user need webfonts?
  2. If yes, which one(s)?

Webfonts are provided when:

  • Users have chosen to use webfonts in their user preference.
  • The font is explicitly selected in CSS.
  • Users viewing content in a particular language do not have the fonts on their local devices, or the devices do not display the characters correctly, and the language has an associated default font that can be used instead. Before the webfonts are downloaded, a test currently known as “tofu detection” is done to ascertain that the local fonts are indeed not usable. The default fonts are chosen by the user community.

Webfonts are not applied:

  • when users choose not to use webfonts, even if there exists a valid reason to use webfonts (see above);
  • in the text edit area of the page, where the user’s preference or browser settings are honored.

See image (below) for a graphical description of the process.

‘Tofu’ Detection

The font to be applied is chosen either by the name of the font-family or as per the language, if the designated font family is not available. For the latter, the default font is at the top of the heap. However, negotiating more complex selection options like font inheritance, and fallback add to the challenge. For projects like Wikimedia, selecting appropriate fonts for inclusion is also of concern. The many challenges include the absence of well-maintained fonts, limited number of freely licensed fonts and rejection of fonts by users for being sub-optimal.

Challenges to Webfonts

Merely serving the webfont is not the only challenge that this technology faces. The complexities are compounded for languages of South and South-East Asia, as well as Ethiopia and few other scripts with nascent internationalization support. Font rendering and support for the scripts vary across operating system platforms. The inconsistency can stem from the technology that is used like the rendering engines, which can display widely different results across browsers and operating systems. Santhosh Thottingal, senior engineer for Wikimedia’s Language Engineering team who has been participating in recent developments to make webfonts more efficient, outlines this in greater detail.

Checkbox in the Universal Language Selector preferences to download webfonts

A major impact is on bandwidth consumption and on page load time due to additional overhead of delivering webfonts for millions of users. A recent fallout of this challenge was the change that was introduced in the Universal Language Selector (ULS) to prevent pages from being loaded slowly, particularly when bandwidth is a premium commodity. A checkbox now allows the users to determine if they would like webfonts to be downloaded.

Implementing Webfonts

Several clever solutions are currently in use to avoid the known challenges. The webfonts are prepared with an aim to create comparatively smaller footprints. For instance, Google’s sfntly tool that uses MicroType Express for compression is used for creating the fonts in EOT format (WOFF being the other widely used webfont format). However, the inherent demands of a script with larger character sets cannot always be overridden efficiently. Caches are used to reduce unnecessary webfonts downloads.

FOUT or Flash Of Unstyled Text is an unavoidable consequence when the browser displays text in dissimilar styling or no text at all, while waiting for the webfonts to load. Different web browsers handle this differently while optimizations are in the making. A possible solution in the near future may be the introduction of the in-development WOFF2 webfonts format that is expected to further reduce font size, improve performance and font load events.

Special fonts like the Autonym font are used in places where known textlike a list of language namesis required to be displayed in multiple scripts. The font carries only the characters that are necessary to display the predefined content.

Additional optimizations at this point are directed towards improving the performance of the JavaScript libraries that are used.

Conclusion

Several technical solutions are being explored within Wikimedia Language Engineering and in collaboration with organizations with similar interests. Wikipedia’s sister project Wikisource attempts to digitize and preserve copyright-expired literature, some of which is written in ancient scripts. In these as well as other cases like accessibility support, webfonts technology allows fonts for special needs to be made available for wider use. The clear goal is to have readable text available for all users irrespective of the language, script, device, platform, bandwidth, content and special needs.

For more information on implementing webfonts in MediaWiki, we encourage you to read and contribute to the technical document on mediawiki.org

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering, Wikimedia Foundation

Indian Wikimedia community coordinates Women’s History Month

The Indian Wikimedia community is pleased to invite you to participate in Women’s History Month events, 2014. We started off with a pre-event Wikipedia workshop at Roshni Nilaya School of Social Work, in Mangalore on the 26th of February. We have planned events all through this month. They aim at creating new articles, expanding the existing stubs and translating English articles to various Indic languages.The schedule includes Wikipedia workshops, online edit-a-thons and wikiparties. You could edit articles, translate them, blog about the events or even be an enthusiast. Visit this page to learn more about getting involved.

Real-life Wikipedia workshops will be conducted in different parts of India. Two online edit-a-thons have been planned. The first one on the 8th & 9th of March focuses on women parliamentarians and the second one on the 15th & 16th will be looking to expand the work done during the last year events on women scientists from India. Participants of the Women’s History Month events in India are requested to fill up this opt in form to help the organizers evaluate the quantum and quality of the edits made. Centre for Internet and Society (Access to Knowledge) has extended their support to the Women’s History Month events in India this year.

The Indian events are being conducted as a part of the global event supported by the Wikiwomen’s Collaborative. We look forward to welcoming all participants at this year’s event.

By, Jeph Paul and Netha Hussain, Wikimedians

Wikipedia’s Art & Feminism Edit-A-Thon and the Gender Gap

the Art & Feminism Wikipedia Edit-a-thon, at the John M. Flaxman Library at the school of the Art Institute of Chicago on February 1, 2014

Lending a hand at the Wikipedia Art+Feminism Edit-a-thon, at Eyebeam in New York City

The Wikimedia Foundation’s mission to realize a world in which every single human being can freely share in the sum of all knowledge represents an ongoing challenge to staff and volunteers alike. We must find ways to make information more accessible, increase the breadth of information in each language, and close gaps in editor demographics. Most importantly, we must recognize that so long as there are disparities in information, such as the representation of women and Feminism on Wikipedia, we have yet to realize our goal of truly sharing in the sum of all human knowledge.

On February 1st, 2014, the Wikipedia Community addressed Wikipedia’s gender gap by organizing the Art & Feminism Edit-a-thon, encouraging editors — female or male, novice or experienced — to contribute to pages about art, feminism, and women of all walks of life. The purpose of this event was not only to spread interest in topics needing real visibility on the encyclopedia, but also to empower women to become more involved in the community by providing a supportive framework for their contributions. With over 30 satellite Edit-a-thons running simultaneously across 4 continents and an estimated 600 attendees, this event brought us a small step closer to realizing a truly diverse user base.

Dating back to a study done in 2010 which found the Wikipedia community was comprised of only 13% women, the Foundation has worked with chapter and user groups to provide outreach to women. These Edit-a-thons offer a partial solution to one of the barriers to new editors: it’s intimidating to edit an article if you don’t really know Wikipedian policies, practices, syntax, etiquette, and topical needs. Experienced community members can model and teach best practices as well as support new editors. Some of the satellite Edit-a-thons, like the one hosted by Wikimedia NYC, saw around 150 attendees and therefore approached this learning experience by hosting hourly training sessions, while other, smaller events took advantage of the intimate setting to give participants one-on-one support.

Sharon Cogdill works with a recent University of Minnesota graduate during the Art+Feminism Edit-a-thon at St. Cloud State University, Minnesota

One such iteration of the Art & Feminism Edit-a-thon was hosted in the library at St. Cloud State University by librarian Rachel Wexelbaum, with a total of 10 participants, 9 of whom were women. Under the guidance of Rachel and Professor Sharon Cogdill, the group discussed the various imbalances on Wikipedia, including the gender imbalance. Sharon, sensing the wavering interest in the room and worried that the newcomers present felt left out by the “they” who edit Wikipedia, moved the Edit-a-thon into action by helping everyone create their very own Wikipedia usernames; “they” began to look more like “we.”

Creating an account doesn’t suddenly endow a new user with confidence, to which Sharon can attest from experience (full disclosure: Sharon is my aunt). A professor of Victorian literature and Digital Humanities, she first became an active editor in 2011 when she made a small edit to an article about The Emerald Isle, a 19th century comic opera. Her edit contained a small error, and the owner of the article contacted her on her talk page and explained which Wikipedia policies made the original better. Reflecting on their working relationship, Sharon says, “I have a great mentor, Ssilvers, who has really encouraged me, often by suggesting a Wikipedia page to read on policies or help on some other topic he thinks I’m ready for.”

During the Edit-A-Thon, Sharon published her very first new article on Arthur Collins, which Ssilvers “pushed me to get out there 2 years before I finally did.” The article is about a man, because in Sharon’s words, “this event gave me the environment I needed to let go of it, and besides, women writing about men isn’t not feminist.”

(more…)