Hi Everyone,
Mark your calendars! Wikimedia Tech Talks 2020 Episode 6 will take
place on Wednesday
on 12 August 2020 at 17:00 UTC.
Title: Retargeting extensions to work with Parsoid
Speaker: Subramanya Sastry
Summary:
The Parsing team is aiming to replace the core wikitext parser with Parsoid
for Wikimedia wikis sometime late next year. Parsoid models and processes
wikitext quite differently from the core parser (all that Parsoid
guarantees is that the rendering is largely identical, not the specific
process of generating the rendering). So, that does mean that extensions
that extend the behavior of the parser will need to adapt to work with
Parsoid instead to provide similar functionality [1]. With that in mind, we
have been working to more clearly specify how extensions need to adapt to
the Parsoid regime.
At a high level, here are the questions we needed to answer:
1) How do extensions "hook" into Parsoid?
2) When the registered hook listeners are invoked by Parsoid, how do they
process any wikitext they need to process?
3) How is the extension's output assimilated into the page output?
Broadly, the (highly simplified) answers are as follows:
1) Extensions now need to think in terms of transformations (convert this
to that) instead of events (at this point in the pipeline, call this
listener). So, more transformation hooks, and less parsing-event hooks.
2) Parsoid provides all registered listeners with a ParsoidExtensionAPI
object to interact with it which extensions can use to process wikitext.
3) The output is treated as a "fully-processed" page/DOM fragment. It is
appropriately decorated with additional markup and slotted into place into
the page. Extensions need not make any special efforts (aka strip state) to
protect it from the parsing pipeline.
In this talk, we will go over the draft Parsoid API for extensions [2] and
the kind of changes that would need to be made. While in this initial
stage, we are primarily targeting extensions that are deployed on the
Wikimedia wikis, eventually, all MediaWiki extensions that use parser hooks
or use the "parser API" to process wikitext will need to change. We hope to
use this talk to reach out to MediaWiki extension developers and get
feedback about the draft API so we can refine it appropriately.
[1] https://phabricator.wikimedia.org/T258838
[2] https://www.mediawiki.org/wiki/Parsoid/Extension_API
The link to the Youtube Livestream can be found here:
<https://www.youtube.com/watch?v=jNNy8ALGjaE>
https://www.youtube.com/watch?v=lS1xPkERWCM
During the live talk, you are invited to join the discussion on IRC at
#wikimedia-office
You can browse past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Kindly,
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
tl;dr: Help would be appreciated testing a new MediaWiki codesearch
UI: <https://codesearch-beta.wmcloud.org/>. Sticking "-beta" in
existing URLs should just work.
The current codesearch interface is a pretty bad hack based on
upstream's UI. Originally I implemented it that way with the
assumption that upstream would continue to make improvements that we
could benefit from but that didn't really happen.
The new beta UI implements some features I wanted/others have asked for:
* Switching search profiles doesn't lose your search query
* An overview listing which repositories have results
* An option to get a Phabricator checklist based on the results
Some features are missing (e.g. manual repository selector) that I
don't use, but if people want I can implement them. Please provide
requests or general feedback via email or the codesearch Phabricator
project.
If people are happy/satisfied with the new UI, I'd like to replace the
old one in a few weeks.
I'd also appreciate some help with some of the minor layout/styling
issues. The code[1] is written in Rust and compiled to WebAssembly,
but the styling is all Bootstrap so hopefully it's easy to work with.
I'm not sure it'll remain implemented in client-side Rust, the
performance really isn't that great.
[1]
https://gerrit.wikimedia.org/g/labs/codesearch/+/refs/heads/master/front
end/
Thanks,
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl8jzRMACgkQ8QX4EBsF
JpvHYBAA0Dnq1hMYqDQPMTh/S+6CXKf7YN91mMhWYoPNA/eWP9p8V3Sd6TIy+T3w
wCfNK3SBdsCt7G/ut5ikZ1U3orSr952imrJIGkK6FIV9FDCZ1Obgr/J3bTYNZGpP
gQ+BLvLIfHnNlVA3Wa5IsEf7ja1A7SBddfmjE5nl1NFR/7muzX43kmT+PYlMeJDt
J4EiZOgEdp+Dk12/zdTw0RAGbZDfcTRO6ytxe4ZNNKyef9jLq7OH3QrU6lYF/Nja
zoo+Kq6Bmv7428DrgtfInbdrYgWCRPAyVkuAje/9cH/W3k2RcY26y/2ohSXfS4mg
EBiywlOum+DBsm5gbFRG7fvqjvHBY77sIN7Io67OxZRcECzOfWd1qYiRI81aoRzd
4L+cuuqnK9cQdFzyXIx6C8cVu1HaaOaCum2mLgUxEMX/tome7tQ7ZY2wqEDY51Xv
YCFA91W4sCVmeZBJeYCMURiC7r/Aq0HwQAgzFynWCP5SEngDokwQ5MpOJwlsRhgG
dWdhHsWFvJmS5XofDYLRPGG+RM0l1JXpoxLxWr0k8/udiRmASS6Pev08DBWiayZv
xy62h1WB3lIIEb7W3JpGcQ8j6NZB6if1mkHl5HqjzDjqSbJ7QrbJPYUmQlou28L9
8OezeAhaqZbRKlIy3OR1KCCcCUTcOMo1jAiOlwSImRaD8dVzKkE=
=aRW2
-----END PGP SIGNATURE-----
The 1.36.0-wmf.2 version of MediaWiki is currently blocked at group1.[0]
The new version can proceed no further until this issue is resolved:
* Argument 1 passed to Wikimedia\Parsoid\Utils\DOMDataUtils::getDataMw()
must be an instance of DOMElement
- https://phabricator.wikimedia.org/T259311
Thanks for any help resolving this issue. Since we're past today's
cutoff and there are no deploys on Friday, the train can roll forward on
Monday morning, assuming a fix.
Thanks to Mholloway, Msantos, Legoktm, tgr, and RoanKattouw for their
assistance with earlier blockers this week.
-- Your temporary train trundler
[0]. <https://phabricator.wikimedia.org/T257970>
[1]. <https://tools.wmflabs.org/versions/>
Hi all,
Here are the minutes from this week's TechCom meeting:
== RFC: Stop supporting legacy PHP entry point extensions ==
<https://phabricator.wikimedia.org/T258845>
* New RFC by Kunal (Legoktm) that proposes gradually ending support for
legacy
PHP entry points
* TS: The RFC proposes ending support for legacy entry points by MediaWiki
1.43,
which could be five years from now.
* GL: That long of a timeline might be too conservative considering that
there’s a viable
migration path. Wikidata is removing it from production this week. The
percentage of
extensions on gerrit using the new system leads me to believe that we can
do this on
a shorter timeline, especially if there are advantages to not having to
support the legacy
entry points.
* RK: 1.35 will be an LTS release that ships with support for legacy PHP
entry points,
giving longer support to projects that need it. We could remove them before
1.39, our
next LTS release.
* TS: If there’s a large extension or project that needs it, we can be
sensitive to the
timing of the deprecation.
* Discussion continues on the task
== Consolidate language metadata into a 'language-data' library and use in
MediaWiki ==
<https://phabricator.wikimedia.org/T190129>
* NL: No remaining unanswered questions that would change the direction of
the proposal.
* Ready to move from P3 (Explore) to P4 (Tune)
== RFC: Render data visualizations on the server ==
<https://phabricator.wikimedia.org/T249419>
* DA: This RFC is stalled due to pushback on the technical side coupled
with inactivity on
the product side. Client-side visualization seems to be uncontroversial so
far, but I took the
inactivity as a decrease in priority. I’m still interested in the problem
technically, but it needs
proper resourcing and stewardship. Any change away from current
architecture runs into
other problems. I proposed to take a deeper look at how we store graph
definitions.
* GL: We un-deployed Graphoid from Group 0 and 1 only, which may be the
cause of the
lack of feedback.
* DA: I wouldn’t suggest re-deploying Graphoid. The idea was to deploy a
new version,
new repository.
* TT: Removing Graphoid from group 2 could change the priority. When we
un-deploy
Graphoid, there will be a gap when getting things from Siri as well as
impact to the graphs
on pages related to COVID-19. I did hear some interest, but we need actual
resourcing.
* GL: For anything going into production from now on, we’re considering the
typical
performance expected and determining an error budget. If a project overruns
its error budget
for the quarter, the responsible team will be required to do something
about it, either make it
more stable or lose SRE support.
== RFC: Normalize MediaWiki link tables ==
<https://phabricator.wikimedia.org/T222224>
* TT: There’s currently a straw-man proposal open for feedback. Waiting for
DBA feedback.
* No IRC discussion scheduled for next week
You can also find our meeting minutes at
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes>
See also the TechCom RFC board
<https://phabricator.wikimedia.org/tag/mediawiki-rfcs/>.
If you prefer you can subscribe to our newsletter here
<https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar>
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
Hi all! Question about WikidataPageBanner (https://www.mediawiki.org/wiki/Extension:WikidataPageBanner)... WikidataPageBanner menus are built dynamically and link to section headings on the wiki page where the banner template is used. Is there a way to add WikidataPageBanner menu items that behave like wikilinks and navigate off the page when clicked?
Thank you... Michael H.
Hi,
for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-07-29
Željko
--
= 2020-07-29 =
== Callouts ==
* Release Engineering
** [All] Review guidance at [[wikitech:Deployments/Covid-19]] and Code
Deployment Office Hour at 17:00UTC in #wikimedia-office
** "scap sync" will be renamed to "scap sync-world" in the next
release. If you use "scap sync" non-interactively, please add a note
to: [[phab:T250302]] (and also, explain why you're using it)
** scap sync now has option --canary-wait-time; [[phab:T217924]]
== SoS Meeting Bookkeeping ==
* Updates:
** Looking for a meeting facilitator for 2020-08-05, 2020-08-12 and
maybe 2020-08-19. The facilitator job is creating a wiki page and
sending mail to wikitech-l.
== Product ==
=== Web ===
* Updates:
** '''Summary''': the Desktop Improvements Project's (DIP) new Vector
is now an opt-in user preference everywhere; continuing WVUI Vector
integration, network client, and search suggestion component.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project
(Vector / DIP)]]:
*** [[phab:T250968|<nowiki>[ShoutWikiAds] Replace use of deprecated
hook VectorBeforeFooter</nowiki>]]
*** [[phab:T258588|<nowiki>Sidebar collapsed by default on desktop
improvements</nowiki>]]
*** [[phab:T258058|<nowiki>Enable sidebar instrumentation on test
wikis</nowiki>]]
*** [[phab:T254227|<nowiki>Switch test wikis to new version of vector
by default</nowiki>]]
*** [[phab:T253842|<nowiki>Fix the printable versions of modern
Vector</nowiki>]]
*** [[phab:T249363|<nowiki>Move the existing search to the header in
preparation for Vue.js search development</nowiki>]]
*** [[phab:T257647|<nowiki>Integrate WVUI into Vector for Vue.js
search</nowiki>]]
*** [[phab:T256092|<nowiki>[Modern Vector] Fix broken rendering of
`main` and element in IE9-11</nowiki>]]
*** [[phab:T251212|<nowiki>[Dev] Drop VectorTemplate usage in Vector</nowiki>]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T237036|<nowiki>ext.uls.interface should set targets and
explicitly not target the Minerva skin</nowiki>]]
*** [[phab:T235712|<nowiki>Fix the most common "Module not loadable on
target mobile" warnings (Oct 2019)</nowiki>]]
*** [[phab:T258728|<nowiki>MobileFrontend browser test failing:
User:<username> "before all" hook – Can't call setValue on element
with selector "#wpName1" because element wasn't found</nowiki>]]
*** [[phab:T258096|<nowiki>Browser test failure: Nested references do
not always open</nowiki>]]
*** [[phab:T240622|<nowiki>[Technical debt payoff] Remove
InlineDiffFormatter and InlineDifferenceEngine from
MobileFrontend</nowiki>]]
*** [[phab:T212465|<nowiki>[EPIC] None of our View's should exhibit 2
levels of inheritance</nowiki>]]
** Standardization
*** [[phab:T250762|<nowiki>UsersMultiselectWidget not announcing
status message</nowiki>]]
*** [[phab:T248062|<nowiki>Deprecate and remove
`.background-image-svg()` mixin from
'mediawiki.mixins.less'</nowiki>]]
*** [[phab:T248047|<nowiki>Deprecate & remove
`.background-image-svg-quick()` mixin from
'mediawiki.mixins.less'</nowiki>]]
*** [[phab:T258752|<nowiki>Unify `line-height` to `20px` in widgets to
simplify code and better i18n</nowiki>]]
** Portals
*** [[phab:T128546|<nowiki>[Recurring Task] Update Wikipedia and
sister projects portals statistics</nowiki>]]
** Miscellaneous
*** [[phab:T147221|<nowiki>Vertical alignment of logos and text in
Notifications popup</nowiki>]]
== Technology ==
=== Engineering Productivity ===
==== Release Engineering ====
* Updates:
** [All] Deployments/Covid-19 [[wikitech:Deployments/Covid-19]]
** Train Health
*** Last week: 1.36.0-wmf.1 - [[phab:T257969]]
*** This week: 1.36.0-wmf.2 - [[phab:T257970]]
*** Next week: 1.36.0-wmf.3 - [[phab:T257970]]
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, August 5th, 2020
Time: 15:00-16:00 GMT / 08:00-09:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#
Hope to talk to you in a week!
—Trey
Trey Jones
Sr. Computational Linguist, Search Platform
Wikimedia Foundation
UTC-4 / EDT
Hi all,
https://phabricator.wikimedia.org/T257879 recommends dropping support for
PHP 7.2 in the upcoming MediaWiki 1.35 release. (It would still be
supported in master as it will probably take months for Wikimedia
production to switch.) Tl;dr: 1.35 is an LTS release which we'll support
for 3 years, and supporting an old PHP version in an LTS release tends to
be inconvenient in a number of ways. More details in the task.
Your feedback in the task would be appreciated, especially if you would be
affected by the change in a positive or negative way.