[Wikitech-l] Mobile browser support matrix revision

[Stephen Niedzielski]

Hello!

I noticed that the mobile browser compatibility matrix[0] is a little
dated (last revised March 2017). I don't know how we formally decide to
update it so I'd like to propose the following version bumps given the
last year's metrics cited on wiki[1-2]:

- iOS: modern 8 -> 11; basic 7 -> 9
- Android: modern 4 -> 6; basic: 2 -> 4
- Windows: basic 8 -> (remove OS column)
- Blackberry: basic * -> (remove OS column--it's unclear if star means
  all or none)

Additionally, I propose the following changes:

- Replace "Basic" terminology in the OS table with "Basic (Grade C)"
  for clarity
- Drop "unknown" rows from OS and browser tables as there is no unknown
  column for OS or browser, which is inconsistent, and they're also
  unused

Some of these changes are a little bolder than usual but would help
focus development, design, testing configuration, and the conversation
towards the future. I sincerely apologize if I've offended anyone.

Stephen

[0] https://www.mediawiki.org/wiki/Special:MyLanguage/Compatibility#Mobile
[1]
https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-os/os-family-and-major-tabular-view
[2] https://analytics.wikimedia.org/dashboards/browsers/#mobile-site-by-os
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Github: WMFGerrit closing pull requests

[Tyler Cipriani]

tl;dr: If your team doesn't do any development on GitHub then this email 
likely doesn't affect you.


As you may or may not know there is now a read-only replica of Gerrit 
available at https://gerrit-replica.wikimedia.org/ (hooray); however, 
over the weekend we noticed some missing tags from that mirror (boo).


To fix the missing tags for the replica I forced replication to run for 
all repos in Gerrit today as part of a configuration restart. After a 
replication sync I was able to ensure that all repos on the new replica 
were now up-to-date; however, it also closed all the pull requests that 
were made via pushing branches to wikimedia-org GitHub repos (which is 
the work flow of several apps teams and possibly others).


Apologies for the inconvenience and thanks to Dmitry Brant and Joe 
Walsh for pinging me about the problem.


I've since removed GitHub as a "mirror" -- meaning Gerrit will not 
delete branches there. Paladox has filed a task upstream to allow us to 
specify a full replication for a particular remote (i.e., gerrit-replica 
but not GitHub) instead of all remotes[0], and for added suspenders for 
our belt I've made a patch set that should exclude these projects from 
replicating to from Gerrit to GitHub in the future[1].


I think all of the fallout of this change is taken care of (judging from 
my GitHub search): 



But if your project was affected, please either reach out to me or add 
your project to the GitHub exclusion list in Puppet like in my 
patchset[1] and add me as a reviewer.


Thanks and sorry
-- Tyler

[0]. 
[1]. 


signature.asc
Description: PGP signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Discovery Weekly Update for the week starting 2019-07-15

[Chris Koerner]

Hello,
This is the weekly update from the Search Platform team for the week
starting 2019-07-15.

As always, feedback and questions are welcome.

== Discussions ==

=== Search ===
* Search of wikidata string property values using haswbstatement is
case sensitive - after a bit of discussion, we added a patch for
adding a case-insenstitive subfield for statement field [0], and
re-indexing happened (with a minor issue) to get it into production
[1]
* Implemented support for haslabel:* [2]
* We received a request to delete search indices for now-deleted
zerowiki from production and did the needful [3]
* Glent work: create oozie workflow for glent m0 prep has been finished [4]
* The team did some work with the Multimedia team to index captions as
description fields not label [5]
* David worked on adapting IndexLookupFallbackMethod for glent requirements [6]
* The team worked on evaluating DYM metrics that are available in
current search satisfaction logging [7] with a follow up in [8]
** Metrics we should use moving forward
*** % of search shown a [auto / non-auto] dym
 Target: Increase % without significantly reducing the other metrics
*** % of people shown non-auto dym that click through to dym results
 Target: Increase % of clickthrough
*** % of searches shown dym search results [auto / non-auto] dym
results that clicked a result
 Target: Increase % of clickthrough
