Structured Data on Commons Part Four – Depicts Statements

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.

Wikimedia Commons / CC-BY-SA 4.0 / GFDL

With support for depicts, people searching for specific media files on Commons can begin finding them in a structured, multilingual way. At the time of release, depicts statements can be searched using the keyword haswbstatement. For example, if you wanted to find all instances of depicts (P180) a house cat (Q146), in the search bar you can use: haswbstatement:P180=Q146 and it will return results in all languages.

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.

Wikimedia Commons / CC-BY-SA 4.0 / GFDL

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.

Next: Structured Data on Commons Part Five – Other Statements

Previously: Part Three – Multilingual File Captions


Tech News (2019, week 36)

Please find below the latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. 

Translations are available: Bahasa Indonesia • ‎Deutsch • ‎Tiếng Việt • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎čeština • ‎Ελληνικά • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎فارسی • ‎中文 • ‎日本語

Due to Wikimania and summer vacation, no issue of Tech News has been distributed last week.

Recent changes

  • 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. [1]
  • 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. [2]
  • The limit for rollbacks has been increased from 10 to 100 rollbacks per minute. [3]
  • 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:[4]

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[5]

Meetings

Future changes

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe to receive it on wiki.


Tech News (2019, week 34)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.

Translations are available: Bahasa Indonesia • ‎Deutsch • ‎English • ‎Tiếng Việt • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎svenska • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎中文 • ‎日本語

Tech News

  • There will be no Tech News issue next week. The next issue of Tech News will be sent out on 2 September 2019.

Problems

  • 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. [1]

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. [2]
  • 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).

Meetings

  • 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.

Future changes

  • 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. [3]

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.


Structured Data on Commons Part Three – Multilingual File Captions

Wikimedia Commons

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.

A description template that contains a lot of well-organized information, but might not be serving the purpose that a caption can. Template credit Wikimedia Commons, text may be CC-BY-SA 3.0 where applicable.
A caption for the same file based on facts in the description template.

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.

Adding other languages to a caption.

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.

Next: Part Four – Depicts Statements

Previously: Part Two – Federated Wikibase and Multi-Content Revisions


Half a Million Articles Translated With Content Translation

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.

This system can be customized to address the particular needs of each community, and proved to be useful to help the Indonesian Wikipedia editors to reduce the creation of low quality translations.

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.

Future plans

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.


Tech News (2019, week 33)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. 

Translations are available: Bahasa Indonesia • ‎Deutsch • ‎English • ‎Tiếng Việt • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎svenska • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎中文 • ‎日本語

Recent changes

  • 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. [1]
  • 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. [2]

Changes later this week

  • Due to Wikimania, there is no deployment this week. [3]

Meetings

  •   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.

Future changes

  • The “Wikidata item” link will be moved from “Tools” to “In other projects” section on all Wikimedia projects, starting on August 21st. Full announcementPhabricator task.

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.


Tech News (2019, week 32)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. 

Translations are available: Bahasa Indonesia • ‎Deutsch • ‎‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎中文 • ‎日本語

Changes later this week

  •  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).

Problems

Meetings

  •   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.

Future changes

  • 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.

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.


Distraction-free editing

Editing Wikipedia with VisualEditor on the mobile web

Distraction-free_editing.png
Illustration of a person editing Wikipedia on a mobile device — Distraction-free editing.png () by Jess Klein /Wikimedia Foundation, CC-BY-SA-3.0.

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.

Blank_white_screen_with_a_loading_spinner.png
English: This blank white screen with a spinner provides no feedback to the editor about what is loading or happening.
Blank white screen with a loading spinner.png () by Jess Klein /Wikimedia Foundation, CC-Zero.

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.

Editing_Wikipedia_on_mobile.gif
English: In this gif, you can see that a user taps on an edit button and instead of seeing a blank white screen with a loader, they see a series of screens and overlays to indicate progress (and if we did this right, they won’t even realize that this is happening).
Editing Wikipedia on mobile.gif () by Image by Jess Klein CC0 and text from Wikipedia. https://en.wikipedia.org/wiki/Nellie_Bly, CC-BY-SA-3.0.

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.

Way-finding_improvements_to_mobile_editing.gif
English: As you can see here, the contributor can get to the content faster!
Way-finding improvements to mobile editing.gif () by mage by Jess Klein, CC0 and text from Wikipedia. https://en.wikipedia.org/wiki/Nellie_Bly, CC-BY-SA-3.0.

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.

Share feedback

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.

Originally posted by Jess Klein to Down the Rabbit Hole on 22 July 2019.


Structured Data on Commons, Part Two – Federated Wikibase and Multi-Content Revisions

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.

To the left, the previous method of calling a page revision. To the right, calling a page revision using MCR.

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.
  • An extra slot had to be configured in order to store Wikibase entities on MediaWiki in addition to wiki-text.
  • MediaWiki extensions have to be compatible with MCR, and the tools had to be identified and updated. This ensures, for example, that the tools we use to prevent spam and other malicious behavior work with MCR.
  • 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.

Next: Part Three – Multilingual File Captions

Previously: Structured Data on Commons – A Blog Series


Tech News (2019, week 31)

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.

Translations are available: Deutsch • ‎English • ‎español • ‎français • ‎polski • ‎português do Brasil • ‎suomi • ‎čeština • ‎русский • ‎українська • ‎עברית • ‎العربية • ‎नेपाली • ‎中文 • ‎日本語

Problems

  • Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch. [1]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 July. It will be on non-Wikipedia wikis and some Wikipedias from 31 July. It will be on all wikis from 1 August (calendar).

Meetings

  • You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 31 July at 15:00 (UTC). See how to join.

Tech news prepared by Tech News writers. More information on how to contribute is available at Tech/News#contribute

Translate • Get help • Give feedback • Subscribe or unsubscribe for on wiki distribution.