Tech
A place to talk about tech related to a Wikimedia wiki.
Have a technical wiki question? Ask here. This can include for example:
- requests for new tools, scripts, and bots;
- help with CSS or JavaScript;
- API help;
- and data collection help (including database queries).
Please sign by entering four tildes (~~~~) or by clicking on the signature icon 
; this will automatically produce your name and the date.
Contents
Not all pages tagged with {{delete}} appear in Category:Deleteme[edit]
Hi. Why are some some pages tagged with {{delete}} not appearing in Category:Deleteme? This seems to apply to pages in the CNBanner and Translations namespaces. I already tried purging both the pages themselves and the category, and I checked that the pages in question do in fact list "Deleteme" as a category at the bottom. Is this behavior intended? PiRSquared17 (talk) 19:14, 10 March 2019 (UTC)
- Known issue. I think Billinghurst suggested doing some magic via a Scribunto Module. But given that I have no idea how that works I can't help in this case. —MarcoAurelio (talk) 11:35, 13 March 2019 (UTC)
- I have edited the config page, so hopefully the translations come through, though no promises, and no promises that this is the best way to handle it. We probably look to see what other versions are out there, and see whether there is actually value in it for us. — billinghurst sDrewth 20:29, 13 March 2019 (UTC)
- And as a general note, I think that there is some cache, weird shit issues with regard to {{delete}} and the translations blackmagic. What happens is that a junk page is created and then removed in Translations: ns, and the parent has some artefacts without visible artefacts. Those artefacts should all be cleared now anyway a little work with translation admin hat can resolve that, and I probably look at it once a month. — billinghurst sDrewth 20:59, 13 March 2019 (UTC)
- @Billinghurst: Thanks, it seems to be working! PiRSquared17 (talk) 15:40, 14 March 2019 (UTC)
- And as a general note, I think that there is some cache, weird shit issues with regard to {{delete}} and the translations blackmagic. What happens is that a junk page is created and then removed in Translations: ns, and the parent has some artefacts without visible artefacts. Those artefacts should all be cleared now anyway a little work with translation admin hat can resolve that, and I probably look at it once a month. — billinghurst sDrewth 20:59, 13 March 2019 (UTC)
- I have edited the config page, so hopefully the translations come through, though no promises, and no promises that this is the best way to handle it. We probably look to see what other versions are out there, and see whether there is actually value in it for us. — billinghurst sDrewth 20:29, 13 March 2019 (UTC)
Changing the helppage link[edit]
Hi, I'm an admin at sc.wikipedia, and I have an issue with the sidebar. How can I change the "helpage|help" link from "https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents" to "https://sc.wikipedia.org/wiki/Agiudu:Agiudu"? I've seen that on the other wikis the local Help:Contents page it's always the one that's opened, how can I fix this problem?--L2212 (talk) 17:03, 13 March 2019 (UTC)
- @L2212: Add to w:sc:MediaWiki:Helppage text
Agiudu:Agiudu. Stryn (talk) 17:32, 13 March 2019 (UTC)
Bot script for demographic histograms at lt.wikipedia[edit]
Greetings! I need someone who could write a script for collecting data from such kind of excel table and convert it to demographic histogram like this (or insert additional columns into already existing ones). I am planing to collect all the census data of all Lithuanian settlements but I need a tool to insert it to the pages. Anyone (@User:Emaus, @User:Papuass, @User:Ladsgroup, @User:xqt)? Hugo.arg (talk) 09:20, 15 March 2019 (UTC)
Google indexing and caching new pages too fast[edit]
Is there a way to control Google's indexing of new pages or if it's not at the moment, is this something that could be developed? There is a 90-day wait for unpatrolled pages in en-wiki, but in other projects new pages are indexed and sometimes also cached as fast as under 30 minutes.
Fast indexing also causes other problems, but attack pages are in my opinion the worst issue, because they might cause harm to real people. Probably the most common form of an attack page is a nonsense page about a school kid written by their "friends". Such a page might contain private information and insults, and can remain visible for weeks if Google caches the page before it's deleted. Attack pages are also created about notable people whose names might be googled and the cached attack page can be the first result.
We have FlaggedRevs in the Finnish Wikipedia, so if the indexing was possible to be tied to a new page being unreviewed/reviewed, even a few hours' delay would help a lot. The community would have time to review pages before they appear at the top of Google results. -kyykaarme (talk) 16:51, 16 March 2019 (UTC)
- @Kyykaarme: Could you elaborate what you mean by "a 90-day wait for unpatrolled pages in en-wiki"? Who waits 90 days with what? --AKlapper (WMF) (talk) 16:55, 16 March 2019 (UTC)
- I suspect he means mw:Manual:$wgRCMaxAge (after which the unpatrolled status "expires" or rather vanishes), but I'm not aware of search engines relying on it. Also, remember the Cunningham's Law: reducing exposure to those articles would certainly make them worse, not better. --Nemo 17:08, 16 March 2019 (UTC)
- I've understood from this that unpatrolled pages will not be indexed in 90 days, because they probably have NOINDEX in their source code somehow. Projects can also control which pages or namespaces are indexed, except article space which is always indexed even if an article has NOINDEX inserted manually (we recently noindexed our admins' noticeboard when we noticed that Google was indexing posts less than a minute after they were made). Finnish Wikipedia is so small that all new pages will be noticed and bad pages deleted. There is no need for an attack page to be visible in Google, our editors work fast but sometimes not fast enough when there is also a Google spider "patrolling" recent changes. I once deleted an attack page that had been live for a bit over an hour in the middle of the night, but Google had cached it 24 minutes after creation and its content was still visible in Google's cache 20 days later. -kyykaarme (talk) 18:05, 16 March 2019 (UTC)
- The English Wikipedia uses mw:Page Curation (mw:Extension:PageTriage), which, among other things, controls indexing during the first 90 days. Until phab:T50552 is complete, it isn't really suited for use on other projects. Using the extension seems like overkill if the only goal is to delay indexing, but it might be the only option currently available. — JJMC89 (T·C) 04:43, 18 March 2019 (UTC)
- Thanks JJMC89 for the note on PageTriage. Kyykaarme, indeed Google is quite bad at indexing updates and deletions. This is most commonly a problem with existing pages, where vandalised versions get cached in snippets for many hours or sometimes days after being removed (which may actually be the reason the vandalism is inserted in the first place). Maybe we should try to address this root problem rather than a symptom? Nemo 09:35, 18 March 2019 (UTC)
- I don't know what you mean by root problem? To me the root problem is that Google indexes new pages too fast, pages that should not be on Wikipedia at all. The system that English Wikipedia uses is not doable or even desirable for other projects. But we have FlaggedRevs, which means that some articles are "preapproved" and some are not. If the indexing of unreviewed articles was delayed, editors would have time to cull the worst cases before they appear in Google results. There would have to be some kind of time limit, because some articles might never get reviewed. As for vandalism in existing pages, I just had the chance to do two tests. Someone had vandalized the lead in two articles, and it was visible in Google results in the text snippet under the article link and in the "infobox" on the right. In both cases the vandalism disappeared in 5-20 minutes after I had reverted the edits. The text snippet cleared up as fast as in five minutes and the box took about 10-15 minutes longer. Is that what you meant and how would you address it? -kyykaarme (talk) 22:13, 20 March 2019 (UTC)
- Thanks JJMC89 for the note on PageTriage. Kyykaarme, indeed Google is quite bad at indexing updates and deletions. This is most commonly a problem with existing pages, where vandalised versions get cached in snippets for many hours or sometimes days after being removed (which may actually be the reason the vandalism is inserted in the first place). Maybe we should try to address this root problem rather than a symptom? Nemo 09:35, 18 March 2019 (UTC)
- The English Wikipedia uses mw:Page Curation (mw:Extension:PageTriage), which, among other things, controls indexing during the first 90 days. Until phab:T50552 is complete, it isn't really suited for use on other projects. Using the extension seems like overkill if the only goal is to delay indexing, but it might be the only option currently available. — JJMC89 (T·C) 04:43, 18 March 2019 (UTC)
- I've understood from this that unpatrolled pages will not be indexed in 90 days, because they probably have NOINDEX in their source code somehow. Projects can also control which pages or namespaces are indexed, except article space which is always indexed even if an article has NOINDEX inserted manually (we recently noindexed our admins' noticeboard when we noticed that Google was indexing posts less than a minute after they were made). Finnish Wikipedia is so small that all new pages will be noticed and bad pages deleted. There is no need for an attack page to be visible in Google, our editors work fast but sometimes not fast enough when there is also a Google spider "patrolling" recent changes. I once deleted an attack page that had been live for a bit over an hour in the middle of the night, but Google had cached it 24 minutes after creation and its content was still visible in Google's cache 20 days later. -kyykaarme (talk) 18:05, 16 March 2019 (UTC)
- I suspect he means mw:Manual:$wgRCMaxAge (after which the unpatrolled status "expires" or rather vanishes), but I'm not aware of search engines relying on it. Also, remember the Cunningham's Law: reducing exposure to those articles would certainly make them worse, not better. --Nemo 17:08, 16 March 2019 (UTC)
Ability to upload file(wiki azb)[edit]
Hello. How to create an upload file in the azb wiki.Survey azb:ویکیپدیا:فایل یوکلهمه ایمکانین ویکیده یارادماق.E THP (talk) 12:55, 20 March 2019 (UTC)
