Wikitech-l March 2019

wikitech-l@lists.wikimedia.org

94 participants
76 discussions

Discovery Weekly Update for the week starting 2019-03-11
by Chris Koerner 18 Mar '19

18 Mar '19

Hello, This is the weekly update from the Search Platform team for the week starting 2019-03-11. As always, feedback and questions are welcome. == Discussions == === Search === * As part of the ElasticSearch v6 upgrade: ** uploaded ElasticSearch 6.5.4 packages to reprepro [0] ** Adapted the ElasticSearch puppet module [1] ** Tested that we can run multiple ElasticSearch clusters on same hardware [2] * We discovered that the Maven Wrapper does not support XDG_CACHE_HOME, so we updated java8: to actually use the new image; fixing the mvn wrapper cache issue [3] * Upon unpacking the Greek analysis chain, we found that the filter isn't properly handling language-specific lowercasing in language analyzers; fixed it by adding Greek empty-token filter and keep lang-specific lowercasing [4] * As part of the lang-specific lowercasing, we also upgraded the ICU normalization [5] [6] * We decided we should use a better/cleaner approach for icinga elasticsearch check and merged http and https elasticsearch icinga checks into one [7] * We also updated the alerts for mjolnir daemons, so we can tell when it starts misbehaving [8] [0] https://phabricator.wikimedia.org/T218113 [1] https://phabricator.wikimedia.org/T217196 [2] https://phabricator.wikimedia.org/T193654 [3] https://phabricator.wikimedia.org/T218099 [4] https://phabricator.wikimedia.org/T217602 [5] https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Greek_and_Unexpected… [6] https://phabricator.wikimedia.org/T203117 [7] https://phabricator.wikimedia.org/T215587 [8] https://phabricator.wikimedia.org/T214494 ---- Subscribe to receive on-wiki (or opt-in email) notifications of the Discovery weekly update. https://www.mediawiki.org/wiki/Newsletter:Discovery_Weekly The archive of all past updates can be found on MediaWiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates Interested in getting involved? See tasks marked as "Easy" or "Volunteer needed" in Phabricator. [1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R [2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R Yours, Chris Koerner (he/him) Community Relations Specialist Wikimedia Foundation

1 0

Fwd: [discovery] Discussion around CirrusSearch extensibility
by Deb Tankersley 18 Mar '19

18 Mar '19

Cross-posting to wikitech-l for more community input on how extensions can interact with CirrusSearch. :) Thanks, Deb -- deb tankersley program manager, engineering Wikimedia Foundation ---------- Forwarded message --------- From: David Causse <dcausse(a)wikimedia.org> Date: Mon, Mar 18, 2019 at 9:56 AM Subject: [discovery] Discussion around CirrusSearch extensibility To: A public mailing list about Wikimedia Search and Discovery projects < discovery(a)lists.wikimedia.org> Hi, I've put a couple pages on mw.org to start discussing about the problem we are currently facing as to how extensions can interact with CirrusSearch without stepping on each other toes. To describe the problem briefly: some extension provides additional data to the wiki structure (generally through custom Content Handlers) and CirrusSearch itself is not aware of the best ways to take benefits of this additional data to ameliorate ranking or results display. Cirrus has provided (organically) various hooks to let us build what we have today: - wikidata search integration for Entities, Properties & Lexemes - search keywords But as more and more integrations have to be done (SDoC) we need to step back and decide on better ways to let extensions augment the search experience. Beware that the discussion at this stage may only be relevant to developers who worked on these extensions. A page describes the current "query construction" mechanism[1] (with an emphasis on parts that poses problems at the moment) and a first list of use cases and a first set of solutions[2]. This is just a starting point for the discussion. Thanks for your input. [1] https://www.mediawiki.org/wiki/Extension:CirrusSearch/Query_Construction [2] https://www.mediawiki.org/wiki/Extension:CirrusSearch/Query_Construction/Us… _______________________________________________ Discovery mailing list Discovery(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/discovery

1 0

Wednesday: Technical Advice IRC Meeting
by Johanna Strodt 18 Mar '19

18 Mar '19

