Getting ready to travel again I haven’t traveled in four years. My last trip happened in 2019 when I spoke at a local Google Developers Group event in Brasília. As a disabled person, I’ve been quite cautious about returning to all in person activities—the lack of testing and masking discourage me from attending most conferences and meetings. CZI reached out to me by the end of December asking me if I had interest in attending a workshop in Buenos Aires in April (thanks for the recommendation, Karen!

17/01/2023-23/01/2023

Mapping

• User bradrh consulted the US Forest Service Motor Use Maps to update motor vehicle access restrictions on forest roads and trails in several national forests.
• Bryce Cogswell (bryceco) listed every OpenStreetMapper that has managed to map for more than a thousand days without a break.
• Lejun described ► how to merge data from different sources into OpenStreetMap. He explained the different tools and methods, including the JOSM plugin UtilsPlugin2.
• Christoph Hormann wrote a blog post describing the problems with the name key and promised to try to propose a possible solution in his next post.
• Tomas_J has provided ►
  pictures and suggested tagging for a few Slovak-specific features.
• Valerie Norton (valhikes) has summarised her mapping activity around Gunnison, Colorado between February and September 2022. Details of each hike, with lots of photos, are posted on her blog.
• Voting on the suggestion to announce proposals on the OSM Community forum, as well as the tagging mailing list, has closed. It was approved with 48 votes for, 5 votes against and 0 abstentions.

Community

• OpenStreetMap recently hit a milestone with more than 10 million user accounts. The milestone was discussed on r/openstreetmap. It should be noted that only about 1.9 million of these accounts have been used to make a map edit.
• Daniel Capilla (dcapillae) has created ► a tutorial on how to make a metrominuto (a schematic map of a municipality or city that represents the distances between its main points and the average time it takes to walk between them) of your area of interest.
• Mevesscarto gave ► us an update on their progress to armchair map the French department Côtes d’Armor.
• watmildon explained the JOSM and MapWithAI workflow that they are using to add missing street addresses to OSM.

OpenStreetMap Foundation

• Get to know the new OSMF Board. In December 2022, four new members were elected to the OpenStreetMap Foundation Board, complementing the three members already serving. The new members, Arnalie Vicario, Craig Allan, Mateusz Konieczny, and Sarah Hoffmann, have joined Guillaume Rischard, Mikel Maron, and Roland Olbricht.

Local chapter news

• Nominations for the OpenStreetMap US 2023 Board Elections are now open. The OSM US blog has more details if you are interested.

Education

• UN Mappers has launched the UN Maps Learning Hub, a self-learning platform accessible to anyone interested in the OpenStreetMap project. Courses will be available in several languages and will cover aspects of topographic and humanitarian mapping. The OSM Basics course is already available.

OSM research

• With the release of the OSHDB (OpenStreetMap History Database) Version 1 for spatio-temporal analysis, the HeiGIT team at Heidelberg University has reached an important milestone. The data is open to everyone, whether they belong to journalism, science or humanitarian organisations. The ohsome dashboard allows you to analyse OSM temporal data for any region. A significant enhancement is the new OSHDB filters that allow practitioners to filter entities by the shape of the geometry (one measure of quality often discussed by the OSM community).
• GeoObserver has published ► the third part of its ‘Meierloch’ trilogy on the distribution of surnames and their visualisation on a map.

switch2OSM

• Roberto Brazzelli described ► how the municipality of Limone (Piemonte, Italy) provides a map of amenities using uMap. Data is maintained in OSM by council staff, but updates are quality controlled via QGIS with data cached in Google Sheets from Overpass queries.

Software

• Kshitij Raj Sharma has created ‘OpenStreetMap Stats Generator’, which uses osmium to analyse the change files from OSM and generate statistics in different file formats such as csv, json, and jpg. Results are also being tweeted. A second bot follows the recent trends on OSM and retweets the findings with hashtags #osm, #openstreetmap and #hotosm every three hours.
• rtnf asked why the OpenStreetMap Stats Generator needs an OpenStreetMap login and proposed a lightweight version without the need for credentials.

Programming

• [1] rtnf, inspired by posts on imagery collected by MapComplete (we reported earlier), has created a web app that randomly samples MapComplete images. In his blog, he explained how to visualise tagged imgur images on OSM.
• Jake Coppinger reported on his efforts writing a vector tile server for osm2streets to provide lane-accurate street maps with OpenStreetMap. Jake also revealed that his Safe Cycling Map now works for the entire world.
• Tobin Bradley recorded a screencast video that captures how protomaps is used to create a PMTiles file, a single file vector tiles format, and integrate it into a MapLibre demo map. This setup allows you to create vector tile maps with static infrastructure.
• starsep explained how Bing StreetSide imagery can be used for mapping with JOSM.

Did you know …

• … about the shop suffix for repair? You can use this to specify services available for computers, bicycles, shoes and more, as tooted by OSM Tourism.
• … Thomas Gratier’s comprehensive listing of map-related things?
• … the OSM Welcome tool, hosted by OSM-Belgium? This app helps identify new contributors to OSM in a given area, how many edits they’ve made, and their preferred editor. It also keeps track of which users have been sent a welcome message via the site.
• … the comparative overview of possibly every OSM-related Android app?

Other “geo” things

• The Equal Earth physical map of the world is now available in German, thanks to the work of Simon Scherrer.
• Devin Lea has started a new weekly social media hashtag #MapPromptMonday with a different theme each week. Last week the theme was using colour-blind friendly symbology. Upcoming themes have been listed.

Upcoming Events

Where	What	Online	When	Country
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-01-28
南区	京都！街歩き！マッピングパーティ：第35回 六孫王神社		2023-01-29
Windsor	OSM Windsor-Essex Monthly Meetup		2023-01-31
San Jose	South Bay Map Night	✓	2023-02-01
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
	OSMF Engineering Working Group meeting		2023-02-07
Strasbourg	Mapathon CartONG		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
London	London social pub meet-up		2023-02-08
München	Münchner OSM-Treffen		2023-02-08
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09
左京区	京都！街歩き！マッピングパーティ：第36回 金地院		2023-02-12
København	OSMmapperCPH		2023-02-12
San Jose	South Bay Map Night	✓	2023-02-15
Karlsruhe	Stammtisch Karlsruhe		2023-02-15
Olomouc	únorový olomoucký mapathon		2023-02-16

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by ChristopherGS, Kasey2, MatthiasMatthias, Nordpfeil, PierZen, SK53, SeverinGeo, Strubbl, TheSwavu, barefootstache, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Last week the Wikimedia Foundation Web team deployed a new desktop experience to English Wikipedia under the Desktop Improvements project, introducing the largest change to Wikipedia in over a decade. In addition to a refreshed design and a variety of new features, this experience also represents a large shift in Wikipedia’s accessibility. Web accessibility means that web resources are designed and developed so that they are usable to all people regardless of ability. This inclusive practice is essential to the Wikimedia Foundation’s mission to provide free and equitable access to information. 

In this post we’ll explore how the Web team tackled accessibility challenges and share opportunities for us to better address the needs of disabled people and other historically marginalized groups.

Modernized experience, more accessibility challenges

In many ways, the new experience pushed the boundaries of Wikipedia’s former design and codebase. It focused on making the site more welcoming and usable for new readers and editors by adding interactivity and rich experiences to a site that was a relic of an older, simpler internet. While we have ample research and testing showing that these changes improve usability, they also presented many new accessibility challenges, especially for keyboard and assistive tech users.

Custom widgets

Features like the improved search and language switcher introduced more complex JavaScript-based widgets, which need to include appropriate semantics and keyboard/mouse interactions.

For example, the new search features an ARIA enriched component that is text zoomable by user preference. In contrast neither assistive technology exposure nor text scalability were available in the old interface.

Menu restructure

As part of our effort to help new users better understand the details of Wikipedia, its navigation, and editing tools, the new interface updates many of the menus and navigation links. Related links were grouped together, and certain links were moved to declutter the interface and provide focus for the most important actions. This restructure also impacts how screenreader users discover and navigate links on the site, so we had to consider how to best update accessible labels, the heading structure, and navigation methods like landmark regions along with these changes. 

Dynamic, customizable interface

Users now have the ability to customize their experience by pinning and unpinning important menus into the sidebars next to article content. In order to support this customization, we had to consider how focus management and the HTML source order will be impacted when elements are pinned and unpinned.

Inclusive product development

Going into the redesign, our team aimed to maintain and improve the existing standards for accessibility. To accomplish this, the Web team worked to embed accessibility into our product development process.

Inclusive values and processes

The Web team was an early adopter of the Inclusive Product Development Playbook, a new framework aiming to build inclusive practices into product development across the Wikimedia Foundation. The playbook helped us implement new processes for staying accountable to accessibility, including checks throughout the different stages of product development and improved testing methods. For example during the initial design stage of each feature, our designer created working HTML prototypes for testing and feedback. For the table of contents feature, this prototype was even expanded to a browser extension, which allowed testers to try out new features as they browsed Wikipedia naturally. These prototypes were useful for design iteration in general, but were also a helpful tool for surfacing early accessibility considerations – i.e. starting discussions around the expected behavior for keyboard interactions.

We were also able to leverage help from users and volunteers who generously contributed accessibility-related feedback and bugs on the wikis and in our public issue tracking board. Community feedback throughout the project helped us prioritize accessibility bugs and enhancements.

Accessibility-first development

During development, the engineers were proactive about implementing new features with accessibility in mind from the beginning. One example of this was when the team reordered the DOM to ensure a logical source order near the beginning of the project. This effort involved extensive research and discussion, as it was a large change to the underlying HTML structure of Wikipedia and would have large implications on new features, existing extensions and gadgets, and of course accessibility.

We also utilized Foundation-wide accessibility and design standards with features like the improved search, which was implemented with the new Codex design system. Codex is a design and component library that has accessibility features built in, and it plays an increasingly important role at the Foundation for scaling accessibility. The Web team plans to further integrate Codex into our work in the near future.

Accessibility testing

The Web team relied on a variety of tools and testing methods to catch accessibility issues, including automated tests and manual testing by engineers and quality assurance testers. Our automated tests run daily accessibility reports and report data to a dashboard to track errors over time, helping the team measure impact from our efforts and making it easier to spot new errors at a glance.

The Web team also conducted two rounds of accessibility testing with experts from the American Foundation for the Blind in September 2022 and October 2022. These tests evaluated the new interface across several screen reader and browser combinations against WCAG (Web Content Accessibility Guidelines) 2.1 Level AA Conformance. Overall, the results were positive, and we saw noticeable improvements comparing the original experience with the new. Any unresolved issues that were discovered from testing have been prioritized, and we are working diligently to resolve them this month.

Future opportunities

Accessibility is a living, iterative process that requires ongoing effort; it isn’t a checklist or set of compliance that can be “done”. Similarly, the accessibility of the Wikipedia experience and our team’s approach to inclusive product development needs to continue to evolve, too.

Even after the launch, there are still many opportunities for improvement that are being addressed.

1. Continued education for building accessibility awareness and expertise within the team and the Wikimedia Foundation.
2. Need for better authoring practices and tools so that editors are empowered to create accessible wiki content. The accessibility changes discussed in this post are limited to the user interface around the content, as most of the page content is user generated.
3. Address accessibility technical debt, particularly with features that were built in the past or have cross-team dependencies that make prioritizing that work more difficult.
4. Continued research with under-served groups to better understand the impact of our ongoing changes, especially with assistive tech users and other groups like users with ASD/ADHD.

While we still have a long way to grow, we are proud of our progress so far. We were able to prioritize and iterate on accessibility throughout the project and contributed to a longer process of building up accessibility expertise and best practices. If you would like to help, we welcome and appreciate your feedback on the Desktop Improvements project page or on the Web team’s issue tracker. Thank you for following our journey!

Wikipedia Day is an occasion to celebrate Wikipedia’s birthday. Every year on or around January 15 Wikipedia fans organize their own parties in their own communities to discuss Wikipedia and share cake. As part of the Wikipedia Day celebration by Igbo Wikimedians’ community, a good number of Igbo Wikimedians sent in Goodwill Messages to Wikipedia while reacting to the relevance of Wikipedia to them (individually). They pointed out some challenges they encounter while editing on Wikipedia and did not forget to render some advice to the Igbo Wikipedia administrators on ways forward. Interesting reactions and anonymous feedbacks were gotten from over 50 (fifty) Igbo Wikimedians. A survey with details of how long the members have been editing on Wikipedia, the relevance of Wikipedia so far, their level of contribution to English and Igbo Wikipedia as well as their experiences while editing on Wikipedia was recorded and reported herein.

Members’ duration of editing Wikipedia

On such a day when Wikipedia is celebrated, there was need to determine how long some Igbo Wikimedians have been editing on Wikipedia (English and Igbo). It was recorded that a larger percentage have edited or contributed on Wikipedia for less than one year while the least have contributed for three years and above. Indications here shows that there is a significant increase in new Igbo Wikimedians within the last one year.

Level of relevance Wikipedia has been to members

The Wikipedia Day 2023 celebrations opened our eyes to the fact that Wikipedia has been a very relevant project to Igbo Wikimedians. Non-relevance of Wikipedia was at zero percent. Obviously, the relevance of Wikipedia on the Igbo community cannot be over-emphasized.

Contribution to Igbo and English Wikipedia

The impact of local language on the Igbo community was demonstrated from their level of contribution to Igbo Wikipedia. Quite a number of the Igbo Wikimedians contribute more on Igbo Wikipedia. Subsequent feedbacks herein reveals the reasons behind this. However, indications from the chart below also shows that a higher percentage have contributed on both English and Igbo Wikipedia.

Why the interest on Igbo Wikipedia?

With majority of Igbo Wikimedians indicating that they contribute more on Igbo Wikipedia, there was a need to ascertain why the preference. Over fifty members of the community shared their reasons among which are these:

“It is because it’s my language. It gives me the opportunity to share my thoughts and language to the world.”

“The fact that one can Edit and write more about our language and our culture. Language visibility is the most thing that interests me to always contribute.”

“As an indigenous language activist, Igbo Wikipedia provides me the leverage to project my indigenous language (Igbo) at the digital space.”

“The fact that I can freely share knowledge and also partake in the sum of knowledge.”

“Am happy to be among Igbo Wikipedia because it’s helps me to learn my mother tongue”

“It’s very much easier as i can contribute with easier as a speaker of Igbo Language”

“Overall it’s just the joy of having Wikipedia in my own language and the opportunity of contributing to global knowledge in my local dialect”

“I love that it makes English articles available in our local language thereby encouraging free knowledge devoid of language barrier.”

“The sharing of knowledge in diverse field of life interests me about Igbo Wikipedia. The preservation of culture is part of it too.”

“What interests me mostly about igbo Wikipedia is the fact that it gives me an opportunity to edit in my local language and it helps me to be more expressive.”

“They friendly nature of the people i met, the way they socialize and how much patient they exercise to educate us, to list but a few.”

“The cooperation of the contributors.”

More responses on this can be seen on the Meta Page.

Why do you like/dislike editing on Igbo Wikipedia?

Notwithstanding the fact that majority of Igbo Wikimedians share positive feedbacks on their interest on Wikipedia editing, there was at least a feedback that reveal few members had issues which makes them reluctant to edit on Wikipedia. One anonymous feedback recorded that there were “Network issues and reference errors” which poses a challenge to Wikipedia editing. Indeed network challenges could be very frustrating while editing. Also noticing reference errors after translating articles could be discouraging.

How has your experience been while editing on Igbo Wikipedia?

It was a field day for Igbo Wikipedia on Wikipedia Day celebration as every Igbo Wikimedian found editing on Igbo Wikipedia an interesting experience. Thank you Wikipedia!

What areas do you think we should improve on the Igbo Wikipedia?

Having extracted reactions from members on their Wikipedia experiences, they pointed out areas where Igbo Wikipedia should be improved upon. Some interesting suggestions (as shown below) were drawn from the responses and will be of importance to editors of Wikipedia.

“Please assign admins who can serve as checkers to articles because 50 percent of the articles on the ig pages were translated,not giving the equivalent of the source language.”

“I don’t think there is any.”

“More translation tools should be added to the Igbo Wikipedia interface to enable translators have varieties of tools to consult while translating contents.”

“Addition of audio templates to Wikipedia. It will help tackle the misprounciation of indigenous names on Igbo Wikipedia.”

“We need more competitions to improve the interactiveness”

“More active Wikimedians. Get more technical hands. Cleaning up edited article”

“I think organizing continuous training so as to imprint in the minds of people how to contribute rightly and correctly.”

“The community is doing very well but given the inflation rate may be it will be fine to increase micro grant”

“I think we should make more information about the Igbo culture more available for people to and stop letting others hijack what’s ours from us.”

“You guys are already doing so well”

“Making accurate edits during contest with the aim of presenting our language well rather than to win prizes.”

“The teaching and learning of the central Igbo. Many translate and edit in their different local dialects. The use of central Igbo in editing and translation should be encouraged just like the one in the translated Igbo bible which everyone is conversant with.”

See more

Advice for the Igbo Wikipedia admins?

Wikipedia Day 2023 had a good number of Igbo Wikimedians advising their Wikipedia administrators. Recommendations and accolades were also rendered viz:

“They should keep up the good work”

“Let the work continue with the same agility”

“Always appreciate the newbie’s whenever they publish a new article by sending them email or by writing on their talk page. It helped to motivate me back then.”

“I want to appreciate the admins for their effort to make Igbo Wikipedia stand out but will also encourage them to check articles during contest because most editors deviate from the meaning the text try to convey but only translate to win a price. I know it’s can’t be that easy but If there should be a way so as to have the exact meaning in the target language.”

“We should focus on human development. Recruitment and training of new editors so as to be able to keep up with the vast information Wikipedia has to offer.”

“They are doing great and more hands are needed as Admins.”

“Y’all should keep up the good work you’re doing and we’ll keep supporting you guys and together we’ll make the Igbo Wikipedia second to none.”

“Prompt warning in the case of vandalism should be activated.”

“Igbo Wikipedia admins have been awesome/tolerable over the time, I only advice they keep it up.”

“The admins are doing really great,but they should look into the area of unprofessionalism … Yes, everyone can edit on Wikipedia but there should work on how to review people’s work before publication or create a space where professionals can proofread works posted by others before publication.”

“Just encouragement to keep doing what they’re doing. Proud to be a member”

See more

Igbo Wikimedians drop goodwill message for Wikipedia @22

The highpoint of the Wikipedia Day 2023 celebration for the Igbo Wikimedia community was the pouring in of Goodwill and Birthday messages on Wikipedia. It was quite an interesting collection as expressed below:

Happy birthday to Wikipedia It’s been good working with you guys Many prosperous years ahead From Ngene Blessing

Hurray!!!. A hearty congratulations to Wikipedia @22. Shine on Yours Sincerely, Viva

I am Obedmakolo , am so much Interested in the move of the wikimedia world , it’s so much interesting to see another year again as editors and seeing wikimedia moving higher. Let the zeal continue and more to come we see wikimedia become more great again than this. Happy wikimedia day to all.

Frankincense Ifeanyi Diala is wishing Wikipedia a Happy 22 Years of Existence. Keep flourishing like the Cedars of Lebanon and the Olives of Israel.

I’m excited that I can preserve and digitize my language through you. Long live Wikipedia – Tochi Precious

More greater heights and many more things to accomplish (Ramzyshelby)

I love the open concept of Wikipedia. It’s a good experience to read, edit and contribute to knowledge on Wikipedia. There’s always something to be do on Wikipedia…I so much love the Language diversity. Goodness Ignatius.

I really appreciate everyone in the Igbo Wikipedia am happy to be among you all and happy birthday to our Wikipedia May the good God keep us going

Judith is wishing Wikipedia wonderful happy return in Jesus name amen. Happy birthday Wikipedia

I go by the name Lebron jay and I just want to wish Wikipedia a very Happy Birthday. Being a repository of free knowledge made accessible to just anyone is something that’s worthy of being acknowledged and celebrated. Long live Wikipedia!

Long live the Wikimedia foundation, long live Wikipedia. Cheers to more knowledge.

Happy birthday Wikipedia More success Momoh Khadijat

Happy 22 years of free knowledge sharing Happy 22 years of impacting lives Happy 22 years of existence More years to celebrate with greater achievements

Happy Wikipedia Day 2023 to the Wikimedian community. Keep up the good work in providing free knowledge to all. Ndewo! From Adaora Obuezie

May God bless the Wikipedia foundation and am wishing Wikipedia more days of celebration…… Mary Ogochukwu

Happy birthday the world wide open source of free knowledge movement. You have impacted many with the free knowledge disposition. Many happy returns to the entire community.

Hello I am Senator Choko, wanna wish Wikipedia a happy birthday and more success and great ideas to the community…

I sincerely wish Wikipedia rapid growth. ( Nelospecial)

More years to becoming the best among many others in this 2023. Abubakar Ibrahim

I celebrate Wikipedia @22 today. It has been an awesome one year experience contributing to Wikipedia in my language, Igbo, and I am willing to do more. More years to celebrate free open knowledge and making the world a better place. Cheers Mbenma Esther

Wikipidia! Oke mbara Na-Enye mmụta, Nghọta, Amamihe na nkuzi ọgbara ọhụụ, Nnabata onye ikwu na onye nta. Mgbasa mmụta n’ụwa niile. Ọnwa zuru ụwa ọnụ. Ị dị afọ iri abụo na abụọ ugbu a. Ka ọgbụgba afọ gị mịta mkpụrụ Ezi mmụta, agamnihu, udo na Mbawanye. Oby Ezeilo

Congratulations to Wikipedia @22 and many more years to Wikipedia.

Bravo to the super community of editors, you guys rock. keep the ball rolling my language elites.

Happy birthday Wikipedia, the Igbo wiki network loves you. We appreciate your choice of including the Igbo language in the media. – Dr. Okafor O.E.

I love Wikipedia and Wikimedia movement. Greater heights and more

Hi wiki, I just wanted to say a very big thank you, for giving me the privilege, exposure and opportunity to learn, edit and meet wonderful people around the world that I can learn from. I really appreciate all the help and enlightenment I have gotten,but most especially for bringing me this opportunity. It means a lot to me. With lots of thanks, Nwonwu Uchechukwu.

Am glad that Wikipedia is growing especially Igbo Wikipedia. I congratulate the Wikipedia family on this Wikipedia day. May God grant us wisdom to do more.

We extend our best wishes to you on your fifteenth anniversary of service with the Doe Corporation. Throughout the years we have enjoyed your dedication and enthusiasm for your job. To show our appreciation for your hard work, we invite you and your wife to attend the Doe Corporation’s annual awards banquet next month. You will receive your complimentary tickets in the mail. We wish you continued success for many years to come.

I’ve been involved (as an editor on Wikipedia) for barely 3 months and it’s been amazing- editing and translating articles on Igbo Wikipedia! Thanks for providing the platform to do this! Keep up the good work

I’m so happy to be part of this organization that works hard to make information available to everyone for free. Pray that God will reward you all abundantly.

I heartly congratulate the Wikipedia Foundation on its 22nd Anniversary. I Wish the foundation a more fruitful and sustainable years ahead, touching lives in the area of free knowledge depository. With best Regards, Ngoudechi.

Happy Anniversary Wikipedia and many more to come. Cheers

See more Goodwill Messages on the Meta Page

Wikipedia is indeed the source of knowledge for the common man and Igbo Wikimedians Community were proud to be a part of the Wikipedia Day 2023 celebration.

Long Live Wikipedia and the Wikimedia Foundation!

Holger Ellgaard – the Wikipedian Holger.Ellgaard – is dead.

Ellgaard was one of the most prolific article writers on Swedish Wikipedia, having written thousands of articles. He made a couple of hundred thousand edits on Swedish Wikipedia and another hundred thousand edits on Commons, where he had uploaded more than fifty thousand photographs since coming to the Wikimedia movement in the spring of 2007.

An edit count says very little in itself – some of us, like me, have a large number of minor fixes and few excellent articles. Holger, on the other hand, wrote a large number of featured and good articles, the kind of texts the community wanted to highlight as its best and put on the main page for everyone to see, more than anyone else on Swedish Wikipedia. On Swedish Wikipedia, his texts were the embodiment of quality content. Having spent his professional life as an architect and with a passion for photography, he wrote about buildings and city planning, architecture and infrastructure. His articles were long, well sourced and full of illustrations, usually his own photos. He liked to visit a place before writing about it, photographing it and making sure he had the pictures he wanted.

Many of his best articles were ambitious in scope. He wrote about buildings, but also on the Swedish kitchen standard and the redevelopment of central Stockholm from the 1950s to the 1970s. He wrote about any conceivable aspect of Stockholm as a city: public toilets in Stockholm, traffic signals in Stockholm, emergency housing in Stockholm, illuminated signs in Stockholm, railroad tunnels in Stockholm.

When Wikimedia Sweden started giving out an annual award to someone who had contributed to free knowledge in Sweden, Holger was the inaugural recipient. He felt like an obvious choice. Not only because of the amount of work he had put into writing his articles, but also his willingness to help anyone writing within his area of expertise. The Swedish Wikipedia community has lost one its most treasured contributors.

He was a great public educator. And now he isn’t, and we’re less for his absence.

Üsküdar University in Istanbul might be familiar to some Wikimedians; as it was the venue for the Wikidata Training Days in October 2022.  The event was organized by Wikimedians of Turkic Languages User Group and  participated by Wikimedians from 10 countries has inspired the students of the university so much that it paved the way for the foundation of  a Wikipedia Student Club in the university. 

The members of Wikimedia User Group Turkey (WMTR) visited the university and talked with the club members. Isna, the president of the club, told that the idea of founding such a club  in their university has been discussed for a long time but finally she and her friends took the initiative and the club was formed in November 2022, only one month after they had Wikimedians in their school for the Wikidata Training Days. 

are her classmates from the psychology department, others are from the departments of electrical engineering, sociology and virtual communication design. “We are nine girls and a boy,” she says. “and I’m sure we’ll produce some good work to fill the gender gap in wiki projects” she adds. 

Since the club was founded at the end of the fall term, so now the club members are getting prepared for the  activities of the next semester as they study their finals. They first would like to develop their own wiki-skills and invite others to join them. They plan to collaborate with other university clubs by organizing joint activities.  “We are talking with the Philosophy Student Club to organize an event at the beginning of the fall term,” says Isna. “We are planning to invite members of Wikimedia User Group Turkey for giving a short training on wikipedia-editing followed by an edit-a-thon on women philosophers.”

WMTR members wanted to learn if their professors know about their initiative and what they think.  Isna expressed that their Deputy Dean told her that he uses Wikipedia and  he likes it  because Wikipedia is a “free encyclopedia.” Another instructor also said she was happy to hear students start volunteering on editing Wikipedia because there are a lot of topics not yet covered at Turkish Wikipedia. 

Congratulations to the bold students of Üsküdar University for creating a club for contributing Wikipedia and its sister projects.

I’ve been working on linking Commons items to Trove. It’s not complicated, on the surface, but of course once you get into it things get more annoying. I’m trying to just figure out the basics, and not get too deep into the weeds.

Basically what we want is for every file on Commons, that has been sourced from an institution that’s aggregated in Trove, to have a P10044 statement (‘Trove Work ID’), and for that to be displayed in the |source= parameter of the Information template. But we also want to say which library (etc.) it came from, and to link to that library’s catalogue (because that’s where the actual image file is stored). This means, I think, that we’ll want to stick to the SLQ, SLWA, SLSA, AWM-image, etc. templates that have institution-specific information and links, and just add a simple line to those that explains that the file’s metadata is also on trove and what its ID there is.

I was intending to write a pretty different blog post about progress on mwbot-rs but...ugh. The main dependency of the parsoid crate, kuchiki, was archived over the weekend. In reality it's been lightly/un-maintained for a while now, so this is just reflecting reality, but it does feel like a huge setback. Of course, I only have gratitude for Simon Sapin, the primary author and maintainer, for starting the project in the first place.

kuchiki was a crate that let you manipulate HTML as a tree, with various ways of iterating over and selecting specific DOM nodes. parsoid was really just a wrapper around that, allowing you get to get a WikiLink node instead of a plain <a> tag node. Each "WikiNode" wrapped a kuchiki::NodeRef for convenient accessors/mutators, but still allowed you to get at the underlying node via Deref, so you could manipulate the HTML directly even if the parsoid crate didn't know about/support something yet.

This is not an emergency by any means, kuchiki is pretty stable, so in the short-term we'll be fine, but we do need to find something else and rewrite parsoid on top of that. Filed T327593 for that.

I am mostly disappointed because have cool things in the pipeline that I wanted to focus on instead. The new toolforge-tunnel CLI is probably ready for a general announcement and was largely worked on by MilkyDefer. And I also have upload support mostly done, I'm just trying to see if I can avoid a breaking change in the underlying mwapi_errors crate.

In short: ugh.

Oral knowledge as a form of human communication involves the oral reception, preservation, and transmission of cultural content from one generation to the next. Folktales, ballads, chants, prose, and poetry may all be transmitted orally or musically. In this method, a culture can pass down oral history, oral literature, oral law, and other types of information to future generations without the need for writing systems or even in conjunction with them.

Today, there needs to be more freely licensed oral knowledge in audiovisual forms that can be used for teaching, research, reference materials, or other educational purposes.

Between 2020 and 2022, the Wikimedia User Group Nigeria and the Yoruba Wikimedians User Group, with the support of the Wikimedia Foundation, which owns Wikipedia, produced 100 Nigerian oral histories and 20 audiovisual recordings of Yoruba Indigenous work to support learning, teaching, and other educational purposes.

On January 18, 2023, the Wikimedia User Group Nigeria and the Yoruba Wikimedians User Group collaborated to donate these materials to the Department of Linguistics and African Languages at the University of Ibadan.

The event was held at the Department of Linguistics and African Languages at the University of Ibadan. It was attended by the Dean, Faculty of Arts, Professor O.A. Oyesile; the Head of the Department, Linguistics and African Languages, Professor Oye Taiwo; and the Head of the Department, History, Professor Rasheed Olaniyi. Others included Professor Phillips Ogundeji, Professor Wole Oyetade, Professor Herbert Igboanusi, Professor Duro Adeleke, and other members of the academic staff.

The Head of the Department of Linguistics and African Languages, Professor Oye Taiwo, welcomed everyone to the event and introduced the faculty members to the donors, the Wikimedia User Group Nigeria, and the Yoruba Wikimedians User Group delegates, led by Olaniyan Olushola and Mikaeel Sodiq, respectively.

According to the Dean, Professor O.A. Oyesile “The work is most appreciated, especially because it creates new sources of knowledge and contributes to cultural revival. The work is not only useful for academia but also useful for indigenous cultures generally. The university is open to more collaboration between the town and the gown. It is my hope that the department will utilize this opportunity very well.”

Professor Phillips Ogundeji, a member of the Nigerian Academy of Letters and a senior faculty member, said, “This type of collaboration is what we really need; we are happy that this is happening during our own time.”

Professor Herbert Igboanusi, a language expert, said in his remarks, “Initially, I was skeptical about the quality of works on Wikipedia and often discouraged my students from citing Wikipedia as a reference or using its contents in their works. Now, I can see that the standards have improved.”

Professor Duro Adeleke described the donation as “laudable.” According to him, the donated audiovisual materials would not only be useful for the Department of Linguistics and African Languages but also for the Department of History, the Department of Communication and Language Arts, and Religious Studies.

Wikimedia User Group Nigeria and Yoruba Wikimedians User Group delegates thanked the Dean, Faculty of Arts, and Department of Linguistics and African Languages, and other members of the academic staff for their collaborations.

The Community Wishlist Survey starts today. This is an annual survey that my team at the Wikimedia Foundation runs, to figure out what we should work on for the following year. It’s always so interesting to see what features and bugs are felt to be the most important. Quite often I agree, and get excited about working on them; sometimes I’ve never even heard of the software components in question! The Wikimedia universe is wide and varied.

So if anyone Wikimedians out there have ideas, please come and propose them!

Other languages: Bahasa Indonesia, Deutsch, English, Tiếng Việt, brezhoneg, français, italiano, polski, suomi, svenska, čeština, русский, українська, עברית, العربية, فارسی, বাংলা, 中文, 日本語, 粵語, ꯃꯤꯇꯩ ꯂꯣꯟ

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

Problems

• Last week, for ~15 minutes, all wikis were unreachable for logged-in users and non-cached pages. This was caused by a timing issue. [1]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 January. It will be on non-Wikipedia wikis and some Wikipedias from 25 January. It will be on all wikis from 26 January (calendar).
• If you have the Beta Feature for DiscussionTools enabled, the appearance of talk pages will add more information about discussion activity. [2][3]
• The 2023 edition of the Community Wishlist Survey (CWS), which invites contributors to make technical proposals and vote for tools and improvements, starts on Monday 23 January 2023 at 18:00 UTC.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

All the other things we changed in addition to Wikipedia’s look

This week my team reached an important milestone in our biggest project — the deployment of a new look for English Wikipedia. This was the most significant change to the desktop site in over a decade.

However, far more has changed than just appearance, and in this blog post, I hope to shed some light on what we’ve achieved and the people that did it. [1]

Since the first patchset back in January 2020, the redesign of Wikipedia’s desktop site has led to various improvements to our codebases and tooling.

I’m sure many would smirk at the idea a redesign could take three whole years, rather than three months, but much of this time has been consulting with various partners and refactoring the code that has evolved over twenty years. We’ve followed an agile approach to development, incrementally building out a grand vision set by our designers. Our first iteration, to our Basque language Wikipedia, was in fact deployed as far back as July 2020. We’ve built responsibly, intentionally, and strategically, thinking holistically about the entire behemoth that is our codebase. When I look back at our release timeline at all the things we did as a means to an end of this project, it’s incredible to see what’s been achieved over three years.

We became better at disagreeing

I’ve noticed huge improvements in the way Wikimedia Foundation works through internal impasses. As an engineer, I am so grateful that this project had technical program managers supporting us throughout our daily rituals and helping us overcome any obstacle that was thrown our way. Whether it was throwing people in a room together or just asking the right questions, or negotiating conflicting strongly held opinions, we found solutions to make big impactful changes whether it was using Vue.js or growing trust with each other. Among others, thank you to Jazmin, Lani, Suman, Nat, and Daniel for all your help here.

We worked effectively with our editing community

We’ve strengthened our relationship with our editing communities.

Although we deployed to English Wikipedia in January 2023, the new look and feel has been the default for many of our other projects, in far less complete form for a much longer time.

We owe a tremendous amount to our pilot communities and their feedback as we’ve iteratively built out the design. I am astounded by the quality and respectful feedback many volunteers were able to give us, and by the lengths our team has gone to describe our motivations and goals. For example, the limited width improvement for reading has been a controversial feature ever since we introduced it, and when we realized there was no accessible documentation for why something which had been of obvious importance to us, we wrote documentation ourselves. My work colleagues have organized and executed various office hours, some of which I’ve attended, which often although only scheduled for thirty minutes have massively overrun due to the enthusiasm and engaging conversation we’ve had. Kudos to Alex, Szymon, Olga, Phuong, Martin, Letizia, Sherry, and all the volunteers with their feedback that helped us tweak the new design.

We improved our frontend development practices

Our codebase was very much a backend-first piece of software, and working with frontend code historically has been a little lackluster, with a lack of support for modern JavaScript, a lack of industry-standard build tools, no frontend framework, and lockin to a myriad of less-desirable libraries such as JQuery.UI, moment and homegrown libraries.

One big challenge, we’ve faced historically has been deciding on which of the many JavaScript frameworks to use in our stack. This had a thorny decision to make, but with good management, and a process for discussion and discourse, we agreed that we should use Vue.js going forward for frontend development. We also found ways to support the writing of ES6 code without tooling, and our designers have been working with teams across the oranization to build a design system toolkit.

Since our initial pilot experiment of Vue.js, which is used in the new search experience, our toolkit has grown, incorporating views from a variety of teams and projects. Thanks go to Eric, Anne, Volker, Roan, Nick, Jan, Stephen, Alex, Barbara, Nat, and many others for trailblazing this tremendous effort.

We made improvements to backward compatibility

As I wrote previously in 2018, when we update the design of our site, old versions tend to stay around for a very long time. This traditionally hasn’t come for free, and historically often small things, such as markup changes, and removing CSS, require changes in multiple versions that can result in dozens of patches.

We’ve had a huge over-reliance on markup, where changing the HTML structure or an ID broke key integrations, such as unstyled menu items. To allow us to make the big changes we had planned, and reduce the burden on developers, we created a shared data and presentation layer using templates. This resulted in a 20% decrease in code maintained by my team.

To counter this we added APIs and tightened contracts where code integrates. For example, we now have stable methods for modifying the page subtitle and adding items to menus with icons in a consistent manner.

We’ve broken features many times during the project and I appreciate the patience and forgiveness of developers as we’ve tried to prevent that from happening again. Thank you, Leon, Ed, Roan, Ammarpad, Clare, Bernard, Mo, and Bartosz for all your help and patience here.

We improved language support

Language support in the new version is far more prominent than it historically has been and appears beside the article title. Making this feature more prominent invited considerable feedback from our community and required working closely with our language team, and distracting them from their own projects. Thanks to Santhosh, Pau, and the language team for working closely with us!

We simplified APIs and removed code paths

As we approached what looked like straightforward changes, such as adding items to menus, we met an unnecessarily high level of complexity. In the case of menus, there were over 5 different APIs for code to add an item to a menu. We simplified a lot of that for our own sanity. Thanks to Ammarpad, Clare, and Mo for your efforts here.

We retained a good level of accessibility

The old desktop look and feel actually enjoyed very good accessibility so we wanted to keep this standard going into the new redesign. We were lucky to benefit from not one but three engineers who specialized in this field and kept us accountable throughout the project and were fortunate enough to receive lots of feedback from users and experts in the field. Kudos in particular to Bernard, Jan, and Volker who’ve all been wonderful, and to the managers that have enabled them. Bernard in particular organized some very useful feedback from the American Foundation for the Blind.

We built with performance in mind

We’ve improved our performance. We’ve removed unused CSS and limited CSS to pages that need it and we’ve standardized thumbnail traffic. We’ve monitored big changes such as the switch to Vue.js and a new API for search. Thanks in particular to Volker, Nick, and Timo.

We restructured our Wikitext markup language

For the new table of contents experience, we needed to restructure Wikitext. In the old version, the table of contents was part of the parsed article HTML content rather than metadata that could be rendered elsewhere. This change in particular was a tricky change to make while maintaining the older style version. This hopefully serves as a blueprint for a major restructuring of article HTML in the future. Thanks to the content transform team — in particular Subbu, C Scott, and James.

We improved third-party support

Our software is run by various websites that are not Wikipedia and many of these look different from Wikipedia, using plugins known as skins. When we began the project various skins for our third parties were broken, unmaintained, or more complex than necessary due to limitations in the existing architecture and shared similar challenges to the ones that were blocking our goal. Auditing these helped us predict challenges we would face. There are now 101 skins that our 3rd parties can use with much better support and we have better systems in place for backward compatibility. You can explore these beautiful creations at the Skins lab and even make your own. Thanks to all the skin developers for their patience, engagment and insight: Mainframe, Alistair to name a few.

We started to monitor visual regressions

About a year into the project we were noticing lots of visual regressions sneaking into our releases, which slowed down our overall velocity.

To counter this we created a visual regression framework and incorporated it into our deployment process. This tool is now starting to be used outside the team. Kudos to Suman and Nick for most of the work here.

For more information on this, see Visual Testing: Building A More Robust Wikipedia Interface By Spotting the Differences. [2]

We started to log JavaScript errors

At the start of the project, we had no JavaScript error logging. We now do. Thanks to Jason L and Daniel for your support here.

We improved the mobile experience

While we didn’t quite get as far as we would have liked with this. The new desktop skin is more responsive than the old one. Mostly this has been an issue of prioritization — we have a perfectly capable mobile site right now, but the choice is important, and we’re keen to at least have a viable skin.

Meanwhile, our mobile traffic grows, so we’ve kept one eye open at all times. We’ve brought the technology stack for the mobile site closer to the desktop site and vice-versa. Features previously absent on the mobile site, are now available to use on mobile and some of the best ideas on mobile have been merged with the desktop versions. There are new projects over the next year that look at improving our diff pages.

Thanks in particular to Bernard, Jan, Bartosz, and Jason S here.

… but we’ve still got work to do

Importantly our work is not done. There are several imperfections that we had to deprioritize or delay. In particular:

• The new desktop skin is not as responsive as we’d like it to be. This wasn’t prioritized as we have a mobile site and much of the challenge here lies in working with our content creators to make article content responsive (in particular large tables).
• The new skin is not as performant as it could be. We’re currently shipping more than 2kb of CSS than we need to, for example, due to the way we roll out features, and overall the site’s critical CSS is a little larger than before. The flip side of this is added functionality that should make the site more useful, and a design that degrades on older browsers
• The font size is smaller than we’d like it to be because changing it at this point would create significant work for our editors.
• There are still remaining issues with accessibility on the site. We’ve received consultancy and believe we have identified those issues and continue to work towards fixing them.
• Several blogposts about our work are still being written. [3]

I look forward to improving these imperfections and more. Most importantly because of the last three years, I feel we have a much better foundation to work from now. The next improvement to the desktop experience will surely not take another decade.

Footnotes

[1] Apologies if I have missed out any of the village. If I have, please let me know and I’ll happily and apologetically credit you in this post.

[2] This was updated from the original blog post on 19th January to add a link to Nick’s blog post.

[3] I will be updating this post with links to these so please check back in a week or so!

This blog post is available on my personal blog as well as on Medium.com.

Thanks Alex for the last minute technical writing support!

In 2022, Wiki Loves Earth international photo contest supported the initiative Wiki4HumanRights, in partnership with the Wikimedia Foundation (WMF) and the Office of the High Commissioner for Human Rights (OHCHR). Its goal is to raise awareness of nature protection and human impacts on nature.

Two countries submitted their photos this year: Germany and Portugal. The international jury for this year’s special nomination consists of 3 people: 

• Maksym Gavrilyuk (Ukraine, an expert in Ukrainian Nature Conservation Group, Director of the National Institute of Natural and Agrarian Sciences at Bohdan Khmelnytsky National University of Cherkasy);
• Olivia Bonner (USA, Equitable Decarbonization Legal Fellow at Stanford Law School); 
• Valentina Vera-Quiroz (USA, Human Rights, Tech, and Policy Fellow at Wikimedia Foundation).

Overall, we received 1,021 photos for this special nomination. After a review by the organizing team and two rounds of jury evaluation, we have the top-5 winners from Germany. Let’s meet them!

First place: In this photo, blackbirds are sitting on the stone and looking away at the Nordufer Wittow Rügen (nature reserve in Germany) with a beautiful gray background.

Second place: Here, we can see a charming yellow-blue view of wind turbines on the German north-sea coast. One of the jurors, Olivia Bonner, commented on this photo: “The natural light haloing around the wine turbines is very effective.”.

Third place: This picture presents two cute ducks confidently walking on the road near human civilization. One of the jurors, Olivia Bonner, commented on this photo: “This is a good photo to introduce some levity and absurdity into the conversation of biodiversity and human development.”.

Fourth place: Here is a picture of a beautiful white swan near the Rhine surrounded by rocks.

Fifth place: The contrast between nature and industry is shown. In the foreground, you can see the “Bergstraße-Nord” landscape protection area, where the photo was taken. In the background, you can see the biosphere reserve “Palatinate Forest”. One of the jurors, Olivia Bonner, commented on this photo: “This very clearly and starkly demonstrates the risk and perpetuation of pollution.”.

This year, a special nomination “Human rights and environment” was held for the second time. Last year, it attracted 8,116 photos from 9 countries; you can find last year’s winners here.

You can check the final results of Wiki Loves Earth 2022 here. And follow the project on social media to keep up with updates (Facebook, Instagram, Twitter)!

By Olesia Lukaniuk, Project Manager for Wiki Loves Earth International

Sometimes, a picture can tell you everything you need to know. Images both engage and inform readers. Increasing visual content in articles is a proven way to improve comprehension. But Wikipedia doesn’t always make it easy to actually see what you’re reading about.

Fewer than half of Wikipedia articles have any images at all, and those that do can only possibly show you a small subset of the 90 million media files currently on Wikimedia Commons. Behind every Wikipedia article, with images carefully selected to fit the narrative flow of an encyclopedia entry, there may be many more images of the subject available on Wikimedia Commons.

A tool launched this month is addressing this problem by putting images front and center—and making it easier for editors to add them to the article content. View it! is a new way to access all the images related to articles across all Wikimedia projects. The tool has been developed by a small team of community developers funded through the Wikimedia Foundation’s Structured Data Across Wikimedia program and advised by the Wikimedia Foundation Culture and Heritage team. It is available as a user script, which means any logged-in user can install it right now for this new visual experience simply by copying and pasting a line of code into their account settings (instructions here).

View it! puts relevant images at the top of every article in a new expandable image pane. Plus it also adds a tab (currently called “View” in English) that opens a full-screen gallery of images. For more options, users can also click through to the Toolforge project for advanced search options. And there is also a “lite” option, which simply adds a tab to every article with a link to these Toolforge results without changing the visual experience of the article. Either version can be installed globally for a Wikimedia account, and will work in all Wikimedia project content pages—from Wikidata to Wikivoyage, and all other sister projects.

The main goal of View it! is to increase the discoverability of Commons media while enriching content pages by illustrating a subject. In turn, though, the tool also aids editing by surfacing new images that editors can use in an article. A copy-to-clipboard function allows users in edit mode to select an image from the View it! gallery to place in the article. In this way, View it! indirectly benefits even logged-out readers of Wikipedia who do not have it installed, since it can be used to assist the editors in finding media to improve the visual content of the pages they are reading.

On the backend, View it! uses the MediaWiki API for Wikimedia Commons to search for images based on properties associated with the article. Every Wikimedia content page (such as a Wikipedia article) has a linked Wikidata entity, which is used to store information, such as the category of Commons media associated with that topic. Additionally, Wikimedia Commons files can use Structured Data on Commons to store information about entities depicted in a media file. Using these two data sources, the default configuration displays a combination of images that are either (1) found in an article’s associated Commons category or (2) where the subject is tagged as depicted in an image. A custom View it! API powers the user scripts and Toolforge project, and can also be consumed directly by any app. Code is published on Gitlab.

Development on View it! began in August 2022. Since then, the team has held multiple live demos and community discussions, responding to user feedback and suggestions that we received. View it! has already been installed by over 160 users during our beta phase.

Please install View it! for yourself, and share your feedback in comments on this blog or on the View it! discussion page on Meta-Wiki.

The (fairly terrific) locator-tool now has aerial imagery available as a map layer, making geolocating photos even more fun.

A new extension this week: CopyCreds

The CopyCreds extension registers two new tags and , which make the text inside them visually distinctive, and allows for click-to-copy. The goal is to make life easier for those who document usernames and passwords in MediaWiki.

I like the idea of a simple click-to-copy system for a wiki, but I’m not sure it warrants two new tags. Personally I’d prefer something like foo or something like that, with a means to customize the colour etc. of the displayed value. Actually, maybe that’s what CopyLink does. There used to be one called CopyToClipboard which also did something similar.

Maybe someone should write the Copyencabulator 2000, to unite them all…

10/01/2023-16/01/2023

Breaking news

• The next public OSMF Board meeting will be held in the online boardroom on Thursday 26 January at 13:30 UTC.
  The preliminary agenda is on the Board/Minutes/2023-01 wiki page and this is also where the draft minutes will be added.The topics to be covered are:
  • Treasurer’s report
  • Provisional 2023 budget
  • Strategic plan – formal structure report
  • Advisory Board – monthly update
  • Monthly presentation – YouthMappers
  • Guest comments or questions.

  Find out on the Monthly Board Meetings wiki page how to have future board meetings automatically added to your calendar.

About us

• Do you read our blog in English?
  Do you want to read the new issue two days earlier?
  Do you want to help prepare weeklyOSM?
  Are you a native English speaker?
  Then we are looking for you!
  Write us a short email to info at weeklyosm dot eu and we will let you know how you can help.
• From this issue we are publishing our weeklyOSM articles under the CC0 licence instead of CC-BY-SA. You can link, cite, reuse or rephrase our articles without restrictions. Nevertheless we are of course happy if you still attribute us.

Mapping

• One culture’s profanity may be another’s street name. Meta’s #ProfanityCleanup edits triggered a discussion on Talk-GB about this topic.
• Andy Townsend (SomeoneElse) documented how he followed a path that existed only on a map and concluded that it doesn’t belong in OSM.
• Mateusz Konieczny is seeking the community’s view on the difference between surface=fine_gravel and surface=compacted.
• Voting is underway on the proposal to extend the usage of utility=* to apply consistently to service/industrial buildings and cabinets, until Thursday 26 January.

Community

• In the Geomob Podcast #164 Ed Freyfogle chatted with Simon Poole, OSM mapper since 2010, former chair of the OSMF, and maintainer of Vespucci, about his perspective on OpenStreetMap.
• The OpenStreetMap Ops Team gave an update on the status of the migration of the old forum content to the new OSM Community forum.

Local chapter news

• The OpenStreetMap Polska Association is ► proud to announce the signing of an agreement with CloudFerro, the operator of the Creodias platform to enable, but not limited to, further development of the www.openaedmap.org project.

Events

• @dukera, in a video, explained how Overpass can be used in geospatial intelligence.
• Edward Betts is going to talk at the upcoming FOSDEM about linking OpenStreetMap and Wikidata.

OSM research

• A paper from HeiGIT and GIScience at Heidelberg University, on improving the accuracy of OSM missing building detection in sub-Saharan Africa, was featured on the May 2022 cover of Transactions in GIS. The team proposed a novel few-shot transfer learning method (FSTL) to improve humanitarian organisations’ mapping workflows in the Global South. Further details on the approach, and its current limitations, is available on the HeiGIT site.

Licences

• Pieter Vander Vennet investigated, using Overpass, what licences MapComplete users are applying to their uploaded pictures. The vast majority are uploaded with the default licence, being CC0/public domain. Power users, though, often change the licence to CC-BY or CC-BY-SA. As a by-product of his investigation, a ranking of MapComplete’s most active users has been compiled, led by ‘legendary mapper’ Awo.

Software

• Anne-Karoline Distel spotted that Field Papers was not working (see also a Reddit thread). Ciarán (DeBigC) reported it on GitHub and, fortunately, Alan Maconchie restarted the server. However, as with other Stamen services, they are looking for others to take on support.
• James Milner found that ChatGPT is pretty good at generating GeoJSON.
• GeoDesk reported a new feature: stats queries. The thread includes various examples of typical queries, from the opening hours of pubs in Scotland, to the length of rivers in Colorado.

Programming

• MTRNord tooted that they have created a script to quickly build transit maps using the Cartes tool, after it was reported on weeklyOSM.

Releases

• QA tool Osmose has introduced a new check for buildings on agricultural land that appear to be too large.

Did you know …

• … there are special phrases that cause Nominatim to search for a specific key=value pair?
• … if you mix up latitude and longitude, Alvin Bryan has some tips to remember them correctly?

OSM in the media

• Carey Davies, writing in The Great Outdoors magazine, provided in-depth analysis of recent mountain rescue incidents in the English Lake District, which were occasioned by the use of outdoor hiking apps based on OpenStreetMap data. Earlier, The Guardian and online magazine Grough had also covered this topic. It is these reports that led to SK53’s path analysis, which we reported earlier.
• Alex Roddie, quoted in The Great Outdoors article above, published his own detailed analysis of the use of OpenStreetMap by a range of outdoor hiking applications. He received a lot of feedback from experienced UK-based mountain guides on both Twitter and Mastodon.
• Netzpolitik recommended ► installing StreetComplete and other FOSS tools to rid yourself of GAFAM.

Other “geo” things

• Google Maps has introduced a visual positioning system ‘to provide location and navigation services for users of its AR “Live View” feature’.
• Giorgia Tolfo blogged on how the Living with Machines project is digitising 19th century Ordnance Survey maps from the British Library. The work is complementary to the well-known historical maps hosted by the National Library of Scotland, as the focus is on maps not already available digitally. Living with Machines is the flagship Digital Humanities project of the Turing Institute, the UK national AI research institute.
• The American Geographical Society published its ‘Map of the week’ with the title ‘What does the land under Antarctica’s ice sheet look like?’.
• Christoph Hormann wrote about the open licensing of map designs.
• Abhishek Nagaraj and Scott Stern have written an essay on the distinctive economic properties of maps and the role that geographic information plays in economic geography.
• Astronomers also create maps. See the universe from above!

Upcoming Events

Where	What	Online	When	Country
Dar es Salaam	State of the Map Tanzania		2023-01-19 – 2023-01-21
Budapest	Hiking by the pipeline between Normafa-Stop Shop-Aranyvölgy		2023-01-21
Toulouse	Réunion du groupe local de Toulouse		2023-01-21
	Downtime		2023-01-22
Bremen	Bremer Mappertreffen (Online)		2023-01-23
	OSMF Engineering Working Group meeting		2023-01-24
Düsseldorf	Düsseldorfer OpenStreetMap-Treffen	✓	2023-01-25
	[Online] OpenStreetMap Foundation board of Directors – public videomeeting		2023-01-26
IJmuiden	OSM Nederland bijeenkomst (online)	✓	2023-01-28
南区	京都！街歩き！マッピングパーティ：第35回 六孫王神社		2023-01-29
Windsor	OSM Windsor-Essex Monthly Meetup		2023-01-31
San Jose	South Bay Map Night	✓	2023-02-01
Hannover	OSM-Stammtisch Hannover		2023-02-06
	MapRoulette Monthly Community Meeting		2023-02-07
Stuttgart	Stuttgarter Stammtisch		2023-02-07
City of Westminster	Missing Maps London Mapathon		2023-02-07
Zürich	OSM-Stammtisch		2023-02-08
München	Münchner OSM-Treffen		2023-02-08
Salt Lake City	OSM Utah Monthly Map Night		2023-02-09
Neufchâteau	OpenStreetMap – Réunion à Neufchâteau		2023-02-09

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by MatthiasMatthias, Nordpfeil, PierZen, SK53, Strubbl, TheSwavu, YoViajo, derFred.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

We released Semantic MediaWiki 4.1. Learn what changes it brings.

As maintainers of Semantic MediaWiki (SMW), we are responsible for releasing new versions. Today we released version 4.1, the 65th release of SMW. This release follows SMW 4.0.2, which was released on July 21st 2022.

Semantic MediaWiki 4.1 is a minor release. It contains new features, improvements, and bug fixes. Because it is a minor release, it does not contain any breaking changes, does not require running the update.php script, and does not drop support for older versions of MediaWiki.

Changes

• Improved compatibility with MediaWiki 1.38 and 1.39
• Improved compatibility with PHP 8.1 (not complete yet)
• Fixed type error occurring during specific number formatting on PHP 8.0+
• Fixed bug causing the job queue to be flooded with jobs
• Fixed issue with the pipe character in the Ask API
• Fixed rebuildData.php issue for the smw_ftp_sesp_usereditcntns table
• Fixed issue in the category result format
• Fixed upsert warning log spam
• Added user preference that allows enabling or disabling the entity issue panel
• Added support for partial ISO dates
• SMW now ships with updated vocabularies including Schema.org, Dublin Core, FOAF and SKOS
• Various grammar and spelling fixes
• Translation updates

Credits

Over 20 people contributed to this release. We would like to thank all contributors.

Special credits go to Abijeet Patro (and TranslateWiki), Bernhard Krabina from KM-A, Sébastien Beyou from WikiValley and Alexander from gesinn.it.

Upgrading

We recommend that everyone running older versions of SMW upgrades. Especially if you are running SMW 4.0.1 or older, as these versions contain a known security vulnerability.

No need to run "update.php" or any other migration scripts.

Get the new version via Composer:

• Step 1: if you are upgrading from SMW older than 4.0.0, ensure the SMW version in composer.json is ^4.1.0
• Step 2: run composer in your MediaWiki directory: composer update --no-dev --optimize-autoloader

Get the new version via Git:

This is only for those that have installed SMW via Git.

• Step 1: do a git pull in the SemanticMediaWiki directory
• Step 2: run composer update --no-dev --optimize-autoloader in the MediaWiki directory

Semantic MediaWiki hosting

If you are looking for a hosting provider for your wiki, we recommend ProWiki. We provide MediaWiki and Semantic MediaWiki hosting. Create your wiki instantly via the free trial.

 

tl;dr: [[WP:IDONTLIKEIT]]

Yesterday, a new version of the Vector skin was made default on English Wikipedia.

As will shock absolutely no one who pays attention to Wikipedia politics, the new skin is controversial. Personally I'm a Timeless fan and generally have not liked what I have seen of new vector when it was in development. However, now that it is live I thought I'd give it another chance and share my thoughts on the new skin. For reference I am doing this on my desktop computer which has a large wide-screen monitor. It looks very different on a phone (I actually like it a lot better on the phone). It might even look different on different monitors with different gamuts.

So the first thing that jumps out is there is excessive whitespace on either side of the page. There is also a lot more hidden by default, notably the "sidebar" which is a prominent feature on most skins. One minor thing that jumps out to me is that echo notifications look a little wonky when you have more than 100 of them.

On the positive though, the top bar does look very clean. The table of contents is on the left hand side and sticky (Somewhat similar to WikiWand), which I think is a nice change.

When you scroll, you notice the top bar scrolls with it but changes:

On one hand, this is quite cool. However on reflection I'm not sure if I feel this is quite worth it. It feels like this sticky header is 95% of the way to working but just not quite there. The alignment with the white padding on the right (I don't mean the off-white margin area but the area that comes before that) seems slightly not meeting somehow. Perhaps i am explaining it poorly, but it feels like there should be a division there since the article ends around the pencil icon. Additionally, the sudden change makes it feel like you are in a different context, but it is all the same tools with different icons. On the whole, I think there is a good idea here with the sticky header, but maybe could use a few more iterations.

