Now that the underlying software for Structured Data on Commons has been put in place, along with Captions helping to demonstrate the software worked, the development team was ready to release the first form of structured statements for Commons: depicts.
Depicts is a statement for representing the concepts or topics present or expressed in a media file. The depicts statement can be considered the most basic example for modeling information about a file.
After making sure basic depicts support was working, the development team added support for qualifiers. By using qualifiers for depicts, users are able to represent the file even further by refining, contextualizing, or expanding the simple statement. For example, the previous statement of depicts (P180) a house cat (Q146) can be refined to depicts (P180) a house cat (Q146) [color: gray (Q42519)] and will return only files with statements that match a gray cat. As with basic depicts, this functionality is multilingual and will find whatever languages are available.
Now that Commons has the most basic modeling for data in a file in place, the development team turned to supporting other types of statements beyond depicts. These other types of statements will be covered in the next part.
Due to Wikimania and summer vacation, no issue of Tech News has been distributed last week.
You can use the new termbox interface if you edit Wikidata on a mobile device. This is to edit labels, descriptions and aliases easier on the mobile pages. 
The new version of MediaWiki has been deployed during the last week.
The previously announced change of positions of the “Wikidata item” link on all wikis has been rollbacked due to unexpected cache issues. 
The limit for rollbacks has been increased from 10 to 100 rollbacks per minute. 
The advanced version of the edit review pages (Recent Changes, Watchlist, and Related Changes) now include two new filters. These filters are for “All contents” and “All discussions”. They will filter the view to just those namespaces. However the “All discussions” filter does not include pseudo talk pages, like discussions that are in the Project: or Wikipedia: namespaces. But it will include changes happening on Project talk: or the Wikipedia talk:. 
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 3 September. It will be on non-Wikipedia wikis and some Wikipedias from 4 September. It will be on all wikis from 5 September (calendar).
When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if your password is one of the most common passwords in the world. If your password is not strong enough, please consider to change your password for a stronger password. 
There will be no Tech News issue next week. The next issue of Tech News will be sent out on 2 September 2019.
Some abuse filters stopped working because of a code change. Only variables for the current action will work. Variables defined inside a branch may not work outside of that branch. You can read more to see how to fix the filters.
Only six accounts can be created from one IP address per day. Between 12 August and August 15 this was two accounts per day. This was because of a security issue. It is now six accounts per day again. 
Changes later this week
Only a limited number of accounts can be created from one IP address. An IP address can be whitelisted so that it can create as many accounts as needed. This is useful at events where many new persons learn to edit. IP addresses that are whitelisted for this reason will also not show CAPTCHAs when you create accounts. This will happen on Wednesday. 
The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 August. It will be on non-Wikipedia wikis and some Wikipedias from 21 August. It will be on all wikis from 22 August (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 21 August at 15:00 (UTC). See how to join.
There is an RFC about creating a new global user group with the right to edit abuse filters. This will be used to fix broken filters and make sure all filters will still work when software changes happen. You can read more and comment.
Special:Contributions/newbies will no longer be working. This is because of performance reasons. It showed edits by new accounts. You can see this in the recent changes feed instead. 
Wikimedia Commons holds over fifty million freely-licensed media files. These millions of images, sounds, video, documents, three-dimensional files and more contain a vast amount of information related to the contents of the file and the the context for the world around them. As Commons has collected files over the years, the volunteers who curate and maintain the site have developed a system to contain and present this information to the world, using MediaWiki, wikitext, and templates.
A description template is the first and primary way information about a file is show to users. These templates can be a powerful tool for displaying information about files; descriptions provide meaningful context and information about the work presented. Descriptions can be as long as the user would like, providing wikitext markup and links for others to find out more. Description templates can also hold translations by adding language fields. However, the Structured Data team saw some areas that a feature like captions could improve upon from descriptions templates.
Multilingual captions help share the burden of descriptions by providing a space to describe a file in a way that is standard across all files, easy to translate, and easy to use. Captions do not support wikitext so there is no knowledge needed of how to links work in this space — links can still be provided in the more expansive file description. Captions are added during the upload process using the UploadWizard, or they can be added directly on any file page on Commons. The translation feature for captions is a simple interface that requires only a few steps to create and share a caption translation.
The “multilingual” in “multilingual captions” highlights a primary focus of Structured Data features: opening up access to Commons to as many languages as possible beyond its present capabilities. This is enormously beneficial to the Wikimedia movement and Wikimedia Foundations’ mission of sharing knowledge with the world. In addition to captions, future features planned provide supporting adding “statements” from Wikidata to files, effectively describing them in an organized way that can be accessed by programs and bots to present media. These statements can be multilingual as Wikidata supports translations, which will make statements searchable in any language that has a translation provided.
File does not exist : Book-covered_walls_(Unsplash).jpg
Content Translation achieved a new milestone, supporting already the creation of 500,000 Wikipedia articles. The Language team has been working during the last year to make the tool more solid, and has plans to expand the use of translation to help more communities to grow.
Wikipedia users can learn about many topics. However, the exact number of topics they can access is very different depending on the language they speak. While English speaking users can access more than 5 million articles, Bengali speakers have access to 75 thousand articles.
Translating articles into new languages is a practice that can help content to propagate more fluently across languages, and reduce this language gap. To facilitate this process, we here at the Wikimedia Foundation developed a content translation tool that helps Wikipedia editors to easily translate articles. Content Translation simplifies translating Wikipedia articles into different languages by automating many of the boring steps of the manual translation process.
In early August, Content Translation reached a new milestone: more than half a million articles were created since the tool was released four years ago, making this a good time to reflect on the impact of the tool and discuss future plans.
A more reliable tool
During the past year, the Language team worked on a new version of the tool. Based on user research and feedback, the plan was to create a more solid version of Content Translation to increase the tool adoption and use.
For the new version we replaced the default editing surface provided by the browser with Visual Editor, which supports rich wiki content in a way that is much more reliable. This required a rewrite most of the translation tools, and we wanted to take this opportunity to review them and provide better guidance for newcomers.
As the new version became more complete it was gradually exposed more prominently during the year, and finally replaced the previous version completely without major regressions. During the year more than 149.000 translations were created, a 23% increase compared to the previous year.
We started conversations with different communities to identify the main blockers before the tool could be provided by default and exposed to more users.
Better collaboration between humans and machines
In addition to the number of articles created, we focused on the quality of the content. The new version improved the guidance provided to newcomers. In particular, a new system was created to encourage users to review and edit the initial machine translation, and approaches based on Artificial Intelligence were explored to improve some automatic steps.
Content Translation provides machine translation as initial content for editors to review and improve. The machine translation is provided as a starting point, and translators are highly encouraged to rewrite the content, in order to eliminate errors and make the translation sound more natural.
The new version incorporates new quality control mechanisms for machine translation. Now the tool encourages translators to review the initial automatic translations on a paragraph basis, keeps in a tracking category those translations published with unmodified content for editors to review, and prevents publishing those which exceed the limits defined. The limits to prevent publishing become more strict for users with previous deleted translations, users ignoring the warnings, and cases where several paragraphs contain unmodified contents. In this way, the limits adapt to reduce potential recurrent misuse of the tool.
In general, our measurements suggest that translations are less likely to be deleted than the articles started from scratch. The survival rate for translations even when those are created by newcomers seems quite good. A recent study shows that a significant percentage of the translations created with the tool survive the community review. Although the survival rate is better for experienced users, it is still very good for newcomers (users that created their account during the last 6 months). For example, only 7.5% of translations created by newcomers in last june were deleted after a month.
In addition, Artificial Intelligence is becoming more present in the tool to make the initial translations better:
We believe that automation with adequate quality control mechanisms makes it easy for translators to create higher quality translations more easily.
Translation has helped already many communities to create new content. However, there are still communities with potential to grow by using translation that have not been using the tool as much.
Content Translation’s Boost initiative is aimed at expanding the use of translation to help more communities grow. By enabling new and more visible ways to contribute by using translation, we expect communities to attract new editors, and expand the knowledge available in their languages.
We identified potential for expanding its use to more contexts that can benefit from translation:
Translation can be used by more wikis. The adoption of Content Translation varies significantly from wiki to wiki, and there are wikis with potential to benefit from using translation more.
Translation can be used in more ways. Currently, Content Translation focuses on creating new articles on desktop. Supporting new kinds of contribution such as expanding existing articles with new sections, or mobile translation enable more opportunities to contribute.
During the next months we will focus on wikis with potential to grow by translation. As a representative set of those wikis we have initially selected Malayalam, Bengali, Tagalog, Javanese, and Mongolian. We’ll be contacting these communities to gauge the interest in the project, and learn about their particular needs to support them better. We expect these and similar communities to benefit as a result. Our specific plans will be heavily influenced by research in the selected communities and their feedback. Please, provide any feedback about this initiative in the discussion page. We are interested in hearing your ideas on how to help communities grow by using translation.
Editors using the mobile website on Wikipedia can opt-in to new advanced features via your settings page. This will give access to more interface links, special pages, and tools. Feedback on the discussion page is appreciated. 
Due to the absence of volunteer maintenance of Cologne Blue skin, the link to activate it will be hidden. The skin will still work, but editors using it are encouraged to switch to another skin. 
Changes later this week
Due to Wikimania, there is no deployment this week. 
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 August at 15:00 (UTC). See how to join.
The “Wikidata item” link will be moved from “Tools” to “In other projects” section on all Wikimedia projects, starting on August 21st. Full announcement, Phabricator task.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 August. It will be on non-Wikipedia wikis and some Wikipedias from 7 August. It will be on all wikis from 8 August (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 7 August at 15:00 (UTC). See how to join.
Today everyone can see IP addresses if someone edits without an account. In the future this could be more hidden. This is to protect unregistered editors so fewer can see their IP address. This would only happen after we make sure the tools for vandal fighting can still be effective. You can read more and comment.
Editing Wikipedia with VisualEditor on the mobile web
The Wikimedia Foundation’s goal for VisualEditor this year is to create a frictionless environment for editing on mobile to help editors publish more frequently, with more joy. After brainstorming, the Foundation’s Editing team came up with a set of mobile design principles to apply to a plethora of possible design interventions. This post describes our thinking behind the first round of interventions.
Intervention 1: Manage Performance Expectations
Evaluating the user experience, we noticed that certain areas of the experience felt pretty slow to editors. While performance is something that we will continue to work on (and can really only manage to some degree as the other part of the equation is the user’s environmental bandwidth), we can make this moment feel less painful for the user by managing their expectations around performance.
The key issue here is that users aren’t given any kind of feedback during moments like these. Many folks click their edit button and see this blank white screen with a spinner.
We thought of a few different ways to address this, including microcopy telling users what’s happening, skeletons and loading screens. Ultimately, we decided to address this by creating a seamless animation transition. To do this we grey out the read mode and transition it to line up with the edit mode. Then when the editor is ready we seamlessly swap it in. We combined this with a user interface refresh to provide a more reassuring throbber and instructional microcopy. In addition to reassuring contributors, the loading overlay helps editors to maintain their focus on the edit that they initiated the editor with the intention of making.
Intervention 2: Improve Wayfinding through Section Editing
We believe that mobile editors can be more productive when they are able to focus on editing only one section at a time.
While the performance expectation intervention is in the realm of meeting fundamental expectations, the second issue we tackled is more unique to Wikipedia: navigating to your edit! One complaint that we repeatedly heard from editors during user testing was that they would find something to edit, click the edit button and then take a really, really, really long time to scroll to the part of the page that they intended to edit. This is acutely painful for users on mobile devices because the amount of information revealed to them at any given time is significantly smaller than on a desktop experience. What was happening in mobile was that you’d click a section editing button and get taken to the editing view but scrolled more or less in the proximity of the section you intended to edit.
Our intervention removed all of the other content so that you can focus on just that one specific part of the content. This directly relates to our mobile design principles — we are removing stimulation and setting the stage so that an editor can do one thing at a time.
Initial Testing Results
We tested these interventions on-wiki, on usertesting.com and, at in-person editing events. The initial feedback has been quite positive. Users have been able to maintain their location within the edit and are using words like “expected” or “obvious” when describing the behavior of the interactions.
We’ve also learned that many people expected to be able to have the functionality to edit the whole page as well as choosing to dive in and edit within sections. Additionally (while unrelated specifically to this intervention, but useful for the future iteration of the product), we observed several users attempting to switch back and forth between the different edit modes without much success.
Shipping and Next Steps
These first two interventions (the loading overlay and section editing) have already shipped to Wikipedia and, in addition to the qualitative analysis efforts that I described above, we have recently concluded an A/B test thatshowed that “contributors using Section Editing are ~3% more likely to save the edits they start than contributors using full-page editing.”
The loading overlay was deployed to all Wikipedias and the same was done for section editing after we analyzed the test results.
What’s next for VisualEditor on Mobile?
Although 3% seems like such a small increase, we are banking on lots of incremental interventions having a large collective impact. The Editing Team analyst, Neil Patel Quinn said, “Considering the difficulty of making it possible to contribute to an encyclopedia on a four-inch screen, a 3% increase from a single tweak to the interface is a real accomplishment.” The next three interventions that we are tackling are:
1. Make VisualEditor default for new users on mobile. All of our testing suggests that there are just too many steps for an editor to get into VisualEditor, which in theory, is the more new-contributor-friendly experience. Let’s lessen the burden and make VisualEditor more discoverable by openly testing out this hypothesis.
2. Make it easier to edit context items (links, citations, images, infoboxes, templates, etc.) on mobile. Editing these items is an unnecessarily complex activity. We’re creating a new part of the interface that will show additional details about, and actions related to, editable elements within articles. These interventions will help editors to focus on one thing at a time while simultaneously creating more structured workflows around specific editing tasks.
3. Make a single state toolbar. Contributors are confused about what steps to take to publish their changes, how to undo a mistake and go back without losing all of their changes, and how to get back into editing mode after “accepting changes”. That combined with the fact that contributors are confused about why the toolbar behaves in unexpected ways is why we need to refine the toolbar so that it can be used as a guidepost during editing.
A few things that you can do to help
Excited? Great! So are we. We want to collaborate with you to make this a great mobile editing experience. Here are three things that you can do right now.
Edit Wikipedia using your smartphone via the mobile web
The best way to help with this effort is to try editing on your phone. Don’t focus on the new features, just make some great additions to the encyclopedia.
After you’ve made edits or contributed in some other way on mobile, tell us about it by posting on our product page.
Incorporate user testing into an upcoming event
Do you organize events for editing Wikipedia articles? If so, we would love to collaborate with you to learn how Wikimedians are editing directly from you, so drop us a note on the Talk page.
Thanks to Ed Erhart, Peter Pelberg, Sherry Snyder, Bartosz Dziewoński, Carolyn Li-Madeo, and Ed Sanders for proofreading and feedback. Thanks again to all those who have participated as testers.
🤜🏽 David Chan, Bartosz Dziewoński, Ed Sanders, and Peter Pelberg for working on the implementation of the Wikipedia editing features described here.
Structured Data on Commons (SDC) relies on two other pieces of software to make it work: federated Wikibase and Multi-Content Revisions (MCR). Both of these things required a lot of time and resources to make them work, with federated Wikibase developed by Wikimedia Deutschland, and MCR development shared by several teams across the Wikimedia Foundation and Wikimedia Deutschland. MCR, as one of the most significant changes to MediaWiki in the past decade, underwent an extensive proposal-and-discussion period before development.
Wikibase is a free, open-source database software extension for MediaWiki developed to as part of the Wikidata project. Federated Wikibase allows a wiki with Wikibase installed (the client) to communicate back to a central Wikibase installation (the repository). In the context of the structured data project, the client, Commons, needs to be able to get and return information from the repository, Wikidata. The information Wikidata holds that Commons needs is the structure and relationship between concepts being described in files Commons. For example, if an image depicts a house cat, the labeling of “house cat” as depicted is stored on Commons, while the concept of “depicts” comes from Wikidata.
Federation means making calls from one wiki’s Wikibase instance to another to retrieve information, and those calls have the potential to end up affecting the performance of the websites. Making sure that structured data didn’t cause such a slow down was one of the challenges with federated Wikibase. Additionally, enabling cross-communication between Wikibase instances required a lot of new code changes that sometimes had surprising side effects on the host wiki. The development teams spent months finding and fixing all of these problems.
Multi-Content Revisions completely changes how pages are assembled and displayed to a user. On a wiki without MCR, a page revision – that is, the version of a page as it exists when edited and saved at a particular state in time – is stored and displayed as a single type of data, such as some form of wikitext mark-up, JSON, or Wikibase entries. Since SDC needs to store and display more than one type of revision at a time, software needed to be written to change how a page revisions work for Commons.
MCR restructures a part of how MediaWiki stores information, by adding a layer of “indirection” as a way to link between revisions with different data components. The additional layer required not only new server-side code and an interface, but a massive change in the data schema and accompanying migration to the new schema.
Since the way page revisions and the data contained were stored in the back-end, there was additional work to make this change on the front-end, facing Commons users.
Diff views have to work with multiple slots. A diff view details a revision of a page, and engineering had to be done to show diffs from multiple slots of a revision.
Multi-slot views were needed. This work parallels the work on diff views, and shows the content of all slots when viewing a revision of a page.
MediaWiki’s internal search engine, Cirrus Search, had to be engineered to work with MCR. Cirrus Search can crawl each slot, which will surface the information there to the widest possible audience. The enables semantic search of structured, linked data in files.
All of this engineering for MCR and federated Wikibase had to be completed before the Structured Data team was able to release its features to Commons. The Structured Data team is very grateful to the Core Platform, Wikidata, and Search Platform teams for all their work to make structured data storable, displayable, and searchable on Commons. With the infrastructure they created, the SDC team can create more powerful structured data features for Commons contributors.