Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.
Template styles
Hey all.
So, since the Jerusalem Hackathon I've been working on a very very longstanding issue we have had with styles. The current WIP solution: template styles.
That new feature allows attaching proper CSS to templates, finally getting rid of limited and troublesome inline styles in elements of the page. The upsides:
- No redundancy: If you use a style on more than an element, simply place them all in the same class and share styles;
- Even less redundancy: if you have a family of templates sharing styles, you can put all the styles in the one "library" template and include that;
- Proper style sheets means support for
@media
blocks, finally (thus making it possible for styles to work right on mobile, amongst other things); - Smaller and easier to maintain templates;
- Style sheets becomes available to anyone being able to edit the template, rather than just admins; and
- No more need to edit common.css and have to deal with the crap of caching, or the risk of breaking the site.
The downsides... well, I can't think of any yet but I'm sure we'll find some eventually. :-)
There is a test wiki in Labs where the current WIP extension is deployed. Feel free to register (not with your real Wikimedia credentials!) and play with it. Beware that this is my testing ground and thus may randomly be unstable. The main page there is a transcluded template with styles if you want a quick and easy example to look at. There is no documentation (yet) but the jist of it is simple: add a <templatestyles>...</templatestyles>
element to a template containing a style sheet, and that style will be prepended to any page that transcludes that template (just once, even if the template is transcluded multiple times, including recursively). Not unlike TemplateData, you can actually put the templatestyles element on a subpage - but I expect that would be a bad idea in this case since it affects transclusions and thus should track the template's own protection level.
This pet project of mine has a lot of buy-in and support from the WMF (tracked in phabricator at T483) so once we're happy about how it works I've no doubt it will end up being deployed in production fairly quickly. — Coren (talk) 15:05, 14 April 2016 (UTC)
- Sweeeeet! Hope this gets deployed soon, so we can properly style the Main Page.
-- [[User:Edokter]] {{talk}}
15:52, 14 April 2016 (UTC)
- Extreme enthusiasm \m/ =) \m/ fredgandt 16:46, 14 April 2016 (UTC)
- Best thing EVAH ! Will take us 5 years to get rid of the existing cruft I'm sure, but this will be awesome. —TheDJ (talk • contribs) 17:56, 14 April 2016 (UTC)
- Yeah, this looks very good. --Edgars2007 (talk/contribs) 17:57, 14 April 2016 (UTC)
- FYI, I experimented with this using the Wide image template. {{Wide image}}. —TheDJ (talk • contribs) 16:58, 18 April 2016 (UTC)
- Yeah, this looks very good. --Edgars2007 (talk/contribs) 17:57, 14 April 2016 (UTC)
- Wonderful! Sounds like an awesome change. Kudos to you for implementing/coming up with this. APerson (talk!) 02:35, 20 April 2016 (UTC)
I have only one thing to say: Lua Lua Lua.
This would be better if it came with a lua library that would allow adding such styles without a hacky extensiontag:
frame:extensionTag{ name = 'templatestyles', content = 'some text', args = { name = 'foo', group = 'bar' } }
Potentially something like mw.templatestyles or mw.styles or mw.html.styles. This would make the conversion of existing modules much more efficient. 08:28, 21 April 2016 (UTC) — Preceding unsigned comment added by 197.218.89.56 (talk)
- That sounds like a nice enhancement I think, but not necessarily a requirement. —TheDJ (talk • contribs) 11:23, 27 April 2016 (UTC)
One limitation of the styles in templates is that each page needs to be edited to add them. I think that this is a severe limitation, and would require unnecessarily editing thousands of pages just to add a template to it, even for the smallest tweak. There are possible ways to overcome this. 197.218.81.82 (talk) 20:11, 24 April 2016 (UTC)
- I counter that by saying that styling and page structure will no longer accidentally go out of sync. And not every page needs to be edited, just purged, which the queue does already for your template change. —TheDJ (talk • contribs) 11:23, 27 April 2016 (UTC)
- Expanding the use to categories
Instead of adding these to only templates, a more generic tag could be created, e.g. <styles> or <wikistyles> (to avoid possible clashes with HTml) and when they are added them to the Category page they apply to all pages within it. 197.218.81.82 (talk) 20:11, 24 April 2016 (UTC)
- This is a lot more difficult than it sounds. It means that a category would have to purge every single page within it after someone edited the category page. That mixes the models of templates and categories. —TheDJ (talk • contribs) 11:23, 27 April 2016 (UTC)
- A shadow css for each page
For example, Cat/theme.css or //en.wikipedia.org/wiki/Theme:Cat.css 197.218.81.82 (talk) 20:11, 24 April 2016 (UTC)
- This has been proposed before, but it complicates purging, dependency tracking, parsoid and a host of other things (just like Categories). It has been considered, but was rejected. —TheDJ (talk • contribs) 11:23, 27 April 2016 (UTC)
Also, something not mentioned here, is if two templates contain contradictory styles which one will win. Another question is how VE will interact with it because it doesn't have a preview so if someone removes a template and adds another with styles it would need to update the styling of the page content in the editor. 197.218.81.82 (talk) 20:11, 24 April 2016 (UTC)
- Conflicts are possible indeed, but the effects are at limited to the pages that the templates are transcluded on. I personally am not not afraid of it. If we find people often apply their rules to all divs, we could expand the validator to always require people start their rule with a classname or something like that. Solvable problems I think. —TheDJ (talk • contribs) 11:23, 27 April 2016 (UTC)
Earth to JDForrester
Wikipedia:Village pump (technical)/Archive 145#Do you want one Edit tab, or two? It's your choice, and especially the subsection "VE was imposed as primary editor", have been archived. User:Alsee was told off last week because he wasn't patient enough and User:Jdforrester (WMF) had no time then to address this, but his interpretation that nothing would be forthcoming the week after that comment (the 14th) was completely misguided.
Sure enough, it's the 21st, and the product manager, who promised before the implementation that VE would not be the primary editor on enwiki, has still not responded anywhere about this. He has edited a lot of other things, and must have seen the messages on his talk page, but apparently acknowledging that something seems to have gone wrong and that you will look into it (preferably with some timeline) is too hard. Easier to just let it archive and forget about it. If only we had some people at the WMF who could drop you a note at your talk page there, some WMF-community intermediaries or something similar. Oh well, we can always dream... Fram (talk) 12:12, 21 April 2016 (UTC)
- I left a post for the Executive Director noting that we were assured that this was not going to happen, and that we have been unable to get any response on it. Alsee (talk) 01:51, 24 April 2016 (UTC)
- Weren't you told off at some phabricator ticket for saying that Jdforrester wasn't going to respond last week, when they were certain that that would happen and that the lack of communication was only for the week of the 13th? It's the only fast reaction we have had in all this, and it was of course incorrect... It has been archived here once, at least thanks to Flow it can't get archived at his talk page. We have a new deployment this thursday, I presume, if it isn't fixed by then it is just another giant FY against enwiki and another lie by the same people at the WMF. But we need to respect them and work together instead of against each other, of course. Still waiting for that to happen from there to here... Fram (talk) 14:51, 25 April 2016 (UTC)
@Elitre (WMF):, can you ask Jdforrester when he plans to reply to these concerns, and when he plans to actually do something about them? If he has done either meanwhile, great, last time I looked a could find a lot of activity but nothing about this, despite posts on his talk page. If we need to contact him at another (public) location, feel free to post a link to whatever page is best to reach him. It has been two weeks now... Fram (talk) 10:18, 27 April 2016 (UTC)
- He has already replied at one of the countless venues where related questions were posted ;) Best, --Elitre (WMF) (talk) 15:41, 27 April 2016 (UTC)
Tech News: 2016-17
21:02, 25 April 2016 (UTC)
Change of "Save page" button to "Publish"
The use of Publish instead of Save Page would look more confusing IMO as many experienced users are already used to saving pages. Publishing would mean it's final, and Wikipedia itself is not final. Was there community consensus or Meta discussion on that change? And will this go live together with the new MediaWiki version? 49.148.95.70 (talk) 04:05, 27 April 2016 (UTC)
- Some documentation would need to be changed … --Pipetricker (talk) 09:03, 27 April 2016 (UTC)
- "as many experienced users".. Please note that these people are far fewer than that globally there are (potential, incidental or inexperienced) users of the MediaWiki software. Just saying. —TheDJ (talk • contribs) 10:54, 27 April 2016 (UTC)
- And every save is final, because every action is public and logged eternally. It's a matter of perspective. —TheDJ (talk • contribs) 10:58, 27 April 2016 (UTC)
- Comment on the phab tickets - I can't see any good reason this shouldn't be able to be controlled via a local variable such as Mediawiki:Save-button-label. — xaosflux Talk 11:10, 27 April 2016 (UTC)
- Is it like a localization to Wikipedia? 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- It's currently controlled via MediaWiki:Savearticle but will apparently change to MediaWiki:Publishpage.[6] The wording is also being changed in the VisualEditor interface, in other wikis, and presumably in many foreign languages when they catch up. The transition may cause some confusion but there will probably be more long-term confusion if the English Wikipedia decides to override a coming "Publish page" default. PrimeHunter (talk) 11:33, 27 April 2016 (UTC)
- (edit conflict) The current save button uses MediaWiki:Savearticle. Use to find it out once its deployed. Also, blah
en-gb
blah blah always broken. — Dispenser 11:46, 27 April 2016 (UTC)
- Is it like a localization to Wikipedia? 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- I missed on that one. Was there a discussion in this Wikipedia about the change? The discussion in the link is to Phabricator, not necessarily about Wikipedia, and many users may haven't been aware until the bot message was posted here. 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- Comment on the phab tickets - I can't see any good reason this shouldn't be able to be controlled via a local variable such as Mediawiki:Save-button-label. — xaosflux Talk 11:10, 27 April 2016 (UTC)
- And every save is final, because every action is public and logged eternally. It's a matter of perspective. —TheDJ (talk • contribs) 10:58, 27 April 2016 (UTC)
- "as many experienced users".. Please note that these people are far fewer than that globally there are (potential, incidental or inexperienced) users of the MediaWiki software. Just saying. —TheDJ (talk • contribs) 10:54, 27 April 2016 (UTC)
- I think this is very unwise. "Publish" is not a good word and is confusing (especially for non-native English speakers who come here). "Save" (or "Post") is simple, direct, common, and easily understood. "Publish" is entirely inaccurate. How did the word "publish" get so corrupted that someone wants to use it for single impermanent iteration of a Wikipedia page that could get reverted by someone else within seconds? Softlavender (talk) 13:35, 27 April 2016 (UTC)
- Actually, they've been talking about this for years, and multiple studies with users say that this change needs to be made. Inexperienced people consistently believe that "Save" means "Save inside my personal account, but don't show it on the web". And because of a lifetime of being told to "save early, save often", they often save before trying to do something that feels risky to them – like "Show preview". I'm looking forward to this change, because it looks like there will be less confusion for new editors and consequently less mess for the rest of us to clean up. Whatamidoing (WMF) (talk) 17:19, 28 April 2016 (UTC)
- @Whatamidoing (WMF): I can believe your argument about "save" versus "publish". But how the hell does "show preview" feel risky? Can you point me to these studies you're talking about? Thanks. BethNaught (talk) 07:07, 3 May 2016 (UTC)
- Our implementation of Show preview is different from any common UI paradigm in or out of a browser. In my experience it is unique to Wikipedia. The entire edit interface is like that, where clicking Back after a save inexplicably and counterintuitively drops you back into the editor. The whole damn thing seems clunky and 1980s-ish, which no doubt contributes to the difficulty of retaining editors from non-tech backgrounds. But that's off topic.
As for "save" vs "publish", I can only say that "publish" would have been less intuitive to me as a new editor, since I didn't come here to publish anything. That said, the uncertainty will be very short-lived for the new user. Absent any other button that looks like it will commit their edit, they will probably click Publish and discover what it does. I don't think the problem will turn off many editors who are motivated enough to last in this environment longer than a few days anyway. After a few edits, it won't matter if the button says save, publish, or XYZ; they will know where it is and what it does. ―Mandruss ☎ 07:49, 3 May 2016 (UTC) - Beth, there really isn't anything to read. Most of these are face-to-face studies, with a researcher and a user sitting down together and seeing whether the user can figure out how to edit a page, and ask them to talk about what they're doing and thinking. The researchers then summarize their notes, which – if we're lucky – eventually get posted to Commons, but (of course) not all the researchers are in the WMF, so not all of them think to do this. And even when the reports are published, the content is unfortunately as minimal as what I've just told you. For example, from a recent one study about the visual editor (still unpublished, AFAICT), the sole content about Save/Publish out of 17 slides is just seven words: "Confusion about whether 'save' also meant 'publish'". If you then go talk to the researcher, you can get more information, but there really isn't anything to read. It'd make a horrible source for supporting a claim in an article. As a result, what I know about "users feel that 'Show preview' is risky" is: users feel that 'Show preview' is risky. Maybe they worry that their computers crash easily? Maybe they had "save early, save often" drilled into them from any early age? Maybe it's just the order of the buttons (Save page, then Show preview, then Show changes)? I don't know. But that's the fact: many newbies feel like 'Show preview' is a risky button, so they want to do something 'safe', like saving their work, before they try it.
I also agree with Mandruss' comment: Experienced editors really don't look at the button anyway. This change is about getting people past their first couple of edits (well, and doing whatever makes Legal happy, of course). Whatamidoing (WMF) (talk) 17:18, 3 May 2016 (UTC)- One of the Asian Wikipedias - I think it's zh: - doesn't allow "Save page" until you've used "Show preview". --Redrose64 (talk) 18:02, 3 May 2016 (UTC)
- Yes, it's the Chinese Wikipedia. I suspect that experienced editors here would find that very annoying, but since Chinese is a dual-script wiki (the articles can be written in a mix of simplified and traditional characters, but displayed entirely in whichever one the reader prefers), that has probably saved them a lot of grief. It might make sense for all of the "language variant" wikis (Gan, Inuktitut, Kazakh, Kurdish, Serbian, Tajik, Uzbek) to try that. Whatamidoing (WMF) (talk) 18:11, 3 May 2016 (UTC)
- This is a very strange basis on which to make even fairly trivial UI changes. I don't see how, on the basis of the data you apparently have, you can say this is a "fact". It's a second-hand report of a handful of observations, with no information about how these test users were selected, whether this alleged confusion was a significant barrier to otherwise productive editing, or whether the use of "publish" as the button label actually reduced their confusion. Do an A/B test and show that it makes a difference in the aggregate for a reasonable sample of the actual user population and then roll out the change. Opabinia regalis (talk) 18:41, 3 May 2016 (UTC)
- One of the Asian Wikipedias - I think it's zh: - doesn't allow "Save page" until you've used "Show preview". --Redrose64 (talk) 18:02, 3 May 2016 (UTC)
- Our implementation of Show preview is different from any common UI paradigm in or out of a browser. In my experience it is unique to Wikipedia. The entire edit interface is like that, where clicking Back after a save inexplicably and counterintuitively drops you back into the editor. The whole damn thing seems clunky and 1980s-ish, which no doubt contributes to the difficulty of retaining editors from non-tech backgrounds. But that's off topic.
- @Whatamidoing (WMF): I can believe your argument about "save" versus "publish". But how the hell does "show preview" feel risky? Can you point me to these studies you're talking about? Thanks. BethNaught (talk) 07:07, 3 May 2016 (UTC)
- Actually, they've been talking about this for years, and multiple studies with users say that this change needs to be made. Inexperienced people consistently believe that "Save" means "Save inside my personal account, but don't show it on the web". And because of a lifetime of being told to "save early, save often", they often save before trying to do something that feels risky to them – like "Show preview". I'm looking forward to this change, because it looks like there will be less confusion for new editors and consequently less mess for the rest of us to clean up. Whatamidoing (WMF) (talk) 17:19, 28 April 2016 (UTC)
- Comment: apparently, this is just changing the default, which is overridable with the local MediaWiki: message. So there's no need to harangue the engineers if you don't want this to happen here. BethNaught (talk) 07:07, 3 May 2016 (UTC)
table
What is the value to make a table length freeform? It will be the entire length of the page section available. Does this make sense? Moscowamerican (talk) 04:49, 26 April 2016 (UTC)
- @Moscowamerican: If I understand question correctly, then answer is - it's by default. --Edgars2007 (talk/contribs) 07:21, 26 April 2016 (UTC)
- A table's logical dimensions are governed by the presence or absence of a caption, the number of rows and the number of cells per row; the HTML specs do not set a maximum for either of the latter two, but there is a maximum of one caption. The amount of content in each cell does not affect the logical dimensions.
- A table's physical dimensions (measurements in pixels) depend upon many factors, and are not consistent between browsers even when installed on the same computer. It is not a good idea to design a table for a particular width or height, since something as trivial as the fonts that are installed on the viewing user's computer can significantly alter the size of the text, and thus the amount of space occupied by that text, and hence the table dimensions. What looks good on your computer might not look good on mine, and certainly won't look the same on everybody else's. --Redrose64 (talk) 07:41, 26 April 2016 (UTC)
Oh. okay thank you (talk) (talk Moscowamerican (talk) 09:04, 28 April 2016 (UTC)
List instances of template
Is there a way to find all pages where a specific template is directly invoked (short of searching a database dump)? That is, places where {{example}} exists, but not pages where a template that transcludes Template:example, for example {{Transcludes example}}, is included. I'm guessing not, but it's worth a try. — crh 23 (Talk) 20:18, 26 April 2016 (UTC)
- @Crh23: try searching:
insource:/\{\{example/i
. --Edgars2007 (talk/contribs) 20:31, 26 April 2016 (UTC) - More specifically -
insource:/[^{][{]{2}[Ee]xample[}]{2}[^}]/
fredgandt 20:43, 26 April 2016 (UTC)- Out of interest, is there an advantage to using
/[Ee]xample/
over/example/i
or/[{]{2}/
over/\{\{/
? — crh 23 (Talk) 20:51, 26 April 2016 (UTC)- Since template names are case sensitive, searching insensitively (the i denotes this) is inadvisable. The rest of the changes I suggested filter out
{{{example}}}
and{{examples are awesome}}
etc. Specifying/[^{][{]{2}[Ee]xample[}]{2}[^}]/
is specifying:- "E" or "e" followed by "xample" where that word is preceded by two opening braces not preceded by any opening braces and followed by two closing braces not followed by any closing braces.
- The end result being only the exact results you want. What it doesn't do is account for the possible use of
<nowiki>...</nowiki>
or<pre>...</pre>
or the like, which would be an epic regex since the tags might not be immediately wrapping the template markup. fredgandt 23:33, 26 April 2016 (UTC) - Of course (I thought as falling asleep last night) there are a few cases where the template may be used in other templates that would result in preceding and/or following braces. fredgandt 10:51, 27 April 2016 (UTC)
- I just tried making it more specific and account for whitespace and the possibility of arguments that I completely forgot to account for before (derp), but the server(s) rejected it. It did however occur to me that the easiest and most effective way to find them (whatever they are) is to add a hidden tracking category to the template you're hunting. fredgandt 19:42, 29 April 2016 (UTC)
- Since template names are case sensitive, searching insensitively (the i denotes this) is inadvisable. The rest of the changes I suggested filter out
- Out of interest, is there an advantage to using
Removal of conversion templates from infobox that converts anyway?
This straddles technical and policy issues, so I'll keep it short. Are edits such as this one desirable since the template it's used in appears to automatically convert the measurements into the desired form anyway? (Related to my comments in this thread). Ubcule (talk) 20:35, 26 April 2016 (UTC)
- Template:Convert is called twice, (they all use convert), and that does not seem efficient. But don't worry about performance. Stylistically there could be made an issue concerning the "proper number of significant digits" to display (the previous version having three significant digits in the height), and another issue to debate could just be the "cleanliness" of having a straight input with no template. But the source sometimes mandates the template input (WP:Verifiability, and thus conversion (WP:Reliability), per MOS:CONVERSIONS. — CpiralCpiral 22:21, 26 April 2016 (UTC)
- @Cpiral: Thanks for the response; I'm still not 100% sure if I was in the right or not- I think your intended answer is that this doesn't really matter anyway?..!
- (FWIW, the reason I initially made the edits wasn't for performance or style reasons, but because someone had changed it from the template style to the plain style- without making clear the reasoning or the fact that the parent template still did the conversion anyway. If I'd known that, I might have had second thoughts in the first place).
- Ubcule (talk) 18:12, 27 April 2016 (UTC)
Possibly unfree file templates
I've just tagged a couple of files as possibly unfree at Wikipedia:Possibly unfree files/2016 April 26 but the templates aren't working on that page and the uploaders' talk pages. The file page template does however show up. I copied and pasted the template from the file page onto the talk pages. Cloudbound (talk) 21:50, 26 April 2016 (UTC)
- PUF has been closed. Please make your nominations at FFD. BethNaught (talk) 21:52, 26 April 2016 (UTC)
- I've added a {{deprecated template}} as this was not mentioned in the template or its documentation. Peter James (talk) 00:38, 27 April 2016 (UTC)
- BethNaught and Peter James, thanks for your responses. Cloudbound (talk) 17:19, 28 April 2016 (UTC)
Is it possible to fix my account create date?
Hi, I'm trying to figure out why my account has the wrong start date (it is probably connected to the switchover from UseModWiki to MediaWiki in 2002). This report says I started Jan 26, 2002. However my edit summary gives my first edit as September 24, 2001. Is there anyway this could be fixed? Manning (talk) 01:10, 27 April 2016 (UTC)
- Not from here, no. You would need to ask somebody with sysadmin rights - and they might refuse. The place to make such requests is phab:. --Redrose64 (talk) 10:03, 27 April 2016 (UTC)
Watchlist: pages that have changed
To indicate a change since last visit in items on a watchist, the tiny green dots (bullets) are not as immediately distinguishable from the tiny blue dots as would be yellow or amber dots. Would it not be better to use yellow or amber dots?
I think the previous discussion concentrated on the shape, not the colour, and so I make bold to raise the question again. Theodoxa (talk) 11:18, 27 April 2016 (UTC)
- Color was discussed as well. Other colors did not fit the scheme of the interface, while green ususally indicates change.
-- [[User:Edokter]] {{talk}}
13:47, 27 April 2016 (UTC)
My edit is not mentioned in the article history
Not sure whether to treat this for a bug - it is a minor inconvenience anyway. Still I thought I'd mention it as there could be room for improvement. I performed a minor edit to the article Aeroprakt A-32 Vixxen, changing "sped" to "speed" and "woulded" to "moulded". Thse modifications are reflected in the article - and that's what counts! - but are not visible in the article history. Neither does the edit show in the list of my "contributions". Mentioned for what it is worth... Thanks for taking care. Jan olieslagers (talk) 12:54, 27 April 2016 (UTC)
- Editor Ahunt made those edits in these changes. If you were trying to do the same thing at the same time and he saved first, your duplicate edits are ignored by the system. --David Biddulph (talk) 12:59, 27 April 2016 (UTC)
- (edit conflict) The changes were made by somebody else.[7] This is probably what happened: You clicked edit before the changes so you saw the old version in the edit box, but you saved after the other editor had already saved the same changes. That meant your edit made no change and became a null edit. Users are not informed of this but just see the previously saved article and assume they did it themselves. Null edits are not registered anywhere. PrimeHunter (talk) 13:02, 27 April 2016 (UTC)
- Pffieuw! Talking of a quick reaction! A clear explanation, too. If anything, it teaches me to type faster :) Many thanks! Jan olieslagers (talk) 13:04, 27 April 2016 (UTC)
Some API + javascript help needed
I want to add a link into toolbox portlet to Google with query text: "German Wikipedia's pagename". So I need make an API call to get dewiki pagename. Code, what I have come up with:
$(function () {
var req = new XMLHttpRequest();
req.open("GET", mw.config.get('wgScriptPath') + "/api.php?action=query&format=json&prop=langlinks&redirects=1&lllang=de&titles="+encodeURIComponent(title), false);
req.send(null);
var response = eval('(' + req.responseText + ')');
mw.util.addPortletLink(
"p-tb",
"https://www.google.com/search?q=" + response,
"google"
)});
I'm 100% sure, that above is completely wrong, at least the API part (but the query itself should be OK). So maybe somebody could translate that piece into working code. Would be nice, that
- the link doesn't show up, if there isn't dewiki article
- variable "response" should get PAGENAMEBASEd (remove parenthesis, if there are such). --Edgars2007 (talk/contribs) 16:14, 27 April 2016 (UTC)
// Guarantee that our dependencies are loaded
mw.loader.using( [ 'mediawiki.api', 'mediawiki.util' ], function() {
var api = new mw.Api( {
ajax: {
// Use a user agent, so that sysadmins can find you and tell you to fix your tool
headers: { 'Api-User-Agent': 'MyAPITool/1.0' }
} } );
api.get( {
// Use the new output structure of the api
formatversion: 2,
prop: 'langlinks',
lllang: 'de',
titles: mw.config.get( 'wgPageName' ),
redirects: true
} ).done( function( data ) {
if ( !data.query.pages[0].langlinks.length ) {
// no german langlink for this page
return;
}
var title = data.query.pages[0].langlinks[0].title;
// Strip parenthesis
title = title.replace( /\s\(.*\)/, '' );
// Add when page is ready
$( function() {
mw.util.addPortletLink(
'p-tb',
'https://www.google.com/search?q=' + encodeURIComponent( title ),
'google'
);
} );
} ); // add .fail promise if you want to handle errors
} );
Something like this should do it... I didn't test it, but it should show the general direction. —TheDJ (talk • contribs) 16:52, 27 April 2016 (UTC)
I wrote a script that does something like this a long time ago.User:Writ Keeper/Scripts/googleTitle.js.Basically, if I'm just trying to get the name of the page I'm on, I wouldn't bother with the API call-- just use the wgPageName variable (EDIT: Oh, crap, didn't realize you're looking for dewiki's article from enwiki. Well, nevermind, I'll just leave this for the record of my poor reading comprehension. Writ Keeper ⚇♔ 16:55, 27 April 2016 (UTC)mw.config.get("wgPageName")
is the right syntax these days, I think) and remove the parens/urlencode/whatever on my own.- Thanks, TheDJ! It works. --Edgars2007 (talk/contribs) 17:14, 27 April 2016 (UTC)
mobile view, interwiki and categories
I noticed something that puzzled me, and am curious to know if it's known, is it intentional, and what the community thinks:
I have an android device, with 2 browsers: an inbuilt one (not even sure how it's called: android shows it as "internet"), and google chrome. With the inbuilt one and with Brion's hack ("Mobile sidebar preview" in preferences => gadgets), I have 2 buttons under each article: "Talk" and "Read in other languages" (assuming article has interwiki), and no link to categories. with chrome on android, I have "Talk" and "Categories", but no interwiki. This happens regardless if I'm logged in or not. Can anyone corroborate? Is it something only I can see? And if others see the same thing, is this intentional? should I report a bug? (I noticed some other small discrepancies, e.g., some pages on some browsers show a folding "toc", while other pages/browsers don't). peace - קיפודנחש (aka kipod) (talk) 19:53, 27 April 2016 (UTC)
Can a template detect if it is called with an uncapitalized (lowercase) initial letter?
Is there any way a template can detect if it is called with an uncapitalized initial letter? E.g., could the (say) {{H}} template distinguish between being called as {{H}} and {{h}}? ~ J. Johnson (JJ) (talk) 23:15, 27 April 2016 (UTC)
- No; this isn't limited to templates either, this is a mediawiki built-in on Wikipedia (but not Wiktionary). Any page is case-insensitive in its first letter. MediaWiki sees Main page as exactly equivalent to main page. Intelligentsium 23:18, 27 April 2016 (UTC)
- I'm pretty sure a template invoking some specific Lua could, but am a learner and deathly tired so can't currently say exactly how. fredgandt 02:14, 28 April 2016 (UTC)
- The question comes down to where the case-flattening is done. E.g., a template {{mw}} exists, showing that the namespace tolerates uncapitalized names. And when a template (like articles) is reached via a redirect, the name actually called is displayed, so some kind of information about the called name comes through.
- Of course, if there is some way of distinguishing this, and some idiot applied that some where, then every thing we have told everyone about the first letter being case-insensitive would be wrong, and hell would break loose. So maybe I don't want to know? ~ J. Johnson (JJ) (talk) 18:26, 28 April 2016 (UTC)
- {{mw}} only displays lower case at top of the page because it transcludes {{lowercase title}} from {{Mw/doc}}. The real pagename is Template:Mw. PrimeHunter (talk) 18:42, 28 April 2016 (UTC)
- Also, Template:Mw and template:mw are exactly the same page - no redirection is performed. Try going to wp:vPT, which is a redirect - you'll see that it says at the top "(Redirected from Wikipedia:VPT) - the capitalisation was already adjusted before the redirect was acted upon. It might be possible (and I promise nothing here) for Lua code to be able to detect if a template (or other page) was reached via a redirect, but Lua cannot tell if capitalisation was altered in the ways I've just demonstrated. --Redrose64 (talk) 19:05, 28 April 2016 (UTC)
- Ah, I see. (I did forget about the transclusion.) Thank you all. ~ J. Johnson (JJ) (talk) 21:22, 28 April 2016 (UTC)
- It's possible for Lua modules to see what template they were called from by using
frame:getParent():getTitle()
, but there's no way at the moment to tell whether that template was accessed via a redirect or not. — Mr. Stradivarius ♪ talk ♪ 02:00, 30 April 2016 (UTC)
- @J. Johnson: - why do you ask? fredgandt 21:22, 28 April 2016 (UTC)
- I was curious. I stumbled across {{mw}}, and got to wondering. And it did occur to me that there might be a use for such a property in a narrow set specialized templates. But they're fairly dubious, so I am glad this property does not exist. ~ J. Johnson (JJ) (talk) 21:33, 28 April 2016 (UTC)
- Well as I said, Lua can read (and parse, and execute, and expand ...) the page content, so can (with effort) determine if the markup has an initial capital or not, but with no good reason to do it - meh.
A template could more easily correct itself by substituting a call to it with markup that's guaranteed to be one way or the other (if that was ever a concern). i.e.fredgandt 22:22, 28 April 2016 (UTC){{example|foo=bar}}
could be automatically replaced with{{Example|foo=bar}}
. Note: If either were called to be substituted, the case of the first letter wouldn't matter.
Search Contribs AFTER a Specific Date
Currently Wikipedia allows users to search contribs made before a specific month/year. However, when dealing with IP vandalism who hop around, it would be exceedingly useful to be able to search contribs made after a specific month/year (especially when combined with wildcard and range searches). Is this currently possible? If not, how do I go about suggesting it? Please ping me in reply. Thank you! EvergreenFir (talk) Please {{re}} 06:55, 28 April 2016 (UTC)
- Yes, go to their contribs page, click the "older 50" link, and then the "newer 50" link. Notice that the URL's query string now contains something like
&dir=prev&offset=20160427095616
(among other things). Here, thedir=prev
means "start at the specified date/time and go forwards in time from that point", andoffset=20160427095616
is the start point, formatted CCYYMMDDhhmmss, so this works out as 09:56:16, 27 April 2016. You can set your own start point by adjusting that to a different date and time, so to give all contributions made at or after 12:00, 1 April 2016 (UTC) you would use&dir=prev&offset=20160401120000
. --Redrose64 (talk) 11:38, 28 April 2016 (UTC)
As a matter of interest, with a certain gadget enabled (see the note below), it is possible to view the contributions of a range of IPv4 or IPv6 addresses, in the last N months. For IPv4, you would need to enter a range, say /24, but for IPv6 a single IP defaults to showing /64. Two examples follow. The first defaults to showing edits in the last month, while the second specifies edits in the last three months.
{{blockcalc|142.105.159.0/24}}
{{blockcalc|months=3|2601:188:0:ABE6:65F5:930C:B0B2:CD63}}
Total affected |
Affected addresses |
Given addresses |
Range | Contribs |
---|---|---|---|---|
256 | 256 | 256 | 142.105.159.0/24 | contribs |
Total affected |
Affected addresses |
Given addresses |
Range | Contribs |
---|---|---|---|---|
1 /64 | 1 /64 | 1 | 2601:188:0:abe6::/64 | contribs |
Johnuniq (talk) 12:01, 28 April 2016 (UTC)
- @Johnuniq and Redrose64: Thank you both. I'll make sure I have that gadget enabled (I think I do) and that trick with the url query will work. It would be nice if we could get a less cumbersome way of doing it (like the dropdown menus for seeing edits before a certain date. EvergreenFir (talk) Please {{re}} 19:14, 28 April 2016 (UTC)
Watchlist getting stuck
For quite a while now, ever since the last big update, when I try to bring up my Watchlist it takes ages - much MUCH longer than bringing up Contributions or getting to the Main Page. But this afternoon I have been unable to even get to my Watchlist. Sorry if I missed the memo (lol) but does anyone know what is going on? Thanks, Shearonink (talk) 21:11, 28 April 2016 (UTC)
- I'm having this problem too, Safari 6.1.6 (yes, I know, haven't updated). I managed to log on using Chrome, deleted my watchlist, then tried logging in with Safari and had no problem. I started reloading the watchlist a bit at a time, and after adding all the As, which was okay, then the Bs and then I got a message telling me there are too many pages to load (the entire watchlist - all of it – is barely over 2000, so As and Bs is a small number). Have we stopped supporting old versions of Safari? Victoria (tk) 01:21, 29 April 2016 (UTC)
- Adding: I tried to go to my contribs to comment out the scripts I have on my .js and other pages and hung when I clicked "contribs" so I think it's more than the watchlist. Victoria (tk) 01:28, 29 April 2016 (UTC)
- Nice to know I'm not the only one. Haven't tried Chrome, am running on Safari atm, but haven't been able to access my Watchlist at all today. Is anyone else having this issue? Shearonink (talk) 03:09, 29 April 2016 (UTC)
- "Have we stopped supporting old versions of Safari?". Officially not yet, but that is probably because no one thought about taking that action yet. It is really hard to support older versions of Safari, because it is a tiny group of the userbase, and because it is very difficult for developers to run older versions of
Mac OSSafari (basically you need a 2nd mac that you don't upgrade). I would say that Safari 8 and up is what is effectively supported. —TheDJ (talk • contribs) 09:08, 29 April 2016 (UTC)- Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)
- You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talk • contribs) 09:17, 29 April 2016 (UTC)
Ok, thanks. The problem might not be with the browser, though, and I'm not sure how to respond to the "the reports like this … " part of this. I managed to load 500 pages back to the my watchlist and it worked, then it hung again when I loaded the next 100. So basically, just reporting that when I try to log in, when I try to view my watchlist, (and last night trying to view diffs, page history, and contribs) it hung. So there's an issue somewhere. Victoria (tk) 12:16, 29 April 2016 (UTC)Struck old - these conditions no longer apply. Victoria (tk) 21:37, 29 April 2016 (UTC)
- You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talk • contribs) 09:17, 29 April 2016 (UTC)
- Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)
- Since yesterday I've gone from being unable to view the watchlist, contribs, page histories, spent many hours trying to troubleshoot, and now get a complete freeze trying to log in. I think that it would nice if the three people posting to this thread who are experiencing similar difficulties could have a little more troubleshooting help other than being told that the browser isn't supported, please update. I get update messages from other websites and usually I have months to do the updating. Here it has to be done after the fact. And in the meantime you're locked out. Victoria (tk) 21:37, 29 April 2016 (UTC)
- Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)
- Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)
- The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talk • contribs) 17:37, 30 April 2016 (UTC)
- Hi TheDJ, that's a good point. While logged out I went the main page and clicked today's featured article, clicked through the first link, tried to click that page's history and froze. Also, while logged out, I went from the TFA to the German version, was able to click through a few links, and was able to open the page history without freezing. I can log into Commons and load my watchlist there. I was also able to click history on a file without freezing. So it seems to be an issue with en.wp. Basically if I click anything that's blue here, whether or not I'm logged in, it freezes and I have a very hard time getting out of the freeze. My concern is not so much whether I can edit, because I haven't been much recently, but whether it's feasible to add some sort of notification to anyone using Lion/Safari 6.xx that Wikipedia doesn't support the browser, instead of causing an ugly freeze. P.s trying to preview causes in edit conflict, so apologies for mistakes. Also, thanks for filing the bug report. Victoria (tk) 18:20, 30 April 2016 (UTC)
- Hm, that is strange. Do you have any Gadgets enabled in your preferences per chance ? —TheDJ (talk • contribs) 19:53, 30 April 2016 (UTC)
- TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)
- Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talk • contribs) 23:04, 30 April 2016 (UTC)
- TheDJ, yeah I've hacked at it a bit too since Friday and it does show very odd and inconsistent results, but I've been doing a lot of cache-clearing and restarting, which might have something to do with it. The thing is, my machine isn't ancient - 2012 model Macbook pro – and I chose to skip the Mavericks update because it had problems when released. If we're finding these issues on the other wikipedias then I have to wonder how many people in the world run four-year-old machines who haven't updated in two years and are experiencing these freezes/crashes and if that's what we want? I don't have any issue with other major websites at all yet – only here. If I want to edit here I'll use Chrome as Diannaa suggests above until I get around to doing the necessary backing up (I have tons of files ). Thanks for spending time with this. Victoria (tk) 01:15, 1 May 2016 (UTC)
- Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talk • contribs) 23:04, 30 April 2016 (UTC)
- TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)
- The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talk • contribs) 17:37, 30 April 2016 (UTC)
- Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)
- Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)
- Root cause found. I knew this started to sound somewhat familiar. Together with valhallasw, I reported this issue to both Safari and Chrome before (but neither ticket was ever closed it seems). It's apparently fixed in newer versions of Safari and Chrome, but not in old versions of course. We saw something similar happened in august 2015. —TheDJ (talk • contribs) 09:24, 1 May 2016 (UTC)
- I have the same problem. I'm using Safari 6. Everything is working good in my Wikipedia account (Talk, Sandbox, Preferences, Beta, Read Edit, View History) except when I go to my "Contributions" and Watchlist", my wiki page hangs/freezes and unable to proceed.--Richie Campbell (talk) 02:48, 2 May 2016 (UTC)
- I was having this problem yesterday on iOS7. Updating the iPad to 9.31 cleared it up, though this option won't be available to everyone.LeadSongDog come howl! 13:28, 2 May 2016 (UTC)
- Update: TheDJ - I'm now on Mavericks and using Safari 7.0.6. Bad news is that it still freezes - i.e. if I try to load the history of a page it freezes (with the swirling colored circle). Good news is that it's a softer freeze - I can back out of it, I can close Safari, all things I couldn't do with Safari 6. To digress slightly, the update to Mavericks was done after a lot of backing up, researching El Capitan and a trip to the Apple store where I was advised that these machines designed for Lion don't do great when updating all the way to Yosemite or El Capitan, so we compromised. Mavericks will allow me to go all the way to Safari 9 (a big jump), which I'll do in a few days, but I'd like to hack around with this first and see what else I find. I've not yet tried to replace my watchlist. Victoria (tk) 15:33, 2 May 2016 (UTC)
- We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talk • contribs) 17:39, 2 May 2016 (UTC)
- TheDJ thanks for putting in the patch. I'm not sure what's happened, but I had all of two pages on my watchlist, was able to log in this morning, and now can't get past the log in screen without the hard freeze again. I deleted the two pages from my watchlist (using Chrome) and was able to get back in, but I don't think it's quite there yet for Safari users. Victoria (tk) 20:26, 2 May 2016 (UTC)
- We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talk • contribs) 17:39, 2 May 2016 (UTC)
Watchlist & contribs corruption
I imagine this is relevant to a discussion above: Watchlist getting stuck. I've got Mac OS X Lion 10.7.5 [with Safari 6.1.6 (7537.78.2)] and keep getting a "some webpages are not responding" message whenever (and only when) I try to check my WP watchlist and contributions. Any other activity on Wikipedia, e.g. accessing mainspace or pages such as this, or online generally is fine. The same error message was identified on apple.com back in January 2014; for me it's only been an issue in the last two days. Has something changed on Wikipedia in that time? I also use an ancient iPad, btw, but I can access Watchlist, etc. no problem on that. Frustrating – but my question is, why is this suddenly an issue? Cheers, JG66 (talk) 14:13, 30 April 2016 (UTC)
- Because the code of website has a couple hundred changes per week, and because old browser are not as capable as new browsers. Oh and because browsers have hundreds and hundreds of bugs in them. And apparently those conditions came together to create a problem :) —TheDJ (talk • contribs) 18:01, 30 April 2016 (UTC)
- Btw, I have Mac OS X Lion 10.x.x & have been running a higher version of Safari than yours. At this point I've given up using Safari to access my Watchlist - Chrome works but it's annoying to have to switch between the two. Would be nice to know why the Watchlist has been misbehaving - but apparently only for Safari users. Shearonink (talk) 03:28, 1 May 2016 (UTC)
Template:Not English/dated prodding pages?
I noticed that the pages User:Chole72/sandbox, Draft:Detective Willy, and User:Fc20/Sequência algorítmicamente aleatória all now show up in Category:Proposed deletions needing attention, due to them being non-articles with prod tags. In each case, the last edit to the pages was an edit by AnomieBOT on November 14, 2015 to subst Template:Not English/dated. It seems that it is that template which is adding the prod tags, but somehow it seems to be malfunctioning. Can someone with more knowledge of templates than me figure out what is going on and how to get the template to stop prodding these pages (being outside article space, they aren't eligible for prod)? Also, should the template even be prodding anything at all? A prod tag is supposed to be able to be removed by anyone for any reason, but in this case when you go to edit the pages, there isn't even a prod tag there to remove. I suppose someone could object to the proposed deletion by editing or removing the Not English template, but I personally don't think obfuscating how to object to prods is a good idea. Calathan (talk) 15:15, 29 April 2016 (UTC)
- It looks like User:Liz has removed the Non English template from the pages, which means they are currently no longer proposed for deletion. However, I'm still hoping someone who understands templates can figure out why the template was placing the prod tags on them. Looking at the template code (which I don't understand well), I think the template was supposed to prod them after 14 days, but instead it was prodding them after about 6 months. I would still prefer that it doesn't try to prod them at all. Calathan (talk) 17:50, 29 April 2016 (UTC)
- Yes, I removed the PROD tags and posted a note on Anomie's talk page about it. I think the problem was that the {{Not English}} tags had a timestamp which is unusual for a simple tag. Then, they turned into expired PRODs. Since PRODs are not used on User or Draft pages, PRODs are not appropriate deletion tools for these pages. Liz Read! Talk! 17:54, 29 April 2016 (UTC)
I just did some more searching around, and I think I've figured out more about what is going on here. Based on Template talk:Not English#Dated, User:Rayukk tried to make Template:Not English propose articles for deletion after 14 days, and about a day later User:Jac16888 disagreed with that change and undid it. Template:Not English/dated was something Rayukk made to implement this, and Template:Not English was only using the dated template for a brief time until Jac16888 undid the change. So the pages that are getting prodded are just those where Template:Not English was substituted during that brief period of time. I think all that needs to be done is to replace Template:Not English/dated on any page that uses it with the current version of Template:Not English. I'll go ahead and do that. The issue with Template:Not English/dated prodding pages is basically moot, since that template shouldn't actually be used anywhere. Calathan (talk) 18:29, 29 April 2016 (UTC)
- Actually, I need to get to work (on my actual work, not Wikipedia), but if someone else could go through the pages that link to Template:Not English/dated and change them to use the normal Template:Not English, I think that would solve the problem. If no one else has time, I'll try to do that when I have more time. Calathan (talk) 18:40, 29 April 2016 (UTC)
- Sorted, in most cases I just removed it, it's only left now on a few testing pages--Jac16888 Talk 19:42, 29 April 2016 (UTC)
- Template:Not English/dated has now been sent to WP:TFD. GeoffreyT2000 (talk) 04:15, 30 April 2016 (UTC)
- Sorted, in most cases I just removed it, it's only left now on a few testing pages--Jac16888 Talk 19:42, 29 April 2016 (UTC)
Notifications glitch?
I just receive an errant notification "Uncle Milty mentioned you on Wikipedia:Articles for deletion/Bocconi Toastmaste..." The notification links to the closed AfD in which my username does not appear. The edit by Uncle Milty mentions Bbb23, but not me. Does anyone know what might have caused this?- MrX 22:17, 29 April 2016 (UTC)
- The cause is an accidental transclusion, like the one that caused /Archive 145#Bogus alerts. --Pipetricker (talk) 22:43, 29 April 2016 (UTC)
- I too was pinged, but nowhere in the diff or the page do I see my name. [8]—cyberpowerChat:Online 22:47, 29 April 2016 (UTC)
- The attempted user-linking
{{User:Bbb23}}
in that diff caused the page User:Bbb23 to be transcluded, and your signature (with a link to your user page) is on that page. --Pipetricker (talk) 23:06, 29 April 2016 (UTC)- You can transclude pings? Oh wow, am I going to have fun with that!- MrX 00:33, 30 April 2016 (UTC)
- Yes, otherwise the {{ping}} template wouldn't work. Unfortunately, with wikitext there's no easy way to tell whether a transclusion was accidental or not, leading to problems like this one. To mitigate this somewhat there is an upper limit on the number of users you can notify in one edit (I think it is 50 at the moment). By the way, if you find yourself pinging the same 50 users a lot, you might consider using {{mass notification}}, which makes the process (rather scarily) efficient. — Mr. Stradivarius ♪ talk ♪ 01:12, 30 April 2016 (UTC)
- Ping is always preceded by u| so looks like it isn't a notification problem. 49.148.4.159 (talk) 14:14, 2 May 2016 (UTC)
{{u|Example}}
is just one of the ways to make a link to a user page to cause a ping, but wasn't involved here. --Pipetricker (talk) 16:34, 2 May 2016 (UTC)
- You can transclude pings? Oh wow, am I going to have fun with that!- MrX 00:33, 30 April 2016 (UTC)
- The attempted user-linking
- I too was pinged, but nowhere in the diff or the page do I see my name. [8]—cyberpowerChat:Online 22:47, 29 April 2016 (UTC)
Checklinks
Why is not working [9]? Xaris333 (talk) 14:35, 30 April 2016 (UTC)
- What is not working for you? I see the interface and headings but as expected no list of links since Atromitos Yeroskipou has no external links. PrimeHunter (talk) 16:16, 30 April 2016 (UTC)
Sorry. I was using the Greek version. [10] Xaris333 (talk) 16:46, 30 April 2016 (UTC)
- The tool appears to be broken for some foreign languages. There is a report about Romanian at User talk:Dispenser#Checklinks. Checklinks is made and run by Dispenser. PrimeHunter (talk) 21:01, 30 April 2016 (UTC)
Deleted pages
On my last few runs of tagging uncategorized articles for the categorization project, the list has been polluted with several phantom entries for non-existent pages, as well as one page which does exist and is properly categorized, but will not drop from the list no matter what I do — a null edit won't work; decategorizing it and recategorizing it again won't work; and even the trick of last resort, deleting and then restoring the page, won't work.
The common element to the deleted pages is that they were all deleted on April 22 — and the page which does exist is a recreation of a page that was previously deleted, again on April 22. So clearly some kind of data corruption issue occurred on that date.
The articles are: Graffiti in Early Modern England, How to create wikipedia page, Ideographic world, LinksManagement, Redmoments, Revatha College, Balapitiya and Rvijayjha.
The last time I reported an issue like this, I was forced to tolerate the phantom titles as permanent speedbumps of the list, which had to be repeatedly worked around for six full months before they finally got cleared from the list. In order to properly work with this tool, however, I need it to be clean. I'm willing to wait a few days of delay if need be, but I will not tolerate it taking six months to get these entries off the list again: this needs to be fixed as close as feasibly possible to right away. Bearcat (talk) 01:09, 1 May 2016 (UTC)
- @Bearcat: are you showing something in side of enwiki being wrong, or just in that wmflabs tool? If only on the tool please contact its maintainer here: User_talk:JaGa. — xaosflux Talk 01:16, 1 May 2016 (UTC)
- The last time this came up, the issue was not with the tool, but with corruptions within the data that enwiki was feeding to it — JaGa was completely unable to do anything about it the last time, because the tool wasn't the problem and it had to be fixed on this end. Bearcat (talk) 01:18, 1 May 2016 (UTC)
- Thank you, so to be clear - everything inside of enwiki looks fine, correct? The tool maintainer may need to help identify what is going on - there could also be a database replication problem on the copy at wmflabs. — xaosflux Talk 01:28, 1 May 2016 (UTC)
- I noticed something similar the other day and commented at phab:T115517#2248620. Anomie⚔ 22:39, 1 May 2016 (UTC)
- Thank you, so to be clear - everything inside of enwiki looks fine, correct? The tool maintainer may need to help identify what is going on - there could also be a database replication problem on the copy at wmflabs. — xaosflux Talk 01:28, 1 May 2016 (UTC)
- The last time this came up, the issue was not with the tool, but with corruptions within the data that enwiki was feeding to it — JaGa was completely unable to do anything about it the last time, because the tool wasn't the problem and it had to be fixed on this end. Bearcat (talk) 01:18, 1 May 2016 (UTC)
Is it malicious ?
Preview says:
Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.
What it was inserted was
/* Hide TemplateData from your display */
.templatedata-header,
.mw-templatedata-doc-wrap,
.tdg-editscreen-main {
display: none;
}
I dont think it is capable of compromising one's account. --にょろん (talk) 13:07, 1 May 2016 (UTC)
Tech News: 2016-18
20:09, 2 May 2016 (UTC)
Watchlist message problems
Please see MediaWiki talk:Watchlist-details I think something screwy is going on with the styling for this tag. — xaosflux Talk 02:46, 3 May 2016 (UTC)