If you expand the Sidebar menu, the result feels very ugly and out of place to me:

idk, I really hate the look of it, and the four levels of different off-whites. More to the point, one of the key features of Wikipedia is it is edited by users. To get new users you have to hook people into editing. I worry hiding things like "learn to edit" will just make it so people never learn that they can edit. I understand there is a counter-point here, where overwhelming users with links makes users ignore all of them and prevents focus on the important things. I even agree somewhat that there are probably too many links in Monobook/traditional vector. However having all the links hidden doesn't seem right either.

On the fixed width

One of the common complaints is that the fixed width design wastes lots of screen real estate. The counter argument is studies suggest that shorter line lengths improve readability.

As a compromise there is a button in the bottom right corner to make it use the full screen. It is very tiny. I couldn't find it even knowing that it is supposed to be somewhere. Someone had to tell me that it is in the lower-right corner. So it definitely lacks discoverability.

Initially, I thought I hated the fixed-width design too. However after trying it out, I realized that it is not the fixed width that I hate. What I really hate is:

• The use of an off-white background colour that is extremely close to the main background colour
• Centering the design in the screen

 I really really don't like the colour scheme chosen. Having it be almost but not quite the same colour white really bothers my eyes.

I experimented with using a darker colour for more contrast and found that I like the skin much much better. Tastes vary of course, so perhaps it is just me. Picking a dark blue colour at random and moving the main content to the left looks something like:

 

 Although I like the contrast of the dark background, my main issue is that in the original the colours are almost identical, so even just making it a slightly more off-white off-white would be fine. If you want to do a throwback to monobook, something like this looks fine to me as well:

