socksfinder now runs on Kubernetes.

No worries, it was in my plans to migrate at some point. Plus I'll be facilitating a workshop on Toolforge and Kubernetes in late November, so that will provide me with a concrete use-case for illustration.

1. I'm a volunteer scripts, gadgets, bots and tools developer at frwiki and wikidata, and I do some occasional training for Scribunto beginners, even though I'm not very active in modules development.
2. I have to say that, having done this stuff since 2009, I'm really happy with how things are improving from a third-party developer's perspective. That being said, there are significant remaining pain points, including:
   • a lack of relevant metrics about who uses what and what depends on what;
   • a lack of attention from upstream to the tools people actually use — which itself is the result of the previous pain point — resulting in these tools being regularly broken with nobody to fix them (this is getting better, but there's room for improvement);
   • the inability to efficiently share and localize code across wikis;
   • the frequent low bus factor or absence of proper maintainership for tools people actually use, which sometimes could be solved by resolving the previous pain point;
   • the frequent diverging forks or competing implementations of highly valuable tools, which could be avoided by solving the same sharing problem;
   • the completely inappropriate tooling for developing tools (scripts, gadgets, templates, modules…) on MediaWiki: it's widely recognized that software development highly benefits from using version control systems with branchs (eg. git), code review (eg. gerrit, pull requests), test suites, proper tagging and release systems, etc., yet most of the development done outside of the core of MediaWiki has none of these. I'm not calling for more custom-tailored tools within MediaWiki, but for more integration with existing tools, so that developers can use their tools of choice (which they are productive with and which improve without any cost for Wikimedia).

To be honest, I can't remember why I'd be admin of this project; I don't even see what it does… I see I've received a few mails about it since the end of 2018 but never really paid attention to them…

Sounds very cool, thanks!

In T30856#4702333, @Trizek-WMF wrote:

I've made the change.

In T30856#4702196, @Trizek-WMF wrote:

Don't you think it would be safer to suggest to create a link that would link directly to the ressource on fr?
mw.loader.load("//fr.wikipedia.org/w/index.php?title=MediaWiki:Gadget-mediawiki.toolbar.js
That solution would ease overall maintenance and avoid code depreciation, no?

Hi everyone,

Thanks @Krenair !

In T30856#4691858, @Jdforrester-WMF wrote:

In T30856#4691074, @Arkanosis wrote:

@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?

Yes, sorry, you have one week to test.

@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?

@Whatamidoing-WMF : Hi! I've been willing to test the upcoming deployment to make sure that the gadgets currently used by many on the French Wikipedia still work if the classic edit toolbar is disabled. So, following the information on the page you linked to from my user talk page, I went today to the English Wikipedia on the beta cluster which is currently running 1.33.0-alpha (26665a6). Unfortunately, it looks like the classic edit toolbar has not been disabled there, so I'm unable to test the gadgets from the French Wikipedia as planned.

In T30856#4539731, @Whatamidoing-WMF wrote:

http://wikitech.wikimedia.org/wiki/Server_switch ends on 10 October 2018. Maybe we could start this process the week after that? That would mean that it could go on the Beta Cluster on Tuesday, 16 October and deployed to the communities the following week (e.g., most Wikipedias on Thursday, 25 October).

In T30856#4499678, @Whatamidoing-WMF wrote:

@Arkanosis (and others), I think we're ready to talk about re-re-re-scheduling this. Do you have a preferred month (any time this calendar year)?

Other subjects of interest (in addition to JavaScript): Lua, MediaWiki (inc. PHP), bots (inc. Python)…

I'm afraid the current implementation of HDT is not ready to handle more than 4 billions triples as it is limited to 32 bit indexes. I've opened an issue upstream: https://github.com/rdfhdt/hdt-cpp/issues/135

In T179681#3736916, @Lucas_Werkmeister_WMDE wrote:

I ran the conversion directly from the ttl.gz file

Interesting, I couldn’t get that to work and had to pipe gunzip output into the program.

FWIW, I've just tried to convert the ttl dump of the 1st of November 2017 on a machine with 378 GiB of RAM and 0 GiB of swap and… well… it failed with std::bad_alloc after more than 21 hours of runtime. Granted, there was another process eating ~100 GiB of memory, but I thought it would be okay — so I'm proved wrong.

Sorry if it has been discussed in the past, but couldn't such issues be addressed by switching to a non-backtracking regex engine such as Google's RE2?

In T30856#3379890, @Whatamidoing-WMF wrote:

@Arkanosis : James and I have just agreed to postpone this for another month, until T162849 is completed. The plan is the same as discussed above at T30856#3341485, except at the end of August instead of at the end of July. If you are not available in late August, then we can wait for you.

In T30856#3361186, @matmarex wrote:

259 users on frwiki (the query took about 20 minutes), out of 23284 "active" (the query took about 5 minutes).

@Whatamidoing-WMF @Jdforrester-WMF : thank you. I don't understand why we don't wait for everything to be ready instead, but that should do it. That would be awesome if you could drop me an email once the beta cluster is ready, so that I don't miss the opportunity.

In T30856#3335563, @Trizek-WMF wrote:

I think there is a possible confusion between the ones (like me) who emulate the old 2006 toolbar and the others who actually use the 2006 editor.
How can we check who is using what?

Am I the only one to think these numbers don't add up? @Jdforrester-WMF: do you think it is possible for local scripts to break these metrics?

@Whatamidoing-WMF : I'm pretty confident most of them if not all are actually using the local gadget and neither the original toolbar nor another more recent one. There's some “tradition” of customizing this legacy toolbar on the French Wikipedia through one's common.js. Additionaly, no one changed their mind when shown the very useful page at https://www.mediawiki.org/wiki/Editor (though I'd admit it doesn't mean much).
What I don't know is how it'll break when the original toolbar it's more or less based on will disappear.

Hi everyone,

Marvelous ! Thank you! :-)

Wonderful. I know have a working training scenario :)

