[07:30:18] https://tools-static.wmflabs.org/bridgebot/9ff52742/file_33414.jpg [07:30:30] It's a bar that appears at the bottom of https://developer.wikimedia.org/he/build-tools/ [07:30:49] The words "next" and "previous" are not translated into Hebrew correctly. [07:31:05] Where do these translations come from? I don't see them in translatewiki. [08:04:23] amire80: Those appear to be from mkdocs-material. https://github.com/squidfunk/mkdocs-material/blob/04c0defa358593c51afcf3e01ece7510d4b8e25f/src/partials/languages/he.html#L30-L31 [08:07:36] Thanks! [08:29:49] JJMC89, I submitted a pull request. [08:36:07] I wonder whether I did it correctly... I couldn't find clear instructions for submitting translation updates. [13:01:16] @amire80: That PR looks pretty good to me. I'll follow it so I have an idea when it has landed upstream and we can pull it into the site. If it lingers, we could try to figure out how to override the translations locally too. [13:02:46] There is also a small discussion at T309144 about the possibility of changing all of the theme translations to be done for us through TWN. [13:02:47] T309144: Consider replacing mkdocs-material theme translations with our own data - https://phabricator.wikimedia.org/T309144 [13:14:24] T309144 [13:21:39] * bd808 wonders why bridgebot did not pass the stashbot link over to telegram... [13:25:16] No Telegram bots cannot read each other by design [13:25:49] Ah, but the link on irc side, dunno [13:28:59] yeah, I just tested in the #wikimedia-cloud channel and the same sort of interaction did end up with the stashbot output mirrored to the telegram side. I'm not seeing anything materially different in the config for bridging this channel and the config for that channel, but it must be there somewhere. [13:57:33] Seyram Komla will be presenting a talk about Wikimedia Cloud Services in about 3 minutes in https://meet.jit.si/wikimania2022-hackathon-tech-sessions [14:01:40] bd808, I generally really dislike translating by manually editing text files. It's especially horrible for RTL language. But this one was so short that I didn't mind doing it. [14:04:20] I asked to document their localization process: https://github.com/squidfunk/mkdocs-material/issues/4244 [14:05:10] Based on that, we may decide if it's appropriate for translatewiki. [14:31:26] we'll continue with the wikidata game work in 30 mins here: https://meet.jit.si/wikimania2022-hackathon-wikidatagame [14:33:44] Jesed @dhinus @Mwintirew and anyone else who wants to continue with yesterday's work [14:34:07] Awesome! You can also add this to the on wiki schedule/social room if you want to catch more people. (Don't have to, though) [14:35:19] yes I've already started hacking a simple prototype 😉 [14:35:25] wohooooooo [15:04:19] @dhinus Jesed @Mwintirew i'm in https://meet.jit.si/wikimania2022-hackathon-wikidatagame [15:32:34] Hi everyone! Please note that signups for the showcase tomorrow are open! Anyone can present what they worked on. We'd love to learn what you've been up to this weekend! https://etherpad.wikimedia.org/p/wikimania2022-hackathon-showcase [15:46:07]

Hello, at the Hackathon in May I finished a program to convert Blocks from Visual Programming Language Snap to Source Code. A block is a sentence with gaps for the variables. Different blocks can be combined to a program. I am interested in code snippets in different programming languages. If you are interested in sharing code snippets you can join the https://meet.jit.si/wikimania2022-hackathon-tech-sessions Jitsiroom [16:33:35] @dhinus https://phabricator.wikimedia.org/T315162 [16:42:01] A lot of the work was done before the Hackathon, but after working on it for a good chunk of yesterday and this morning I've now got a new release of my wikidatum Ruby gem out for use with the Wikibase REST API 🙂 [16:42:58] I've got methods for all GET/POST/DELETE requests from https://doc.wikimedia.org/Wikibase/master/js/rest-api/, though not everything is fully supported (can't create references/qualifiers on statements yet) [16:43:08] and I haven't done any PUT requests yet because they scare me 😛 [16:54:01] and here's the repo for it: https://github.com/connorshea/wikidatum [16:54:34] @connorshea: that sounds like something worth announcing in the final showcase tomorrow! Signup is at https://etherpad.wikimedia.org/p/wikimania2022-hackathon-showcase [17:02:41] @bd808: I've signed up to present for that now, thanks! 😄 [19:11:44] The results of my hacking day are live on toolforge, very minimal but kinda works 😉 https://whopaintedthis.toolforge.org/ [19:12:14] If anyone has any suggestion, in particular on how to improve the wikidata query, that would be very welcome! https://github.com/dhinus/wikidata-painters/blob/main/src/lib/wikidata.js [19:13:52] Nice! A "Next" button would be nice to continue playing (re @dhinus: The results of my hacking day are live on toolforge, very minimal but kinda works 😉 https://whopaintedthis.toolforge.org/) [19:17:50] What kind of improvement are you looking for? (re @dhinus: If anyone has any suggestion, in particular on how to improve the wikidata query, that would be very welcome! https://github.com...) [19:20:03] @Jan_ainali the "Next" button is a nice idea! You can also refresh the page and you should get a new image (from the same pool of 5 images) [19:20:52] And that's because Wikidata is caching the results of the query... I don't know if there's a way to disable the cache [19:21:51] @MaartenDammers apart from the cache problem, the current query sometimes returns 2 paintings by the same artist (and the artist name is listed twice) [19:22:23] easiest way would probably be to make `query()` append a random string to the `fullUrl` (re @dhinus: And that's because Wikidata is caching the results of the query... I don't know if there's a way to disable the cache) [19:22:46] Was about to say that you can break the cache by supplying a random string yourself from the app (re @lucaswerkmeister: easiest way would probably be to make query() append a random string to the fullUrl) [19:23:09] the query would probably also faster by doing the random order + limit in a subquery, and then only adding the label service afterwards [19:23:39] @lucaswerkmeister I tried doing something similar but got stuck in the Sparql syntax 😛 [19:25:13] i.e. https://w.wiki/5Zy2 – 1.5 instead of 5 seconds in a quick test just now (re @lucaswerkmeister: the query would probably also faster by doing the random order + limit in a subquery, and then only adding the label service aft...) [19:25:40] you can append `&whatever=${random}` to the URL and not worry about the SPARQL syntax at all ;) (re @dhinus: @lucaswerkmeister I tried doing something similar but got stuck in the Sparql syntax 😛) [19:25:44] awesome, thanks! [19:26:05] any idea on how to avoid the duplicate artists? [19:26:36] I also get duplicate images sometimes (e.g. two images for the same painting) [19:51:04] Deployed v0.2.0 😉 I'm logging off for today, but let me know if you have other suggestions, or feel free to open an issue in GitHub 🙂 [23:04:16] dhinus: I would indeed add a next button [23:04:20] particularly after "winning" [23:05:10] after you find it, I would also include a popup with the image title and linking to the file [23:05:35] might be required for license, although most will be PD