How we will see unregistered users
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.
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)
Toolhub / "Magnus' tools"
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 :-)
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.
A barnstar for you!
|The Surreal Barnstar|
|Thank you for coordinating GSoC and Outreachy this summer! You are awesome! ^>^|
The Test Wiki identity confirmation
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.
@PlyrStar93 That's correct! I've filed the request.
Thank you! Actually Skizzerz already assigned the rights.
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:
- v1.16: Introdced srinfo, srprop
- v1.17: Introduced nearmatch, score, titlesnippet, sectiontitle, etc.
- v1.22: Deprecated srbackend
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.
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.
Share your experience and feedback as a Wikimedian in this global survey
- This survey is primarily meant to get feedback on the Wikimedia Foundation's current work, not long-term strategy.
- Legal stuff: No purchase necessary. Must be the age of majority to participate. Sponsored by the Wikimedia Foundation located at 149 New Montgomery, San Francisco, CA, USA, 94105. Ends January 31, 2017. Void where prohibited. Click here for contest rules.
Thanks, and regards,
There are no older topics