Just a quick note: the issue described in T93489 still applies to gerrit-test.wmflabs.org when cloning through HTTP, ie. git review -s doesn't work, you have to install the commit hook manually.

Hi @Paladox and thanks for the info.

I didn't know about the Gerrit testing instance. Thanks!

Hi @Danny_B and thanks for your kind reply.

Hi Trizek,

Fix applied. Thank you!

In T108811#1877912, @Arkanosis wrote:

I guess the “quick fix” for now is to replace the current

$notice = Html::inlineScript( Xml::encodeJsCall( 'document.write', array( $notice ) ) );

with something like

$notice = Html::inlineScript( Xml::encodeJsCall( '$('#content').prepend', array( $notice ) ) );

(not quite sure about how encodeJsCall works).

See here for the code.

In T108811#1877832, @Arkanosis wrote:

I've not experienced this issue with a fresh install of the 1.26 release with the DismissableSiteNotice extension I made last night.

I guess the “quick fix” for now is to replace the current

$notice = Html::inlineScript( Xml::encodeJsCall( 'document.write', array( $notice ) ) );

with something like

$notice = Html::inlineScript( Xml::encodeJsCall( '$('#content').prepend', array( $notice ) ) );

(not quite sure about how encodeJsCall works).

In T108811#1877883, @ashley wrote:

For what it's worth...years ago, in r41679, I merged DismissableSiteNotice into core. Skizzerz improved it substantially in the follow-up revisions (r41706, r41711), making it work properly for browsers with JavaScript disabled and everything; usage of document.writeln was also removed in this latter revision (instead of document.writeln the current version of DismissableSiteNotice uses document.write).
These improvements were lost when the core merge was reverted in r41958 by Tim Starling. Maybe now would be an appropriate time to salvage some of those improvements and ditch document.write altogether?

Hi everyone,

@Trizek: we probably have the same issue with a bunch of features (most of functions defined in that Common.js, I guess), so please let me know about anything similar you know is not working.

The code handling this template is the BoiteDeroulante function in MediaWiki:Common.js . It's only called on $( document ).ready(), hence the issue.

$ wget 'https://en.wikipedia.org/' -O -
--2015-10-26 16:20:00-- https://en.wikipedia.org/
Resolving en.wikipedia.org (en.wikipedia.org)... 2620:0:862:ed1a::1, 91.198.174.192
Connecting to en.wikipedia.org (en.wikipedia.org)|2620:0:862:ed1a::1|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://en.wikipedia.org/wiki/Main_Page [following]
--2015-10-26 16:20:00-- https://en.wikipedia.org/wiki/Main_Page
Reusing existing connection to [en.wikipedia.org]:443.
HTTP request sent, awaiting response... 500 Internal Server Error
2015-10-26 16:20:00 ERROR 500: Internal Server Error.

In T110185#1578109, @kaldari wrote:

@Arkanosis: As far as I can tell, it looks like refToolbar never actually worked on French Wikipedia. refToolbar assumes that template parameters do not include spaces (as they are reused as ids), but template parameters on French Wikipedia commonly do include spaces, which breaks refToolbar. Can you confirm whether or not refToolbar has always been broken?

I've seen anouncements on Wikitech-ambassadors about the document.write breaking change, but nothing about legacy gadgets which as far as the French Wikipedia is concerned breaks much more things.

Hi @Dereckson, hi everyone,

In T539#1030505, @Krenair wrote:

In T539#1030241, @Edokter wrote:

In T539#1029945, @Ricordisamoa wrote:

...and enwiki should load it dynamically.

Please define 'dynamically'. If you mean load it raw from MediaWiki, I think that is a bad idea. How long before we have global gadgets?

Why is that a bad idea? Long enough.

In T539#22469, @Mattflaschen wrote:

@Arkanosis are you still working on this? If not, I may take it.

In T539#10638, @Qgil wrote:

In T539#8125, @Arkanosis wrote:

For me that's a missing feature.

This feature should probably be discussed upstream, though.

I wonder if we're really talking about the same tokens (CSRF vs auth)… But maybe phabricator uses auth token as CSRF tokens. Anyway, the result is the same:

In T539#8120, @chasemp wrote:

If you want to hit phab w/ a bot it comes w/ some responsibilities as well as power.

In T539#8118, @Arkanosis wrote:

we want the end-user […] to get publicly available information about tasks (summary, state…)

I understand the need of a token for state-changing requests, not for read-only requests. Here, we want the end-user (who certainly wont always have an account, let alone a bot account) to get publicly available information about tasks (summary, state…).

In T539#8038, @chasemp wrote:

maniphest.query has the ability to query multiple id's: