Recently, I stumbled upon a technical writing course which I found very
useful and I wanted to share it and thought of sending an email to
wikitech-l recommending it. Also, I've been looking for a resource about
VueJS with not much luck and wanted to send an email asking if anyone knows
Instead, I have this idea to have a virtual library for developers so they
can share useful resources with each other. You go to a wiki page and see
list of courses, books, conference videos, on each topic and different
people recommanding them. You can also request a resource for a topic and
people respond to you. If the wiki page grows too big, we can split them to
sub pages based on topics, and so on.
I started the page in https://www.mediawiki.org/wiki/User:Ladsgroup/Library
but I'm planning to move it to the main namespace if no one objects. Please
take a look, add more recommandations, co-sign, request for a resource,
respond to a request for a resource, etc.
What do you think? Please let me know if you think it's a horrible idea or
you have feedback on details (mediawiki.org? maybe we should move it to
Hope that'd be useful.
It does the same as the @ operator, except that it takes care to prevent a
very bad bug that existed before PHP 7. Details at
If there are other issues or benefits, please write them on the task. The
overhead of AtEase is prerty minor, so really any benefit at all is likely
to tip the balance toward keeping it. But, in the event that there isn't
any, then perhaps we should slowly phase it out.
this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
Daniel Zahn <dzahn(a)wikimedia.org>
// sorry for cross-posting
A lot of heated discussion occur on talk pages – thus, edit conflicts
happen on talk pages a lot. To be able to solve these more effectively, the
Technical Wishes team at Wikimedia Germany is designing an additional user
interface for this situation. This interface is shown to you when you write
on a discussion page and another person writes a discussion post in the
same line and saves it before you do. With this additional editing conflict
interface you can adjust the order of the comments and edit your comment.
If you'd like to know more about this feature, please visit the project
This interface is created as a result of the Technical Wishes survey  in
2015, in which the German Wikipedia community wished for a simpler way to
resolve edit conflicts. For regular edit conflicts on article pages, the two
column conflict user interface was created, which has been available as a
beta feature since November 2018. The plan is to make this additional
interface for talk pages available in a few months.
We are inviting everyone to have a look at the planned feature and let us
know what you think on our central feedback page ! -- For the Technical
Wishes Team: Max Klemm
Working Student Community Communication for Technical Wishes
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0https://wikimedia.de
Imagine a world in which every single human being can freely share in
the sum of all knowledge. Help us to achieve our
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e.
V. Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt für Körperschaften I Berlin,
The committee has finished selecting new members and the new committee
candidates are (In alphabetical order):
- Amir Sarabadani
- Martin Urbanec
- Tonina Zhelyazkova
- Tony Thomas
And auxiliary members will be (Also in alphabetical order):
- Nuria Ruiz
You can read more about the members in 
The changes compared to last term are:
* Lucie has resigned in September 2019. Tpt (as one of auxiliary members)
filled her seat in the meantime and now Tpt is moving to be an auxiliary
* Martin Urbanec is joining the main committee to fill Lucie/Tpt seat
* Jay Prakash is joining auxiliary members
* Rosalie is leaving the auxiliary members.
This is not the final structure. According to the CoC , the current
committee publishes the new members and call for public feedback for *six
weeks* and after that, the current committee might apply changes to the
structure based on public feedback.
Please let the committee know if you have any concern regarding the members
and its structure until *09 June 2019* and after that, the new committee
will be in effect and will serve for a year.
Amir, On behalf of the Code of Conduct committee
It's time for Wikimedia Tech Talks 2020 Episode 4! This talk will take
place on 5 June 2020 at 5 PM UTC.
Title: API portal and gateway
Speaker: Evan Prodromou, Product Manager for APIs in the Platform Team
Summary: How does Wikimedia become "the essential infrastructure in the
ecosystem of free knowledge"? One way is by making a platform that helps
software developers become successful. In this talk, Evan Prodromou,
Product Manager for APIs in the Platform Team, discusses the ongoing work
to provide a Wikimedia developer platform. With this platform, app creators
can include Wikimedia data and content into their software in new and
emergent ways. From modernizing our API paradigm, through unified user
authorization, documentation, and developer onboarding, the Platform team
is working to make a developer experience that rivals those from other
major Internet players.
The link to the Youtube Livestream can be found here:
During the live talk, you are invited to join the discussion on IRC at
You can browse past Tech Talks here:
If you are interested in giving your own tech talk, you can learn more
Note: This is a public talk. Feel free to distribute through appropriate
email and social channels!
Sarah R. Rodlund
Technical Writer, Developer Advocacy
Hooks::run() was soft-deprecated in Nikki Nikkhoui's HookContainer
patch, merged on April 17.  And my patch to remove almost all
instances of it in MediaWiki Core was finally merged over the weekend.
 That means that everyone writing core code now needs to learn how
to use the new hook system.
HookContainer is a new service which replaces the functionality which
was previously in static methods in the Hooks class. HookContainer
contains a generic run() method which runs a specified hook, analogous
to Hooks::run(). However, unlike Hooks::run(), you generally should
not use HookContainer::run() directly. Instead, you call a proxy
method in a hook runner class.
Hook runner classes give hooks machine-readable parameter names and types.
How to call a hook
In MediaWiki Core, there are two hook runner classes: HookRunner and
ApiHookRunner. ApiHookRunner is used in the Action API, and HookRunner
is used everywhere else.
How you get an instance of HookRunner depends on where you are:
* In classes that use dependency injection, a HookContainer object is
passed in as a constructor parameter. Then the class creates a local
$this->hookRunner = new HookRunner( $hookContainer );
* In big hierarchies like SpecialPage, there are always
getHookRunner() and getHookContainer() methods which you can use.
* Some classes use the ProtectedHookAccessor trait, which provides
getHookRunner() and getHookContainer() methods that get their
HookContainer from the global service locator. You can also call
MediaWikiServices::getHookContainer() in your own code, if dependency
injection is not feasible.
* There is a convenience method for static code called
Hooks::runner(), which returns a HookRunner instance using the global
* Extensions should generally not use HookRunner, since the available
hooks may change without deprecation. Instead, extensions should have
their own HookRunner class which calls HookContainer::run().
Once you have a HookRunner object, you call the hook by simply calling
the relevant method.
How to add a hook
* Create an interface for the hook. The interface name is always the
hook name with "Hook" appended. The interface should contain a single
method, which is the hook name with a prefix of "on". So for example,
for a hook called MovePage, there will be an interface called
MovePageHook with a method called onMovePage(). The interface will
typically be in a "Hook" subnamespace relative to the caller namespace.
* Add an "implements" clause to HookRunner.
* Implement the method in HookRunner.
Note that the name of the interface is currently not enforced by CI.
Alphabetical sorting of interface names and method names in HookRunner
is also not enforced. Please be careful to follow existing conventions.
How to deprecate a hook
Hooks were previously deprecated by passing options to Hook::run().
They are now deprecated globally by adding the hook to an array in the
Using the new system in extensions
Extensions should create their own HookRunner classes and use them to
call hooks. HookContainer::run() should be used instead of Hooks::run().
As for handling hooks, I think it's too early for a mass migration of
extensions to the new registration system as described in the RFC.
Extension authors who are keen to pilot the new system can give it a
go. Make sure you add Nikki and me as reviewers.
More information about the new system can be found in docs/Hooks.md
. The patch to add it should soon be merged.
-- Tim Starling