User talk:SPage (WMF)/Archive 1

Subpages
More tests on subpages:

HTML5 named entities
Regarding the sub-section you added just now at HTML5: Would it not be better to encode  as   instead of as  ? The advice at List of XML and HTML character entity references is to use numeric references for apostrophes, because the named entity was never defined in legacy HTML (unlike,  ,  , and  , which are the only entities defined in both XML/XHTML and legacy HTML). It seems wiser to restrict output to numeric entities (which are guaranteed to parse) whenever named entities might not validate or render, even if current browsers don't mind. — Richardguk (talk) 21:45, 6 September 2012 (UTC)
 * Good question, legacy HTML vs numeric. You're right, that's what Sanitizer.php does and there are lots of numeric references in our code and no &amp;apos;. Except it's not decimal 27 (&#27;), it's 39 (&#39;) which is hexadecimal 27 (&#x27;). FWIW I have never had to encode apostrophe. I was just distilling the wikitech-l discussion because it was news to me and seemed important. -- S Page (WMF) (talk) 22:06, 6 September 2012 (UTC)
 * Thanks for the helpful response – and for spotting my own hex/dec parsing failure, inadvertently proving that numeric entities are not foolproof when I am typing them! — Richardguk (talk) 22:20, 6 September 2012 (UTC)

Cloak request
Hey there, you requested the cloak, but did not send a memo to us. Please do this:

As for what cloak will appear, it then will be something like *!*@wikimedia/s-page-wmf, as this is the name with which you are requesting the cloak, if you'd own user:SPage, you can make the confirming edit with that account, and I will get you a cloak with that name. Just let me know. -Barras (talk) 10:09, 6 October 2012 (UTC)
 * I did this a few days ago, but retrying in Pidgin IRC client there's no /ms command, and /msg doesn't know of "wmfgc". Anyway, sounds like it's coming, thanks. -- S Page (WMF) (talk) 19:58, 11 October 2012 (UTC)
 * Try  instead of   when your IRC client does this. Same goes for /cs -> ChanServ, /ns -> NickServ, etc.-- Krenair  (talk &bull; contribs) 20:18, 11 October 2012 (UTC)

welcomecreation
Hello, thank you very much for your list of wikis and instructions: I've used them for MediaWiki_1.21/wmf5 and notified those 200 wikis which customized it, plus about 250 wikis which don't yet have translations. --Nemo 21:37, 5 December 2012 (UTC)
 * Usually, the extensive release notes are only on wiki, but a bullet point mentioning the bug name and giving a couple lines of advice on how to keep customisations should surely be included in the release notes file IMHO. --Nemo 08:04, 6 December 2012 (UTC)

Setting up centralauth
Hi how can I setup centralauth because two websites are runescape-wikisaur.tk and random-wikisaur.tk and the database are paladox_wiki and paladox_enwiki 86.159.74.81 17:40, 4 August 2013 (UTC)
 * I'm no expert, I barely managed to fake it on one wiki :-) . We've updated Extension:CentralAuth with more info but there are a lot of moving pieces. Try asking on the wikitech-l mailing list, or on . -- S Page (WMF) (talk) 02:02, 5 August 2013 (UTC)

Requests for comment/Allow styling in templates
Hi, Requests for comment/Allow styling in templates is being considered as one of the RFCs to be discussed at the RFC review on 2013-11-06 via IRC. You are receiving this notification because you edited or discussed this RFC. We hope to see you there.--Qgil (talk) 00:43, 5 November 2013 (UTC)

mediawiki-ui: buttons problems
Hi S.

I've seen your changes on Wikimedia Foundation Design/Patterns and components about mediawiki-ui.

French Wikipedia currently use the Agora styles. Since yesterday, we don't have our big blue buttons on many pages (including important ones like the how-to-do an article page) and the new style doesn't work either.

Is it normal? How can I fix it?

Thanks, Trizek (talk) 14:55, 8 November 2013 (UTC)


 * If you need a CSS or JS module, you must tell the ResourceLoader about it. If you rely on someone else loading it then when they change, the module isn't around. When I go to a fr-wiki Article au hasard and in a JavaScript console I enter mw.loader.getState( 'mediawiki.ui' );, it responds "registered", not "ready". Try mw.loader.load( 'mediawiki.ui' ) and see if that improves the look, it seems to help on https://fr.wikipedia.org/wiki/Aide:Premiers_pas/2. To ensure the module is loaded, see ResourceLoader/Migration guide (users) or maybe you can   it in MediaWiki:common.css. -- S Page (WMF) (talk) 05:28, 9 November 2013 (UTC)
 * Thank you! mw.loader.load( 'mediawiki.ui' ) works when I use it in Firebug.
 * Just to confirm, I have to import mw.loader.load( 'mediawiki.ui' ) on the common.css?
 * And thank you for the notification :) Trizek (talk) 11:39, 9 November 2013 (UTC)
 * Done! Everything works now. Thank you! Trizek (talk) 10:59, 10 November 2013 (UTC)