I don't really know if this is just my particular tastes or if other people agree with me. However, making it more left aligned and increasing the contrast to the background makes the skin go from something I can't stand to something I can see as usable.

This past weekend at Wikipedia Day I had a discussion with Enterprisey and some other folks about different ways edit counters (more on that in a different blog post) could visualize edits, and one of the things that came up was GitHub's scorecard and streaks. Then I saw a post from Jan Ainali with a SQL query showing the people who had made an edit for every single day of 2022 to Wikidata. That got me thinking, why stop at 1 year? Why not try to find out the longest active editing streak on Wikipedia?

Slight sidebar, I find streaks fascinating. They require a level of commitment, dedication, and a good amount of luck! And unlike sports where if you set a record, it sticks, wikis are constantly changing. If you make an edit, and months or years later the article gets deleted, your streak is retroactively broken. Streaks have become a part of wiki culture, with initatives like 100wikidays, where people commit to creating a new article every day, for 100 days. There's a new initiative called 365 climate edits, I'm sure you can figure out the concept. Streaks can become unhealthy, so this all should be taken in good fun.

So... I adopted Jan's query to find users who had made one edit per day in the past 365 days, and then for each user, go backwards day-by-day to see when they missed an edit. The results are...unbelievable.

Johnny Au has made at least one edit every day since November 11, 2007! That's 15 years, 2 months, 9 days and counting. Au was profiled in the Toronto Star in 2015 for his work on the Toronto Blue Jays' page:

