User talk:RobinHood70

Jump to: navigation, search

the edit to the page with the tables[edit]

Sorry, I should have probably left a note after reverting. I agree that having empty (but existent cells) is better than having non-existent cells. I only reverted your edit because it caused some of the text that was supposed to in the first column to appear in the second column. As an example, the text This action is disabled by default in <code>DefaultSettings.php</code> moved from the function column to the example column (and it belongs on the function column). Cheers. Bawolff 22:51, 4 November 2010 (UTC)

I'm sorry...I never even noticed! I'll have another look at it and try again. My bad! RobinHood70 23:12, 4 November 2010 (UTC)

Adding img_id and oi_img_id[edit]

You may be interested in bug 71198, which would add img_id and oi_img_id. That way, you could do a prop=imageinfo query that would grab the image info for, say, 500 or 5,000 images, which you would specify using an imgid parameter. Later, of course, it will be a prop=fileinfo query. Leucosticte (talk) 19:43, 24 September 2014 (UTC)

Thanks! – RobinHood70 talk 19:52, 24 September 2014 (UTC)

Fixed at Template:API-head[edit]

Re API:Allredirects, we were fixing it over at Template:API-head. Cheers, John Vandenberg (talk) 02:00, 22 February 2015 (UTC)

I was just about to look at that. You got there before I did and confused my royally by fixing it! :P Thanks! Robin Hood  (talk) 02:01, 22 February 2015 (UTC)
No worries. If you are bored, you could help me roll out Template:API-head onto the API pages. I am going to be doing API:Lists first. I am standardising them before setting up a bot to build these pages from the API paraminfo. See Thread:Project:Current issues/Api documentation bot. John Vandenberg (talk) 02:09, 22 February 2015 (UTC)
While I haven't been adding API-head to the pages, I've actually been updating each page as I create my bot-framework version of it. A bot is probably a good idea in the long run, though, since we can more easily add info as each version is released. For bot creators, it would be ideal if historical info was kept for a reasonable amount of time. I still come across wikis running on versions below 1.20...I found one on 1.15 a while ago, though I don't remember where off-hand. That's good info to know when programming. Anyway, I digress. I'll go have a look at the Props page and see what I can do there. Robin Hood  (talk) 02:33, 22 February 2015 (UTC)
Yea, the pywikibot team is now doing the same thing. We add a decorator on our API methods, and require new contributions determine this info.([1]) We're nearly supporting v1.14 without any loss of functionality (except features which dont exist) and I've got most tests passing with v1.11 [2], but there is some serious opposition to the concept of supporting v.11. hehe. Which bot framework are you developing? John Vandenberg (talk) 02:46, 22 February 2015 (UTC)
The properties page is done now. Unfortunately, that's about all I'm up to tonight. Let me know if you need any more help on anything. I have historical copies of the MediaWiki code almost back to the beginning if there's any research needed of that nature. If nothing else, helping out here keeps me away from the content dispute I'm on on WP. This is why I like editing here, we don't really tend to get much of that. :) Robin Hood  (talk) 03:03, 22 February 2015 (UTC)

UESP off-topic[edit]

I gained most of my knowledge on the Unofficial Elder Scrolls Pages.

Ahha-ha, as a trailing-edge gamer I'm spending too much time on trying to figure out what to make when I return from a quest. So much homework!! :) -- SPage (WMF) (talk) 07:22, 24 February 2015 (UTC)

I made potions a fair bit for a while, but then I found I was constantly carrying all kinds of potions and getting bogged down. These days, I mostly just keep health and one or two magicka and stamina potions, except at the early levels. Careful how much time you spend at UESP, though. Speaking as a self-confessed addict, I think it's only fair to warn you that people have come to UESP and never left. :D Robin Hood  (talk) 15:36, 24 February 2015 (UTC)

Api properties split[edit]

Hi, thanks for working on API pages. I'm trying to write some articles for "" but they refer to the API pages so I'm looking at them too.

Who else works on these pages? Is there a mw:Project:Documentation for us? I see User:Shirayuki localizing them and a bunch of people improving them.

You recently split Api:Properties, I'm curious why?