API Help Template
That's a handy feature and I think it'll be great for documenting current versions of parameters, but I'm concerned that if we move to that exclusively, we'll lose a lot of the other information currently available on the page, like information on what version a parameter was introduced in, deprecated in, or removed from. That's important information for people like me who are developing bot frameworks and need to know historical information so that a bot can be universal rather than bleeding-edge only. Most of the non-MediaWiki wikis I deal with, and that I would expect my bot to be able to deal with, are still running on 1.19 and I've seen wikis running on versions as old as 1.15. In some cases, people have also added notes to the parameter documentation that the API simply doesn't include.

Before deprecating the current documentation methods, we'll need to figure out how to integrate the information currently on the page with the auto-documentation. – Robin Hood  (talk)  19:49, 23 February 2015 (UTC)


 * Thanks for your interest and working on the API pages, these are good points. I'm not removing documentation until I see Special:ApiHelp/somemodule isn't missing anything, so it's going slowly. I created T90528 about showing version information. We can always append and prepend more information to the wiki page, one reason I used Api help instead of a simple transclusion is to organize improvements like this. -- SPage (WMF) (talk) 05:15, 24 February 2015 (UTC)


 * Good plan. Templates give us at least some degree of flexibility. The API:Opensearch page brings up another point (besides the obvious formatting issue): documentation should probably be tweaked a bit for non-fixed parameters like namespace. The values given in the documentation obviously won't all be valid on another wiki. – Robin Hood  (talk)  06:09, 24 February 2015 (UTC)


 * Yes, I noticed that, it's really unworkable for Wikidata sites parameter, e.g. wikitech:Special:ApiHelp/wbgetentities (!!). I created T91364, I appreciate any ideas you may have. (Also, what I'm proposing is T89318 "Replace on-wiki API documentation with Special:ApiHelp transclusion".) -- SPage (WMF) (talk) 23:32, 3 March 2015 (UTC)

API modules as subpages
On my talk page, you suggested moving the Properties pages to being subpages of API:Properties or possibly API:Query (in which case, I would assume Properties, Lists, and Meta would become subpages of Query, and each submodule would become a subpage of those). I don't mind doing all the moves over the next little while and then updating the links in the modules, but I'd like to get a firm plan of what to do before we start so there's no wasted effort. Thoughts? – Robin Hood  (talk)  19:50, 3 March 2015 (UTC)
 * I haven't forgot about this, I just haven't had time to think it through :) The API TOC is already pretty big, there are pros and cons to subdividing it up. Maybe try one small section? SPage (WMF) (talk) 06:07, 10 March 2015 (UTC)
 * RobinHood70, I tried it out on just one page, see API:Property/Categories. The actual query is . As I understand it   is the query submodule and it just happens to be a "property" kind of submodule, so I'm dubious about going to a deeper API:Query > Property > Categories subpage structure or just API:Property > Categories as I've done. Also there's the singular vs. plural: it makes sense to have a page describing API:Properties, but since the api is singular , I felt the parent should be singular; maybe it should even be API:Prop/Categories to match the api param. I don't have a strong opinion, and I think everything works thanks to the magic of #REDIRECTs. Who else I should invite to ponder this sort of restructuring? -- SPage (WMF) (talk) 11:28, 7 April 2015 (UTC)
 * I think I'd still go with Properties as the parent page, rather than the singular Property, but like you, I don't really feel strongly about it. I'm not sure who else to invite to the discussion. Maybe some of the people who've commented on the Phabricator thread? The problem, I think, is that a lot of people look at the documentation, but not a lot of people edit it, so it's hard to say who to consult. Thanks for patching in the link update, btw. I've had a bad spell recently and had to let a lot of things slide. – Robin Hood  (talk)  00:50, 9 April 2015 (UTC)