* There was a bug where there was an unexpected result set returned by
Elasticsearch [9], we went ahead and closed it because it looks like
the same root cause is fixed in [10]
* CirrusSearch will now provide a query dispatcher (once the train
finishes week of July 30) [11]
* We did a spike: load search data into turnilo to test whether
exploratory data can do away with some of the dashboards and decided
that with respect to our 'did you mean' suggestions and this seems
like a plausible path forward [12]
* WikibaseLexemeCirrusSearch started to fail for no particular reason
(seems to be due to missing class exported by WikibaseLexeme) and will
be fixed in this week's train (July 30) [13]

=== Wikidata Query Service ===
* Finished reindexing database [14] which fixes resource problems with WDQS [15]
* Wikidata RDF dumps no longer have BETA marker [16]
* Fixed continuation support for MWAPI in WDQS [17]
* Implemented support for wdtn: prefix for WDQS GUI [18]
* Fixed incorrect VIAF URIs in WDQS data [19]
* Implemented support for ChronologyProtection in WDQS Updater [20]
* Refactored label service to support more complex queries [21]

=== Portal ===
* The weekly update to the wikipedia.org portal had been failing for a
few weeks, Hashar helped out and fixed it, thanks! [22], but we still
have another ticket to be fixed [23]


[0] https://phabricator.wikimedia.org/T206613
[1] https://phabricator.wikimedia.org/T227136
[2] https://phabricator.wikimedia.org/T224611
[3] https://phabricator.wikimedia.org/T227718
[4] https://phabricator.wikimedia.org/T216783
[5] https://phabricator.wikimedia.org/T226722
[6] https://phabricator.wikimedia.org/T227262
[7] https://phabricator.wikimedia.org/T228226
[8] https://phabricator.wikimedia.org/T216058
[9] https://phabricator.wikimedia.org/T220637
[10] https://phabricator.wikimedia.org/T228063
[11] https://phabricator.wikimedia.org/T216429
[12] https://phabricator.wikimedia.org/T216058
[13] https://phabricator.wikimedia.org/T229215
[14] https://phabricator.wikimedia.org/T228122
[15] https://phabricator.wikimedia.org/T213210
[16] https://phabricator.wikimedia.org/T226153
[17] https://phabricator.wikimedia.org/T209034
[18] https://phabricator.wikimedia.org/T205777
[19] https://phabricator.wikimedia.org/T218522
[20] https://phabricator.wikimedia.org/T212550
[21] https://phabricator.wikimedia.org/T175840
[22] https://phabricator.wikimedia.org/T228639
[23] https://phabricator.wikimedia.org/T213806



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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] For title normalization, what characters are converted to uppercase ?

[bawolff]

Apparently that will change in php7.3, which we will move to eventually but
probably not anytime soon: https://3v4l.org/W7TiC

--
bawolff
On Mon, Aug 5, 2019 at 12:32 PM Nicolas Vervelle 
wrote:

> Last question (I believe) :
> I've implemented something similar as Php72ToUpper in WPCleaner, and it
> seems to work fine for removing false positives.
> I've only one left on frwiki : ⅷ
> .
> My code still converts it to uppercase, but on frwiki there is one page for
> the lowercase letter, and one page for the uppercase letter, so this letter
> is not converted to uppercase by current MediaWiki version.
> Is it missing in Php72ToUpper to prevent it to be converted with PHP 7.2 ?
>
> Nico
>
> On Mon, Aug 5, 2019 at 8:45 AM Nicolas Vervelle 
> wrote:
>
> > Thanks Giuseppe !
> >
> > I've subscribed to T219279 to know when the pages are properly converted,
> > and when I can remove the hack in my code.
> >
> > Nico
> >
> > On Mon, Aug 5, 2019 at 7:03 AM Giuseppe Lavagetto <
> > glavage...@wikimedia.org> wrote:
> >
> >> On Sun, Aug 4, 2019 at 11:34 AM Nicolas Vervelle 
> >> wrote:
> >>
> >> > Thanks Brian,
> >> >
> >> > Great for the link to Php72ToUpper.php !
> >> > I think I understand with it : for example, the first line says 'ƀ' =>
> >> 'ƀ',
> >> > which should mean that this letter shouldn't be converted to uppercase
> >> by
> >> > MW ?
> >> > That's one of the letter I found that wasn't converted to uppercase
> and
> >> > that was generating a false positive in my code : so it's because
> >> specific
> >> > MW code is preventing the conversion :-)
> >> >
> >>
> >> Hi!
> >>
> >> No, that file is a temporary measure during a transition between two
> >> versions of php.
> >>
> >> In HHVM and PHP 5.x, calling mb_toupper("ƀ") would give the erroneous
> >> result "ƀ".
> >>
> >> In PHP 7.x, the result is the correct capitalization.
> >>
> >> The issue is that the titles of wiki articles get normalized, so under
> >> php7
> >> we would have
> >>
> >> ƀar => Ƀar
> >>
> >> which would prevent you from being able to reach the page.
> >>
> >> Once we're done with the transition and we go through the process of
> >> coverting the (several hundred) pages/users that have the wrong title
> >> normalization, we will remove that table, and obtain the correct
> >> behaviour.
> >>
> >> You just need to subscribe https://phabricator.wikimedia.org/T219279
> and
> >> wait for its resolution I think - most unicode horrors are fixed in
> recent
> >> versions of PHP, including the one you were citing.
> >>
> >> Cheers,
> >>
> >> Giuseppe
> >> --
> >> Giuseppe Lavagetto
> >> Principal Site Reliability Engineer, Wikimedia Foundation
> >> ___
> >> Wikitech-l mailing list
> >> Wikitech-l@lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] For title normalization, what characters are converted to uppercase ?