A few things I noticed looking at Api:Categories

  • the {{API-head}} doesn't identify this as a submodule of action=query
  • maybe the individual pages should be subpages of API:Properties or Api:Query, that way they have crumbtrail back to their parent.
  • the introductory text "Gets a list of all categories used on the provided pages." and the {{API-head}} desctext "List all categories the page(s) belong to." are redundant.
  • Api:Categories might be able to be just {{Api help|query+categories}}, but some of the other query submodules have information about versions as you pointed out.
  • the link in the generated help returned by getHelpUrls() is , they'll need to be updated

Thanks. -- SPage (WMF) (talk) 08:14, 24 February 2015 (UTC)

By and large, the API documentation pages are catch as catch can, and there's no formal process for them that I'm aware of. I've found some of them to be woefully out of date, and a few have no documentation at all (mostly less-used or new features). Truth be told, I only started updating them out of self-interest as I designed modules in my bot framework that mirror the API. Of course, now that I've started doing it, I'm admittedly motivated to keep doing it due to the addiction issues I mentioned in the above topic. Seems UESP isn't the only place that has this issue. ;)
Mostly, as you note, I've seen Shirayuki doing the translations. Anomie is also a big help, though his main focus is on editing the API modules themselves. Lately, John Vandenberg has also been doing quite a bit of work and Cgt (recently changed from Cgtdk) has also been popping up here and there.
As for the split, the Properties page was getting a bit long and especially with the Info and Revisions modules being so large, I found it difficult to read through. There was also the issue that the third-level headers repeated between the different modules, so linking to them was impossible without adding manual anchors and after editing one of them, the page would refresh and display the same section from the Info module. Splitting resolves all that. Since the List modules were already split the same way for the same reasons a couple of years ago, it made sense to me to do the same for the Properties and Meta modules as well, even though splitting Meta makes that page look a little bare.
And on to Categories:
  • The API-head module has gone through a number of revisions, as you can see, but it does now include a {{{query}}} parameter, so it would be easy enough to add a "Query" to the box somewhere. Distinguishing it between a Property, List, or Meta would take an additional parameter, I think, or at least a change in approach to the existing one (e.g., query=prop).
  • I'd have no objections at all to making the various pages subpages of their respective parents, though we'd have to go through and update the getHelpUrls code once again (more on that when I get to that bullet).
  • I left the redundant introductory text as is for the moment because I wasn't sure if we wanted to keep the full text in the intro for those reading that, and the quick description in the box for those just looking for a summary, or if it was better to eliminate the redundancy.
  • I'm honestly not sure what the best approach is to versioning, and I'm hoping your Phabricator post will generate some ideas. It seems silly to bog down the code with outdated parameter and version info, but I don't see any other easily automated way to do it. The best I can come up with is adding a "Deprecated/Removed Parameters" section to the page that we would update manually, but that still leaves the issue of documenting when a parameter was introduced.
  • I've actually done the getHelpUrls work already (see this series of edits), but I've decided that it's better for my health (literally) to stay away from the whole Git/Gerrit updating thing. While it may not seem like it at a glance, I'm actually cognitively impaired and the longer I focus on a difficult task, the more out-of-it and error-prone I get. The entire process around updating the MediaWiki code usually left me with a headache and completely useless for anything but watching TV for a couple hours. It's just not intuitive to me at all. That all being said, I just noticed Anomie's last post there and that may be a solution. I'll have to look into it. I'll wait to do anything until we decide whether we're moving the pages to subpages or not. Robin Hood  (talk) 16:11, 24 February 2015 (UTC)
  • For those reading along, I submitted your getHelpUrls() work as gerrit:202368. We can tweak getHelpUrls() if and when we move to subpages, and even without updating the old wiki-page URLs will redirect. -- SPage (WMF) (talk) 02:07, 24 April 2015 (UTC)

Help needed again[edit]

Hi RobinHood,

you helped me recently with a answer to a Commons API question. Now I have another related problem. Could You have a look on Talk page and maybe explain a solution therefor? Many thanks. --Arch2all (talk) 10:16, 7 November 2015 (UTC)

A barnstar for you![edit]

Vitruvian Barnstar Hires.png The Technical Barnstar
For you, a true MW-API hero! Thanks for all your helps! Dalba 18:18, 20 August 2016 (UTC)