API Help translation
Maybe is better if direct links to translation of API messages will be included into someone page? I did not found them anywhere. For example, links to translation of --Kaganer (talk) 22:57, 17 March 2015 (UTC)
 * MediaWiki Action API
 * API Explorer
 * API feature usage
 * API sandbox
 * Kaganer I'm not sure what you're asking. There are translations of some of these API strings, e.g. mediawiki-api translated to Russian, although viewing a core API module's help in Russian shows many strings are untranslated. Or are you talking about wiki pages that should show translated API messages, but don't? If I visit https://www.mediawiki.org/wiki/Extension:Flow/API?uselang=ru#action.3Dflow I see some Russian in the transcluded API help, which suggests the right language should show up when a page uses  to pull in API documentation (once help templates and strings are translated). So Api help is what I'm working towards in T89318. Regards, -- SPage (WMF) (talk) 00:29, 18 March 2015 (UTC)
 * Okay, templates is "in-wiki", these is seen for developers and possible translators. But core API messages in, and if some people want to quickly improve or verify or correct translation some API message, then it will find a link where? I am an experienced translator, and I spent some time to find the untranslated text of API Help. Or these messages is obsolete, and all API Help texts will be "in-wiki" through set of translatable templates? If not, maybe these links for translators to be place in API/Localisation, as example? --Kaganer (talk) 00:48, 18 March 2015 (UTC)
 * I added API/Localisation with three of your links (I left out ext-0-all, it is really big); I also added API/Localisation to the API Table of Contents. Can you review these? I'm not sure where else we could mention API message translation.
 * Api help is just a wrapper I wrote that transcludes the localized api.php help output and prefaces it with an explanation, it should help us reduce the amount of API stuff on-wiki that needs translation. Cheers! -- SPage (WMF) (talk) 04:14, 18 March 2015 (UTC)

"BadMethodCallException" from Echo adding to talk pages
I got two earlier, what about here? -- SPage (WMF) (talk) 08:20, 20 March 2015 (UTC)

Complicated fake transclusion
Hey S,

I just saw your question on User:Skierpage: "Seems a complex way of getting info out of a page's infobox. Why not a version of Labeled Section Transclusion that locates any infobox param?"

The answer is: That would mean putting the LST tags in the infobox template's code, but you can't use LST in a template. If you have a page you want to transclude content from, the LST tags need to be on that page directly. It's a known limitation of LST.

When I built this system, this was the only way I could make it work. If I had to do it again today, I would probably write a Lua module to extract the content from the page's infobox, using string functions.

HTH :) Guillaume (WMF) (talk) 18:27, 27 March 2015 (UTC)

API help
Hi! I'm a complete newbie to API, so need some help. I wanted to delete some pages through API (because can't delete them in ordinary way), so I used such link, but get error "mustposttoken". Could you tell me what I should do? --Edgars2007 (talk) 11:01, 23 July 2015 (UTC)
 * Sure. You might get faster answers on or on the wikitech-l mailing list, and the answer benefits everyone. Anyway, what API:Delete says. You have to POST the request. Clicking a URL in a browser results in an HTTP GET request. You have to use a library or utility that can make POST requests, but that means you also have to provide it your session cookies so MediaWiki can verify that you are the logged-in user with delete rights. As a quick hack, you might be able to use the cURL utility. What I do is
 * open the browser's developer tools window (Ctrl+Shift+I in Firefox), switch to the Network tab
 * perform a similar request on a test wiki page
 * choose 'Copy as cURL' from the context menu
 * edit the command line, removing the API query string on the end of  and turning it into a set of cURL's   post parameters. Something like
 * curl -F 'action=delete' -F 'title=User:SPage_(WMF)/junk' -F 'reason=test' -F 'format=json' -F 'token=hexadecimal stuff+\' -H 'Host: www.mediawiki.org' -H 'User-Agent: SPage testing' -H 'Cookie:all your cookies from your browser ' 'https://www.mediawiki.org/w/api.php'
 * This is so fiddly that it's much easier to learn how to use a bot like Pywikibot, see Manual:Pywikibot/delete.py.
 * Cheers, -- SPage (WMF) (talk) 20:15, 23 July 2015 (UTC)
 * I added a section to API:FAQ, [Why] do I get mustposttoken error. -- SPage (WMF) (talk) 23:29, 23 July 2015 (UTC)
 * OK, thanks. Will take a look and try to delete something :) --Edgars2007 (talk) 09:09, 31 July 2015 (UTC)