https://phabricator.wikimedia.org/T335420
Hi, I want to list this resolved task on the workboard TaxonBot, but can't
see it in Backlog or anywhere (I guess because it's resolved).
Can you help me please?
Thank you,
Martin ...
We would like to announce the release of MediaWiki Language Extension
Bundle 2023.04. This bundle is compatible with '''MediaWiki >=
1.38.0''' and requires '''PHP >= 7.4.0'''.
The next MLEB is expected to be released in 3 months. If there are
very important bug fixes, we will do an intermediate release. Please
give us your feedback at
[[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]].
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2023.04.tar…
* sha256sum: c39c9d969255808a628e9fe2a9a2eceefd14ee5d3d0ef8d1fd1a4765804ad896
* Signature: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2023.04.tar…
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/postorius/lists/mediawiki-i18n.lists.wikimedia.…
* Report bugs to: https://phabricator.wikimedia.org/project/view/1464
Release notes for each extension are below.
== Highlights ==
* This is the last release of MLEB supporting '''MediaWiki >= 1.38'''
== Babel ==
* Fix "User categories creation should be able to use templates"
({{phab|T211665}}, {{gerrit|881947}})
* Add ability to override Babel categories ({{gerrit|881944}})
* Fix "Some language tags show wrong language ("English") in Babel
boxes" ({{phab|T64714}}, {{gerrit|884400}})
== CleanChanges and cldr ==
* Localisation and maintenance updates.
== Translate ==
* Optionally allow setting a source language for aggregate groups
({{phab|T281073}})
* Allow fetching translation statistics for messages with similar
prefix ({{phab|T298966}})
* Fix bug with importing fuzzy translations from .po files ({{phab|T323430}})
* Add back-links in various special pages in the Translate extension
* Use a text-based group selector in Special:ExportTranslations in
order to improve usability when a large number of message groups are
present ({{phab|T331843}})
* Show error message if group being exported has no translations for
selected language ({{phab|T331824}})
* Display "Translate" tab if a user has permission to translate
irrespective of whether public editing is enabled ({{phab|T334330}})
* Add support to configure readable and writable translation memory
services separately ({{phab|T322284}})
** Support for the <code>mirrors</code> configuration parameter will
be dropped in the next MLEB release.
== UniversalLanguageSelector ==
* Localisation and maintenance updates.
* Fix issues with up/down keys navigation for the ULS menu ({{phab|T328956}})
* Remove ULSMobileWebfontsEnabled configuration option ({{phab|T332837}})
--
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com
== *What* ==
Flamegraphs provide insight to where and how your MediaWiki component or extension spends its time. We instrument real web requests on the MediaWiki app servers at WMF (using php-excimer, a low-overhead sampling profiler) and continually publish interactive SVG visuals by entrypoint (e.g. index.php, JobQueue, ResourceLoader load.php, or rest.php API). [1] [2]
Read more about the Arc Lamp pipeline, introduced by Ori during the 2014 HHVM migration [3], through our blog post:
https://techblog.wikimedia.org/2021/03/03/profiling-php-in-production-at-sc…
== *What's New* ==
The user interface at https://performance.wikimedia.org/php-profiling/ has undergone major changes.
• Date: You can now choose any date in the last *2+ years*. Previously, this was limited to 2-3 weeks. In the dropdown menu, choose "Other", and select any date using the native datepicker. Existing URLs remain compatible.
• Source: Real-time performance data from the *MediaWiki-on-Kubernetes* deployment is now available through here (excimer-k8s and excimer-k8s-wall). While web traffic remains largely on bare metal (except for test2wiki), internal MediaWiki API traffic is already partly on Kubernetes. Refer to T333120 <https://phabricator.wikimedia.org/T333120> for work by SRE ServiceOps (e.g. CXServer uses MediaWiki-on-Kubernetes).
• Entrypoint: *JobQueue* (RunSingleJob) is now included in the selector, plus the new detailed breakdowns <https://phabricator.wikimedia.org/T253679> for *EditAction*, *PreSend*, and *PostSend* are now promoted here. These were previously available via the file browser only.
== *How* ==
The new interface is an HTML form with vanilla JavaScript to navigate you to the right SVG.
Details at https://gerrit.wikimedia.org/r/c/performance/docroot/+/908374.
As before, we promote "good" defaults. You don't have to make any choices to start exploring the data. Press the big blue button to instantly view the most recent index.php flamegraph with the default settings.
--
Timo Tijhof,
Performance Team,
Wikimedia Foundation.
[1] https://wikitech.wikimedia.org/wiki/Performance/Runbook/Arc_Lamp_service
[2] https://www.mediawiki.org/wiki/Excimer
[3] https://techblog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twi…
This email is a summary of the Wikimedia production deployment of
1.41.0-wmf.5
- Conductor: Jaime Nuche
- Backup Conductor: Chad Horohoe
- Blocker Task: T330211 <https://phabricator.wikimedia.org/T330211>
- Current Status <https://versions.toolforge.org>
📊 Numbers
Sparklines comparing the last 5 trains.
- 296 Patches █▆▄▁▅
- 0 Rollbacks ▁▁▄█▁
- 0 Days of delay ▁█▁▁▁
- 1 Blockers ▁▃██▃
🎉 Traintastic Folks 😻 Thanks to folks who reported or resolved blockers:
- Jesús Martínez Novo
- Bartosz Dziewoński
--
Jaime Nuche
Software Engineer III
Wikimedia Foundation <https://wikimediafoundation.org/>
Dear Wikitechians,
On *Wednesday March 1st*, the SRE team will run a planned data center
switchover, moving all wikis from our primary data center in Virginia to
the secondary data center in Texas. This is an important periodic test of
our tools and procedures, to ensure the wikis will continue to be available
even in the event of major technical issues in our primary home. It also
gives all our SRE and ops teams a chance to do maintenance and upgrades on
systems in Virginia that normally run 24 hours a day.
The switchover process requires a *brief read-only period for all
Foundation-hosted wikis*, which will start at *14:00 UTC on Wednesday March
1st*, and will last for a few minutes while we execute the migration as
efficiently as possible. All our public and private wikis will be
continuously available for reading as usual, but no one will be able to
save edits during the process. Users will see a notification of the
upcoming maintenance, and anyone still editing will be asked to try again
in a few minutes.
CommRel has already begun notifying communities of the read-only window. A
similar event will follow a few weeks later, when we move back to Virginia.
This is currently scheduled for *Wednesday, April 26th*.
If you like, you can follow along on the day in the public
#wikimedia-operations channel on IRC (instructions for joining here
<https://meta.wikimedia.org/wiki/IRC/Instructions>). To report any issues,
you can reach us in #wikimedia-sre on IRC, or file a Phabricator ticket
with the *datacenter-switchover* tag (pre-filled form here
<https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?projects=Data…>);
we'll be monitoring closely for reports of trouble during and after the
switchover. (If you're new to Phab, there's more information at
Phabricator/Help.) The switchover and its preparation are tracked tracked
in Phabricator Task T327920 <https://phabricator.wikimedia.org/T327920>
On behalf of the SRE team, please excuse the disruption, and our thanks to
everyone in a number of departments who've been involved in planning this
work for the past weeks. Feel free to reply directly to me with any
questions.
Thank you,
--
Clément Goubert (they/them)
Senior SRE
Wikimedia Foundation
*Fixing my list addressing errors...*
TLDR: The Foundation will be conducting a retrospective on the Technical
Decision Making Process.
To the entire Wiki technical community,
For quite some time now, we have experienced issues with the Technical
Decision Making Process (TDMP). Volunteer contributors and staff have asked
if we are still operating the Technical Decision Forum (TDF, the member
body that participates in the TDMP). Communication about it from the
Foundation has been inconsistent, and interest from the volunteer community
in joining has been low. Some of our most senior engineers on Foundation
staff have expressed that the process is flawed, doesn’t create room for
discussion about the technical issues surrounding a decision, and doesn’t
ensure participation by all stakeholders who may be affected by the
decision. Suffice it to say, the current state of affairs leaves many
participants wanting more.
We must also remind ourselves of the purpose of a decision making process.
The decisions are not meant to be random or isolated. They should be
aligned to our technical strategy, and we should be able to look at the
decisions we have made and understand how they advance our progress against
that strategy. If the process is working as it should, the decisions that
are produced should represent settled wisdom, and not need to be revisited
too quickly. The goals for a well-run process include:
-
A straightforward, widely understood decision making process, that
-
Facilitates impactful technical decisions to be made in a timely manner,
-
Incorporates input from staff and volunteers in our technical community,
with
-
Decisions that align with accountability for decision outcomes, and
-
Clear communication and transparent operations throughout the process.
On examination of the contributing factors that have led us to this point,
the factor that stands out to me is the need for clear accountability:
accountability for the TDMP itself and accountability for each of the
decisions we make. Technical decision making, beyond a certain magnitude,
is a core organizational process for any engineering organization. It is
therefore important for us to examine and improve this process from time to
time to ensure organizational effectiveness. Not unrelated, regular
retrospectives are a routine agile software engineering practice to enact
continuous improvement. To keep our decision making process effective and
efficient, we need to conduct regular retros. Overall accountability for
maintaining an effective decision making process should rest with a person
who is sufficiently able to marshal resources and address problems at a
large scale – here at the Foundation, that resides in the executive level.
The Foundation will be conducting a retro on the TDMP over the next couple
of months. Because we don’t yet have a habit of doing retros on this
process, and because there is a wide range of stakeholders we seek to hear
from, the process will be a bit more structured than an ordinary retro, and
will take more time. As we do more of these, we should get better at them.
The feedback gathered through the retro will be used to make changes to
improve the TDMP.
Foundation staff will follow up with more information about the kickoff of
the retro and what steps will follow. I am looking forward to wide
participation in this retro.
Here are the links to the relevant wiki page and Phab ticket:
- Wiki page
<https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision…>
- Phabricator ticket <https://phabricator.wikimedia.org/T333235>
Thank you! And apologies for all the crossposting.
Tajh Taylor (he/him/his)
VP, Data Science & Engineering
Wikimedia Foundation <https://wikimediafoundation.org/>
*Sorry for cross-posting*
Hello, this is Wikimedia Deutschland’s Technical Wishes team with news on
Kartographer:
As was requested by many community members, it is now possible to see
nearby articles on a Kartographer map. This offers an additional way of
exploring content on the wikis. The feature was deployed to most Wikimedia
wikis <https://phabricator.wikimedia.org/T334079> on April 11. To try it
out, open any Kartographer map into full screen mode and click on “Show
nearby articles” in the footer.
Some links if you would like to learn more:
-
The help page on mediawiki.org with a short overview of this feature:
https://www.mediawiki.org/wiki/Help:Extension:Kartographer#Show_nearby_arti…
-
Our project page with more detailed information:
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation/Nearby…
German, Catalan, Russian and Hebrew Wikipedia, and English and German
Wikivoyage have already been using this feature since October, and have
given plenty of feedback – thanks a lot! If you have any feedback, please
let us know on this talk page:
https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Geoinformation/N…
With this deployment, our focus area “Better support for geo information
<https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Geoinformation>” is
coming to an end. On behalf of the whole Technical Wishes team, many many
thanks to everyone who tested, gave feedback, was interviewed, reviewed
tickets, or contributed in any other way. It is deeply appreciated!
Johanna
for the Technical Wishes team at Wikimedia Deutschland
--
Johanna Strodt Project Manager Community Communications for the Technical
Wishes project
Hello Everyone,
Today it was identified that the Graph extension [1], which uses the older
Vega 1 & Vega 2 libraries, had a number of security vulnerabilities.
In the interest of the security of our users, the Graph extension was
disabled on Wikimedia wiki's. We know that this is disruptive for editors
and readers, and WMF teams are working quickly on a plan to respond to
these vulnerabilities.
We recommend that any other third party users of the Graph extension should
disable the use of that extension on their wikis.
A configuration change will suppress the exposed raw tags and graph json
definition to avoid excess disruption to the end user experience when the
extension is disabled. [2] This also provides a tracking category
"Category:Pages with disabled graphs" showing the pages that used to
contain graphs. Local administrators can localise the name of the category
and its description by editing [[MediaWiki:Graph-disabled-category]],
[[MediaWiki:Graph-disabled-category-desc]] interface messages on your local
wiki.
On Wikimedia projects, graphs created via the extension will remain
unavailable. This means that pages that were formerly displaying graphs
will now display a small blank area. To help readers understand this
situation, communities can now define a brief message that can be displayed
to readers in place of each graph until this is resolved. That message can
be defined on each wiki at [[MediaWiki:Graph-disabled]] by local
administrators.
Wikimedia Foundation staff are looking at options available and expected
timelines. For updates on this topic, follow the public Phabricator task
for this issue: https://phabricator.wikimedia.org/T334940
We are seeking translation to be able to distribute a massmessage about
this to various language wikis tomorrow. Please help us translate here:
https://meta.wikimedia.org/wiki/User:Seddon_(WMF)/Graph_massmessage
Thank you,
Seddon
[1] https://www.mediawiki.org/wiki/Extension:Graph
[2]
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
Seddon (he/him they/them)
*Engineering Manager*
*Wikimedia Foundation*
Greetings. The Wikimedia Foundation is pleased to share a summary of our
draft annual plan with you. It's available on Meta-wiki, and we encourage
you to take a look.[0] We'd also love to hear your thoughts, so feel free
to leave a comment on the talk page.[1] The comment period is open from now
until May 19th. Thank you for your interest in our work.
[0]
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024
[1]
https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2023-…
Yours,
Chris Koerner (he/him)
Senior Movement Communications Specialist
Wikimedia Foundation