Hello Srishti,
I read your message in the Wikitech-l mailing list. I asked about usecases for block based programming and you answered that you have thinked about a usecase for kids. I am interested in that usecase. What have you done regarding that topic in the past. Have you written down your ideas somewhere.
Hello! The high-level idea was to develop an experimental extension in Scratch to enable children to create information-rich and data-driven stories, animations, and games using content and data from Wikidata/Wikipedia. From a quick digging into Scratch, we found that children do try to copy content right now from Wikipedia to use it in their projects. See for reference: https://scratch.mit.edu/projects/2026251/editor/, https://scratch.mit.edu/projects/303064240/editor/. A bunch of extensions available under Scratch 3.0 allows children to do much more powerful things. For example, a Translate extension enables them to translate words between languages via Google Translate: https://en.scratch-wiki.info/wiki/Translate_Extension. There is a parallel between the idea we were thinking of implementing and this extension. But, having said this, I believe that this project would also need research besides development to understand how children use it and maybe discussion w/the Scratch team about what they think of an idea like this. I believe that Wikipedia/Wikidata has rich information that can be accessed via such an extension that children can then use to narrate stories about their favorite television stories, movie characters, musicians, etc. @Tuxology. I initially proposed this idea pre-pandemic to the Scratch conference and was accepted. But we let go when the pandemic hit. Also, the last thing is that this idea is relevant to the Scratch community and might not be relevant to the wiki world; if you decide to go further, I might be up for providing feedback on the design and conducting research w/ children in my personal capacity.
There is a discussion at [[API talk:Edit#sample code for C sharp]] which may involve you. Kindly look into it. Regards, Usernamekiran (talk) 07:16, 8 February 2022 (UTC)
Hi!
You get this message because you are an admin on a Wikimedia wiki.
When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.
Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.
If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.
We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.
Thank you. /Johan (WMF)
18:17, 4 January 2022 (UTC)
Hi Srishti,
I was looking for a way to contact the Toolhub team, but I didn't see anything on the meta pages, so I'll just tell you and hope you'll put it in the right place :-)
I saw the demo app, and I like it. However, I know that Hay's directory is a good basis but incomplete, at least as far as my tools are concerned. I recently wrote myself my own issue tracker, and as part of this, I made a list of all my tools, JavaScript on-wiki tools etc.
You can get the up-to-date list at https://magnustools.toolforge.org/buggregator/api.php?action=get_tools though you might have to filter a bit, as it also includes deactivated tools etc. It also has columns for open and closed "tickets" (issues, bug reports etc). I am going through those as time allows, so they are biased towards "open", but they might be a long-term indicator for your quality scores. I have added the "name" property from the Toolhub API where I could (I think I have all tools in your database matched).
Feel free to use this data as you see fit. Please note that the "id" field is the "stable" one, so if you add a tool of mine from there, maybe use something like "mm-tool-ID" for your "name" property.
Cheers, Magnus (I am not usually on this wiki, please drop me a line on Wikidata instead if you like)
Hello Magnus! Thanks for reaching out :) I wanted to share with you that Toolhub currently supports two ways to add tools- one via a `toolinfo.json` file that conforms to the schema https://meta.wikimedia.org/wiki/Toolhub/Data_model#Toolinfo_schema and directly via the UI. Once you are logged in, you will be able to add tools via https://toolhub-demo.wmcloud.org/add-or-remove-tools. Maybe when you get a chance, explore this feature? It will be awesome to have your tools on Toolhub!
Hello Srishti, are you still in charge of GSoC ? We are having discussion here in France. We are having discussion here in France. I noticed this the Feb. 20th deadline of "Mentoring organization application deadline". I assume WMF applied. But can we, French folks, still get a student into GSoC while mentoring him here in France, possibly in Wikimedia France's office ? Nothing solid yet, we are exploring this possibility for Wikimedia France's LinguaLibre. EDIT: I opened a topic on zulipchat > GSoC.21.
Also, Lingualibre.org is rocking well. 50,000 audios last months, a record and amounts for 5% of Commons' upload. We are looking to reach more diverse languages while keeping in mind the local community. Hope we can share a drink this summer ! (Wikimania ? other).
Hey there! Thanks for reaching out :) I have replied to your message on Zulip.
 |
