Re: [Wikitech-l] [Commons-l] Sunsetting VP8 version of WebM for video playback

[Brion Vibber]

On Mon, Feb 4, 2019, 2:26 PM Gergo Tisza  On Mon, Jan 28, 2019 at 12:22 PM Brion Vibber via Commons-l <
> common...@lists.wikimedia.org> wrote:
>
>> IE 11 users will receive low-resolution, slow JavaScript-based video
>> playback instead. If you find this is troublesome, the recommended solution
>> is to switch to any other browser.
>>
>
> Will they get a warning that they should try another browser? This seems
> like a sensible limitation, as long as the user has a chance of figuring
> out why they are being limited.
>

Yeah, I could have it detect sub-par JS playback performance and display an
explanation in an overlay recommending a more modern browser. Will file a
task to improve this experience...

-- brion

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

Re: [Wikitech-l] The mw.ext construct in lua modules

[John Erling Blad]

Those that break the naming scheme *somehow* is 7 extensions
(ArticlePlaceholder (mixed case), DynamicPageListEngine (not extension
name), JsonConfig (not extension name), LinkedWiki (not ext
structure), SemanticScribunto (not extension name), Wikibase Client
(not ext structure), ZeroPortal (not ext structure)) of a total of 17.
I have not counted two of my own that will not follow this scheme, and
Capiunto which use require. I have neither included TemplateData.

That is; the naming scheme is followed by approx 40% of the extensions.

There are probably some lua-libs I haven't found.

-- list --
# ArticlePlaceholder
mw.ext.articlePlaceholder

# TitleBlacklist
mw.ext.TitleBlacklist (Only a single method)

# BootstrapCompoinents
mw.bootstrap.*

# Capiunto
Doc says mw.capiunto, but this seems wrong

# Cargo
mw.ext.cargo

# DataTable2
mw.ext.datatable2

# DisplayTitle
mw.ext.displaytitle

# DynamicPageListEngine
mw.ext.dpl

# FlaggedRevs
mw.ext.FlaggedRevs

# Inference
Under development.

# JsonConfig
mw.ext.data.get

# LinkedWiki
mw.linkedwiki

# ParserFunctions
mw.ext.ParserFunctions (Only a single method)

# Pickle
Under development. Uses another loader.

# SemanticScribunto
mw.smw

# TimeConvert
mw.ext.timeconvert

# TitleBlacklist
mw.ext.TitleBlacklist

# VariablesLua
mw.ext.VariablesLua

# Wikibase Client
mw.wikibase

# ZeroPortal
mw.zeroportal

On Tue, Feb 5, 2019 at 5:50 PM Brad Jorsch (Anomie)
 wrote:
>
> On Mon, Feb 4, 2019 at 5:26 PM Eran Rosenthal  wrote:
>
> > > What is the problem with the ".ext" part?
> > 1. It adds unnecessary complexity both in the extension (need to init
> > mw.ext if it doesn't exist)
>
>
> It's one line in the boilerplate. That's not much complexity.
>
>
> > and more important - in its usage when the Lua
> > extension is invoked (longer names)
> >
>
> It's 4 characters. Also not much to be concerned about. You're also free to
> do like
>
> local foo = mw.ext.foo;
>
> if you want shorter access within your code.
>
>
> >(there is very small risk of name collision -  mw.ModuleA and mw.ModuleB
> > are unlikely to clash as different extensions, and mw.ModuleA and mw.FUNC
> > are unlikely to clash because function names
> > <
> > https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Base_functions
> > >
> > are usually verbs and extensions
> >  are usually
> > nouns)
> >
>
> Scribunto has its own built-in packages too, which are also usually nouns.
> What if, for example, Extension:Math
>  added a Scribunto module at
> "mw.math" and then we also wanted to add a Scribunto-specific version of Lua's
> math library
> ?
> Or Extension:CSS  and a
> Scribunto counterpart to mw.html
> ?
> Or if Extension:UserFunctions
>  did its thing at
> "mw.user" and then we got around to resolving T85419
> ?
>
> Having mw.ext also makes it easier to identify extensions' additions,
> avoiding confusion over whether "mw.foo" is part of Scribunto or comes from
> another extension. And it means you can look in mw.ext to see which
> extensions' additions are available rather than having to filter them out
> of mw.
>
> BTW, we have "mw" in the first place to similarly bundle Scribunto's
> additions away from things that come with standard Lua. If someday standard
> Lua includes its own "ustring" or something else Scribunto adds a module
> for (and we upgrade from Lua 5.1), we won't need to worry about name
> collision there either.
>
>
> > 2. Practically the convention is to not use mw.ext - the convention (based
> > on most of the Lua code - e.g wikibase) is to not use mw.ext
> >
>
> Of extensions in Gerrit (as of a few days ago when I last checked),
> Wikibase and LinkedWiki seem to be the only two extensions not using
> mw.ext, while Cargo, DataTable2, DisplayTitle, DynamicPageListEngine,
> FlaggedRevs, JsonConfig, ParserFunctions, and TitleBlacklist all do.
>
> --
> Brad Jorsch (Anomie)
> Senior Software 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] Upcoming Search Platform Office Hours—February 6th

