[00:01:40] Sads. SecureLinkFixer is breaking all the parser tests when i try and run them locally [00:01:49] It'd be cool if that was more isolated [00:08:16] bawolff: would you agree checking all extension.json and check against the api to get the corresponding git commits and update the versions? [00:15:31] biberao: agree that it does what? [00:20:34] bawolff: let me try to rephrase [00:21:01] i mean i can use the extensions i find to compare with the ones in the api and update with the commit [00:22:49] If you mean comparing the version from a local api with the local extension.json, I'm not sure what that will accomplish, as it will be both the same data [00:23:45] bawolff: no like [00:23:48] for new commits [00:23:54] like i get the version [00:24:02] compare if theres a new one [00:25:12] It depends on what you are trying to accomplish [00:25:47] e.g. you might want to compare if its say the latest revision in REL1_XX and not the latest revision in master, or something like that [00:27:47] bawolff: how [00:28:48] ? [00:29:19] bawolff: maybe i didnt understand [00:31:16] "https://www.mediawiki.org/w/api.php?action=query&list=extdistbranches&edbexts=Bootstrap&format=json" < its not an extension like AbuseFilter [00:31:18] ? [00:31:56] I'm not sure i understand what you're asking [00:49:44] biberao: if you installed the extensions from git, you should compare with whatever branch you pulled it from [00:50:48] for instance, I have: [00:51:04] Platonides: yes thats what i meant to say [00:51:08] find extensions -name .git -execdir git checkout -q $BRANCH \; [00:51:09] find extensions -name .git -execdir git pull -q \; [00:51:10] commits and teh branch [00:51:25] thanks [00:51:35] i didnt understand properly what bawolff meant [00:51:54] (and then, you find vector extension with a submodule which is not kept up-to-date in the parent repo :/) [00:52:47] if you have e.g. MediaWiki 1.35.*, you should use both core and extensions from a branch named REL1_35 [00:53:24] Platonides: so it will be a mess? [00:53:51] using an extension from the master branch will often work with an older mediawiki, but it might not [00:54:23] biberao: not really, vector may be the only extension we have that using a submodule [00:54:58] i see [00:55:32] also note, nowadays skins are separate as well [00:55:36] There's definitely more than vector using submodules [00:55:43] VisualEditor has submodules [00:55:50] hmm [00:56:09] * bawolff just discovered that today when i couldn't figure out for the life of me why VE wasn't working locally [00:56:42] And then there is wikibase, but i guess nobody is really surprised by that [00:57:18] it really was VisualEditor (extensions/VisualEditor/lib/ve), not vector [00:57:25] sorry about that [00:59:47] I think most everything else just uses composer dependencies for the same purpose as submodules [01:02:40] https://phabricator.wikimedia.org/T298444 [06:49:47] Izno[m]: I'm testing locally and created a wrapper template for my module and it works. However, if I pass {{PAGELANGUAGE}} or {{#translation:}} through the template to the module, they are empty [06:50:31] so if this is the template content: {{#invoke:Calc_fn_name|main|{{{1|}}}|{{#translation:}}}} [06:50:58] and template is called like {{Calc_fn_name|IF}} [06:51:33] I honestly don't know how the magic words work [06:51:50] it was a hope of mine that it would work the way I wanted 🙂 [06:52:52] Ok :) Then I can just use the more verbose template call, but it is still shorter than the full module invocation, so I'm happy! [06:53:55] (I'll subscribe to the feature request you referred to) [07:23:32] Now I'm trying the wrapper template in action, but when used in a table cell, it messes up the row. What used to be =ABS(234.5) in the first cell is now = followed by a line break and: ABS(234.5) || Absolute value of 234.5 || 234.5 [07:24:04] row is: | ={{Calc_fn_name|ABS|{{PAGELANGUAGE}}}}({{formatnum:234.5}}) || Absolute value of 234.5 || {{formatnum:234.5}} [07:24:28] (just looking at preview at the moment) [07:33:03] page is https://wiki.documentfoundation.org/Documentation/Calc_Functions/ABS (I didn't save the changes yet) [08:01:55] buovjaga, you have whitespace in your wrapper template. Commonly it's between the end of the substantive content and the `` that comes with the documentation. In this case, it comes before, with the ws between the includeonly and the next line. [08:02:20] Basically, this kind of whitespace gets treated as significant by the parser. [08:02:45] oof, thanks [08:03:15] I'm sure I've tripped up on that before, but I create templates so rarely I forget [08:03:45] Yeah, it's a common trip up [08:04:42] I think Parsoid, the next gen parser, is supposed to fix that particular one, but I also know they're going to use the old preprocessor to start, which might be where the problem is. I cba to hunt down the relatively ancient task on it right now. [17:51:16] I had some problem with 'composer update --no-dev' with my old style of moving the vendor-folder away and then recreating. I could run backups and take snapshots and have another go at upgrading these 9 wikis [18:34:48] i ve set $wgFileExtensions with all the extensions i want to be able to upload which include xls and gpx. However... File extension ".xls" does not match the detected MIME type of the file (text/plain). [18:34:54] what am i missing here [18:35:13] Permitted file types: bmp, doc, docx, flac, gif, ico, jpeg, jpg, mp3, mpp, odg, odp, ods, odt, ogg, pdf, png, ppt, pptx, ps, rtf, svg, swf, tif, tiff, xls, xlsx, xml, gpx [19:09:14] !wg VerifyMimeType | curmudgeon [19:09:14] curmudgeon: https://www.mediawiki.org/wiki/Manual:%24wgVerifyMimeType [20:03:26] that looks like a workaround. if i disable the verification, other problems can rise from that. [20:05:01] I mean, we just don't suggest uploading xls ;) [23:19:41] Hi there, we are struggling a bit with Gerrit. Would anyone be able to take a look at the following PR? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/726595 [23:22:06] from what I can see, you're not struggling with gerrit, you're struggling with the ages old question of "how do I get people to review my code?" (which, as it turns out, can sometimes be an utter pain in the ass if you're not on the WMF's or a regional chapter's payroll :-/) [23:23:52] Hmm, that's a bit patch [23:23:57] *big [23:24:31] ashley: Hmm, probably? [23:24:39] Do you know how it would be best to approach this? [23:24:45] and LanguageConverter isn't exactly the most popular and well-understood thing in core :D [23:24:53] I could give it a +2 and we could see in due time what breaks ;) [23:25:06] I like that idea. [23:25:16] cscott is usually the lang converter person [23:25:24] Who was it that used to have the slogan "move fast, break things" ... [23:25:31] facebook :P [23:25:42] Well, we don't wanna be like Facebook. [23:25:46] I think they moved quickly to virtual reality and broke their business ;) [23:25:49] Maybe we can make an exception this time :p [23:26:22] I literally had that same talk with a colleague yesterday. Gonna be interesting to see if they remove Mark as CEO ... [23:27:21] Umm, hmm, does directly editing languages/i18n/sh.json make the translatewiki people mad? [23:27:26] Honest question, im not sure [23:28:06] I'm going to try out the patch and test it out [23:28:57] pretty sure it does [23:29:01] I would appreciate that. [23:29:18] good catch bawolff, it probably does (frankly after all these years, I'm *still* not sure why it's so hard to implement proper merge support, so that i18n files could be editable on repo as well...) [23:30:45] So. What would be best to do from here in order to have the patch approved and merged? [23:31:11] * bawolff just happy that this is latin vs cyrillic and not chinese or arabic. Its so much easier to test languages where i can the letters apart. [23:31:41] 🙃 [23:32:24] deni49: so far, I think the new translations should be removed from languages/i18n/sh.json - its better to only add en and qqq, and add any new stuff to sh.json on translatwiki [23:33:25] editing the translation files directly is generally discouraged, as it requires coordination with the TWN folks to make sure everything works [23:33:56] Gotcha. Since I am new to this, how to go about doing this on translatewiki instead? [23:34:36] lol, that's a good question. I just assume translatewiki is magic :) [23:35:07] to give a serious answer, after the patch is merged, you can create an account on translatewiki, and it has an interface where you can edit translations for that language [23:35:21] * bawolff has not actually ever translated anything on translatewiki [23:35:34] you'll need an account there and it's gotta have translator rights, and then you should be able to create/edit e.g. https://translatewiki.net/wiki/MediaWiki:Variantname-sh/sh [23:36:19] Cool. So "languages/i18n/sh.json" should be deleted? Anything else? [23:36:27] bawolff: I still think the whole "non-en/qqq files are effectively uneditable on repo" limitation is annoying and hindering and some of us just prefer the raw source instead of a fancy editor with all the JS bells and whistles [23:36:43] just three three additions to that file need to be undone [23:37:20] That's the only thing that sticks out so far. Let me test it and get back to you [23:38:04] I mean, i also don't know if there is complicated politics around this only being one-way (e.g. sh-latn -> sh-cryl), as if we're favouring one of the variants [23:38:30] But if nobody has objected on those grounds, I'm going to assume that's ok [23:38:58] My understanding is that that is the consensus of the community. [23:43:01] Okay, I have no clue how to remove the change from sh.json. Upon trying to edit it I get "Bad Gateway". The guy who is the main force behind this just went to sleep. [23:43:42] Its generally easier to edit with command line git tools. The gerrit web interface really sucks [23:45:10] I'll have to look into setting that up then. [23:45:25] Thanks for looking at testing this. When do you think you will know more? [23:46:45] Probably about 10 minutes [23:47:07] 🙏