Au, 25, has the rare distinction of being the top editor for the Jays’ Wikipedia page. Though anyone can edit Wikipedia, few choose to do it as often, or regularly, as Au.

The edits are logged on the website but hidden from most readers. Au said he doesn’t want or need attention for his work.

“I prefer to be anonymous, doing things under the radar,” he said.

Au spends an average 10 to 14 hours a week ensuring the Blues Jays and other Toronto-focused Wikipedia entries are up to date and error-free. He’s made 492 edits to the Blue Jays page since he started in 2007, putting him squarely in the number one spot for most edits, and far beyond the second-placed editor, who has made 230 edits.

...

Au usually leaves big edits to other editors. Instead, he usually focuses on small things, like spelling and style errors.

“I’m more of a gatekeeper, doing the maintenance stuff,” he said.

Next, Bruce1ee (unrelated to Bruce Lee) has made at least one edit every day since September 6, 2011. That's 11 years, 4 months, 14 days and counting. Appropriately featured on their user page is a userbox that says: "This user doesn't sleep much".

It is mind blowing to me the level of consistency you need to edit Wikipedia every day, for this long. There are so many things that could happen to stop you from editing Wikipedia (internet goes out, you go on vacation, etc.) and they manage to continue editing regardless.

I also ran a variation of the query that only considered edits to articles. The winner there is AnomieBOT, a set of automated processes written and operated by Anomie. AnomieBOT last took a break from articles on August 6, 2016, and hasn't missed a day since.

You can see the full list of results on-wiki as part of the database reports project: Longest active user editing streaks and Longest active user article editing streaks. These will update weekly.

Hopefully by now you're wondering what your longest streak is. To go along with this project, I've created a new tool: Wiki streaks. Enter in a username and wiki and see all of your streaks (minimum 5 days), including your longest and current ones. It pulls all of the days you've edited, live, and then segments them into streaks. The source code (in Rust of course) is on Wikimedia GitLab, contributions welcome, especially to improve the visualization HTML/CSS/etc.

I think there is a lot of interesting stats out there if we kept looking at streaks of Wikipedians. Maybe Wikipedians who've made an edit every week? Every month? It certainly seems reasonable that there are people out there who've made an edit at least once a month since Wikipedia started.

Of course, edits are just one way to measure contribution to Wikipedia. Logged actions (patrolling, deleting, blocking, etc.) are another, or going through specific processes, like getting articles promoted to "Good article" and "Featured article" status. For projects like Commons, we coud look at file uploads instead of edits. And then what about historical streaks? I hope this inspires others to think of and look up other types of wiki streaks :-)

When women are exposed to women role models in science, they are more likely to pursue STEM careers and feel a greater sense of belonging in them–a key indicator for career longevity. Reading just one story of a woman in a successful career makes a difference for the confidence and performance of undergraduates in the same field. From this exposure, men too can understand that women thrive with careers in science just as much as men. So imagine 100,000 people reading that same story. What could that do for inequity in STEM at large? You may ask, how could anyone (beyond the rare celebrity scientist) reasonably get that much exposure? Ah, well we have a tale for you.

