The Wikimedia Language Engineering team recently completed their latest development sprint, with a special focus on preparing for the upcoming deployment of the Universal Language Selector (ULS) extension on multiple wikis. The team also hosted a ULS-specific office hour on May 8, 2013 (logs).

ULS deployment prep

The Language Engineering team is working on refining several important features of the Universal Language Selector. This extension will provide an umbrella of services including selection of UI language, input tools and fonts. ULS will superannuate Narayam and Webfonts to provide a unified solution for configuring language settings for MediaWiki. During this development sprint, critical bugs related to positioning of ULS’ activation area and its “cog icon” label were fixed. These affected multiple MediaWiki skins and interlanguage wiki pages. The improved version will be deployed over several phases. More information about the upcoming deployment can be found in the deployment schedule.

ULS testing

ULS features are to be verified based on the test scenarios identified. These scenarios, based on the Cucumber framework, can be adapted for automatic as well as manual testing. The scenarios cover core features of ULS: triggers, language settings panel, display settings, font selection and input tools selection. These have been written in a simple “Given-When-Then” format and provide the steps for easy walkthroughs. The testing instance hosts all the latest updates that are being made. The team is looking for volunteers who can help us with testing and reporting bugs. Let us know if you would like to join and help (write to runa at wikimedia dot org or ping us on #mediawiki-i18n) .

What’s next

The team will be completing all feature changes and testing them by end of the current sprint to be ready for kicking-off the roll-out of phase 1 of ULS. Roll-out will be coordinated by Niklas Laxström with administrators of all scheduled wikis. The team will also be hosting a bug triage session on May 29, 2013 on freenode.net IRC on the #mediawiki-i18n channel.

ULS is live on Commons!

Meanwhile, based on consensus reached by the Commons community, Universal Language Selector and the Translate extensions have been enabled on Commons.

For more details about the Language Engineering projects and ways to participate, please write to me [runa at wikimedia dot org] or ping us on #mediawiki-i18n.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

MediaWiki, the software that powers most of the Wikimedia movement, is an amazing piece of technology. It brings the power of a wiki-world to millions of people. Not only those who are amongst the 500 million who visit a Wikimedia movement site each month, but also those who participate on one of the countless other wikis it powers.

MediaWiki is being used in all kinds of environments, from internal and private corporate wikis to other Free Culture wikis. That is, of course, the great benefit behind Free and Open Source Software; the software can be modified and used in new situations the original authors didn’t necessarily expect.

Because the Wikimedia Foundation wants the MediaWiki project to be as healthy as possible, and also address the needs of as many different constituencies as possible, the Foundation invests a lot of time and effort into ensuring the entire MediaWiki community feels empowered, not just those that happen to have an @wikimedia.org email address. You can see this effort most notably from the Engineering Community Team and the efforts especially around volunteer coordination and outreach.

To encourage further outside investment in MediaWiki, we are opening a Request for Proposals (RFP) (PDF) for the release management of MediaWiki. The long-term goal of this effort is to jump-start these activities as community-supported functions, thus encouraging widespread leadership in the future of MediaWiki.

The process for this RFP is a community-involved one. There is a three-week period for organizations to prepare and submit their proposals, after which the community can comment on and ask questions of the proposers. The Wikimedia Foundation will take all of this feedback into account when making the final decision for who will lead the release management of MediaWiki for the next year.

With this, the future of MediaWiki looks bright, and we’re excited to see where this will lead us!

Greg Grossmeier, Release Manager
Rob Lanphier, Director of Platform Engineering
Wikimedia Foundation

In the recently concluded development sprint, the Wikimedia Language Engineering team made a new release of the Mediawiki Language Extension Bundle (MLEB), fixed bugs related to the Page Translation feature in Translate UX (TUX) and began work on design changes for the Universal Language Selector (ULS). The team also hosted a bug triage session that was well attended.

Input Settings from the ULS Language Settings Panel

Universal Language Selector Design Changes

Development and design changes have been initiated for the Universal Language Selector. The option to position the extension’s main panel in the sidebar was added and this feature is now being polished. Changes to the layout of the Language Settings dialog have been initiated, and usability tests for the proposed design changes were also done.

Using Wikimedia’s default GeoIP locator, ULS can now infer the user’s location and suggest language preferences.

MLEB Release

The April release for the Mediawiki Language Extension Bundle (MLEB) was announced by Amir Aharoni. Starting with this release, MLEB is no longer compatible with MediaWiki 1.19. MLEB 2013.04 and its later versions can only be used with MediaWiki version 1.20.4 or above.

The notable changes include update to CLDR v.23, bug fixes to further stabilize TUX and design changes for the Universal Language Selector. An experimental feature to present a restricted translation environment for new translators was developed for TUX. This is not enabled by default. Basic support for the XLIFF file format has also been added to Translate.

Up Next

During the next development cycle, the team will complete the changes to the Universal Language Selector design and test the features. The team is also participating in Google Summer of Code (GSoC) and the Outreach Program for Women (OPW), and will be working on completing the tasks in the next stages of the programs. More information about the other open projects for internationalization can be found in the master list.

The next Language Engineering office hour will be held on 8 May 2013 at 17:00 UTC (10:00 PDT) in #wikimedia-office on Freenode IRC.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Quim Gil, the Wikimedia Foundation’s Technical Contributor Coordinator, recently wrote about internship programs that the Wikimedia tech community participates in. These programs provide a valuable platform for a diverse group of contributors and nurture deeper collaboration across open source communities. He also shared details about participating in Google Summer of Code (GSoC) and Outreach Program for Women (OPW) for Wikimedia projects.

The Wikimedia Language Engineering team welcomes students to participate in the projects listed for Google Summer of Code and those listed for the Outreach Program for Women. The projects listed aim to resolve shortcomings or enhance various language tools that the team maintains; they include:

• improving the jQuery.ime input method library;
• building browser extensions for stand-alone operation of input methods;
• creating a dashboard for language coverage information;
• converting legacy wiki content into translatable entries.

Providing support for nearly 300 languages is no easy feat. There is constant demand for enhancements of tools, and this demand is only expected to grow. The team constantly encourages volunteers including students, language community members and others, to work with them on internationalization challenges. This includes various components like Translate UX (TUX) and Project Milkshake, in which participants can:

• increase coverage of input methods and font library;
• improve language rules for the internationalization library;
• test and prepare validation tools;
• test and enhance the translation tool;
• write documents.

They can also contribute by building extensions like SpellingApi and LocalisationUpdate, or even creating usable multi-lingual CAPTCHAs.

Open projects are also added to the master list maintained for all mentorship programs. After ascertaining the availability of mentors, participants can collaborate on a project of interest. If no mentors are listed, students can ask the team on  #mediawiki-i18n (Freenode IRC) or write to me (runa at wikimedia dot org) for more information.

We look forward to all the exciting proposals for our projects for Google Summer of Code and Outreach Program for Women. Student applications close on May 3rd and May 1st respectively.  Time is short — apply now!

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

OPW’s robocats happy to work on their first contributions.

These days we are welcoming a new wave of candidates for Google Summer of Code and FOSS Outreach Program for Women (OPW) internships. Interested? Stop reading and hurry up! Or keep reading to learn why these free software mentorship programs are doing so much good.

Since 2006, Wikimedia has mentored 32 GSoC students. From those, only one (3.13%) was a woman (accepted in 2011), and she didn’t stick around. This number is even lower than the general percentage of women accepted in GSoC 2012 (8.3%) although perhaps it is in line with the composition of our own tech community (data missing). Can we do better?

We think we can. This is why we joined OPW last November. It was the first round open to organizations other than the GNOME Foundation, founders of the initiative. After 5 rounds of OPW, GNOME women are not an exotic exception anymore. It is too soon to evaluate results in the Wikimedia tech community, but the six interns we got during the 5th round delivered their projects in the areas of software development, internationalization, UX design, quality assurance and product management, and so far they are sticking around. We also learned some lessons that we are applying to the next internship programs. As we speak, several women are applying for Wikimedia in the current GSoC edition. A promising trend!

But there is more positive change. Paid internships are like subcutaneous injections for a free software community: in just one shot you get a full time contributor dedicated to help you within a defined scope and amount of time, with the incentive of a stipend ($5,000). The lives of the injected contributors change in the new environment. They learn and they adapt to new situations. They acquire a valuable experience that will help them becoming experienced volunteers and better professionals. At least this is the goal. But the life of the community receiving the injection also should change for good with the arrival of these full time contributors. This is also the goal. So what has improved so far in our tech community?

Scaling up complex projects

Mentorship programs require a good alignment of project ideas supported by the community and by available mentors. Thanks to the efforts of many, we have now a list of possible projects, including a selection of featured project ideas ready to start. The list includes proposals coming from different Wikimedia projects, Wikimedia Foundation-driven initiatives and MediaWiki features for third parties.

These project ideas link to Bugzilla reports in order to keep track of the technical discussion, involving the candidates, the mentors and whoever else wants to join. Full transparency! We also provide basic guidelines for candidates willing to propose their own projects.

All this has been done for the current GSoC and OPW round, but is potentially also useful in the context of other initiatives like OpenHatch, SocialCoding4Good, or Wikimedia’s Individual Engagement Grants. If you want to propose a technical project that could keep a person or team busy for 3–4 months, now you know where to start.

Improving our Welcome carpet

We are still learning how to attract newcomers.

Each mentorship program brings a wave of newcomers willing to get up to speed as soon as possible. We are betting on the “the medium is the message” approach, giving as much importance to the proposals as to the participation and collaboration of the candidate in our regular community channels. But all this requires better landing surfaces in mediawiki.org.

This pressure and the repetition of similar questions by newcomers have encouraged the creation or promotion of references such as Where to start, How to contribute and Annoying little bugs. We keep working on an easier introduction to our community through the fresh and work-in-progress Starter kit, a team of volunteer Greeters and other initiatives discussed at the new Project:New contributors. And you know what? Several former interns are involved!

Diversity enters our agenda

We believe that “a healthy mix of demographic and cultural characteristics everywhere throughout the movement is key to Wikimedia’s success.” Diversity is good for creativity and sustainability, which are primary goals of any free software community. Yet diversity in these communities tends to be quite limited, and our case is not an exception.

We have mentioned the problem of male predominance, but there are other biases and types of discrimination that we would like to help leveling. What about working on other barriers caused by abilities, age, language, or cultural, ethnic, or economic background? Just like we are doing with OPW, we can start with programs for specific audiences that we can sync with mainstream activities like GSoC, increasing their diversity. Ideas are welcome.

Quim Gil, Technical Contributor Coordinator (IT Communications Manager)

Among the Wikimedia projects, Wikipedia has the highest number of individual language projects — 285. The Language Engineering team focuses on building language tools and assets that improve the ability to interact with any article on Wikipedia. Language assets like fonts and input methods are integrated into MediaWiki and its extensions, and our wikis are localized using collaborative translation with translation tools to ensure a decent user experience.

Collaboration in Language Projects and the Language Maven Program

Language Engineering community meetup during GNUnify 2013 at Pune, India

Language tools are constantly evolving to ensure support for our users. It is a slow if not impossible task to scale our small engineering team to support hundreds of languages without close collaboration with our language communities, which have many capable and technically-savvy editors and administrators.

The Wikimedia Language Engineering team has compiled a proposal for the formation of a special interest group named the Language Mavens. With members from various language communities from around the globe, we hope to learn from our users, seek advice, guidance and validation on language features. We hope that the Language Mavens will pull in participation from community members and experts who care about language support features and their adoption in the wikis they read and contribute to.

Getting started with the Maven Program

The Language Maven pilot was rolled out earlier this month on April 13 with a meeting that was well attended. Program scope and activities were discussed. One of the recommendations was to ensure that documents and handy checklists be prepared for easy reference to the language tools available to each language community. Activities that the Mavens can participate in include usability tests, bug triages, testing days and even blogging to share valuable insights about the internationalization tools in their favorite language wiki projects.

The Mavens program is aimed to focus on collecting feedback and providing support for language tools and assets being deployed by the team. This will help develop a long-term user group that will be instrumental in helping other language community members learn more about the latest language features and tools being rolled out. The Maven team expects to meet once every month and communicate through the mediawiki-i18n mailing list. To participate as a Language Maven, please fill up this form to let us know about your interest or ping me (runa at wikimedia dot org) for any questions!

Help us make your language experience better — join the Mavens!

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

The Wikimedia Language Engineering team continued to develop additional features for Translate UX (TUX) and to fix bugs, including a number of critical bugs that affected Microsoft Internet Explorer. TUX has now been deployed on Wikimedia sites and on translatewiki.net. The team also launched the new outreach program, called Language Mavens, and conducted an office hour.

The view after the user logs in to the new home page of translatewiki.net. This is currently in development.

Redesigning the main page of translatewiki.net

As part of the original specifications for TUX, the translatewiki.net main page is being redesigned. The layout will now include a set of tiles for the project groups that will contain the projects’ logo and statistics. The links conveniently placed on the tiles can be used to access the project messages for translation and proofreading. Once logged in, users will be presented with summarized statistics of their recent activities.

Significant changes are also planned for the account sign-up form. Along with features that will allow newly signed-up users to familiarize themselves with the translation workflow, it’ll make the process of getting the translation permissions smoother. The page will also include artwork to depict cultural diversity from around the world. The main page is currently under preparation, but the special page can already be accessed on translatewiki.net.

Language Mavens: The new outreach program

Language Mavens, the new outreach program for the Language Engineering team, was launched to provide better support to the various language communities within Wikimedia projects. The program was announced during the monthly office-hour (read the logs). After a meeting with the initial group of participants, the pilot phase is now underway. The program aims to regularly connect with the language communities across the Wikimedia projects to get feedback about the user experience and any improvements needed in the language support features. To optimize the internationalization tools and workflows, the program will also facilitate participation in activities such as bug triages and testing days. The team will hold regular meetings with the Maven team members. The program is open for participation, and new members can sign up online. To get more details about the program, you can read the program’s description and write to runa at wikimedia dot org.

Up next

For the next development sprints, the team will continue to work on the projects mentioned above, and also devote significant efforts on redesigning the Universal Language Selector (ULS) interface based on the design review document. The Language Engineering team will host a community bug triage session on April 24th, 2013 at 17:00 UTC. The team also invites students participating in Google’s Summer of Code 2013, to work with them on several internationalization projects.

To know more about our projects and ways to participate, please find us on the IRC channel #mediawiki-i18n (Freenode) or write to runa at wikimedia dot org.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

The Wikimedia Language Engineering team completed its recent development sprints with a focus on feature completeness of ‘Translate User eXperience’ or ‘TUX’ for deployment and also made preparations for its new community outreach project. Below are some of the highlights from the sprint.

Work is underway on the design of the new main page for translatewiki.net

Translate Editor – TUX, has been deployed: The Language Engineering team has been blogging on improvements to the Translate Extension which has now been deployed to WMF sites and been enabled as the default editor on translatewiki.net. Issues encountered while using the new editor can be reported via Bugzilla. More details about TUX’s design features can be found in our previous blog post.

New Language Outreach Program: A new outreach and support program to facilitate feedback from our language wiki projects is also currently in development. The program would facilitate focused feedback about the tools being developed and reaching out with solutions to the larger communities working on Wikimedia projects in various languages. The pilot phase is scheduled for launch in the coming weeks and an announcement with the details of the program will be shortly made.

Updates to the MediaWiki Language Extension Bundle (MLEB): In other news, Amir Aharoni announced the release of the new version of the MediaWiki Language Extension Bundle (MLEB). Besides development updates to TUX, version 2013.3 of MLEB includes bug fixes to the Universal Language Selector (ULS) as well as new fonts for Hebrew, Javanese and Arabic. Last but not least, a Marshallese input method has been contributed to jQuery.ime by Nick Doiron.

Testing plan for language tools: A preliminary outline of a testing plan for all internationalization tools currently maintained by the team was completed. Guided by earlier discussions with the Fedora Localization Testing Group (FLTG), the initial draft includes setup of test environment, preparing test scenarios, collecting feedback and analyzing results.

Preparations for visualization of language coverage information: Work also continued on the Language Coverage Matrix, a collection of data about the availability of language tools for different languages in Wikimedia projects. Currently, the focus is to prepare a technical specification for automated presentation and access to this information.

Event participation and other news: Siebrand Mazeland represented the Wikimedia Language Engineering team at the Internationalization and Localization Conference organized by Lingoport in Santa Clara. (More details: presentation slides, and talk recording)

The ongoing development sprint will focus on creating a new design for the translatewiki.net homepage, launch of the pilot phase for Language support outreach program, and publication of the Language Engineering roadmap for the next fiscal year 2013-2014. The Language Engineering team is also looking to hire JavaScript and PHP engineers with deep experience in i18n and l10n technologies. Additionally, a few of the projects that are open for participation have been listed here.

The Language Engineering team is available to answer any technical questions you may have about the tools it develops. You can join us at our monthly office hour scheduled this month on April 10, 1700 UTC and 1000 PDT or find us on irc.freenode.net at #mediawiki-i18n. Logs from the last office hour held on March 13, 2013 can be found here.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

The Wikimedia Language Engineering team has been regularly reporting updates about improvements to the Translate editor, as part of the “Translate User eXperience” project, or “TUX”. Pau Giner, the team’s UX expert, has also conducted online sessions to talk about these features. If you have missed these updates, here is a summary of what we are changing about the way the Translate editor is used.

The main editor screen of Translate’s new version, with Spanish translations in List view.

Translate is a MediaWiki extension that is used for translating software and wiki pages. Besides providing translations through the web-based editor and proofreading features, it also supports export and import of gettext files for offline translation. The editor provides various features to assist in translation, such as:

• Message documentation, also known as “context”;
• Suggestions from translation memory and machine translation;
• Checking translations for common syntax mistakes;
• Translation status of messages.

Originally created by Niklas Laxström, this extension has grown in features through contributions made by other contributors, as well as by the Wikimedia Language Engineering team. The extension uses a continuous development model and, if you use the extension on a wiki you administer, you are encouraged to update it periodically using the MediaWiki Language Extension Bundle (MLEB).

The workflow and features for Translate were recently redesigned to provide users with an improved experience. The development was done based upon the designs in the workflow specification document. This included changes in navigation, editor look and feel, translation area, filters, search, and color & style. Here are some of the notable new features and changes:

Editing Modes: The translation editor will now provide two translation modes and one proofreading mode. For translation, the user will be able to choose between the ‘List’ view, more suitable for smaller messages, or the ‘Page’ view, designed for longer pieces of text like paragraphs of a wiki page. The proofreading mode will allow users to view translations by other users and mark their accuracy. Although users can view the messages translated by themselves in this mode, they cannot mark them as accepted.

Message status-based filtering: Users will have the option to select and only view messages that match a filter, depending on their status. In the editor, users can choose an appropriate filter to quickly access ‘Translated’, ‘Outdated’ or ‘Untranslated’ messages in translation mode, and ‘Translated’, ‘Outdated’ and ‘Unproofread’ in proofreading mode. Translations marked as ‘Outdated’ (equal to the jargon term “fuzzy”) need attention, for example because the source message has changed.

Message editor and translation aids: The messages in focus are shown within an editing area that is divided into two separate sections: one for translation, and the other for translation helpers, like context documentation, suggestions from previous translation and external translation services. The layout aims to make optimal use of available space and also provides users with the additional option to focus better on a message by expanding the size of the editing area to the entire width of the editor. The navigation to the next message, the ability to save drafts and the display of warnings make the translation process more fluent. Development of some exciting features for improving context-related translation aids is also on the cards.

Search and edits: Users can search translatable strings using the search field at the top of the edit section. The search results are displayed within various categories like ‘source’ or ‘translated’ messages. An additional overview displays the languages and message groups where they occur and users can further filter them based on the sub-groups. Users will be able to directly go into ‘Translation mode’ to make changes to the messages in the search results. A navigation arrow can bring them back to the list of results.

Not all of these features are available on Wikimedia wikis yet, but they will be soon. The current development version is available on translatewiki.net. If the new editor is not visible, appending “&tux=1” to the URL will enable the new features. Appending “&tux=0” will disable them.

While redesigning Translate’s User experience has been a significant project, development is continuously carried out to make the extension even better to use. And for this, we are always looking for valuable feedback from our users. Bugs and features requests can be filed through bugzilla; additionally, one can write to me at runa at wikimedia dot org with their feedback and suggestions.

Runa Bhattacharjee, Outreach and QA coordinator, Language Engineering

Help us squash bugs!

Reporting a new software bug is only the first step towards fixing the issue; the sorting and prioritization steps come next, usually referred to as “triage”.

Wikimedia’s Bug Squad has started hosting bi-monthly Bug Days as a part of our QA weekly goals. During a bug day, bug triagers and developers sort bug reports, usually from a specific component or reports fitting a specific criteria. Triaging reports includes testing reports to confirm they are valid, prioritizing reports so developers can efficiently address pressing issues, and identifying and marking duplicate reports to avoid duplicated work.

Our next Bug Day is today (March 19th), and we’ll work on bug reports in Mediawiki extension > LiquidThreads. For more information on the event and how to participate, check out the event page.

We have already held three Bug Days. The first Bug Day on January 29, 2013 focused on reports that had not been changed for over a year. We retested many reports to see if they were still valid for newer versions of MediaWiki and MediaWiki Extensions. We also requested more information from reporters whose reports needed clarification. We addressed 30 reports out of about 170. Because of the recent Gerrit upgrade, our bug day on February 19, 2013 addressed bug reports in the Git/Gerrit component. Our focus was addressing upstream issues in Gerrit that may have been fixed with the update. For upstream bugs that were not fixed with the update, status reports were left on our corresponding Bugzilla reports. We addressed about 24 bug reports out of 70 open reports in Git/Gerrit. Our latest bug day focused on General/Unknown reports in the MediaWiki product, which is known to be catch-all for bug reports. 38 reports were triaged. Many were retested and confirmed, prioritized, and moved out of General/Unknown into their proper components.

You can contribute to the Wikimedia Foundation by triaging bug reports. Follow the Calendar of QA events, to keep up with upcoming Bug Days and other testing events. You can also find an announcement of upcoming Bug Days on Bug Management’s Triage page. Bug Days are not just for bug triagers; developers are welcome to join and help by ‘taking’ reports and submitting bug fixes. Fixing bugs is a great way for new volunteer developers to get started, and joining a Bug Day would be a great way to find a few bugs to fix.

Bug Days support the Wikimedia Foundation by ensuring the quality of bug reports and bringing focus to reports that may not have had attention in a while. It is difficult for developers to keep up with the number of bug reports that reside and move into Bugzilla every day. Bug Days and bug triaging can help developers efficiently address these issues.

Valerie Juarez, Bug Management Intern