// Sorry for cross-posting! Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC** on #wikimedia-tech. Questions can be asked in English and German! The Technical Advice IRC Meeting (TAIM) is a weekly support event for volunteer developers. Every Wednesday, two full-time developers are available to help you with all your questions about Mediawiki, gadgets, tools and more! This can be anything from "how to get started" over "who would be the best contact for X" to specific questions on your project. If you know already what you would like to discuss or ask, please add your topic to the next meeting: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting Hope to see you there! Johanna (for the Technical Advice IRC Meeting crew)

1 0

New Gerrit privilege policy
by Tim Starling 18 Mar '19

18 Mar '19

Following approval by TechCom and WMF Interim CTO Erika Bjune, I've moved the new Gerrit privilege policy page out of my userspace to https://www.mediawiki.org/wiki/Gerrit/Privilege_policy This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project ownership]], with some additional changes. I've now redirected both of those pages to the new policy page. The main changes are: * The wmde LDAP group, representing WMDE staff members, will be given +2 access to mediawiki/* projects, similar to the rights given to WMF staff members. * The ability of ShoutWiki and Hallo Welt! to manage access to the extensions they maintain is described and formalised. * The ownership model for extensions is discouraged in favour of individual requests on Phabricator. An extension owner was able to promote developers to +2 access at their own discretion. * The Phabricator projects for requesting access have changed. I'm in the process of moving the tickets over. * The revocation policy has been expanded, better describing the present situation and making several minor changes. -- Tim Starling

12 22

Unbreak now! problem in this week train Watchlist
by יגאל חיטרון 18 Mar '19

18 Mar '19

Hello. There is a regression problem, that started on this week deployment. I can see it in group 1 from yesterday evening. I do not file a phabricator ticket, because there is no algorithm to reproduce the problem. >From time to time the API post query "mark this revision as read" does not work. In these times, there is a reproducing algorithm: 1) Open Special:Watchlist. 2) Pick an unread revision. 3) Open the diff to last version, or the view mode of the page. 4) Expected: the revision, and the whole page, should be automatically marked as read. 5) Refresh the Special:Watchlist. 6) Got: the revision remains bold. 7) Open API query for unread revisions, the relevant one is still there. 8) Try partagraphs 5-7 every 5 seconds. 9) In about twenty minutes the data is updated correctly. I saw this yesterday at about 19:45 UTC, and it happens again just now. Thank you. Igal (User:IKhitron)

6 12

Read access to patrolled flag in wikimedia API
by Сибирев Кирилл 17 Mar '19

17 Mar '19

Hi, we are using wikimedia http api for getting pages recent changes [1]. We'd like to be able to distinguish patrolled and unpatrolled revisions and this feature is supported according to docs, but we still can't use it because of access permissions. For example if i making requests like [2] or [3] i am getting {"code": "permissiondenied", "info": "You need the \"patrol\" or \"patrolmarks\" right to request the patrolled flag."} error. This API behaviour looks inconsistent to me, because anyone can see patrolled/unpatrolled colored markup at wikipedia revision history web pages. I think patrol right should be checked only at write (ones that mark revisions patrolled or not) API requests and not for read requests. Is this behaviour really inconsistent and implemented that way due to technical restrictions or am i missing something? Can it be changed, so we can get patrolling information for revisions or maybe there are some workarounds exist? [1] https://www.mediawiki.org/wiki/API:RecentChanges [2] https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=t… [3] https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=t…

5 7

Thank you Tuesday
by Bartosz Dziewoński 15 Mar '19

15 Mar '19

Any day can be Tuesday if you really want. * Thanks to Strainu for insightful comments on the "Backlog on bugs" thread. * Thanks to Roan and Ed for stepping up to review major OOUI patches this week (and to Moriel, Cormac and Matthias who proposed said patches). -- Bartosz Dziewoński

2 1

TechCom Radar 2019-03-13
by Kate Chapman 15 Mar '19

15 Mar '19

Hi All, Here are the minutes from this week's TechCom meeting: * IRC Meeting Scheduled: RFC: Add a frontend build step to skins/extensions to our deploy process <https://phabricator.wikimedia.org/T199004> March 20 2pm PST (21:00 UTC, 22:00 CET) in #wikimedia-office * IRC Meeting Scheduled: RFC: Let's stop using QUnit as a mechanism for integration tests <https://phabricator.wikimedia.org/T212521> March 20 2:45pm PST (21:45 UTC, 21:45 CET) in #wikimedia-office * Last Call extended by one week: RfC: Standards for external services in the Wikimedia infrastructure. <https://phabricator.wikimedia.org/T208524> ending March 20 1pm PST (March 20 20:00 UTC, 21:00 CET) * Last Call: The Great Namespaceization and Reorg <https://phabricator.wikimedia.org/T166010> ending March 20 1pm PST (20:00 UTC, 21:00 CET) * Under discussion: Remove .m. subdomain, serve mobile and desktop variants through the same URL <https://phabricator.wikimedia.org/T214998> * Under discussion: RFC: Skin <templating https://phabricator.wikimedia.org/T217158> * No IRC meeting this 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> Thanks, Kate -- Kate Chapman Senior Program Manager, Core Platform Wikimedia Foundation kchapman(a)wikimedia.org

1 0

Fwd: MathML Refresh
by Physikerwelt 15 Mar '19

15 Mar '19

Hi all, just for your information: An update about the upcoming improvement in the MathML implementation in Firefox and the new implementation in Chromium. Best physikerwelt ---------- Forwarded message --------- From: Frédéric Wang <fred.wang(a)free.fr> Date: Fri, Mar 15, 2019 at 11:35 AM Subject: MathML Refresh Heads up To: <dev-tech-mathml(a)lists.mozilla.org> Hello Mozilla developers, As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to: - Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies). - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing. - Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary. We expect that this effort will improve browser interoperability and reduce complexity of current implementations. This is just a heads up to say that some work is likely to happen to update/remove/add MathML features. The appropriate "Intents" will be sent later to these mailing lists. Frédéric and Rob, [1] https://mathml.igalia.com/ [2] https://mathml-refresh.github.io/ [3] https://mathml-refresh.github.io/mathml-core/

1 0

OOUI v0.31.0 released – PHP layouts, breaking changes et al
by Volker E. 14 Mar '19

14 Mar '19

Hello everyone, I'm pleased to announce that we've released OOUI v0.31.0 yesterday. Key highlights of this release: - IndexLayout (tab layout) and all its dependent layouts - StackLayout, - MenuLayout, - TabPanelLayout and TabSelectWidget/TabOptionWidget are all now provided server-side in PHP as well. Thanks to Cormac Parle, the Multimedia team and Ed Sanders for providing those. - Mixin configs are made extendable Config options are always overridable unless explicitly needed to force a value to them. - New 'success' type was added as FieldLayout message type additionally to 'error' and 'warning'. Apart from above, there are also possible breaking changes in this release: Please carefully consider if they affect your code. - Remove FlaggedElement from InputWidget. Only TextInputWidget & ButtonInputWidget use or require flags, so mixin FlaggedElement to those directly. The following classes are no longer flagged: - CheckboxInputWidget - CheckboxMultiselectInputWidget - DropdownInputWidget - RadioSelectInputWidget - Remove method names, like for example `onMouseUp` or `onMouseMove`, which got deprecated in v0.28.3 and replaced by `onDocumentMouseUp` and `onDocumentMouseMove`. - Drop `iconTitle` and `indicatorTitle` properties, deprecated in v0.30.0, use `title` instead. - Drop 'search' indicator, deprecated in v0.30.0, in this release removed completely. This indicator hasn't been used anywhere to our knowledge. 'search' icon is the replacement where needed. You can find details on additional new features, code-level and accessibility changes, styling and interaction design amendments, and all improvements since v0.30.0 in the full changelog[1]. If you have any further queries or need help dealing with breaking changes, please let me know. As always, interactive demos[0] and library documentation is available on mediawiki.org[2], there is comprehensive generated code-level documentation and interactive demos and tutorials hosted on doc.wikimedia.org[3]. OOUI version: 0.31.0 MediaWiki version: 1.33.0-wmf.22 Date of deployment to production: Regular train, starting Tuesday 19 March [0] - https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr [1] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md [2] - https://www.mediawiki.org/wiki/OOUI [3] - https://doc.wikimedia.org/oojs-ui/master/ Best, Volker -- Senior UX Engineer Wikimedia Foundation volker.e(a)wikimedia.org | @Volker_E

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l March 2019