[Trey Jones]

The Search Platform Team
 usually holds
office hours the first Wednesday of each month—that's tomorrow! Come ask us
anything about Wikimedia search!


We’re particularly interested in:

* Opportunities for collaboration—internally or externally to the Wikimedia
Foundation

* Challenges you have with on-wiki search, in any of the languages we
support


But we're happy to talk about anything search-related. Feel free to add
your items to the Etherpad Agenda for the next meeting.


Details for our next meeting:

Date: Wednesday, February 6th, 2018

Time: 16:00-17:00 GMT / 08:00-9:00 PST / 11:00-12:00 EST / 17:00-18:00 CET

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



Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [discovery] Discovery Weekly Update for the week starting 2019-01-21

[Trey Jones]

>
> * Trey also reviewed, updated and manually re-built the Hebmorph plugin
> for ElasticSearch 6 with help from the rest of the Search team [1]


Not quite! We have to give *David* all the credit for updating and
rebuilding the Hebmorph plugin. I just ran a regression test to make sure
nothing too weird happened when using the new version. (It was only
0.002%-0.003%
weirder than expected, which is acceptable.)

—Trey

Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation


On Mon, Feb 4, 2019 at 4:34 PM Chris Koerner  wrote:

> Hello,
> This is the weekly update from the Search Platform team for the week
> starting 2019-01-21 (acknowledging a little delay).
>
> As always, feedback and questions welcome.
>
> == Discussions ==
>
> === Search ===
>
> * Trey did a write up about his ideas for the wrong keyboard
> implementation and UI, and the new language models and parameter
> optimization for TextCat for the wrong-keyboard and wrong-encoding
> detection. [0]
> * Trey also reviewed, updated and manually re-built the Hebmorph
> plugin for ElasticSearch 6 with help from the rest of the Search team
> [1]
> * David double checked that chi to psi/omega indices are no longer
> used and delete them. [2]
> * David also worked on dropping the "archive" type in the general index [3]
> * David wrapped up on moving the phrase suggest related code to its
> FallbackMethod [4]
> * Erik worked on modifying Wikidata entity completion search for
> per-language tuning parameters [5]
> * Erik also worked on a bug where we didn't retain cross-cluster
> identifier in OtherIndexes [6]
> * Erik fulfilled a feature request to add chronological sorting
> by-page-creation-timestamp for search results [7]
> * David also upgraded the Elasticsearch plugins extra, extra-analysis
> and highlighter to elasticsearch 6.5.4 [8]
> * Stas is working on separating ElasticSearch parts of Wikibase into a
> separate extension [9]
>
> [0] [
> https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Implementation_Design_and_Parameter_Optimization_for_Wrong_Keyboard_Detection_and_Suggestion
> [1] https://phabricator.wikimedia.org/T214439
> [2] https://phabricator.wikimedia.org/T214052
> [3] https://phabricator.wikimedia.org/T200198
> [4] https://phabricator.wikimedia.org/T213098
> [5] https://phabricator.wikimedia.org/T213106
> [6] https://phabricator.wikimedia.org/T214050
> [7] https://phabricator.wikimedia.org/T195071
> [8] https://phabricator.wikimedia.org/T214312
> [9] https://phabricator.wikimedia.org/T190022
>
> 
>
> 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
>
> ___
> Discovery mailing list
> discov...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/discovery
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The mw.ext construct in lua modules

[Brad Jorsch (Anomie)]

On Mon, Feb 4, 2019 at 5:26 PM Eran Rosenthal  wrote:

> > What is the problem with the ".ext" part?
> 1. It adds unnecessary complexity both in the extension (need to init
> mw.ext if it doesn't exist)


It's one line in the boilerplate. That's not much complexity.


> and more important - in its usage when the Lua
> extension is invoked (longer names)
>

It's 4 characters. Also not much to be concerned about. You're also free to
do like

local foo = mw.ext.foo;

if you want shorter access within your code.


>(there is very small risk of name collision -  mw.ModuleA and mw.ModuleB
> are unlikely to clash as different extensions, and mw.ModuleA and mw.FUNC
> are unlikely to clash because function names
> <
> https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Base_functions
> >
> are usually verbs and extensions
>  are usually
> nouns)
>

Scribunto has its own built-in packages too, which are also usually nouns.
What if, for example, Extension:Math
 added a Scribunto module at
"mw.math" and then we also wanted to add a Scribunto-specific version of Lua's
math library
?
Or Extension:CSS  and a
Scribunto counterpart to mw.html
?
Or if Extension:UserFunctions
 did its thing at
"mw.user" and then we got around to resolving T85419
?

Having mw.ext also makes it easier to identify extensions' additions,
avoiding confusion over whether "mw.foo" is part of Scribunto or comes from
another extension. And it means you can look in mw.ext to see which
extensions' additions are available rather than having to filter them out
of mw.

BTW, we have "mw" in the first place to similarly bundle Scribunto's
additions away from things that come with standard Lua. If someday standard
Lua includes its own "ustring" or something else Scribunto adds a module
for (and we upgrade from Lua 5.1), we won't need to worry about name
collision there either.


> 2. Practically the convention is to not use mw.ext - the convention (based
> on most of the Lua code - e.g wikibase) is to not use mw.ext
>

Of extensions in Gerrit (as of a few days ago when I last checked),
Wikibase and LinkedWiki seem to be the only two extensions not using
mw.ext, while Cargo, DataTable2, DisplayTitle, DynamicPageListEngine,
FlaggedRevs, JsonConfig, ParserFunctions, and TitleBlacklist all do.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] What would you like to see in gerrit?

[Stephen Niedzielski]

> filtering out CI messages from Gerrit comments.
I use a hacky bookmarklet to hide jenkins-bot comments:

javascript:Array.from(document.querySelectorAll('[class*=messageBox]')).filter(box
=> box.querySelector('[class*=name]').textContent ===
'jenkins-bot').forEach(box => box.style.display = 'none')

I don't know if it works with PolyGerrit.

On Mon, Feb 4, 2019 at 6:44 PM Gergo Tisza  wrote:

> On Mon, Jan 28, 2019 at 4:26 PM Paladox via Wikitech-l <
> wikitech-l@lists.wikimedia.org> wrote:
>
> > Hi, what would you like to see in gerrit or improved?
>
>
> Thanks for all your work on Gerrit! Some things that IMO would be useful:
> * filtering out CI messages from Gerrit comments. This is something the
> next version of Gerrit supports (the "Only comments" checkbox), but I
> imagine something somewhere must be changed so that it can identify bots.
> * making it clearer when CI fails. Currently it's hard to visually
> differentiate failed tests from successful tests, and within failed test
> logs the exact reason for failure from all the other logs. I guess this is
> more of a Jenkins improvement...
> * I really miss the Github feature of selecting a line range (as opposed to
> a single line) from the gitiles plugin.
> * again not really a Gerrit change but our mechanism for linking Gerrit
> patches to related Phabricator tasks is rather crude. T95309 has some
> related discussion but a nice solution would probably not include
> comments/tags and use something more specialized like a custom Maniphest
> field type instead. Or maybe a frontend hack like Pherrit [1].
>
> [1]
>
> https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfgjoebij
> ___
> 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