Hello everyone,
The third edition of the Language & Internationalization newsletter (April
2024) is available at this link: <
https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Newsletter/20…
>.
This newsletter is compiled by the Wikimedia Language team. It provides
updates from January–March 2024 quarter on new feature development,
improvements in various language-related technical projects and support
efforts, details about community meetings, and contributions ideas to get
involved in projects.
To stay updated, you can subscribe to the newsletter on its wiki page. If
you have any feedback or ideas for topics to feature in the newsletter,
please share them on the discussion page, accessible here: <
https://www.mediawiki.org/w/index.php?title=Talk:Wikimedia_Language_enginee…
>.
Cheers,
Srishti
On behalf of the WMF Language team
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all!
We’ve been moving forward on the WDQS Graph Split [1], time for an update!
We have new documentation to help the migration to the split graph:
* Federation limits [2]: Explanation of the limitations of the SPARQL
federation as used on the graph split. This might help you understand what
is possible and what isn’t when you need to federate the main WDQS graph
with the scholarly subgraph.
* Federated queries examples [3]: This document explains how to rewrite
queries to use SPARQL federation over the split graph. We’ve taken a number
of real life examples, and we’ve rewritten them to use federation. While
rewriting queries is not always trivial, the examples that we tried are all
possible to make work over a split graph.
We have been reaching out to people who will be impacted by the graph
split. In particular, we have been having conversations with community
members close to the Scholia and Wikicite projects. In that context, we are
realizing that our initial split proposal (moving all instances of
Scholarly articles to a separate graph - ?entity wdt:P31 wd:Q13442814) is
not sufficient. We have prepared a second and last proposal that will
refine this split to make it easier to use. See "WDQS Split Refinement" [4]
for details. We are open for feedback until May 15th 2024, please send it
to the related talk page [5].
While we refine this split, we are starting work on the implementation of
the missing pieces to make the graph split available. This includes
modifying the update pipeline to support the split and better automation of
the data loading process. We are also working on a migration plan, which we
will communicate as soon as it is ready. Our current assumption is that we
will leave ~6 months for the migration once the split services are
available before shutting down the full graph endpoint.
We need your help more than ever!
If you have use cases that need access to scholarly articles, please read
"Federation Limits" [2] and "Federated Queries Examples" [3], rewrite and
test your queries, and add your working examples to "Federated Queries
Examples" [3].
Send your general feedback to the project page [1].
On a side note, WDQS isn’t the only SPARQL endpoint exposing the Wikidata
graph. You can have a look at "Alternative endpoints" [6], which lists a
number of alternatives not hosted by WMF, which might be helpful during the
transition.
Thanks!
Guillaume
[1]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_split
[2]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…
[3]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…
[4]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…
[5]
https://www.wikidata.org/w/index.php?title=Wikidata_talk:SPARQL_query_servi…
[6]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Alternative_end…
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
I'm writing to ask if there's any updates on https://phabricator.wikimedia.org/T359998. This task has been there for quite a while without any updates. We would like to know if there are any blockers or updates. This task is part of Chinese Wikipedia's establishment of IPBE grantor group to help newcomers conveniently contact IPBEG users.
Best regards,
Diskdance
Hello Hello Everyone,
Welcome to the 2nd edition of the Wikimedia Technical Community Newsletter!
We're excited to bring you a roundup of highlights, news, and information
of interest from and about the Wikimedia Technical Community. The
newsletter is compiled by staff(s) working on developer outreach.
Read the full April’24 newsletter edition here:
🔗https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2024/April
🥁 Here’s a sneak peek of what to expect from this newsletter edition
📢 Action Items
-
Send in your Nominations for the 2024 Coolest Tool Award 🛠
The nomination for the 2024 Coolest Tool Award is open! Please recommend
tools until Friday May 10th, 2024. You can nominate as many tools as you
want by filling out the survey multiple times. Submitting multiple entries
is encouraged! Visit -
https://meta.wikimedia.org/wiki/Coolest_Tool_Award#Coolest_Tool_Award_2024
to nominate a tool and for more information on the award & nomination
process.
-
Are you passionate about the intersection of wiki-based collaboration
and cutting-edge research? Do you have insights, ideas, or findings to
share with the wiki community? We invite you to submit your proposals
<https://wikiworkshop.org/call-for-hall> for presentations, workshops,
and papers to the upcoming Wiki Workshop! Additionally the team will be
holding office hours to answer any questions about this new track and the
submission process. We invite you to schedule some time on Tuesday, April
16 or Thursday, April 25 in the following link-
https://calendar.app.google/igcEC3fqTAF8MRDE7. You can also email us at
wikiworkshop(a)googlegroups.com with any questions about the Hall or the
Workshop in general.
🚀 Project Spotlights: With the 2024 Wikimedia Hackathon just around the
corner, discover everything you need to know about the event format,
program details, social activities, and more! Plus, catch up on the success
stories from the recently concluded Outreachy Internship Program and gain
fascinating insights from the Wikimedia Wishaton.
The Wikimedia Technical Community is large and diverse - it's hard to
capture everything. We would love to hear your ideas. Have a topic you'd
like us to cover or a story to share? Ideas for future newsletter editions?
Please add your suggestion to the talk page
<https://www.mediawiki.org/wiki/Talk:Technical_Community_Newsletter>. We'd
love to hear from you!
If you'd like to keep up with updates and information, subscribe to the
Technical Community Newsletter:
https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter
Until the next edition,
--
*Onyinyechi Onifade *
Technical Community Program Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
(If you don’t work with pagelinks table, feel free to ignore this message)
Hello,
Here is an update and reminder on the previous announcement
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
regarding normalization of links tables that was sent around a year ago.
As part of that work, soon the pl_namespace and pl_title columns of
pagelinks table will be dropped and you will need to use pl_target_id
joining with the linktarget table instead. This is basically identical to
the templatelinks normalization that happened a year ago.
Currently, MediaWiki writes to both data schemes of pagelinks for new rows
in all wikis except English Wikipedia and Wikimedia Commons (we will start
writing to these two wikis next week). We have started to backfill the data
with the new schema but it will take weeks to finish in large wikis.
So if you query this table directly or your tools do, You will need to
update them accordingly. I will write a reminder before dropping the old
columns once the data has been fully backfilled.
You can keep track of the general long-term work in T300222
<https://phabricator.wikimedia.org/T300222> and the specific work for
pagelinks in T299947 <https://phabricator.wikimedia.org/T299947>. You can
also read more on the reasoning in T222224
<https://phabricator.wikimedia.org/T222224> or the previous announcement
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
.
Thank you,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I am contributing to wikimedia-commons android app and we encountered a case where we need to show CAPTCHA within the app, is there any end-points available for this ? To Complete the CAPTCHA verification when it's required ?
Hi Wikitech,
I have over 5 years of professional experience as a software developer, I
would like to join this awesome team and make meaningful contributions . I
have made progress as far as following the participate instructions
<https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker> goes, I
have the code setup locally and would love some help in using phabricator
and making and pushing changes to the codebase.
Is there someone who has experience and is willing to mentor me into doing
this? I would highly appreciate and cannot wait to be part of the team.
Kind regards.
Newton
Hi everyone,
We invite your contributions to the Wiki Workshop Hall, a new track as part
of Wiki Workshop 2024 <https://wikiworkshop.org/> which will take place
virtually as a standalone event on June 20, 2024 (tentatively 12:00-19:00
UTC).
The Hall will be a novel space for Wikimedia researchers and Wikimedia
movement members to connect with each other. Through this new track, we aim
to provide a dedicated space for learning, exchange of ideas, the spark of
curiosity, and community building.
We welcome proposals that align with the interactive and collaborative
spirit of the Wiki Workshop Hall and look forward to a wide variety of
content: experiences and learnings, knowledge pieces, how-tos, open
questions, pain points, etc. During the Hall, a breakout room will be set
up for each accepted proposal, so that Wiki Workshop attendees can move
between rooms to interact with their hosts.
*Learn more about the Wiki Workshop Hall at *
*https://wikiworkshop.org/2024/call-for-hall*
<https://wikiworkshop.org/2024/call-for-hall.html>* and submit your
contributions by **April 29, 2024 (23:59 AoE)*
<https://www.timeanddate.com/worldclock/converter.html?iso=20240430T115900&p…>
*. *
If you have questions about the workshop or about Wiki Workshop Hall,
please email wikiworkshop(a)googlegroups.com with a [Wiki Workshop Hall] tag
in the subject of your email or comment on this post.
Looking forward to seeing many of you in this year's edition.
The Wiki Workshop Hall chairs,
Pablo Aragón, Wikimedia Foundation
Kinneret Gordon, Wikimedia Foundation
Hey all,
This is a quick note to highlight that in five weeks' time, the REL1_42
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself[0]. This is the first step in the release process for
MediaWiki 1.42, which should be out in May 2024, approximately six months
after MediaWiki 1.41.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.42.0-wmf.26, which will be deployed to Wikimedia wikis in the
week beginning 8 April 2024 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be instead be slated
for the MediaWiki 1.43 release unless specifically backported[1].
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.42-release` project
on Phabricator.[2]
If you have tickets that are already tagged for `mw-1.42-release`, please
finish them, untag them, or reach out to get them resolved in the next few
weeks.
We hope to issue the first release candidate, 1.42.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.42.0 a few
weeks after that.
[0]: https://www.mediawiki.org/wiki/Bundled_extensions_and_skins
[1]: https://www.mediawiki.org/wiki/Backporting_fixes
[2]: https://phabricator.wikimedia.org/tag/mw-1.42-release/
Yours,
--
James D. Forrester (he/him or they/themself)
Wikimedia Foundation
Hi All, welcome to the monthly MediaWiki Insights email!
We’re starting this email again by celebrating volunteer contributors who
got their first patch merged in MW core, WMF deployed extensions or
services over the past month:
Many thanks and congrats to Nemoralis, RockingPenny4, Theprotonade, S8321414,
Philip and Aram!
Enable more people to know MediaWiki and contribute effectively
We’ve officially hit the baseline
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
we’ve set to measure the growth in number of people who have submitted
patches to MediaWiki core: During the period July 2022 - June 2023 (= last
WMF fiscal year), 70 people have submitted more than 5 patches to MW core.
This year, we reached this number already in March and are currently
observing a 14.5% increase in the number of contributors who have submitted
more than 5 patches between July 2023 and March 2024 compared to July 2022
- March 2023.
To achieve the goal of a 20% increase, we will continue with consultancy
and code review for teams and volunteers as part of our regular work. We
are also planning a dedicated MediaWiki focus area for the upcoming Wikimedia
Hackathon <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024> to help
people contribute to MediaWiki. If you are attending the Hackathon and are
interested in joining the fun to help others onboard in MediaWiki, want to
get started with MediaWiki development or already have a project you’d like
to get help on, please monitor the Hackathon channels and workboard over
the coming weeks for more communication around this!
Project Snapshots: Sustainability and evolution of the platform requires
the efforts of many: Deprecated wfGetDB(), migration to Prometheus and
supporting page content in core REST API
The theme of many initiatives that ensure sustainability and evolution of
the MediaWiki platform is that it requires the collaborative effort of
many. In some cases this may be work done primarily by specific teams, in
other cases this is a collective effort of staff across teams and
volunteers.
One great example for the collective effort of volunteers and staff is
that wfGetDB()
- the old global function to get database connections - is now
hard-deprecated <https://phabricator.wikimedia.org/T273239>, thanks to many
people who did the migration across many extensions!
<https://phabricator.wikimedia.org/T273239>
With wfGetDB() out of the picture, we no longer rely on global state when
accessing database connections. This means that code that wants to access
another wiki’s database may not end up accidentally mixing information from
two wikis. Besides, the new IConnectionProvider interface -
getReplicaDatabase() is hopefully more readable than wfGetDB(DB_REPLICA). This
is part of our wider work to modernize MediaWiki's platform so that we can
inject services for scale and testing.
Supporting page content in core REST API for fetching HTML
We already talked about RESTBase deprecation and Parser Unification
milestones in the last edition
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/February_…>
of the MediaWiki Insights email. Oftentimes, work on one initiative
benefits other initiatives and vice versa. This is very true for the
following achievement, which is closely related to Parser Unification and
RESTBase deprecation:
The MediaWiki REST endpoints for fetching page HTML
<https://www.mediawiki.org/wiki/API:REST_API/Reference#Get_HTML> now
support all kinds of content. This provides an easy way for bots and
scripts to get the content of any wiki page just like it would be shown to
users when they view an article in the browser (*).
This may seem like a simple and obvious thing, but we did not have the
capability until recently: From introduction of these endpoints in 2020 up
until the completion of the work on T359426
<https://phabricator.wikimedia.org/T359426>, they were limited to wikitext
pages and would fail on pages containing JavaScript or Lua or Wikidata
items.
A lot of changes were necessary “under the hood” to get to a point where
the REST API could provide rendered HTML for all kinds of content, while
using the Parsoid rendering of wiki pages. Much of the necessary work
overlaps with the efforts of sunsetting RESTbase
<https://www.mediawiki.org/wiki/RESTBase/deprecation> and implementing
support for Parsoid page views <https://phabricator.wikimedia.org/T55784>.
Some key aspects were:
- Integrating Parsoid with ContentHandler (T311648
<https://phabricator.wikimedia.org/T311648>)
- Populating the cache with Parsoid output when pages are edited (T320534
<https://phabricator.wikimedia.org/T320534>)
- Removing the caching layer for Parsoid output in RESTbase (T344945
<https://phabricator.wikimedia.org/T344945>)
- Implementing variant conversion for the API endpoint (T317019
<https://phabricator.wikimedia.org/T317019>)
Having support for all kinds of page content in the REST API while using
Parsoid for wikitext pages is a major milestone towards supporting Parsoid
page views. It demonstrates that Parsoid has been fully integrated with the
content rendering and caching infrastructure in MediaWiki. This is the
culmination of the efforts of several teams over multiple years. Many
thanks to everyone involved!
Note that, while the REST endpoints now support all kinds of content, they
are not quite yet ready for prime time: they still lack proper integration
with the edge caches <https://www.mediawiki.org/wiki/Manual:Varnish_caching>
that will ensure good performance when a lot of clients start using these
APIs. To address this issue and to improve version management for API
endpoints, we are considering changing the canonical URLs of the endpoints.
(*) We still use the old parser of page views though. See the last
MediaWiki Insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/February_…>
for where we’re at on the roadmap.
MediaWiki metrics to Prometheus migration: Status and call to action
The Observability team is currently working on migrating MediaWiki metrics
to Prometheus <https://prometheus.io/docs/introduction/overview/>,
utilizing StatsLib <https://www.mediawiki.org/wiki/Manual:Stats>, an
internally developed, Prometheus-capable metrics interface. We have been
using Prometheus in Wikimedia production for several years as it offers
several benefits over Graphite
<https://prometheus.io/docs/introduction/comparison/>. Migrating ensures we
stay ahead with a supported, scalable metrics platform for a more
effective, multidimensional metrics analysis and storage engine.
We are closing in on about 8% of total metrics emitted to graphite migrated
over to Prometheus
<https://grafana.wikimedia.org/d/nCxX65cSk/mediawiki-statslib-migration?orgI…>
and are now ready to invite more people in to help contribute to this
effort! Your expertise can help drive the success of this migration and support
in migrating your component’s metrics to StatsLib (T350592)
<https://phabricator.wikimedia.org/T350592>:
- Look up your component, extension, or module and follow the
examples/docs in the task to migrate your metrics to the new metrics
interface.
- Help deprecate and clean up/remove outdated metrics not in use (or
graphed in dashboards).
- Collaboration in testing and feedback for a seamless transition.
A more detailed announcement and call to action will follow.
Many thanks to the Observability team for their leadership on this
initiative, Derrick, Timo and Larissa from the MediaWiki Platform team for
their consultancy and help in converting MediaWiki metrics so far; Kavitha,
Giuseppe, Janis, and Clement from Service Ops for infrastructure support;
and the Search Platform team for their recent involvement!
Annual Plan 2024/25: Key Result drafts published
The Wikimedia Foundation has recently published the draft “key results”
<https://en.wikipedia.org/wiki/Objectives_and_key_results> by the Product &
Technology department for the upcoming annual plan. While this is not yet
at the project/initiatives level (“hypotheses”), the draft KRs give
insights in focus areas for the next year. The most relevant objectives for
MediaWiki platform work and services for developers are WE5 (“Knowledge
Platform I”) and WE6 (“Knowledge Platform II”). Input and questions on
these drafts
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
are welcome!
Upcoming: MW 1.42 release
MW 1.42 <https://mediawiki.org/wiki/MediaWiki_1.42> release is coming! The
tentative target was set as May 2024
<https://phabricator.wikimedia.org/T359833> and in the next few weeks, it
will be the time to polish and prepare for the release. Stay tuned for
updates and use Phabricator
<https://phabricator.wikimedia.org/project/view/6601/> to engage with us
and raise potential blockers if you haven’t done yet.
Thanks all for reading,
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>