Wikitech-l March 2019

wikitech-l@lists.wikimedia.org

94 participants
71 discussions

Wikidata now officially has more total edits than English language Wikipedia
by Ariel Glenn WMF 20 Mar '19

20 Mar '19

Wikidata surpassed the English language Wikipedia in the number of revisions in the database, about 45 minutes ago today.I was tipped off by a tweet [1] a few day ago and have been watching via a script that displays the largest revision id and its timestamp. Here's the point where Wikidata overtakes English Wikipedia (times in UTC): [ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d www.wikidata.org -r 888603998,888603999,888604000 revid 888603998 at 2019-03-20T06:00:59Z revid 888603999 at 2019-03-20T06:00:59Z revid 888604000 at 2019-03-20T06:00:59Z [ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d en.wikipedia.org -r 888603998,888603999,888604000 revid 888603998 at 2019-03-20T06:00:59Z revid 888603999 at 2019-03-20T06:00:59Z revid 888604000 at 2019-03-20T06:01:00Z Only 45 minutes later, the gap is already over 2000 revsions: [ariel@bigtrouble wikidata-huge]$ python3 ./compare_sizes.py Last enwiki revid is 888606979 and last wikidata revid is 888629401 2019-03-20 06:46:03: diff is 22422 Have a nice day! Ariel [1] https://twitter.com/MonsieurAZ/status/1106565116508729345

2 1

Small change to wmf apache log format
by Alexandros Kosiaris 20 Mar '19

20 Mar '19

In light of the gerrit incidents these last few days, and as part of the process of strengthening gerrit's operational security, we 've just gone ahead and configured gerrit to add the User: HTTP header on the response. To take advantage of that, we 've also amended the wmf apache LogFormat directive to log that header if it exists. I 've documented the change in https://wikitech.wikimedia.org/wiki/Apache_log_format. Note that the order of fields changes just a bit (the last field is now 17 instead of 16, the 16th is now the User: HTTP header if it exists, otherwise a -). If you are aware of anything that might break because of that let us know. Regards, -- Alexandros Kosiaris Senior Site Reliability Engineer Wikimedia Foundation

1 0

Improving the mediawiki.org frontpage: Part 3 (Layout)
by Andre Klapper 19 Mar '19

19 Mar '19

Hi, this is a follow-up email to the 'Audiences' and 'Content' parts in https://lists.wikimedia.org/pipermail/wikitech-l/2018-September/090886.html https://lists.wikimedia.org/pipermail/wikitech-l/2018-December/091213.html Now that the content is defined, the next step for the next two weeks is to sort out the layout. An initial proposal can be found in https://www.mediawiki.org/wiki/MediaWiki/Homepage_improvements_2018#Layout_… Please take a look at the link above and let's discuss on https://www.mediawiki.org/wiki/Talk:MediaWiki/Homepage_improvements_2018 Thanks in advance for your thoughts and input. andre -- Andre Klapper | Bugwrangler / Developer Advocate https://blogs.gnome.org/aklapper/

1 0

Need Help To Spell4Wiki - Wiktionary Audio App
by Manimaran_K 19 Mar '19

19 Mar '19

Hello all, I am Manimaran. I am Free Software Activist and also android developer. I try to make app for contributing Wiktionary. Which help to record audio then upload to commons. I share my efforts to my blog. I face some problem on development. Any one can help me. *Blog* : https://manimaran96.wordpress.com/2019/01/06/spell4wiki-mobile-app-to-recor… *Source code* : https://github.com/manimaran96/Spell4Wiki *APK file* : https://github.com/manimaran96/Spell4Wiki/blob/master/apk_file/spell4wiki_1… *Issue* - When Uploading audio I got an error message* -> *{“error”:{“code”:”permissiondenied”,”info”:”The action you have requested is limited to users in one of the groups: [[Wikipedia:Autoconfirmed users|Autoconfirmed users]], [[Wikipedia:Administrators|Administrators]], [[Wikipedia:User access levels#Confirmed|Confirmed users]].”,”*”:”See https://en.wikipedia.org/w/api.phpfor API usage. Subscribe to the mediawiki-api-announce mailing list at < https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.”},”servedby”:”mw1226″} - But My User name is confirmed via mail. Also Have permission to upload. Then I don’t know why comes this type of issue. - Also trying with other wikipedians username same error comes all of them.

2 2

Gerrit Vandalism
by Jay prakash 19 Mar '19

19 Mar '19

Hi please stop User Mill on Gerrit. He/She vandalised my and my Tech's patches. User:Jayprakash12345

8 8

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

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