[Nicolas Vervelle]

Last question (I believe) :
I've implemented something similar as Php72ToUpper in WPCleaner, and it
seems to work fine for removing false positives.
I've only one left on frwiki : ⅷ
.
My code still converts it to uppercase, but on frwiki there is one page for
the lowercase letter, and one page for the uppercase letter, so this letter
is not converted to uppercase by current MediaWiki version.
Is it missing in Php72ToUpper to prevent it to be converted with PHP 7.2 ?

Nico

On Mon, Aug 5, 2019 at 8:45 AM Nicolas Vervelle  wrote:

> Thanks Giuseppe !
>
> I've subscribed to T219279 to know when the pages are properly converted,
> and when I can remove the hack in my code.
>
> Nico
>
> On Mon, Aug 5, 2019 at 7:03 AM Giuseppe Lavagetto <
> glavage...@wikimedia.org> wrote:
>
>> On Sun, Aug 4, 2019 at 11:34 AM Nicolas Vervelle 
>> wrote:
>>
>> > Thanks Brian,
>> >
>> > Great for the link to Php72ToUpper.php !
>> > I think I understand with it : for example, the first line says 'ƀ' =>
>> 'ƀ',
>> > which should mean that this letter shouldn't be converted to uppercase
>> by
>> > MW ?
>> > That's one of the letter I found that wasn't converted to uppercase and
>> > that was generating a false positive in my code : so it's because
>> specific
>> > MW code is preventing the conversion :-)
>> >
>>
>> Hi!
>>
>> No, that file is a temporary measure during a transition between two
>> versions of php.
>>
>> In HHVM and PHP 5.x, calling mb_toupper("ƀ") would give the erroneous
>> result "ƀ".
>>
>> In PHP 7.x, the result is the correct capitalization.
>>
>> The issue is that the titles of wiki articles get normalized, so under
>> php7
>> we would have
>>
>> ƀar => Ƀar
>>
>> which would prevent you from being able to reach the page.
>>
>> Once we're done with the transition and we go through the process of
>> coverting the (several hundred) pages/users that have the wrong title
>> normalization, we will remove that table, and obtain the correct
>> behaviour.
>>
>> You just need to subscribe https://phabricator.wikimedia.org/T219279 and
>> wait for its resolution I think - most unicode horrors are fixed in recent
>> versions of PHP, including the one you were citing.
>>
>> Cheers,
>>
>> Giuseppe
>> --
>> Giuseppe Lavagetto
>> Principal Site Reliability Engineer, Wikimedia Foundation
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Category aliasing proposals

[Adam Wight]

Friends,

As part of an investigation into category aliasing (think “theater
directors” vs. “theater directors"), we’ve identified two potential
technical implementations and I’m hoping to get feedback to help us choose
between the proposals, or change course entirely.

For a summary of the problem and solutions, please see
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Gendered_Categories
and join the talk page if you wish.

Some questions on my mind are:
* Will the proposed hard-redirect category behavior break any MediaWiki or
third-party software assumptions about hard redirects or categories?
* Is “non-page” category aliasing really the mountain of tech debt I
imagine it to be?
* Have there been other attempts to solve this problem?

Kind regards,
Adam
from the Technical Wishes Team at Wikimedia Germany
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Upcoming Search Platform Office Hours—August 7th

[Trey Jones]

Sorry for the previous incorrect subject line! Search Platform Office Hours
will be on Wednesday, as usual, and not today.

—Trey

On Wed, Jul 31, 2019 at 12:36 PM Trey Jones  wrote:

> The Search Platform Team
>  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, Aug 7th, 2019
>
> Time: 15:00-16:00 GMT / 08:00-9: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
>
>
> *N.B.:* Google Meet System Requirements
> 
>
>
> Hope to talk to you in a week!
>
> Trey Jones
> Sr. Software Engineer, Search Platform
> Wikimedia Foundation
> UTC-4 / EDT
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Extension:OATHAuth - breaking changes!

[Robert Vogel]

Hello everybody!

The extension "OATHAuth" has been refactored recently. As a dedicated
PHP namespace has been introduced for that extension, all full
qualified class names have changed.

It has been noticed that some external code relies on class names
(T228588 [1]) of that extension.

All classes are now in `MediaWiki\Extension\OATHAuth` namespace.

Most notably the former `TOTPAuthenticationRequest` is now called
`MediaWiki\Extension\OATHAuth\Auth\TOTPAuthenticationRequest`.

Also in `extension.json` 
`AuthManagerAutoConfig.secondaryauth.TOTPSecondaryAuthenticationProvider` has 
changed to
`AuthManagerAutoConfig.secondaryauth.OATHSecondaryAuthenticationProvider`.

If your code relies in any way on the internal structure of
`Extension:OATHAuth`, please check if it still works.

### The public Action API does not have breaking changes! ###

[1] https://phabricator.wikimedia.org/T228588

-- 
Robert Vogel
Teamlead Produkt- & Softwareentwicklung
 
Hallo Welt! GmbH
Postfach 11 02 09
93015 Regensburg
Germany
 
Telefon: +49 (0) 941 - 660 80-0
Fax: +49 (0) 941 - 660 80-189
 
hallowelt.com
vo...@hallowelt.com
 
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl
 
Besuchen Sie unsere aktuellen BlueSpice-Webinare:
https://de.bluespice.com/webinar
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] For title normalization, what characters are converted to uppercase ?

[Nicolas Vervelle]

Thanks Giuseppe !

I've subscribed to T219279 to know when the pages are properly converted,
and when I can remove the hack in my code.

Nico

On Mon, Aug 5, 2019 at 7:03 AM Giuseppe Lavagetto 
wrote:

> On Sun, Aug 4, 2019 at 11:34 AM Nicolas Vervelle 
> wrote:
>
> > Thanks Brian,
> >
> > Great for the link to Php72ToUpper.php !
> > I think I understand with it : for example, the first line says 'ƀ' =>
> 'ƀ',
> > which should mean that this letter shouldn't be converted to uppercase by
> > MW ?
> > That's one of the letter I found that wasn't converted to uppercase and
> > that was generating a false positive in my code : so it's because
> specific
> > MW code is preventing the conversion :-)
> >
>
> Hi!
>
> No, that file is a temporary measure during a transition between two
> versions of php.
>
> In HHVM and PHP 5.x, calling mb_toupper("ƀ") would give the erroneous
> result "ƀ".
>
> In PHP 7.x, the result is the correct capitalization.
>
> The issue is that the titles of wiki articles get normalized, so under php7
> we would have
>
> ƀar => Ƀar
>
> which would prevent you from being able to reach the page.
>
> Once we're done with the transition and we go through the process of
> coverting the (several hundred) pages/users that have the wrong title
> normalization, we will remove that table, and obtain the correct behaviour.
>
> You just need to subscribe https://phabricator.wikimedia.org/T219279 and
> wait for its resolution I think - most unicode horrors are fixed in recent
> versions of PHP, including the one you were citing.
>
> Cheers,
>
> Giuseppe
> --
> Giuseppe Lavagetto
> Principal Site Reliability Engineer, Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l