The Surreal Barnstar |
| Thank you for coordinating GSoC and Outreachy this summer! You are awesome! ^>^ |
Hi, I saw your application for sysop at The Test Wiki. Would you be able to confirm that this request is from you? Thank you.
I just saw your changes to API:Opensearch. As I understand it, the preference is to have both the manual API documentation as well as the automatic API documentation. The manual documentation provides additional, version-specific information so that people can target their bots/utilities against multiple versions. In the wild, outside of Wikimedia sites, it's not uncommon to see MediaWiki versions as low as 1.20 or so, so it's important to have historical information readily available.
Thanks for your comment! We are trying to make the documentation of most popular action pages more consistent by following this template API:Documentation for all, embed the API docs as provided via Special:ApiHelp transclusion, add sample code where necessary, etc. We are changing the format only, and not removing any useful information. The deprecated parameters if any and included in the automatic API documentation, would still be shown as it is with the transclusion.
What about information about which version of MediaWiki parameters were introduced in, deprecated in, and probably most importantly, deleted in? I didn't see anything like that in the version of the page after the template was applied. Take, for example, the profile parameter of OpenSearch. If I'm designing a bot, and I'm targetting 1.25 and above, I need to know that that parameter was only introduced in 1.28, and that I can't use it (at least not without some kind of version check). On the previous version of the OpenSearch page, it was obvious at a glance. Now, it's nowhere to be found (unless I go through the page history, which isn't a tremendously useful way to find information). Similarly, if an older parameter is deleted, I need to be able to see that it's deleted at a glance, not read through a bunch of existing parameters to determine that the one I'm using is no longer there. That's why we had the API Param template in the first place, was to document all this kind of information over and above the auto-documentation.
I just had a thought on this: I'm guessing that the motivation for the change is to have the live docs being the main source of information, and that makes sense. What about putting your template first, but then keeping the ApiParam stuff underneath and renaming the section to "Parameter History" or something along those lines? That would accomplish both goals of having the live docs be the easiest to find, while the historical information remains readily available to bot developers.
You are right, and it's my fault that I didn't consider to include in the documentation template the version information about MediaWiki parameters. Thank you for sharing about this :) The parameter section was added back to the Search page by a user, and taking your suggestions into account, I ended up making modifications to their edits and then for now presenting only that information which is not covered in the automated docs here: API:Search#Parameter history. I will investigate how I can use ApiParam to display it in the way it is in the current revision.
I also saw there is a related task on Phab: T90528. I will try to figure out if it is feasible to include this information in the live docs.
That looks good. I really like your colour coding for the version information. That makes the information even more readable than it was previously. I wouldn't necessarily say you should constrain yourself to using ApiParam specifically if you have something that's better formatted. Even as one of its primary designers, I'll admit that it's very plain. Design aesthetics aren't my strong suit. :) However, you should definitely look at it at least in terms of the information it was designed to track, to figure out what kinds of details people want to have captured when it comes to parameter documentation.
On a side-note, one of the frequent issues I've seen come up among designers is that there's little documentation about what output to expect from each API module, beyond one or two examples which don't always cover every possible output. I realize that that's a lot of work for something as large as the API, but I think it's something a lot of developers would probably appreciate. Just something to think about for the future.
:) Another thought that I've -- how about we show Parameter History in a changelog format:
And, then the question would be how important is to show default values and other miscellaneous info that we manually show in the parameter section? Do you've any thoughts on this?
For me, I think that would work. I can't speak for other developers. Default values and the like are certainly nice to have if they've changed over time, but in my experience, that's fairly rare in the API.
Hello :)
I was wondering what is the best way to mention our documentation sprint in the current schedule page for the hackathon? The timing of the schedule are still a work in progress, but at least we can mention that the documentation sprint will take place during the 3 days of the event.
Thanks!
Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future.[1] The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. To say thank you for your time, we are giving away 20 Wikimedia T-shirts to randomly selected people who take the survey.[2] The survey is available in various languages and will take between 20 and 40 minutes.
You can find more information about this project. This survey is hosted by a third-party service and governed by this privacy statement. Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email to surveys@wikimedia.org.
Thank you! --EGalvez (WMF) (talk) 21:26, 13 January 2017 (UTC)