On November 21, 2022, Google’s Doodle of the day featured Marie Tharp, whose discovery led to the acceptance of continental drift theory. Tharp’s impressive career as an oceanographic cartographer was on full display that day as more than a hundred thousand internet users swarmed to her Wikipedia biography. Thankfully, the biography was robust—touting her contributions to her field and the barriers she overcame as a woman geologist in the ’40s and ’50s. Not all women on Wikipedia are as lucky. Only 19% of the biographies on the site are even about women. When they do have a page, bias mirroring gender inequities in STEM and journalism can creep up in the content. Today, Marie Tharp’s biography is comprehensive and an excellent summary of her contributions to science. But just 6 years ago, it told a very different story.

If you read Tharp’s Wikipedia article in 2017, it might escape you that the Library of Congress considers her one of the four greatest cartographers of the 20th century. The page focused more on the work of her colleague Bruce Heezen than it did on her, painting him as the more experienced scientist, rather than her collaborator. At the time, women weren’t allowed on board research vessels, so Tharp relied on Heezen’s sonar data to create her maps of the seafloor. This earlier version of Tharp’s biography contextualized her discovery of an oceanic rift valley in terms of what Heezen thought about it. He was skeptical, calling her theory “girl talk” and even going so far as to erase her work. Once he was convinced she was right, Heezen took credit for Tharp’s discovery for more than 10 years until her contribution was finally acknowledged. The 2017 version of Tharp’s Wikipedia biography hinted at the injustice, noting that her name was mysteriously missing from publications, but it didn’t explain why. A reader might assume Heezen simply did more of the work.

It was a group effort through Wiki Education’s programs, spanning years, that corrected the narrative.

First, in 2017 an undergraduate student completing a Wikipedia assignment in a Wiki Education-supported course added the barriers that Tharp overcame in pursuing geology, namely that only 4% of all earth sciences doctorates at the time were obtained by women. The student also noted the Library of Congress’ honoring of Tharp’s legacy.

Then, in 2018 a geoscience graduate student trained as a Wiki Scientist came along and detailed how Tharp’s discovery of a rift valley supported the theory of continental drift, which was new and controversial at the time. By adding this point, the Wiki Scientist focused the biography more on Tharp’s findings than on Heezen’s skepticism. They also added the reason Heezen finally came around—a male colleague confirmed Tharp’s work. Perhaps most poignantly, the Wiki Scientist replaced the page’s photograph with one of Tharp herself, rather than one of Heezen “showing” her a map of her own creation.

In 2019, another undergraduate student in a Wiki Education-supported geology course gave more context about Tharp’s map of the ocean floor in the introductory section, adding that it specifically charted the ocean’s topography and multi-dimensional geographical landscape. The student found a preliminary manuscript sketch that Tharp and Heezen made and included that too. The student added an award that Tharp received in 2001 and also updated the section about Tharp’s early life, noting that joining her father in his field work as a soil surveyor sparked her initial interest in cartography. Considering that narratives about women scientists (on Wikipedia and off) are more likely than a man’s to focus on their personal life over their career accomplishments, including the origin of Tharp’s passion for science is a great addition to the information about her upbringing.

Where before, the biography passively mentioned that Tharp’s name wasn’t included in publications of her work, this student made the language more active, noting that it was Heezen who took the credit for Tharp’s discovery in 1956 and that the discovery was not attributed to her for more than a decade. There are plenty of historical instances where discoveries made by women were credited to men at first: from the existence of dark matter to the invention of wireless communication and the first computer language compiler tools. Women scientists are still less likely to be credited for their work than men. Given the persistent barriers women face to being recognized, it’s important to accurately document the contributions from women scientists and Wikipedia is a great place to tell the real story in real time.

In 2020, another Wiki Scientist, a physicist this time, returned to Marie Tharp’s biography and added information about inequities for women geologists, namely that they were not allowed to go out into the field at the time of Tharp’s early career. Given the barriers women still face, it’s important we surface where and how these inequities began.

When we don’t tell the full story of women scientists’ achievements, we miss the opportunity to positively influence future generations of scientists. Instead, young people may be exposed to pervasive negative stereotypes suggesting that they don’t belong in STEM, which change the way they talk about their dreams and negatively affect confidence and test performance. Sustained over time, this undermining of confidence can lead to women abandoning careers that don’t align with expectations of their gender, race, or class.

We have the chance to change the story–not only for pioneers like Tharp, but for scientists working now. A Wikipedia biography recognizes a scientist’s contributions in real time. It surfaces her expertise to journalists and panel organizers, humanizes her beyond her CV or university profile, and shows young people interested in STEM what career paths are possible for them. Considering women and people of color are chosen less often for speaking opportunities, are contacted less often by journalists, and aren’t recognized for their work in equal measure to white male peers, exposure on Wikipedia can help turn the tides.

We’re proud to see that the work of students and scientists in our programs lives on, and this process worked exactly as Wikipedia was designed to: building upon itself over time as contributors uncovered more of the real story. Together, we’re helping correct the narrative of women’s place in the advancement of STEM, and there’s one thing we know for sure: a woman’s place is in Wikipedia.

I can’t believe there’s no ‘Ghost signs in Western Australia’ category on Commons!

The interface update, built in collaboration with Wikipedia volunteers worldwide, will make the site more welcoming, easier to use for everyone

The Wikimedia Foundation, the nonprofit that operates Wikipedia and other Wikimedia projects, announced today the launch of Wikipedia’s first major desktop interface update in over ten years. The updated interface, which comes on the heels of English Wikipedia’s 22nd birthday (January 15), prioritizes usability and modernizes the Wikipedia experience to make it easier for everyone to access, explore, and share knowledge. The update is rolling out today on English Wikipedia and is already live on 94% of the 318 active language versions of Wikipedia for all desktop users.

