[19:37:12] [telegram] Hm [19:37:22] [telegram] Video chat? [19:51:29] [telegram] Hello everyone, [19:51:30] [telegram] I am an Outreachy participant in Round 23 [1], working on a project to develop demo videos and toolkits to demonstrate the use of essential tools for smaller wiki communities: [2]. [19:51:31] [telegram] This Outreachy project is part of the larger Small wiki toolkits project to build technical capacity in smaller language wiki communities. More about the initiative: [3]. [19:51:33] [telegram] As part of the project, we are running a survey to gather information about the tools that you find most helpful for your work on the wikis that might benefit for video documentation for others. It will not take longer than 5 minutes to fill out this survey; your feedback will be super valuable for us! [telegram] This survey is conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data handling, see the survey privacy statement: [5]. [19:51:36] [telegram] Best, [19:51:37] [telegram] Alexandra [19:51:39] [telegram] [1] https://www.mediawiki.org/wiki/Outreachy/Round_23 [19:51:40] [telegram] [2] https://phabricator.wikimedia.org/T292135 [19:51:42] [telegram] [3] https://meta.wikimedia.org/wiki/Small_wiki_toolkits [19:51:43] [telegram] [4] https://docs.google.com/forms/d/e/1FAIpQLScQHjansDXfLBGWPNhGBpqWTrhRdAWc5tA2yH-ESOPsMxeZuQ/viewform [19:51:45] [telegram] [5] https://foundation.wikimedia.org/wiki/Popular_Tools_for_Wikipedia,_Wikidata_and_Commons_Survey_Privacy_Statement [20:34:24] [telegram] I got stuck on the first question. What is the difference between a "editor" and "content moderator"? (re @AlexandraShagzhina: Hello everyone, [20:34:25] [telegram] I am an Outreachy participant in Round 23 [1], working on a project to develop demo videos and toolkits to demonstrate the use of essential tools for smaller wiki communities: [2]. [20:34:27] [telegram] This Outreachy project is part of the larger Small wiki toolkits project to build technical capacity in smaller language wiki communities. More about the initiative: [3]. [20:34:28] [telegram] As part of the project, we are running a survey to gather information about the tools that you find most helpful for your work on the wikis that might benefit for video documentation for others. It will not take longer than 5 minutes to fill out this survey; your feedback will be super valuable for us! [4]. [20:34:30] [telegram] This survey is conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data handling, see the survey privacy statement: [5]. [20:34:31] [telegram] Best, [20:34:33] [telegram] Alexandra [20:34:34] [telegram] [1] https://www.mediawiki.org/wiki/Outreachy/Round_23 [20:34:36] [telegram] [2] https://phabricator.wikimedia.org/T292135 [20:34:37] [telegram] [3] https://meta.wikimedia.org/wiki/Small_wiki_toolkits [20:34:39] [telegram] [4] https://docs.google.com/forms/d/e/1FAIpQLScQHjansDXfLBGWPNhGBpqWTrhRdAWc5tA2yH-ESOPsMxeZuQ/viewform [20:34:40] [telegram] [5] https://foundation.wikimedia.org/wiki/Popular_Tools_for_Wikipedia,_Wikidata_and_Commons_Survey_Privacy_Statement) [21:01:35] The reply to a really long Telegram message looks a mess on the irc side of the wm-bb bridge. I'll look at upstream docs to see if there is some setting to limit how much of the original message is quoted by the response. [21:07:08] seems like there is a setting -- https://github.com/42wim/matterbridge/wiki/Settings#quotelengthlimit [21:10:02] [telegram] Nice [21:21:10] In theory quoted replies on the irc side of the bridge will now be limited to 128 chars of quotation now. [21:59:35] [telegram] this isn't limited to video-related tools, right? (because I think I misunderstood that the first time I read the message) (re @AlexandraShagzhina: Hello everyone, [21:59:36] [telegram] I am an Outreachy participant in Round 23 [1], working on a project to develop demo videos and toolkits to demo...) [21:59:48] [telegram] (did that reply look better on IRC? ^^) [22:01:03] https://usercontent.irccloud-cdn.com/file/wZjnFP8O/image.png [22:20:19] [telegram] different question: I just realized the action API can sometimes return JSON with numbers that are too big to be represented in JavaScript; is there a standard way to deal with that? [22:20:25] [telegram] example request: https://en.wikipedia.org/w/api.php?action=query&pageids=123456789123456789 [22:21:13] [telegram] JSON.parse(…).query.pages['123456789123456789'].pageid results in 123456789123456780 because the number doesn’t fit in a 64-bit float [22:21:55] [telegram] (admittedly, for page IDs, this isn’t going to be a problem for real pages in a long while ^^) [22:27:49] the answer is usually "just put it in a string" [22:28:03] don't know what mediawiki does, if anything [22:28:27] [telegram] well, MediaWiki doesn’t seem to be putting it into a string on its own [22:28:58] [telegram] I guess you could argue that it should, and then clients would have to worry less about the loss of precision [22:29:15] [telegram] (and instead start worrying about the API returning a mixture of numbers and strings depending on how large the number is…) [22:29:36] yeah, that seems worse than the large number edge case hoenstly [22:29:57] [telegram] Hmm : https://tools-static.wmflabs.org/bridgebot/4cf498e8/file_10040.jpg [22:30:44] [telegram] https://www.derpturkey.com/untitled/ suggests regex-replacing numbers with "$1" before passing the payload into JSON.parse(), but for MediaWiki responses that’s not really an option, they’ll already contain numbers inside strings plenty of times [22:31:38] php's json_decode has a JSON_BIGINT_AS_STRING flag for decoding, but I'm not seeing any fancy magic for encoding [22:31:45] [telegram] maybe I should use https://www.npmjs.com/package/json-bigint to parse the response 🤔 [22:31:52] [telegram] Is this incorrect, or we are really talking about page ids potentially running into quadrillions? (re @Thecladis: ) [22:32:28] rc_id or rev_id would probably get there first [22:32:39] [telegram] Even so [22:32:52] [telegram] That is probably not until 2300 or so [22:33:00] So far Lucas seems to have shown what I would actually call a reflection bug more than anything else. [22:33:51] [telegram] eh, at 123456789123456789 MediaWiki starts complaining that the params are invalid, so it’s not like you can make it emit entirely arbitrarily large numbers [22:33:56] [telegram] (or somewhere around that length) [22:34:43] [telegram] (1-91-91 is allowed, …12 is too much) [22:34:57] [telegram] Oh. A few hundred thousand years given 1 revision a second. Admittedly we can have tens of revisions per second, perhaps even hundreds, but still quite a safe cushion : https://tools-static.wmflabs.org/bridgebot/693e6822/file_10041.jpg [22:35:15] don't give wikidata any ideas [22:35:51] [telegram] Wel, guids should have even better cushion [22:36:21] [telegram] yeah, so far those IDs aren’t even bigints in the database https://phabricator.wikimedia.org/T63111 (re @Thecladis: Is this incorrect, or we are really talking about page ids potentially running into quadrillions?) [22:36:29] [telegram] pageids aren’t a good example :) [22:37:02] [telegram] I don’t know what other places the API emits numbers (without turnign them into strings) that could actually grow that much [22:38:42] I would think that once we start getting close to those kinds of large numbers standard libraries would begin to natively support them [22:39:05] [telegram] I'm more worried about the fact no one is maintaining and/or update the mediawiki [22:39:06] [telegram] gallery bugs [22:39:07] [telegram] inserted pictures bugs [22:39:09] [telegram] videos and other modern ways to show media not properly supported [22:39:10] [telegram] If this continues - sooner or later wikipedia, which uses the mediawiki will be outdated and replaced by something that actually is properly maintained (re @lucaswerkmeister: eh, at 123456789123456789 MediaWiki starts complaining that the params are invalid, so it’s not like you can make it emit entire...) [22:39:13] Because growing incremental numbers can't just be a problem we face [22:40:34] Hey @HikeAndMap, you might want to tone down that "nobody is maintaining" talk unless you have some actual evidence that me and others are not actually working... [22:40:53] sorry your favorite bugs are not fixed [22:41:28] [telegram] it was in this chat where last week this was discussed. I'm just repeating what I've read 😇 (re @wmtelegram_bot: [irc] Hey @HikeAndMap, you might want to tone down that "nobody is maintaining" talk unless you have some actual evidenc...) [22:42:10] Well you are defaming an entire community of technical contributors so you can take your halo emoji off [22:42:33] [telegram] if you feel not properly credited for the work then I'm sorry - but still - I'm not worried about numbers which lay many many many years in the future.. [22:42:34] [telegram] I'm more worried about the problems right now 🙏🏻 [22:42:52] Also I didn't realize how annoying putting everything in a string was until I started using a more strictly typed language. I filed https://phabricator.wikimedia.org/T298213 earlier today about a timestamp that is sometimes an empty string. [22:42:54] [telegram] Sorry - didn't intend to defame anyone (re @wmtelegram_bot: [irc] Well you are defaming an entire community of technical contributors so you can take your halo emoji off) [22:43:35] there are plenty of underresourced problems, but none of the ones you mentioned actually pose a risk to the long-term stability of the projects [22:43:40] [telegram] True. Both existing content types that are supported but not properly maintained, such as Maps or Graphs for instance, or as was mentioned in Commons group recently Timed Text, or new types that should be supported, and other thing such as, and I feel bad repeating over and over, captcha options for people who cannot see. It feels like bad prioritisation to care about numbers running into quadrillions in a fe [22:43:42] [telegram] gallery bugs [22:43:43] [telegram] inserted pictures bugs [22:43:45] [telegram] videos an...) [22:45:51] [telegram] I think I’ll sum up the answer to my question as, there’s no standard approach to deal with this, but also it’s not a significant problem (unless someone stumbles across an API module which actually returns huge numbers without reflection) [22:46:18] [telegram] and I’ll ignore the weird suggestion that, by asking this question, I’ve somehow implied that this is more important than whatever other feature/bug you happen to care about [22:47:16] [telegram] Well it feels like something you want either personally or have others jump on fixing right away(ish). Sorry if I misinterprited it (re @lucaswerkmeister: and I’ll ignore the weird suggestion that, by asking this question, I’ve somehow implied that this is more important than whatev...) [22:47:41] don't know where you get that impression [22:48:47] [telegram] that was not my intention, sorry if it came across that way (re @Thecladis: Well it feels like something you want either personally or have others jump on fixing right away(ish). Sorry if I misinterprited...) [22:49:23] [telegram] I really just happened to realize it could be a potential issue, and I was wondering if there was some "prior art" I wasn't aware of :) [22:49:59] [telegram] For me it is also very frustrating that such things fall into category of "one's favourite bugs" and are dismissed. This is again a tricky statement, because it is not that push it on Bryan for saying those words, it just feels like the general mood with those kinds of things. (re @Thecladis: True. Both existing content types that are supported but not properly maintained, such as Maps or Graphs for instance, [22:50:12] [telegram] (context is that I'm working on a library to interact with the API, so if there was a standard solution, I'd want to implement it there, to the benefit of the people using my library) [22:50:36] [telegram] An api wrapper? [22:51:18] ultimately resourcing for specific large problems is a management decision that individual developers can't do much about [22:51:40] [telegram] And management is likely not even aware about :) [22:52:04] you can find problems in mediawiki anywhere you want to look [22:52:20] @Lucas for nodejs or client-side stuff? [22:52:40] [telegram] By the way, this is kinda off topic here, but do we habe some statistics on what % of wmf management are active wikimedians themselves? [22:53:01] Curious why you want to write a new API library :) [22:53:09] you'd have to define those words more specifically [22:53:11] [telegram] Perfectly graded by echelons of seniority (re @Thecladis: By the way, this is kinda off topic here, but do we habe some statistics on what % of wmf management are active wikimedians them...) [22:53:42] [telegram] The words management or active wikimedians? [22:53:50] all of the above [22:54:24] (I'm not saying I have an answer, just that it's a hard question) [22:56:01] [telegram] By active wikimedians I mean very active wikimedians, kinda 100+ edits a month in volunteer capacity and or sysops on major wikis. And by management, well, ceo, c levels, whatever comes next I guess. I mean I don't really know at what point people still have quite a lot of power to point at what things have to be done at scale and at what level it is more about doing tasks assigned from above [23:00:00] [telegram] That is true of course. But some things are crappy but still do the job. And some don't really (re @wmtelegram_bot: [irc] you can find problems in mediawiki anywhere you want to look) [23:01:59] [telegram] In very loose understanding of crappy :) [23:02:35] [telegram] that was my instant thought.. if it works it can't be that crappy (re @Thecladis: In very loose understanding of crappy :)) [23:04:55] [telegram] Well, outdated ui design or badly written but proven to be safe code would probably be examples of something that is kinda crappy by modern standards, and should definitely be fixed. But it works, and perhaps should not be as big a prio as it sometimes ends up being. [23:05:50] I last had 100+ edits on my home wiki in Nov. 2018, and before that, 2014. You probably are more interested in people who contributed beforehand, but I don't think that is a good proxy for "getting it" either. I've worked with plenty of people who came from "outside" and you'd probably think they've been a Wikimedian forever. [23:09:27] [telegram] Well said. I agree to this opinion (re @Thecladis: Well, outdated ui design or badly written but proven to be safe code would probably be examples of something that is kinda crapp...) [23:12:08] [telegram] Well I'd put it as a heuristic rather than a foolproof algorithm. But the point is in this case that even with a good understanding of Wikimedia movement as a whole, it sometimes comes down to having to deal with MW and some things limited by MW, such as very poor anti-vandalism capabilities in comparison to the amounts of attacks happening, that one has to deal with it first hand. Well, some staff still edit [23:16:52] [telegram] personally I always think - what's really broken, as in:"absolutely not working as the user would expect" [23:16:54] [telegram] That should be prioritized .. [23:16:55] [telegram] Example: If the user has a car and the car always stops operating after driving 30km, then I say yes it's working for 30km, and maybe in the past that was okay.. But that's not what is supposed to happen. [23:16:57] [telegram] if it fails after 30km and needs to see the service center - then that's the priority over a car driving maybe half the speed but at least can run thousands of km before it needs servicing. [23:16:58] [telegram] But I understand when it comes to prioritizing - opinions differ 😊 [23:17:00] [telegram] Anyway - it's frustrating for the user - if things simply stop working at some point - a point where on modern systems no one should expect it to stop working [23:23:48] I have genuinely no idea what your point is [23:25:29] Or what you hope to gain by making it here...when we were talking about large numbers in API responses [23:26:28] [telegram] legoktm: Node *and* the browser, which already puts it "above" most other JS libraries last time I checked ^^ [23:27:08] [telegram] https://www.npmjs.com/package/m3api if you want to take a look [23:27:17] Ah, neat :) [23:27:43] [telegram] it's at 0.5.0, for the 1.0.0 release I'll write a blog post explaining how it's not just NIH syndrome ;) [23:28:03] [telegram] and what it offers over alternatives and why you would or wouldn't want to use it [23:28:06] something something Rust compiles to WASM which can be used in both :)) [23:28:25] [telegram] hehe [23:28:46] "Specifically, it’s “modern” as of mid-2021" lol [23:29:38] [telegram] The only realistic point of such conversations, save for trying to prove that strangers on the internet are wrong, is a way to find likeminded people to know them in case a more actionable opportunity arises and just to know that they exist :) I wish it could be more than that but that is part of the whole problem, even if the whole 561 member chat here agrees on what one says it is no guarantee that somethin [23:30:30] [telegram] too modern for Debian, as I discovered, they don't ship Node 14 yet 😔 (re @wmtelegram_bot: [irc] "Specifically, it’s “modern” as of mid-2021" lol) [23:32:01] :( [23:32:24] https://tracker.debian.org/pkg/nodejs last I looked into it there was only one person really maintaining it [23:32:40] I wonder why unstable is still at 12 [23:42:51] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989266#10 seems like there wasn't enough time to coordinate upgrading to node 14 before the bullseye release. [23:43:45] [telegram] I see [23:55:25] [telegram] ⧼abusefilter-warning-linkspam⧽ [23:55:25] [telegram] If I want to write on the service desk of mediawiki.org I get this.. [23:55:27] [telegram] any hints what's going wrong why I can't add a comment? [23:55:54] [telegram] It is assumed this only happens to 'some' servers. [23:55:55] [telegram] That's an incorrect assumption without evidence to that assumption. [23:55:57] [telegram] Below I'm adding the evidence this isn't just an issue on smaller servers [23:55:58] [telegram] https://en.wikipedia.org/wiki/Comparison_of_European_road_signs#Speed_limit [23:56:00] [telegram] Scroll down and you get the same error - so it also happens on the "big" en.wikipedia.org [23:56:01] someone set an abusefilter with a custom warning message but didn't bother to actually create the message [23:56:01] [telegram] That's the text I'm trying to post.. how is that spam? [23:56:24] it's probably just looking for "new account" and "has an external link" [23:56:41] try replacing it with [[w:Comparison_of_European_road_signs#Speed_limit]] [23:57:15] [telegram] Thank you! Works (re @wmtelegram_bot: [irc] try replacing it with [[w:Comparison_of_European_road_signs#Speed_limit]]) [23:57:30] did the message include a filter number? [23:57:48] [telegram] no numbers visible on my end (re @wmtelegram_bot: [irc] did the message include a filter number?) [23:58:17] hrm, https://www.mediawiki.org/wiki/MediaWiki:Abusefilter-warning-linkspam does exist [23:59:32] https://www.mediawiki.org/wiki/Special:AbuseFilter/59