Hi all,
I know there's been a lot of discussion/concern and policy decisions around
usage of LLMs for authoring content in Wikimedia projects.
I wonder if there's been similar discussion around AI coding for technical
editors? I'm not sure I've seen it "go by". Can someone link to where these
discussions are happening?
I also wanted to share a policy I wrote for WP1:
https://github.com/openzim/wp1/blob/main/CONTRIBUTING.md#usage-of-llmsai-co…
Cheers,
-Travis
Hello everyone!
We're excited to announce that the next Language Community Meeting is
happening soon - on November 28th at 16:00 UTC! If you’d like to join,
simply sign up on the wiki page
<https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…>
.
This is a participant-driven meeting where we share updates on
language-related projects, discuss technical challenges in language wikis,
and collaborate on solutions. For example, in our upcoming meeting, we plan
to hear from contributors of the Wikitongues project and Fante
Wikimedia Community.
Got a topic to share? Whether it’s a technical update from your project, a
challenge you need help with, or a request for interpretation support, we’d
love to hear from you! Feel free to reply to this message or add agenda
items to the document here
<https://etherpad.wikimedia.org/p/language-community-meeting-nov-2025>.
Also, we’d like to highlight that the 9th edition of the Language &
Internationalization Newsletter (October 2025)
<https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…>
is
now available. This newsletter provides updates from the July–September
2025 quarter on new feature development, improvements in various
language-related technical projects and support efforts, details about
community meetings, and ideas for contributing to projects. To stay
updated, you can subscribe to the newsletter
<https://www.mediawiki.org/wiki/Newsletter:Language_and_Internationalization…>
on
its wiki page.
Are you interested in contributing to the technical work around language
development? See a curated list of technical contribution tasks here:
T407935 <https://phabricator.wikimedia.org/T407935>.
We look forward to your ideas and participation at the Language Community
Meeting. See you there!
Cheers,
Srishti
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone!
This is a friendly final call to remind you that registrations for the
Wikimedia Northwestern European Hackathon 2026 will officially close next
Sunday, February 1, 2026.
⏳ If you’ve been meaning to sign up for this intensive two-day gathering in
Arnhem, Netherlands, now is the time to head over to the project page at
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_Northwestern_Europe_2026
and get your application in.
🇳🇱 Taking place on March 13 and 14 at the Rozet cultural center, this
event is designed as a grassroots unconference for experienced Wikimedians,
developers, and technical contributors from across the region.
💻 It’s a fantastic opportunity to collaborate on technical projects, share
skills in an informal setting, and prep for the International Hackathon in
Milan later this year.
🤝 Since capacity is limited to roughly 100 participants to keep the
atmosphere focused and productive, the organizers will be reviewing
applications based on technical experience and regional focus. 🚀
We can't wait to see what kind of innovative tools and connections emerge
from our time together in Arnhem! ✨
Cheers!
--
Siebrand Mazeland
Wikimedia Nederland
M: +31 6 50 69 1239
T: https://t.me/siebrand
This week's 1.46.0-wmf.13 version of MediaWiki is still blocked[0] on
testwikis.
We can't proceed until the following issue is resolved:
* T415725: TypeError:
MediaWiki\Extension\Translate\MessageGroupProcessing\CachedMessageGroupFactoryLoader::MediaWiki\Extension\Translate\MessageGroupProcessing\{closure}():
Argument #1 ($value) must be of type DependencyWrapper,
__PHP_Incomplete_Class given
- https://phabricator.wikimedia.org/T415725
Once this issue is resolved, the train can proceed to group0.
Thank you for any help!
-- Your perpetually rumpled train crew
[0]. https://phabricator.wikimedia.org/T413804
This week's 1.46.0-wmf.13 version of MediaWiki is blocked[0] on testwikis.
We can't proceed until the following issue is resolved:
* T415619: Creation of dynamic property
MediaWiki\Language\Dependency\FileDependency::$filename is deprecated
{"exception":"[object] (ErrorException(code: 0)
- https://phabricator.wikimedia.org/T415619
As a deprecation warning, this would normally only block _next_ week's
train, but it does appear to be some risk of creating an unacceptably
high volume of logspam.
Once this issue is resolved, the train can proceed to group0.
Thank you for any help!
-- Your perpetually rumpled train crew
[0]. https://phabricator.wikimedia.org/T413804
The Wikimedia Foundation's Product and Technology department is starting
its Annual planning process
<https://meta.wikimedia.org/wiki/Wikimedia%20Foundation%20Annual%20Plan> (APP),
where it decides what it will be allocating resources to/prioritizing over
the next fiscal year. To inform WMF's decision-making on what to
prioritize, they are requesting community members to answer a few
questions/provide feedback on what should be considered at this meta wiki
page
<https://meta.wikimedia.org/wiki/Talk:Wikimedia%20Foundation%20Annual%20Plan…>
until
Feb 10.
Regards,
Sohom Datta
---
Open-source contributor @Wikimedia.
Don't know if this is a problem of the new styles, or of the Phabricator,
but pay attention to this. The status of subtask change is shown before
this subtask was added.
Igal
>
> בתאריך יום ה׳, 8 בינו׳ 2026, 22:47, מאת יגאל חיטרון <
> khitron(a)post.bgu.ac.il>:
>
>> So, it's my memory glich, I trust you.
>> Igal
>>
>> בתאריך יום ה׳, 8 בינו׳ 2026, 22:46, מאת Bartosz Dziewoński <
>> matma.rex(a)gmail.com>:
>>
>>> On 2026-01-08 21:32, יגאל חיטרון wrote:
>>> > It's graphical, you can't see links. But I think the performer name
>>> was
>>> > with link. I can be wrong, of course.
>>>
>>> It really wasn't :) (unless you had some other browser extension that
>>> added one? I know some folks had their own tweaks). You can click on the
>>> dropdown arrow in the top-right corner of the timeline item, then "View
>>> Raw Remarkup", to verify that there really is no link there.
>>>
>>> --
>>> Bartosz Dziewoński
>>> _______________________________________________
>>> Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
>>> To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
>>>
>>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>>
>>
Thumbnails shown on-wiki are already quantized to a set of standard sizes
(if a non-standard size is requested, the next-larger standard size is
used, and scaled to the requested size by the browser). We have recently
extended the set of standard sizes, and are now moving to only allow
standard sizes to be used. Regular editing and viewing will not be impacted
by this change at all.
* What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the
Media API) will continue to behave as they do now - if you request a
non-standard size, the next-larger standard size will be provided, and
scaled in-browser if appropriate.
* What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g.
constructing an upload.wikimedia.org URL with a non-standard thumbnail
size) will be blocked by our CDN. These are already being rate-limited for
requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing
rate-limiting and making it increasingly strict, with the aim being to
refuse such requests entirely by the end of March 2026.
* Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested;
this has been a drain on our thumbnailing infrastructure and cost us in
network bandwidth and storage volume. With the increasing prevalence of
highly aggressive scrapers, this has become an intolerable burden on our
network, infrastructure, and staff, who have spent a lot of time over the
holiday period working hard to keep the wikis available for people to read
in the face of automated abuse.
* What do I need to do?
Most likely, nothing: we have already tracked down some of the more
widely-deployed sources of nonstandard thumbnail requests (e.g. Popups
extension) and fixed them. If you own or operate something that requests
thumbnails by constructing a thumbnail URI directly, then now is the time
to either use the Media API instead or to make sure you only request
standard thumbnail sizes.
* What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px,
1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
And also documented on MetaWiki -
https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see
https://phabricator.wikimedia.org/T414805 for search-links, and examples of
how to fix them.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>