In 2022, a global digital trends report revealed that the number of people who are not connected to the internet dropped below 3 billion for the first time. Wikipedia’s new desktop interface was designed to meet the needs of this next generation of internet users, making it easier for everyone, regardless of their familiarity with the internet, to find knowledge that is trustworthy and reliable. The desktop update, created in close consultation with Wikipedia readers and volunteer editors, is part of a steady series of improvements to the Wikipedia reading and editing experiences over the past several years across mobile and desktop devices.

“The Wikipedia desktop update is one of the major improvements the Wikimedia Foundation is making to help people easily access the world’s knowledge, in support of our mission to make sure every person on the planet has free and equitable access to knowledge, regardless of where they live or where they are from,” said Selena Deckelmann, Chief Product and Technology Officer at the Wikimedia Foundation. “The changes make it easier for people to find and learn from the work of our incredible volunteers. These features were created with feedback from readers and volunteers from all over the world, aiming to meet the needs of our increasingly diverse audience, while keeping the simple and straightforward feel that millions of people have come to trust over the last 22 years.”

The desktop update introduces a variety of new features, including: 

• An improved search experience that now leverages images and descriptions that makes it easier to find articles on Wikipedia, leading to a 30 percent increase in user searches based on testing
• More prominently-placed language-switching tools that allow multilingual readers and editors to more quickly find their preferred language and switch between over 300 languages 
• An updated sticky header with commonly used links such as Search, Page name, and Sections that move with logged-in users as they scroll. This allows users to focus on reading and editing, and reduces scrolling fatigue with user tests showing a decreased scroll rate of more than 15 percent
• A table of contents that provides context on the article and the ability to navigate throughout the reading experience
  

The updated Wikipedia interface does not remove any previous functionality. It instead introduces new tools to improve the existing website experience through enhancements based on consultation with Wikipedia volunteer editors, data analysis, and user testing.  

More than 30 different volunteer groups from all over the world, ranging from India and Indonesia, to Ghana and Argentina, were engaged throughout conceptualization, product development, testing, and rollout. The improvements were further shaped by global research insights and user feedback. This collaborative model is unique to Wikimedia projects, which, unlike other online technology platforms, prioritizes building with users instead of just for them. 

The Wikimedia Foundation remains committed to the core idea of knowledge equity. Through this central philosophy, the Foundation supports freely available knowledge for communities that have traditionally been excluded from structures of power and privilege, and works to break down the social, political, and technical barriers preventing people from accessing and contributing to free knowledge. 

The updated desktop interface is a realization of our commitment to knowledge equity, and is part of ongoing work to better empower users and improve the experience of reading and contributing knowledge across the Wikimedia ecosystem. The Wikimedia Foundation is collecting feedback from new and existing Wikipedia users to continue developing a desktop experience that meets the needs of the growing global Wikimedia community. 

---

About the Wikimedia Foundation:

The Wikimedia Foundation is the nonprofit organization that operates Wikipedia and the other Wikimedia free knowledge projects. Our vision is a world in which every single human can freely share in the sum of all knowledge. We believe that everyone has the potential to contribute something to our shared knowledge, and that everyone should be able to access that knowledge freely. We host Wikipedia and the Wikimedia projects, build software experiences for reading, contributing, and sharing Wikimedia content, support the volunteer communities and partners who make Wikimedia possible, and advocate for policies that enable Wikimedia and free knowledge to thrive. The Wikimedia Foundation is a United States 501(c)(3) tax-exempt organization with offices in San Francisco, California, USA.

Related resources:

• More information about the desktop update on the Foundation website
• The Wikimedia Foundation team behind the new look
• Survey link for feedback about the updated interface

Media Contact: Vidhu Goyal, press@wikimedia.org

By the time you read this, you'll probably have seen Wikipedia's new layout ("skin"), dubbed "Vector 2022". You can read about the changes it brings.

As with most design changes, some people will like it and some people won't. But me? I just feel sad because years ago we had a popular, volunteer-driven skin proposal that was shut down by arguments that today we now know were in bad faith and hypocritical.

Back in 2012, then-Wikimedia Foundation senior designer Brandon Harris aka Jorm pitched a new idea: "The Athena Project: being bold", outlining his vision for what Wikipedia should look like.

During the question-and-answer period, I was asked whether people should think of Athena as a skin, a project, or something else. I responded, "You should think of Athena as a kick in the head" – because that's exactly what it's supposed to be: a radical and bold re-examination of some of our sacred cows when it comes to the interface.

His proposal had some flaws, but it was ambitious, different and forced people to think about what the software could be like.

By 2013-2014, focus pivoted to "Winter", an actual prototype that people could play with and conduct user testing on. Unfortunately I've been unable to find any screenshots or videos of the prototype You can play with the original prototype (thanks to Izno for pointing out it has been resurrected). Jorm would leave the WMF in 2015 and it seemed like the project had effectively died.

But later in 2015, Isarra (a volunteer, and a good friend of mine) unexpectedly dropped a mostly functional skin implementing the Winter prototype, named "Timeless". You can try it yourself on Wikipedia today. (I'll wait.)

By the end of 2016, there was a request for it to be deployed to Wikimedia sites. It underwent a security review, multiple rounds of developers poking at it, filing bugs and most importantly, fixing those bugs. The first set of French communities volunteered to test Timeless in February and March 2017. Finally in August 2017 it was deployed as an opt-in user preference to test.wikipedia.org, then iteratively deployed to wikis that requested it in the following weeks before being enabled everywhere in November.

I've been using Timeless ever since, on both my wide monitor and tiny (relatively) phone, it works great. I regularly show it to people as a better alternative to the current mobile interface and they're usually blown away. On my desktop, I can't imagine going back to a single-sidebar layout.

In January 2021, I interviewed Jorm for a Signpost story, and asked him about Timeless. He said, "I love Timeless and it absolutely should replace Vector. Vector is a terrible design and didn't actually solve any of the problems that it was trying to; at best it just swept them under rugs. I think the communities should switch to Timeless immediately."

What went wrong?

At the end of 2017, following Timeless being deployed everywhere as opt-in, Isarra applied for a grant to continue supporting and developing Timeless (I volunteered as one of the advisors). Despite overwhelming public support from community members and WMF staff, it was rejected for vague reasons that I'm comfortable describing as in bad faith. Eventually she applied yet once again and received approval midway through 2018. This time I provided some of the "official WMF feedback" publicly. But the constant delays and secret objections took a lot of steam out of the project.

Despite all of that, people were still enthusiastic about Timeless! In March 2019, the French Wiktionary requested Timeless to become their default skin. This is a much bigger deal than just allowing it as an opt-in choice, and led to discussion of whether Wikimedia wikis need to have a consistent brand identity, how much extra work developers would need to do to ensure they fully support the now-two default skins, and so on. You can read the full statement on why the task was declined - I largely don't disagree with most of it and the conclusion. If Timeless was going to become the default, it really needed to be the default for everyone.

Of course, this principle of consistency would be thrown out in the 2022 English Wikipedia discussion on whether to switch the default to the new "Vector 2022" skin, which was going to be allowed to opt-out of the interface everyone else was using if they voted against it.

Had the French Wiktionary been allowed to switch their default to Timeless, it would've continued to get more attention from users and developers, likely leading to more wikis asking for it to become the default.

You can skim through how Vector 2022 came about. Just imagine if even a fraction of those resources had gone toward moving forward with Timeless, backing a volunteer-driven project. It's just sad to think of it now.

So...

I started this story with Jorm's op-ed rather than a history of MediaWiki skins because I think he accurately captured that the skin is just a subset of the broader workflows that Wikipedians go through that desperately need improvement. Unfortunately that focus on workflows has been lost and it shows, we're all still using the same gadgets for critical workflows that we were 10 years ago. (I won't go into detail on the various Timeless features that make workflows easier rather than more difficult.)

Vector 2022, coming 12 years after the original Vector, is a rather narrow subset of fixes to the largest problems Vector had (lack of responsiveness, collapsed personal menu, sticky header, etc.). It's just not the bold change we need. Timeless, far from perfect, was certainly a lot closer.

Current proposals like the Cyber Resilience Act[1], the Directive on Liability for Defective Products[2] and proposed amendments to the AI Act include vague and various liability carve-outs for “free and open-source software developed or supplied outside the scope of a commercial activity”. 

Wikimedia projects are run on free and open-source software. The technology is developed both in-house by entities like the Wikimedia Foundation, Wikimedia Deutschland and Wikimedia Sverige, as well as by code contributed by volunteers. Our software can be re-used and modified by anyone for any purpose, without asking for permission. 

Definition of free & Open and a coherent wording across laws

We agree with the approach taken by the EU Commission and the co-legislators to protect software and developers as long as it takes place outside the scope of a commercial activity. We believe that coders must be free to review, tinker with and edit software in order to achieve their full potential. We also agree that people and organisations offering software as part of the commercial activity should not benefit from that same carve-out. 

We worry that the current recitals and amendments are all worded differently and lack a key definition. To guarantee legal certainty we therefore suggest that the co-legislators agree on a common wording for the carve-out across the files and include it as an article in the text. We therefore want to propose the following improvements:

• Universal wording: One single wording should be agreed upon and it should be included as an article in one of the acts. The other acts should reference it. Ideally, Recital 10 from the CRA would be taken as a basis.
• Universal definition: Ideally, free and open-source software should be defined as code that is made available to the public under terms that guarantee the freedom to use, study, share and improve the software.

[1]Proposal for a Cyber Resilience Act – Recital 10 

[2]Proposal for a Directive on the Liability of Defective Products –  Recital 13 

[3]Legal Affairs Committee Opinion on the Artificial Intelligence Act

I added a newly-scanned photo to ArchivesWiki yesterday, and none of its images were loading (via InstantCommons). I think I was probably a bit tired, because I immediately assumed that I’m a crap sysadmin who has no business trying to run a wiki.

Coming back to it this morning, it turns out that it was some transient issue with retrieving info from Commons, and it’s now resolved and everything’s working normally again. Like it has for a decade or so. I’ll guess I’ll put off Giving Up till tomorrow.