→WikiMiniAtlas: Dschwen |
→Aren't article talk pages meant to be no indexed?: there is a technical difference, but the result is often the same. |
||
Line 671: | Line 671: | ||
::::I agree it's quite strange that Google used to ignore article talk pages but not userspace pages. The last community discussion on what should and should not be no-indexed was some time ago and probably needs to be updated; I'm not sure where is the proper venue for such discussion. |
::::I agree it's quite strange that Google used to ignore article talk pages but not userspace pages. The last community discussion on what should and should not be no-indexed was some time ago and probably needs to be updated; I'm not sure where is the proper venue for such discussion. |
||
::::Also on the subject of no-indexing, does anyone have any insight regarding the question I asked [[User:Newyorkbrad/Newyorkbradblog#A_question_about_searchability.2C_robots.txt.2C_and_NOINDEX|here]]? Thanks, [[User:Newyorkbrad|Newyorkbrad]] ([[User talk:Newyorkbrad|talk]]) 13:38, 6 August 2013 (UTC) |
::::Also on the subject of no-indexing, does anyone have any insight regarding the question I asked [[User:Newyorkbrad/Newyorkbradblog#A_question_about_searchability.2C_robots.txt.2C_and_NOINDEX|here]]? Thanks, [[User:Newyorkbrad|Newyorkbrad]] ([[User talk:Newyorkbrad|talk]]) 13:38, 6 August 2013 (UTC) |
||
:::::There is a small difference between them. robots.txt means "don't crawl trough this part of my website". The no indexing part is a side effect of the not crawling. Robots.txt is useful to avoid excessive usage by Google of our resources, where it is of no use to them anyways. NOINDEX means just that "you are free to look at this page, as long as you don't make it part of your public index". It might be that information on such pages is still used for instance for pagerank algorithm scores of indexed pages (not sure about that, but I wouldn't be surprised). Since pages are often available with multiple urls these days, I think that is why google is advising the NOINDEX as the 'go to' technique. Plus they still get to analyze your page as a bonus :D —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 09:32, 7 August 2013 (UTC) |
|||
* I would support adding talk pages to robots.txt but not forcing a NOINDEX on each and every one of them. I would also support adding anything in certain project spaces such as [[WP:AFC]] drafts (although "''most''" should be covered by a full scale inclusion of all talk pages, there are a few that get misplaced in [[Special:PrefixIndex/Wikipedia:Articles for creation|Wikipedia:Articles for creation/]] (starting on page three)). [[User:Technical 13|Technical 13]] ([[User talk:Technical 13|talk]]) 14:30, 6 August 2013 (UTC) |
* I would support adding talk pages to robots.txt but not forcing a NOINDEX on each and every one of them. I would also support adding anything in certain project spaces such as [[WP:AFC]] drafts (although "''most''" should be covered by a full scale inclusion of all talk pages, there are a few that get misplaced in [[Special:PrefixIndex/Wikipedia:Articles for creation|Wikipedia:Articles for creation/]] (starting on page three)). [[User:Technical 13|Technical 13]] ([[User talk:Technical 13|talk]]) 14:30, 6 August 2013 (UTC) |
Revision as of 09:32, 7 August 2013
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.
Google indexing sandboxes?
I was astonished to discover that Google is indexing my sandbox. I'm sure there's been controversy about whether user page and user talk pages should be indexed, but it seems to me that there should be no controversy here, given what the sandbox is for. (I actually don't believe that. Of course there will be controversy.) So, should sandboxes (and their subpages) be by default not indexed, without the user having to do anything to make it that way? EEng (talk) 22:47, 24 July 2013 (UTC)
- By default User: pages are indexed; it's opt-out. Personally I use
{{userpage|noindex=yes}}
on my main user page and{{User Sandbox}}
on my sandboxes; but a simple__NOINDEX__
will also work. --Redrose64 (talk) 23:01, 24 July 2013 (UTC)- Look, I know all that. I didn't ask how to make my sandbox unindexed. What I said is that perhaps sandboxes (which are specifically for drafts, experiments, and other stuff clearly not for public consumption) should be unindexed by default. As an alternative maybe an edit notice on sandboxes should remind the user that the content is indexed by default and explain (as above) how to block indexing; in fact maybe such an editnotice should pop up for all userspace pages -- sandboxes for sure. Just a thought. EEng (talk) —Preceding undated comment added 23:47, 24 July 2013 (UTC)
- Is it currently possible to noindex user sandboxes which don't have
__NOINDEX__
on them, and without noindexing all of userspace? It doesn't appear from http://www.robotstxt.org/robotstxt.html that our robots.txt at http://en.wikipedia.org/robots.txt can say something like "For all *, noindex en.wikipedia.org/User:*/sandbox". Does MediaWiki have a feature to automatically add a noindex tag to each such page? Not that I'm aware of. PrimeHunter (talk) 00:11, 25 July 2013 (UTC)- One other point (just to give a specific motivation): that "temporary" BLP violations are tolerated in userspace drafts, and that userspace is generally below the radar for patrolling and whatnot, are both additional reasons such stuff shouldn't be indexed. But putting it that way, almost everything in userspace shouldn't be indexed since it's hard to tell what's an article draft and what's something else. Dunno. Just pointing out a potential problem. EEng (talk) 04:35, 25 July 2013 (UTC)
- The problem here is there is not entity called 'sandbox'. It's simply a subpage of a userpage. These are indexed by default. Getting them non-indexed (by default) from the English wikipedia setup is indeed rather difficult I think. I can't find any interface messages that are included an such a page that we could abuse for it. And wildcarding is also not possible. —TheDJ (talk • contribs) 08:35, 25 July 2013 (UTC)
- "Temporary" BLP violations are not tolerated in userspace drafts: the BLP policy also applies to user and user talk pages. That some slip under the radar indicates either that recent changes patrollers are not aware of the policy, or that they are not patrolling everything they should: by default, Special:RecentChanges lists all namespaces, so it takes a conscious effort to patrol only, say, articles in mainspace. --Redrose64 (talk) 14:37, 25 July 2013 (UTC)
- You're nuts if you think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles. But forget BLP -- it was just one specific consideration. Anyway, I was making a suggesting that I thought would improve things. If it's not technically feasible, that's that. But pretending that the status quo is just fine might be called looking at things through redrose-colored glasses. EEng (talk) 21:03, 25 July 2013 (UTC)
- I don't 'think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles'; but that's not what I said. My point was that WP:BLP applies everywhere - it's not selective. This is because some people just don't appreciate that once something has been posted on the internet, it's there for all the world to see, and there's nothing that can be done to turn back the clock. An internet page is a published work, even if it's still in draft; libel is libel, regardless of where or how it's published. --Redrose64 (talk) 22:24, 25 July 2013 (UTC)
- Oh, for heaven's sake! (a) if you really think it doesn't matter where and how something potentially libelous is published, you really don't know what you're talking about; (b) not that it matters, because BLP was just a side point, as already mentioned. I'm sorry I bothered to make the suggestion. EEng (talk) 03:15, 26 July 2013 (UTC)
- You asked a question; I tried to help; I might not have asked for thanks, but I certainly didn't ask for my advice to be stuffed right back in my face. But it seems that you have some problem with me. --Redrose64 (talk) 11:20, 26 July 2013 (UTC)
- Oh, for heaven's sake! (a) if you really think it doesn't matter where and how something potentially libelous is published, you really don't know what you're talking about; (b) not that it matters, because BLP was just a side point, as already mentioned. I'm sorry I bothered to make the suggestion. EEng (talk) 03:15, 26 July 2013 (UTC)
- I don't 'think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles'; but that's not what I said. My point was that WP:BLP applies everywhere - it's not selective. This is because some people just don't appreciate that once something has been posted on the internet, it's there for all the world to see, and there's nothing that can be done to turn back the clock. An internet page is a published work, even if it's still in draft; libel is libel, regardless of where or how it's published. --Redrose64 (talk) 22:24, 25 July 2013 (UTC)
- You're nuts if you think a userspace subpage tagged "under construction" is going to be held to the same standard as live articles. But forget BLP -- it was just one specific consideration. Anyway, I was making a suggesting that I thought would improve things. If it's not technically feasible, that's that. But pretending that the status quo is just fine might be called looking at things through redrose-colored glasses. EEng (talk) 21:03, 25 July 2013 (UTC)
- "Temporary" BLP violations are not tolerated in userspace drafts: the BLP policy also applies to user and user talk pages. That some slip under the radar indicates either that recent changes patrollers are not aware of the policy, or that they are not patrolling everything they should: by default, Special:RecentChanges lists all namespaces, so it takes a conscious effort to patrol only, say, articles in mainspace. --Redrose64 (talk) 14:37, 25 July 2013 (UTC)
- The problem here is there is not entity called 'sandbox'. It's simply a subpage of a userpage. These are indexed by default. Getting them non-indexed (by default) from the English wikipedia setup is indeed rather difficult I think. I can't find any interface messages that are included an such a page that we could abuse for it. And wildcarding is also not possible. —TheDJ (talk • contribs) 08:35, 25 July 2013 (UTC)
- One other point (just to give a specific motivation): that "temporary" BLP violations are tolerated in userspace drafts, and that userspace is generally below the radar for patrolling and whatnot, are both additional reasons such stuff shouldn't be indexed. But putting it that way, almost everything in userspace shouldn't be indexed since it's hard to tell what's an article draft and what's something else. Dunno. Just pointing out a potential problem. EEng (talk) 04:35, 25 July 2013 (UTC)
- Is it currently possible to noindex user sandboxes which don't have
- Look, I know all that. I didn't ask how to make my sandbox unindexed. What I said is that perhaps sandboxes (which are specifically for drafts, experiments, and other stuff clearly not for public consumption) should be unindexed by default. As an alternative maybe an edit notice on sandboxes should remind the user that the content is indexed by default and explain (as above) how to block indexing; in fact maybe such an editnotice should pop up for all userspace pages -- sandboxes for sure. Just a thought. EEng (talk) —Preceding undated comment added 23:47, 24 July 2013 (UTC)
Since you bring it up I'll explain. There have been three times, to my memory, that I've made posts outlining (a) the way things are; and (b) why I think it would be an improvement to change that in some way. All three times you've appeared to recapitulate the way things are, ignoring the change I suggested.
- Example above: I said that sandboxes are indexed by default, and should be unindexed by default. You responded by explaining that Sandboxes are indexed by default (which is what I had just said in my original post, and was clearly the reason I made that post) and how I could make my sandbox unindexed, which completely missed the suggestion I was making, which is that they should be unindexed by default.
- In the earlier discussion you linked [1], I pointed out that < reflist > outputs its entries in essentially random order, and that it would useful to be able to control that order, but still get the automatic numbering etc of the < ref > machinery. You responded by explaining that < reflist > outputs in essentially random order (which I obviously already knew, because I said so in my original post) and pointed me to a help page describing a completely unworkable, fragile approach requiring manual numbering of everything, so that if any cite is inserted or deleted all the other numbers have to be manually adjusted throughout the article -- as if somehow that answered the proposal of my post
- In yet another discussion [2], I asked how, when using a citation template, one might include multiple ISBNs (as when there are paperback and hardcover editions with identical pagination, which is very common). Instead of just explaining how to do it (which eventually turned out to be very simple) you and others put a lot of effort into explaining why I shouldn't want multiple ISBNs in one citation. It's infuriating for some research-naive macro-expert technocrats to withhold details on how to do something because their erroneous ideas convince them I should "only supply the ISBN of the volume I actually consulted".
In sum you have an annoying habit of trying to explain why people shouldn't want to do what they want to do, or should get along with current painful and inadequate facilities, instead of addressing the request being made. EEng (talk) 23:42, 28 July 2013 (UTC)
- Sandboxes are noindexed by default. A page that doesn't have {{user sandbox}} isn't a sandbox, it's a subpage; the software can't magically know what you intend to use a subpage for. (As for the rest, could the two of you please take it to WP:DR or something?) --NYKevin 13:21, 2 August 2013 (UTC)
- Defining the problem away doesn't solve the underlying problem. I was aware of the definitional problems from the beginning. At this point my recommendation would be that User: and User Talk: spaces simply be unindexed, period (or at least by default) -- not sure what purpose is served by indexing user page and user talk pages anyway, and this solves the sandbox problem too. If something is ready for public consumption, it ought to be in article space. But I've put much more effort into this minor issue than I care to. BTW there's no dispute between me and RedRose -- he sensed I'm annoyed with him so I explained why. EEng (talk) 15:05, 2 August 2013 (UTC)
Migrate the "Remove VisualEditor from the user interface" gadget to the "Temporarily disable VisualEditor while it is in beta" preference
Let's migrate the "Remove VisualEditor from the user interface" gadget to the "Temporarily disable VisualEditor while it is in beta" preference. This is possible by making the gadget toggle that preference and disable itself via the action=options API and would be trivial to implement (or you could ask ops to make that change directly in the database, but that might not be feasible).
The rationale is obvious – that gadget only fires after VE is loaded (so it's a performance issue) and is not supported by the developers (so it could break surprisingly again, as it already has a few times).
Thoughts? Matma Rex talk 19:19, 25 July 2013 (UTC)
Oh, by the way, this isn't a strawpoll, but a technical question to the technical people, since this is the technical section of the village pump. Matma Rex talk 19:20, 25 July 2013 (UTC)
- Why not simply remove it? — Edokter (talk) — 12:22, 27 July 2013 (UTC)
- The downside is that the WMF have stated the intent of removing their preference for VE at any time. The gadget will be needed later, I suspect. Adam Cuerden (talk) 17:57, 28 July 2013 (UTC)
MediaWiki_talk:Gadget-oldeditor.js#Edit_request. Matma Rex talk 14:24, 2 August 2013 (UTC)
Revision history - Number of watchers
Want to say the changes made to the Revision history specifically the "Number of watchers" link is a great and wonderful idea - I see only positive from the decision. Not sure who to thank ... so posting here. I do have a question...would it not be a good idea to change the name of the link at the top " Revision history" pages to say "page information" as this is what they now contain. This would then also negate the need to redirect and highlight to the section "Number of page watchers" as i believe most will find it in the end. Changing the title will also inform editors and readers alike that much more info can be found through the link then just the number of watchers as it now implies.-- Moxy (talk) 01:59, 27 July 2013 (UTC)
- You're welcome. :-)
- The relevant discussion about changing the page history link is here: Wikipedia:Village pump (technical)/Archive 114#MediaWiki:Histlegend and the watcher tool.
- The "Page information" link is always available in the sidebar. The only reason we're keeping the watchers link on the page history is for historical reasons, really. It's no longer an external tool and it's already available from the sidebar (via the "Page information" link), but users have been trained to find the number of page watchers from the page history, so a link has been retained there. Unlike the sidebar "Page information" link, the "Number of watchers" link now highlights the specific table row and anchors the browser window if possible. --MZMcBride (talk) 05:14, 27 July 2013 (UTC)
- I would like to see that updated to the number of active watchers. At this page, there are more than 35 inactive users "watching" it for every active user. WhatamIdoing (talk) 16:58, 27 July 2013 (UTC)
- What is the defintion of an "inactive user"? XOttawahitech (talk) 21:28, 27 July 2013 (UTC)
- I would like to see that updated to the number of active watchers. At this page, there are more than 35 inactive users "watching" it for every active user. WhatamIdoing (talk) 16:58, 27 July 2013 (UTC)
Page Watchers Active Wikipedia:WikiProject Contents (talk) 1986 55
- πr2 (t • c) 03:05, 28 July 2013 (UTC)
- The problem with WhatamIdoing's link is that it's on Toolserver - you need to throw a six to start. --Redrose64 (talk) 11:15, 28 July 2013 (UTC)
- πr2 (t • c) 03:05, 28 July 2013 (UTC)
The error I get is "A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred."
/home/dispenser/public_html/cgi-bin/cursor.pyx in oursql.Cursor.execute (oursqlx/oursql.c:15932)() /home/dispenser/public_html/cgi-bin/cursor.pyx in oursql.Cursor.execute (oursqlx/oursql.c:15801)() /home/dispenser/public_html/cgi-bin/statement.pyx in oursql._Statement.prepare (oursqlx/oursql.c:7818)() /home/dispenser/public_html/cgi-bin/statement.pyx in oursql._Statement._raise_error (oursqlx/oursql.c:7425)()
-- Moxy (talk) 15:45, 28 July 2013 (UTC)
- I've gotten the same error before; just try again.
- I'm not certain of the definition of 'inactive user', but I believe that it's anyone with no edit or other action during that previous 30 days (might be 60 or 90, but I'm pretty sure that only one action during that timespan is required). WhatamIdoing (talk) 20:59, 31 July 2013 (UTC)
- I assume that an "inactive user" is one that isn't listed at Special:ActiveUsers, in which case it's 30 days. See also Special:Statistics. --Redrose64 (talk) 09:26, 2 August 2013 (UTC)
- Thanks for this info, Redrose64. I guess this means that an inactive user is one who has not contributed in the last 30 days? XOttawahitech (talk) 16:52, 3 August 2013 (UTC)
- I assume that an "inactive user" is one that isn't listed at Special:ActiveUsers, in which case it's 30 days. See also Special:Statistics. --Redrose64 (talk) 09:26, 2 August 2013 (UTC)
Email notifications
I don't know if this is a temporary glitch (the same preferences problem we had a while back?) but my notification emails have set themselves to HTML, not plain text. This seems to have happened sometime in the past 24h. Andrew Gray (talk) 23:19, 31 July 2013 (UTC)
I'm not aware of any preference to get HTML mails. They are always plain text as far as I know. What makes you identify them as HTML? If you see clickable links then it's probably your mail software which adds this to a plain text url. If you use a mail forwarding service then I suppose it might reformat the mails.PrimeHunter (talk) 00:38, 1 August 2013 (UTC)- mw:Echo (Notifications)/Feature requirements#HTML single email notifications does say: "We are planning to use HTML Email as the default format for all notifications, as soon as that feature is ready." mw:Echo (Notifications)/Feature requirements#HTML email digests says: "There will not be any email format preferences unless we hear a strong user demand for this". What type of notification mails is it? PrimeHunter (talk) 00:48, 1 August 2013 (UTC)
- Oh, I now see there actually is an email format preference at Special:Preferences#mw-prefsection-echo. PrimeHunter (talk) 00:53, 1 August 2013 (UTC)
- These were enabled as of about 24 hours ago. Risker (talk) 00:55, 1 August 2013 (UTC)
- AFAIK the first I heard of it was at m:Meta:Babel#HTML Email Notifications are live --Redrose64 (talk) 06:29, 1 August 2013 (UTC)
- Thanks for the pointer; I'll leave a note there. When I saw the preferences button I assumed it had always been there :-) Andrew Gray (talk) 11:39, 1 August 2013 (UTC)
I've just turned it off; as I cautioned when this was first discussed, the email was full of unnecessary bloat. For example, for a nine-words-plus-links mail, before the first character of thoss words, was:
<html><head></head><body> <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" width=3D"100%" alig= n=3D"center"> <tr> <td bgcolor=3D"#E6E7E8"><center> <br /><br /> <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" width=3D"600"> <tr> <td bgcolor=3D"#FFFFFF" width=3D"35"> </td> <td bgcolor=3D"#FFFFFF" width=3D"61"> </td> <td bgcolor=3D"#FFFFFF" width=3D"469" style=3D"line-height:40px;"> = ;</td> <td bgcolor=3D"#FFFFFF" width=3D"35"> </td> </tr><tr> <td bgcolor=3D"#FFFFFF" width=3D"35" rowspan=3D"2"> </td> <td bgcolor=3D"#FFFFFF" width=3D"61" align=3D"center" valign=3D"top" ro= wspan=3D"2"><img src=3D"http://bits.wikimedia.org/static-1.22wmf12/extensio= ns/Echo/modules/icons/Talk.png" alt=3D"" height=3D"30" width=3D"30"></td> <td bgcolor=3D"#FFFFFF" width=3D"469" align=3D"left" style=3D"font-fami= ly:arial; font-size:13px; line-height:20px; color:#6D6E70;">
Note the inclusion of http://bits.wikimedia.org/static-1.22wmf12/extensio= ns/Echo/modules/icons/Talk.png which means calls back to the server when I open my mail.
I fail to see why forcing this on people is thought acceptable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 2 August 2013 (UTC)
- This is not being "forced" on anyone. There is a very simply plain text or HTML preference under Notifications preferences, and it's even mentioned in the emails themselves. This is the default because it's far more readable. Most humans on the Web are just fine with having HTML email, considering they use modern web, mobile, and desktop clients that are easily able to handle calling a single image. Not to mention the fact that most users are not technical enough to know or care whether things like the Talk icon are called from the server or embedded etc. Steven Walling (WMF) • talk 20:48, 2 August 2013 (UTC)
- And that preference was set to HTML, not by me. Ergo, the above email was forced on me. You have the ability to force that that on users, and apparently the authority to force that on users; and you clearly believe that you have the justification to force it on users. But please do not pretend that you did not do so. We were also told a while ago that the option would not persist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:05, 2 August 2013 (UTC)
- As it's a binary preference that (as I understand it) has only come into existence, the alternative was forcing all users to receive plain-text emails; either way you're going to have to "force" a decision on their behalf. Most people are happy with HTML mail; I don't think the preferences of a small group (including you and I) should be able to block a change that is uncontentious for the vast majority. Andrew Gray (talk) 11:00, 3 August 2013 (UTC)
Overwriting sections
I now know of two cases where I have accidentally overwritten sections, thus removing information. The first one I found was at Joan Armatrading where I overwrote a section in October 2012 and then put it back in February 2013. Just today (UTC) I discovered that I did something similar to the Blindness article in March 2008! As I'm obsessive (some would say paranoid) about article integrity, the fact that I, an experienced admin, have managed to make this mistake *twice* without it being detected frankly scares the heebie-jeebies out of me. I'd like to find out:
- Am I the only one who's done this? Is the fact that I've managed to do this so easily an artifact of my screen reader use (because I don't actually see a physical model of the screen)?
- Is there any way to detect other instances like the ones I've described above (either by me or others)? I personally haven't done much article expansion (except last year with Paralympic-related articles, where this problem almost certainly didn't occur. But I wonder if we've lost any other article text this way?
I don't really expect concrete, definite answers (especially to the second question). I'm also not too sure if this is the right place for such a query, but this seems to be the best fit. I just had to get this quandary off my chest. Graham87 16:30, 1 August 2013 (UTC)
- It looks like, in October 2012, you realized that you'd made a mistake - created the same section twice - but not that you'd overwritten a section - so you deleted your duplicate section.
- I think it's fairly difficult to do what you did. You have to (a) open up the wrong section; (b) not realize that you are in the wrong section; and (c) paste the text you've composed outside of Wikipedia (I assume) on top of the existing text, rather than editing it. The last of these isn't done very often, I think; if it is, it's certainly an argument against the new VisualEditor approach to editing.
- The two edits you point to resulted in significant deletions of text, though in the first case it was a two-edit process, and in the second, just a single edit. So one way to detect this would be to look at one's contributions list, for such significant negative figures. Of course, for someone with a lot of contributions (that would be you), this is more difficult. I don't know of any tool to select edits based on characters added or deleted, but I suppose a database extract would be quite easy to sort contributions in that way.
- Also, some context: someone with a good reputation (that would be you) is more likely to not be questioned (or reverted) when he/she makes a mistake, particularly - as I said above - one that seems to me to be quite rare. So your situation is even rarer in that less experienced editors might well be asked "Did you want to overwrite that other section"? -- John Broughton (♫♫) 03:38, 2 August 2013 (UTC)
- @John Broughton: Thanks very much for your response. Yes, in both those examples, I had pasted the section in from a text editor. I do this fairly often when making non-trivial edits to articles because I find it more comfortable and more consistent than an HTML textarea with JAWS. (For an example of one of the ridiculous problems I had, I once had my zoom level set to 400% for a few months without realizing it ... that might have explained my issues with very short lines in the edit window!)
- I imagine it would be easier for me to edit the wrong section without my knowledge because I can quite easily cut off speech (I can press enter to go into forms mode then delete a whole section without hearing any of the text that I've just deleted). I doubt I've remove text in this way too often ... most of my section-level edits are copyediting, where it's quite easy to figure out if I'm editing the wrong section! I'll go through my own article expansions and check for similar issues. Graham87 07:22, 2 August 2013 (UTC)
- Oh, another reason why I use a text editor to edit Wikipedia more than most people probably do is that the in-browser find feature is fairly useless for me no matter which browser I'm using. I can search for text in a browser window, but if I want to edit it, I have to go into forms mode in JAWS and navigate to it again from scratch – thus defeating the purpose of the find feature entirely. With an external editor, finding and replacing text is much easier for me. Graham87 07:56, 2 August 2013 (UTC)
- @Graham87: I find it amazing that you are so fluent in editing wikipedia to begin with. It is good to have you Graham87 ! P.S. Matmarex and I have been adding some keyboard navigation features to mw-collapsibles (our third, but core form of collapsing elements) and sortable tables. I hope they are useful to you as well and at the very least not obtrusive ! —TheDJ (talk • contribs) 09:35, 2 August 2013 (UTC)
- I have occasionally found that I am editing the wrong section. This happens only on discussion pages, and the "wrong" section is one from later on in the page. The scenario is that I read through a thread, consider my reply, and then go for [edit], only to find that the edit window is not the section that I intended. Checking the editing history, I find that in between me going to the page and going for [edit], an archiving bot has been along and deleted some sections from earlier in the page. --Redrose64 (talk) 09:44, 2 August 2013 (UTC)
- @TheDJ: Thanks very much! I've just tested the new sorting code at List of countries by population. I think the idea of making the sort toggles into actual buttons is a good idea for accessibility, but unfortunately, for some bizarre reason, JAWS 14 (the latest version) now doesn't recognize the table headers in both Internet Explorer 10 and Firefox 22 (i.e. it thinks the first entry in the list is the column header and acts accordingly). This is not a good thing.
- @Redrose64: Yeah, I've occasionally encountered that problem as well. And I'll never forget this bug (long since fixed, thank goodness) that caused a similar problem. Graham87 10:07, 2 August 2013 (UTC)
- @Graham87: Eh.. stupid JAWS... Why does it 'make up' table headers. Well perhaps we should remove the "role=button" from the header then. I guess it conflicts with the 'other' definition of it being a header. The tabindex probably will still be enough. This also has implications of other uses of role=button I guess. —TheDJ (talk • contribs) 11:56, 2 August 2013 (UTC)
- @Graham87: I find it amazing that you are so fluent in editing wikipedia to begin with. It is good to have you Graham87 ! P.S. Matmarex and I have been adding some keyboard navigation features to mw-collapsibles (our third, but core form of collapsing elements) and sortable tables. I hope they are useful to you as well and at the very least not obtrusive ! —TheDJ (talk • contribs) 09:35, 2 August 2013 (UTC)
Change to VisualEditor integration on the English Wikipedia
As discussed as part of (one of the two) current RFCs about VisualEditor, we have made some changes to how VisualEditor appears here. The most noticable change is that the wikitext editor ("edit source") is now the primary (first) link, the section edit links' animation is gone (finally!), and VisualEditor is now explicitly called "beta" on its tabs. You can read more details in the update.
My thanks again for those who gave feedback on the proposals, and I'd love to hear thoughts on what further tweaks or changes we can make.
Jdforrester (WMF) (talk) 05:37, 2 August 2013 (UTC)
- The change that has just been done completely overlooks the fact that the vast majority of visitor to WP are readers. Instead of a small link showing [edit] off to the right we now have in your face, intrusive links next to the header. Readers need not see the visual editor link and they do not need to know it is in beta. If readers are going to be subjected to the plethora of edit links at all they should be unobtrusive, i.e. small and to the right and NOT two of them. -- Alan Liefting (talk - contribs) 06:53, 2 August 2013 (UTC)
- @Alan Liefting: To clarify, this change has not changed the position of the section edit links (they've been on the left for some months now, in a change entirely unrelated to VisualEditor), and neither has it changed the provision of the links to readers who are logged-out (it's been that way for years). We've done our best to down-play them now there are two (I, too have concerns about showing both of them at once as being too "heavy"). I don't think that this is perfect, but I would disagree that we have over-looked readers. Jdforrester (WMF) (talk) 07:07, 2 August 2013 (UTC)
- This change makes reading Wikipedia more annoying for screen reader users, due to bug 11555. The word "edit" (now "edit source[editbeta]" appears as part of the heading title, which is read out in full whenever a screen reader user navigates between headings. I wrote it like "editbeta" because that's how my screen reader JAWS pronounces it – it's read as one word and sounds like "edit betta" in the default American English synthesiser, which kinda reminds me of the Macintosh Performa. The hover links that were previously there were inaccessible, but I never noticed them because I use IE as my primary browser; it's the one that works best with JAWS. Graham87 07:35, 2 August 2013 (UTC)
- Hi Graham, I am going to add this to the bug you mentioned. Thanks for your feedback, hope this gets fixed soon. --Elitre (WMF) (talk) 08:32, 2 August 2013 (UTC)
- Thanks for that, Elitre. Graham87 09:46, 2 August 2013 (UTC)
- Strangely, "Beta" does not appear on page .tl, and clicking 'Edit' on a section does not bring up either editor. Chris the speller yack 15:14, 2 August 2013 (UTC)
- Fascinating! That must be a bug due to the . at the beginning of the title, will report it if unknown. Thanks! --Elitre (WMF) (talk) 16:54, 2 August 2013 (UTC)
- Aaand it is now at [3]. Thanks, --Elitre (WMF) (talk) 17:05, 2 August 2013 (UTC)
- Fascinating! That must be a bug due to the . at the beginning of the title, will report it if unknown. Thanks! --Elitre (WMF) (talk) 16:54, 2 August 2013 (UTC)
- Strangely, "Beta" does not appear on page .tl, and clicking 'Edit' on a section does not bring up either editor. Chris the speller yack 15:14, 2 August 2013 (UTC)
- Thanks for that, Elitre. Graham87 09:46, 2 August 2013 (UTC)
- Hi Graham, I am going to add this to the bug you mentioned. Thanks for your feedback, hope this gets fixed soon. --Elitre (WMF) (talk) 08:32, 2 August 2013 (UTC)
Edit source vs. Edit
Can this be switched back so it just says "Edit", esp. on the section headings on an article. Or to have an option in your preferences along the lines of "Change the "new section" tab text to instead display the much narrower "+"." Thanks. Lugnuts Dick Laurent is dead 07:04, 2 August 2013 (UTC)
- See the thread directly above and the corresponding link to Wikipedia:VisualEditor/August 2013 update. Killiondude (talk) 07:12, 2 August 2013 (UTC)
- I've read the update, but I want to change the display to show simply "Edit". Can this be done? Lugnuts Dick Laurent is dead 07:16, 2 August 2013 (UTC)
- If you go to the bottom of Special:Preferences#mw-prefsection-editing, and check the option for "Temporarily disable VisualEditor while it is in beta", that will do it. Canuck89 (converse with me) 08:52, August 2, 2013 (UTC)
- This is going to disable VE, which is not really what is being asked here. (This said, I am not aware of ways to override the default labels, while Lugnuts can certainly propose a rename here or in similar venues). --Elitre (WMF) (talk) 09:20, 2 August 2013 (UTC)
- Has the previous setting of that been lost? I'm pretty sure I disabled the VE the other day, and now my setting seems to have disappeared. Sigh. —Tom Morris (talk) 11:36, 2 August 2013 (UTC)
- If you go to the bottom of Special:Preferences#mw-prefsection-editing, and check the option for "Temporarily disable VisualEditor while it is in beta", that will do it. Canuck89 (converse with me) 08:52, August 2, 2013 (UTC)
- I've read the update, but I want to change the display to show simply "Edit". Can this be done? Lugnuts Dick Laurent is dead 07:16, 2 August 2013 (UTC)
- I'm fairly certain this can be accomplished with a personal JavaScript. There was a thread a while back about removing the brackets from around the edit link; try searching for that. Pinging User:Writ Keeper and User:Theopolisme because I'm rather busy (and don't know JavaScript that well). Ignatzmice•talk 11:42, 2 August 2013 (UTC)
- @Tom, no, it hasn't. (copy/pasting the rest I posted elsewhere: What you experienced was not intended at all (see Wikipedia:VisualEditor/August_2013_update). It is my understanding that the recent changes happened to somehow "break" the unofficial, community-developed gadget that you were using. You can still use the official one which you can find in your Preferences, as noted. Sorry if this caused trouble.) --Elitre (WMF) (talk) 11:48, 2 August 2013 (UTC)
- Here is some JS that renames edit source to edit, and below is some CSS that hides "| edit beta" from section links. WARNING: I have only tested this code on Chrome v28 on Windows 7 - use at your own risk.
- @Tom, no, it hasn't. (copy/pasting the rest I posted elsewhere: What you experienced was not intended at all (see Wikipedia:VisualEditor/August_2013_update). It is my understanding that the recent changes happened to somehow "break" the unofficial, community-developed gadget that you were using. You can still use the official one which you can find in your Preferences, as noted. Sorry if this caused trouble.) --Elitre (WMF) (talk) 11:48, 2 August 2013 (UTC)
Add the following to Special:MyPage/common.js (or a skin-specific file)
// Change "[Edit][Edit source]" to "[VE][Edit]" --top tabs
jQuery( function( $ ) {
if (document.getElementById('ca-ve-edit'))
{
var vetab = document.getElementById('ca-ve-edit');
vetab.getElementsByTagName("a")[0].innerHTML="VE";
var setab = document.getElementById('ca-edit');
setab.getElementsByTagName("a")[0].innerHTML="Edit";
// Change "edit source" to "edit" --section links
sections = new Array();
sections = document.getElementsByClassName("mw-editsection mw-editsection-expanded");
if (sections.length == 0)
{ sections = document.getElementsByClassName("mw-editsection"); }
var i=0;
while (sections[i])
{
sections[i].getElementsByTagName("a")[0].innerHTML="edit"
i++;
}
}
} );
Add the following to Special:MyPage/common.css (or a skin-specific file)
/* == HIDE VE SECTION EDIT LINKS == */
.mw-editsection-divider,
.mw-editsection-visualeditor { display:none !important; }
Any improvements from advanced coders would also be appreciated. - Evad37 (talk) 12:07, 2 August 2013 (UTC)
- Whoo-eee, that's fine! Works splendidly on Safari 6/Mac OS 10.8. Seems to have the side benefit of restoring the "right-click on the header line to edit" gadget to edit source, not VE. I think I'll keep it around! One not-really-a-coding suggestion: You could put the script in your userspace (to make it easy to import/more official) and then stick a line in to import the CSS (as part of the JS), so people don't have to edit two separate pages.
- Done - the script (with some coding changes based on Reaper Eternal's method below) now has a home at User:Evad37/rename editors - Evad37 (talk) 17:16, 2 August 2013 (UTC)
I renamed my tabs using the following code in my personal javascript file:
$( document ).ready( function() { $( 'a', '#ca-addsection' ).text( '+' ); $( 'a', '#ca-history' ).text( 'Hist' ); $( 'a', '#ca-viewsource' ).text( 'Source' ); $( 'a', '#ca-talk' ).text( 'Talk' ); $( 'a', '#ca-edit' ).text( 'Source' ); $( 'a', '#ca-view' ).text( 'Read' ); $( 'a', '#ca-nstab-user' ).text( 'User' ); $( 'a', '#ca-nstab-project' ).text( 'Project' ); $( 'a', '#ca-nstab-mediawiki' ).text( 'Interface' ); $( 'a', '#ca-nstab-help' ).text( 'Help' ); $( 'a', '#pt-mytalk' ).text( 'Talk' ); $( 'a', '#pt-preferences' ).text( 'Prefs' ); $( 'a', '#pt-watchlist' ).text( 'Watchlist' ); $( 'a', '#pt-mycontris' ).text( 'Contribs' ); $( 'a', '#pt-logout' ).text( 'Logout' ); });
Reaper Eternal (talk) 12:24, 2 August 2013 (UTC)
- I've always had Visual Editor disabled under Preferences/Gadgets. It still says "Edit Source" on my browser, as of today. I guess that takes some getting used to. I first noticed it on my Talk Page this morning, and my reaction was that somebody must have protected my page. Then I noticed that it's on all pages. It's a little disconcerting. — Maile (talk) 12:30, 2 August 2013 (UTC)
- The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor, it doesn't actually remove it, so tabs and edit links may still behave strangely. However, the setting at Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable prevents VE from loading, so tabs etc. should behave properly. To replicate the pre-VE behaviour, switch on the Editing one, and switch off the Gadgets one. --Redrose64 (talk) 12:52, 2 August 2013 (UTC)
- The gadget doesn't work currently due to a change in VE. It would be great if somebody with the proper knowledge could update MediaWiki:Gadget-oldeditor.js so users who have enabled the gadget and are satisfied with it don't have to find where to disable VE now. The gadget is not made by the VE team and they don't maintain it or keep VE compatible with it. PrimeHunter (talk) 13:49, 2 August 2013 (UTC)
- PrimeHunter, what's wrong for you with the "official" gadget in Special:Preferences#mw-prefsection-editing --> Usability features? Thanks, --Elitre (WMF) (talk) 14:04, 2 August 2013 (UTC)
- That one works. I only say "gadget" about the Gadgets tab. I was replying to Redrose64 who wrote: "The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor". I know that gadget isn't made by the VE team and they have never said they would keep it compatible with VE. But there are many users who have the gadget enabled and will be annoyed when they see VE has reappeared and they don't know the Editing preference that works. See Wikipedia:VisualEditor/Default State RFC#Was this just turned on for all users? for examples of angry users. PrimeHunter (talk) 14:15, 2 August 2013 (UTC)
- (edit conflict)I agree 100% with User:PrimeHunter. I thought I had disabled this (expletive) thing on the preferences page, and today the bloody thing pops up again with editsource editbeta allover the place. I'm annoyed that I had to waste 10 minutes of my time trying to figure out how to kill it again. Then I see an option to "temporarily" disable it!? I don't want temporary... I don't want to see this thing ever again. A very clear consensus is forming at the RfC that this POS be opt-in only, to cause this thing to turn on again when it's been turned off is spitting in the face of the community.–Wine Guy~Talk 14:23, 2 August 2013 (UTC)
- PrimeHunter, what's wrong for you with the "official" gadget in Special:Preferences#mw-prefsection-editing --> Usability features? Thanks, --Elitre (WMF) (talk) 14:04, 2 August 2013 (UTC)
- The setting at Preferences → Gadgets → Remove VisualEditor from the user interface just hides the VisualEditor, it doesn't actually remove it, so tabs and edit links may still behave strangely. However, the setting at Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable prevents VE from loading, so tabs etc. should behave properly. To replicate the pre-VE behaviour, switch on the Editing one, and switch off the Gadgets one. --Redrose64 (talk) 12:52, 2 August 2013 (UTC)
- I've always had Visual Editor disabled under Preferences/Gadgets. It still says "Edit Source" on my browser, as of today. I guess that takes some getting used to. I first noticed it on my Talk Page this morning, and my reaction was that somebody must have protected my page. Then I noticed that it's on all pages. It's a little disconcerting. — Maile (talk) 12:30, 2 August 2013 (UTC)
- Yeah, I had to say option, sorry for that. If people want to fix the "unofficial" gadget, that's fine: but if this does not happen, I just wanted to make sure everybody realize there is no real need for that anymore since the "official" option does work. WineGuy, can you please see my second comment in this thread? Seeing VE again today was not planned or intended, again, I'm sorry for the trouble. --Elitre (WMF) (talk) 14:43, 2 August 2013 (UTC)
- The unofficial gadget isn't needed currently for users who know the Editing preference, but this may change. The preference displays MediaWiki:Visualeditor-preference-betatempdisable. As strongly hinted by both the message name and text, the Wikimedia Foundation may remove this option when VE is officially no longer in beta. I think we should keep the gadget. If the gadget can be changed to toggle the Editing preference as suggested by Matma Rex then great, but if we delete the gadget and restore it later then I don't know whether its new state can be restored from the old state for those users who had enabled the old version and will be annoyed if they have to enable it again. PrimeHunter (talk) 15:20, 2 August 2013 (UTC)
- In reply to User:Elitre (WMF) above: I appreciate your reply, and also the fact that the developers have once again put you, as the Community Liaison, in the awkward position of having to apologize for their misdeeds. The fact that this problem was "not planned or intended" is yet another indication that this roll-out has been, and continues to be, mishandled. As VE has been forced on people who don't want it, the dev team needs to be more careful about testing before going live with updates. –Wine Guy~Talk 16:36, 2 August 2013 (UTC)
- Wine Guy, there is no way devs can actually know or prevent changes to something (be it VE, MediaWiki or whatever) from damaging something else - unless you don't really think that devs know all of the volunteer-written tools&gadgets everywhere in the wikiverse? :) - which is why things need, well, their maintainers, and caring people who mind letting them notice when their intervention is required. --Elitre (WMF) (talk) 16:48, 2 August 2013 (UTC)
- In this case, I'll have to side with the devs. You can't account for every custom hack people implement. When updates happen, it becomes incumbent on the owners of said hacks to adapt if something breaks. Resolute 16:52, 2 August 2013 (UTC)
- I don't really expect them to account for every custom hack, I do try to be reasonable. It would have been nice if they had anticipated this problem, though. –Wine Guy~Talk 17:39, 2 August 2013 (UTC)
- "Anticipated" can cover a lot of territory, from foreknowledge to delaying these much-requested changes until a volunteer has time to update his code. The first probably happened, and I suspect that the last would have been unacceptable to the people who strongly advocated for these changes. Whatamidoing (WMF) (talk) 21:01, 2 August 2013 (UTC)
- I don't really expect them to account for every custom hack, I do try to be reasonable. It would have been nice if they had anticipated this problem, though. –Wine Guy~Talk 17:39, 2 August 2013 (UTC)
- In reply to User:Elitre (WMF) above: I appreciate your reply, and also the fact that the developers have once again put you, as the Community Liaison, in the awkward position of having to apologize for their misdeeds. The fact that this problem was "not planned or intended" is yet another indication that this roll-out has been, and continues to be, mishandled. As VE has been forced on people who don't want it, the dev team needs to be more careful about testing before going live with updates. –Wine Guy~Talk 16:36, 2 August 2013 (UTC)
Mysterious data override
Someone please have a look at this and comment on what's causing the issue?
Might be Wikidata but I'm as yet totally unfamiliar with that, especially any silent overrides. (Sorry in case I should be apologizing for that.)
TIA, --217.81.163.66 (talk) 12:48, 2 August 2013 (UTC)
- The figure comes from Template:Metadata Population DE-BB. --Redrose64 (talk) 12:58, 2 August 2013 (UTC) (moved from Talk:Steinhöfel#What technical "miracle" is overriding the figures from the info box to avoid having a split discussion) --Redrose64 (talk) 13:39, 2 August 2013 (UTC)
- Thanks Redrose. How do I clean up the source so there will be no inconsistent data issue?
- This looks something like nested implicit template transclusion, that's a little over my level of WP template intricacies at the moment.
- How much of what can I take out without doing damage to what's there?
- As this has broadened into the more general question of "How to resolve data override by (nested/cascading) Data Template Transclusion",
- please find that below and answer there. TIA
- P.S.: Special thanks for cleaning up the TOC issue on the go. Oh yep, I accidentally used braces instead of underscore.
- --217.81.163.66 (talk) 13:12, 2 August 2013 (UTC)
How to resolve data override by (nested/cascading) Data Template Transclusion
please see "Mysterious data override" above and answer here as this has broadened into a new question
TIA, --217.81.163.66 (talk) 13:21, 2 August 2013 (UTC)
- In your example it's done by templates at the English Wikipedia and not by Wikidata. Any template can be coded to ignore parameters and use data from elsewhere, but the behaviour has to be coded into the specific template. The details vary. Steinhöfel uses Template:Infobox German location. The documentation says "Population data automatically transcluded from {{Population Germany}}." PrimeHunter (talk) 13:37, 2 August 2013 (UTC)
Seven nations with population-data templates
Sorry for the confusion, but for years, we have been adding automatic population templates (some copied from German Wikipedia) to keep town-population lists which display each population count in any of thousands of towns, by #switch on town-code numbers in the various templates. Already, thousands of town/region articles of 7 nations use those templates: Germany, Austria, South Africa, Switzerland, Belgium, Turkey, and New Zealand (France not yet, only on dewiki, see: "Category:Template:Metadata Population"). Here's the deal, people at German WP update the population templates, each year, and then we copy each template's #switch data into enwiki, and within an hour, thousands of enwiki articles get the latest population counts+source, as input by editors in German WP. I estimate over 21,000 articles use those templates. That is how we accomplish so much with just 10-15 edits per nation each year. -Wikid77 19:08, 4 August 2013 (UTC)
Search: When something is in a WikiProject:'s talk page, what search namespace would that be in?
I made a post on WikiProject:Psychology Talk and, searchwise, it seems to be gone. How?
Could I have missed the right checkmark in Advanced Search or is this really a glitch in the tech?
Case is this: (Psychology), with brief cross-posts at (Anthropology) and Sociology.
TIA, --217.81.163.66 (talk) 13:09, 2 August 2013 (UTC)
- It's in the Wikipedia talk namespace, but those posts are from today and haven't been indexed by the search feature yet. See Help:Searching#Delay in updating the search index. PrimeHunter (talk) 13:26, 2 August 2013 (UTC)
Negative Image
Hi, I recently updated this image File:Angels_Den_Main_Logo.jpg. Unfortunately, the image came back in a sort of negative fashion; changing the original colours. Thanks. Rhâmusker Rhamusker (talk) 15:54, 2 August 2013 (UTC)
- It looks fine to me (in Firefox 22 under Windows XP): black and gold on a white background. However, different browsers and operating systems can do funny things to JPEGs. Which browser and OS are you using? --Redrose64 (talk) 16:13, 2 August 2013 (UTC)
Template coding help needed
Template:Celestial events by month links has the v-d-e links and the hide button in a largish font. They should not be IMO. Can someone change it? I got a bit lost in the wikicode. Cheers -- Alan Liefting (talk - contribs) 01:14, 3 August 2013 (UTC)
- Just remove
font-size:1.5em;
. PrimeHunter (talk) 01:25, 3 August 2013 (UTC)
- Ta. Thought it might be something like that. -- Alan Liefting (talk - contribs) 01:34, 3 August 2013 (UTC)
Template data for citation
Template data was added for {{citation}}. The problem is that this template has two modes: patent and citation. Patent mode is switched by recognizing the inventor parameters. With a fully populated template data, editors are going to be presented with both sets of parameters, with resulting confusion. Thoughts? -- Gadget850 talk 01:21, 3 August 2013 (UTC)
- I see that there is a notice that TD needs improvement there, but still: I'd consider using labels and/or descriptions in a "creative" way in order to distinguish among the two sets, at least temporarily. For example, patent-related parameters could include something like (P), while (C) would mean citation, so that you can recognize more easily the ones you are looking for. --Elitre (WMF) (talk) 07:48, 3 August 2013 (UTC)
Block showing in one place, but not another
Special:Contributions/71.156.18.97 does not show an active block for 71.156.18.97 (talk · contribs). But his block log shows a block I placed on him yesterday that has yet to expire. Then again, when I go to Special:Block/71.156.18.97, it does not warn me that the IP is already blocked, as I believe it should. Weird! Anyone know what's wrong? Someguy1221 (talk) 04:53, 3 August 2013 (UTC)
Piping a link through an image
Is it possible to pipe a link through an image? I.e. have a picture link to a page? I tried File:Wikipedia-logo-v2.svg|15px but it doesn't work. (Yeah, I know it is not good per MoS, and so it is something I want to add to a W namespace page, not main, so no worries here). --Piotr Konieczny aka Prokonsul Piotrus| reply here 09:30, 3 August 2013 (UTC)
- {{click}}, though I notice that page now says you can do it with an attribute in the image code itself. Andrew Gray (talk) 09:43, 3 August 2013 (UTC)
- . See Wikipedia:Picture tutorial#Links. PrimeHunter (talk) 09:43, 3 August 2013 (UTC)
- Wrong. If |link= and a caption are both used then the funny little double-rectangle icon at upper right of the caption is still a link to the image description page, even though clicking on the image itself follows the |link= link. An example is seen in the first image in this section. (There's some odd stuff going on in the caption which isn't related to this question, but with which I'm hoping some technical wizard will assist -- if you're interested see Talk:Phineas_Gage#technical_stuff.) EEng (talk) 12:19, 3 August 2013 (UTC)
- The icon with the file page link is caused by thumb whether or not there is a caption. It looks bad for small images. PrimeHunter (talk) 12:38, 3 August 2013 (UTC)
- You're right -- thumb alone will do it. And you're also right it looks awful for small (and presumably captionless) images) but in practice such images may correspond to cases where the "link-to-image-description" may not be necessary anyway. (I'm sure someone can step in here and explain the requirements, but certainly many images e.g. WP logo linking to main page don't link to their descriptions.) In the case I linked to above, the object behind the image is a multipage djvu document. Unfortunately the cover page had been scanned crooked, and I didn't want that showing in the article. So I created a separate image of the title page with the crookedness corrected; that's what shows in the thumbnail, but if the reader clicks that image he's taken to the original multipage djvu so he can read whole thing. If for some reason he wants to see the description page for the what's thumbnailed in the article they can click on the little double-rectangle thingamajig (which turns out to be http://bits.wikimedia.org/static-1.22wmf12/skins/common/images/magnify-clip.png). EEng (talk) 13:33, 3 August 2013 (UTC)
- A link to the file description page is not required if the license on the file does not require credit to the author, notification that the file is under the license, or other metadata of that sort to be included when the file is reused. Of the licenses commonly used here, only "public domain" and CC0 qualify (other licenses, such as WTFPL, do qualify but aren't commonly used). I note that your djvu example is an uncommon case; most of the time
|link=
is used on icons, withoutthumb
. Also, is it not possible to fix the djvu? Anomie⚔ 14:12, 3 August 2013 (UTC)- In addition to correcting the crookedness I also wanted to present a version with most of the margins cropped out, so as to present the printing as large as possible -- but of course I didn't want to crop the original. Anyway, I couldn't figure out what sw to use with djvu. EEng (talk) 18:49, 3 August 2013 (UTC) P.S. I want to put a plug in here for a neat, underutilized feature I discovered during this discussion: WP:Picture_tutorial#Image_maps
- A link to the file description page is not required if the license on the file does not require credit to the author, notification that the file is under the license, or other metadata of that sort to be included when the file is reused. Of the licenses commonly used here, only "public domain" and CC0 qualify (other licenses, such as WTFPL, do qualify but aren't commonly used). I note that your djvu example is an uncommon case; most of the time
- You're right -- thumb alone will do it. And you're also right it looks awful for small (and presumably captionless) images) but in practice such images may correspond to cases where the "link-to-image-description" may not be necessary anyway. (I'm sure someone can step in here and explain the requirements, but certainly many images e.g. WP logo linking to main page don't link to their descriptions.) In the case I linked to above, the object behind the image is a multipage djvu document. Unfortunately the cover page had been scanned crooked, and I didn't want that showing in the article. So I created a separate image of the title page with the crookedness corrected; that's what shows in the thumbnail, but if the reader clicks that image he's taken to the original multipage djvu so he can read whole thing. If for some reason he wants to see the description page for the what's thumbnailed in the article they can click on the little double-rectangle thingamajig (which turns out to be http://bits.wikimedia.org/static-1.22wmf12/skins/common/images/magnify-clip.png). EEng (talk) 13:33, 3 August 2013 (UTC)
- The puzzle globe at the upper left of all pages is added by the Wikimedia Foundation to their own website. They own the image and don't have to give attribution to themselves. It's not in the wiki source so it's not copied by mirrors (at least not legally). However, I improperly displayed a small version of it in an earlier post without linking the file page File:Wikipedia-logo-v2.svg. I have changed the example to . This uses the public domain File:Flag of Poland.svg. PrimeHunter (talk) 14:14, 3 August 2013 (UTC)
Has SUL finalization started?
The process of finalizing Single User Login was to start this August. Nearly 2,5 days have passed and there doesn't seem to be any activity or news. --Синкретик (talk) 11:27, 3 August 2013 (UTC)
- The link should be meta:Single User Login finalisation announcement. I don't know the current schedule. PrimeHunter (talk) 12:14, 3 August 2013 (UTC)
- On 12 May the time was changed from 27 May 2013 to August 2013.[4] With no news since then it seems unlikely to happen anytime soon. [5] also shows nothing since 12 May, except unanswered questions about the time. PrimeHunter (talk) 12:25, 3 August 2013 (UTC)
- See the mailing list announcement from 12 May where it says that it will take place in August, but not until after Wikimania. It seems that Wikimania will be held around next weekend. --Stefan2 (talk) 15:41, 3 August 2013 (UTC)
- It looks like the SUL renaming is likely to be held up; see this mailing list comment. The tools aren't there yet, and VE is using a lot of developer time. Andrew Gray (talk) 17:39, 3 August 2013 (UTC)
- I think https://login.wikimedia.org/, where all the logins and unifications go through, was specifically created for this. There has been some changes in the logins. Sometimes the user is automatically logged out when visiting another wiki. However, when the page is reloaded, the user will be logged in again. Plus, the preferences (language settings, etc.) are automatically set when visiting another project for the first time. --Glaisher [talk] 16:45, 4 August 2013 (UTC)
- login.wikimedia.org was created because of Safari (and soon Firefox, it would be already except they've postponed making it the default) "breaking" how the old version of SUL was logging you into the other wikis; this article has some details on that. To work around that, we created login.wikimedia.org so that all the various wikis could have a central location to ask "am I logged in?".
- While loginwiki might wind up being used for global profiles or the like in the future, it wasn't created for the final SUL unification, nor is the final SUL unification actually dependent on loginwiki. The unification is finally being pushed so that long-requested cross-wiki features (like watchlists and notifications) can have some chance of being done sanely. Nor does loginwiki have anything to do (yet) with preferences being automatically set, and when I tried it just now by going to abwiki (which I had never happened to visit before now) it didn't set my language to English. BJorsch (WMF) (talk) 00:19, 5 August 2013 (UTC)
- I think https://login.wikimedia.org/, where all the logins and unifications go through, was specifically created for this. There has been some changes in the logins. Sometimes the user is automatically logged out when visiting another wiki. However, when the page is reloaded, the user will be logged in again. Plus, the preferences (language settings, etc.) are automatically set when visiting another project for the first time. --Glaisher [talk] 16:45, 4 August 2013 (UTC)
Date template improvemt requested
Could someone with a high level of template expertise please take a look at Template talk:Start date#Time display? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:18, 3 August 2013 (UTC)
- Another place to post, if no response here, is Wikipedia:Requested templates, though that page does seem to have some tumbleweeds going though it. Still, little harm done in trying, if necessary. -- John Broughton (♫♫) 17:06, 4 August 2013 (UTC)
Re-focus on power users, as VE usage plummets
This is a reminder how the power users, with the computer power tools, are still the future of WP, so create more tools. I know I should avoid talk of VisualEditor (VE) here, but I just wanted to reassure the technical users how the mainstream users have re-awakened and returned to using the wikitext editor: edits by new/old usernames are 96% wikitext (up from 91% last week), and IP edits are 80% by wikitext editor (up from 70%, 30% were VE) in a sample of 3,000 edits on 3 August 2013. The overall IP edits are still 27% of total (799 of 3,000) as during last month, so no major effects on IP editing (other than many people have been counting the IP edits versus the 73% username-based edits). Be assured: people who write encyclopedia articles tend to be quick-learners and not long distracted by fads, but focus on how to accomplish more. The power users, who make 92% of monthly edits, will likely appreciate the better gadgets or tools. To comment on VE, see: WP:VisualEditor/Default_State_RFC. -Wikid77 (talk) 21:19, 3 August 2013 (UTC)
- Edits by user type dashboard. The August 2013 changes were intended to reduce VE usage by making VisualEditor's beta status clearer, both in the labeling and position of the edit links, and by giving a first-time informational message to new users. As I wrote in the Signpost, during the beta phase of VisualEditor, we need to ensure that we have reasonably representative usage of VisualEditor so it's not developed in isolation from real user concerns (both new and experienced users), but we're looking for a reasonable compromise which achieves that while minimally disrupting the experience of users who have no interest in the beta.--Eloquence* 22:45, 3 August 2013 (UTC)
- You're constantly getting this wrong for many of us Erik, which is sad since it neither helps the community nor your efforts to improve VE: There are users (let's call them "power users") who are more efficient with the Wikitext editor. Since this is clear (already today) those users know the'll eventually continue to use the Wikitext editor and would want to disable the VE. This does not mean those users are not willing to help in development of VE during the beta phase! Actually it's the other way round!
- If you'd say "VE is enabled by default during the beta phase for registered users, so we get as much useful input as possible, but we'll offer an option to disable it in the long term for those who do not want to use VE in day-to-day work" you would make many editors and also yourself much happier than we're now with the unsuccessful launch of VE. --Patrick87 (talk) 23:53, 3 August 2013 (UTC)
- I agree, if the WMF actually relayed the attitude they wanted our help they would have it but when they repeatedly ignore our feedback and insist that hundreds of users across multiple wiki's are just being resistant to change, that doesn't instill an environment of mutual cooperation. I have been here a long time and I have never seen the community in as much of a consensus about anything as they currently are about how negatively the VE application is impacting things here. The problem here is that the WMF wants to push this broken and grossly unfinished app to the masses at all cost knowing its broken. Kumioko (talk) 00:42, 4 August 2013 (UTC)
- This article from the Register pretty much sums things up. Kumioko (talk) 01:18, 4 August 2013 (UTC)
- I agree, if the WMF actually relayed the attitude they wanted our help they would have it but when they repeatedly ignore our feedback and insist that hundreds of users across multiple wiki's are just being resistant to change, that doesn't instill an environment of mutual cooperation. I have been here a long time and I have never seen the community in as much of a consensus about anything as they currently are about how negatively the VE application is impacting things here. The problem here is that the WMF wants to push this broken and grossly unfinished app to the masses at all cost knowing its broken. Kumioko (talk) 00:42, 4 August 2013 (UTC)
- Wikid, I don't think your sample shows what you're claiming. If people are individually choosing to use VisualEditor less, then you should see a steady downward trend. The fact that it declined on the day after it was deliberately made less prominent does not prove that people are rejecting it. That instead proves that the UI changes (location, label, etc.) had the intended effect. If people are deliberately choosing to use it less, rather than being influenced by the UI, then you ought to see fewer edits on the days before these changes than you did in the first week of July. Whatamidoing (WMF) (talk) 20:24, 5 August 2013 (UTC)
Wikidata creep?
- See: Wikidata:Project_chat#Many-to-one pygmy elephant. -Wikid77 15:18, 5 August 2013 (UTC)
Before interwiki language links passed over to Wikidata I had no difficulty in editing them. But now I've given up trying. For example, the en.wp equivalent of it:clacson should be Vehicle horn, not Horn (acoustic), but I have been unable to make the change. When I tried some time ago I got an error message telling me that Vehicle horn was already spoken for (and now I seem to get a message telling me that Vehicle horn was not found...).
Help:Interlanguage links sends me to Wikipedia:Wikidata, which is... erm... tl;dr (I'm tempted to say gobbledegook).
My understanding is that any given WP page can now only link to only one counterpart in any other given language. As anyone with even a basic knowledge of translation (or semantics) will know, this is a naive restriction.
To take a topical [6] example from it.WP: it:Grazia (diritto), a page with no interwiki language link... This Italian legal term is commonly translated into English as "pardon". However, en:Pardon is already taken by it:Indulto—a different [7] concept (the lead of it:Grazia (diritto) distinguishes the Italian legal concepts of grazia and indulto).
While acknowledging that it may be early days, I'm concerned that this is technical WP:CREEP, where the interests of Wikidata are effectively trumping the interests of Wikipedia's global readership. 86.140.51.65 (talk) 22:19, 3 August 2013 (UTC)
- Were we discussing this matter at Oxford Meetup three weeks ago? If so, I'll see you tomorrow! --Redrose64 (talk) 22:36, 3 August 2013 (UTC)
- Wikidata stores the links at each item's page. Editing links is very easy from the graphical user interface, but yes, only one link per language per site per item is permitted.--Jasper Deng (talk) 22:40, 3 August 2013 (UTC)
- The restriction of one link per language seems to me to be at odds with the global character of the Wikipedia project. Fwiw, I feel that this is an issue that deserves discussion online. (The graphical user interface doesn't seem [8] to help redirect it:Clacson to en:Vehicle horn.) 86.140.51.65 (talk) 22:52, 3 August 2013 (UTC)
- In this particular case, it would have to be moved to the vehicle horn item. Yes, this requirement is debatable and something you can bring up at d:Wikidata:Project chat.--Jasper Deng (talk) 00:17, 4 August 2013 (UTC)
- Thank you for your replies, Jasper Deng. I'm not sure I feel altogether prepared to enter the Wikidata habitat. Remaining on en:WP for the moment, WP:Wikidata#Interlanguage links (Phase 1) seems to me cryptic (WP:CREEP) and worrying... For instance, the largely unexplained star network illustration of "Links to all languages from one central point" rings alarm bells of WP:SYSTEMIC: viz. not only creating a conceptual straightjacket of the interlinks, but an "en-centric" one to boot. I hope I am wrong! 86.140.51.65 (talk) 08:01, 4 August 2013 (UTC)
- In this particular case, it would have to be moved to the vehicle horn item. Yes, this requirement is debatable and something you can bring up at d:Wikidata:Project chat.--Jasper Deng (talk) 00:17, 4 August 2013 (UTC)
- The restriction of one link per language seems to me to be at odds with the global character of the Wikipedia project. Fwiw, I feel that this is an issue that deserves discussion online. (The graphical user interface doesn't seem [8] to help redirect it:Clacson to en:Vehicle horn.) 86.140.51.65 (talk) 22:52, 3 August 2013 (UTC)
- Some pages need to interwiki link to a crosslink page: They are many rare cases where an interwiki needs a one-to-many link, and I suggested for years to use wp:crosslink pages (Template:Crosslink), which each would link to multiple other pages based on similar topics being cross-linked, rather than similar page titles. The issue is a one-to-many link by similar semantic content, rather than similar syntax in spelling the page titles. An example was the page "River" which might be better linked to a crosslink page of several related terms in German language, such as de:Bach, de:Fluss, de:Strom, etc. This is a general issue in information science, and I welcome others to expand this concept. -Wikid77 (talk) 19:36, 4 August 2013 (UTC)
- Put in-page interwiki and discussion at WD:Wikidata:Project_chat: I just fixed the page by using the old in-page interwiki links, which have more capability, then opened a thread at Wikidata:
- "Wikidata:Project_chat#Many-to-one pygmy elephant". -Wikid77 15:18, 5 August 2013 (UTC)
- The need for many-to-one page links has been an issue for years, and hopefully the discussion will lead to an early fix. -Wikid77 (talk) 15:18, 5 August 2013 (UTC)
- Thank you, Wikid77. 86.140.51.65 (talk) 21:50, 5 August 2013 (UTC)
Naughty ref template?
On the Maltase article I changed {reflist} to {reflist|2} it now superimposes some of the reference text over an image. It could be fixed by revering my edit but it is a glitch that should be sorted out. Cheers. -- Alan Liefting (talk - contribs) 04:13, 4 August 2013 (UTC)
- It looks OK to me, under Firefox 22. Which browser are you using? --Redrose64 (talk) 08:47, 4 August 2013 (UTC)
- FF22. Might be related to screen resolution. Am running 1280x800. -- Alan Liefting (talk - contribs) 09:14, 4 August 2013 (UTC)
- Hmmm. The plot thickens. Am running Monobook. -- Alan Liefting (talk - contribs) 09:47, 4 August 2013 (UTC)
- Still no change! -- Alan Liefting (talk - contribs) 05:08, 5 August 2013 (UTC)
- It's working for me in Safari 6 on Mac OS 10.7.5. Can someone else give it a try? It would be helpful if we could find someone else with this problem. Whatamidoing (WMF) (talk) 20:27, 5 August 2013 (UTC)
Erroneous message on Watchlist
At the top of my Watchlist is a message that states, "Pages that have been changed since you last visited them are shown in bold." This is just wrong. Pages that have changed are shown with a green bullet point. The message needs to be fixed to match reality (I'm sure it used to mention the green bullets...) Thanks, Bazonka (talk) 08:44, 4 August 2013 (UTC)
- The message hasn't changed in about eight weeks... what is your language setting? --Redrose64 (talk) 09:03, 4 August 2013 (UTC)
- It was set to British English. Changing it to just English fixes the problem. I'm aware that the BrE setting isn't always right, and so I'm sure I'd already changed to English a couple of years ago, but maybe not. In any case, the BrE message does need to be fixed because I can't be the only person using it. Bazonka (talk) 09:29, 4 August 2013 (UTC)
- I've copied MediaWiki:Wlheader-showupdated to MediaWiki:Wlheader-showupdated/en-gb verbatim. --Redrose64 (talk) 09:46, 4 August 2013 (UTC)
- It was set to British English. Changing it to just English fixes the problem. I'm aware that the BrE setting isn't always right, and so I'm sure I'd already changed to English a couple of years ago, but maybe not. In any case, the BrE message does need to be fixed because I can't be the only person using it. Bazonka (talk) 09:29, 4 August 2013 (UTC)
- Users with British or Canadian English often miss important customizations of interface messages, for example links to English Wikipedia help and policy pages. I have restored [9] a warning at Help:Preferences but I suggest we also warn the users more directly. Users with en-gb or en-ca see MediaWiki:Preferences-summary/en-gb or MediaWiki:Preferences-summary/en-ca (both are currently blank) at top of Special:Preferences. Users with the default en see MediaWiki:Preferences-summary. I suggest we set MediaWiki:Preferences-summary/en-gb to something like: "For information about the settings on this page, see Help:Preferences. Your language setting British English is not recommended." Similarly for en-ca. PrimeHunter (talk) 20:28, 4 August 2013 (UTC)
- British is the third most selected language, after Spanish. Then French, Brazilian Portuguese, Russian, Indonesian, German, Arabic, Chinese, Dutch. Only 277 users have Canadian selected. See Wikipedia:Database_reports/User_preferences. -- Gadget850 talk 20:43, 4 August 2013 (UTC)
- Thanks for the stats. Is there ever any good reason to choose British English, for example American words a British user may misunderstand? Does anybody know stats on how many MediaWiki defaults are different for en and en-gb, and what those differences are? PrimeHunter (talk) 21:06, 4 August 2013 (UTC)
- Only way I know is to go to Special:AllMessages, select the desired language, and Go. Custom messages are highlighted in light blue. -- Gadget850 talk 21:11, 4 August 2013 (UTC)
- Here are some I made earlier: en; en-gb; en-ca. --Redrose64 (talk) 21:43, 4 August 2013 (UTC)
- Thanks. I was thinking particularly of the default messages in the MediaWiki software and not customizations at the English Wikipedia. It appears from mw:Localisation statistics that only 51 of 2979 messages have an en-gb variant. I found https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn_8php_source.html and https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn__gb_8php_source.html. The latter appears to show all en-gb variants. Here is a possibly complete summary of differences between en and en-gb: uncategorized/uncategorised, "Add pages and files I [something] to my watchlist"/"Add pages I [something] to my watchlist" (don't know why files are omitted in en-gb but en/en-gb confirms the difference), "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/License. So for a few British spellings and different quotation marks, users with en-gb lose hundreds of customized messages at the English Wikipedia. That seems like a bad deal unless you are fanatical about British spelling, but then you would still have to live with lots of American spellings in articles. PrimeHunter (talk) 23:18, 4 August 2013 (UTC)
- Personally I've found that feelings can run very strong on the License/License issue. EEng (talk) 01:57, 5 August 2013 (UTC)
- I accidentally wrote "License" both times and you copied that. The Licence/License issue probably causes more feelings ;-) PrimeHunter (talk) 13:16, 5 August 2013 (UTC)
- Personally I've found that feelings can run very strong on the License/License issue. EEng (talk) 01:57, 5 August 2013 (UTC)
- 20 of those custom messages are for cite errors. I tried redirects, which don't work at all, and transclusion, which does not work on all pages. -- Gadget850 talk 00:02, 5 August 2013 (UTC)
- Thanks. I was thinking particularly of the default messages in the MediaWiki software and not customizations at the English Wikipedia. It appears from mw:Localisation statistics that only 51 of 2979 messages have an en-gb variant. I found https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn_8php_source.html and https://doc.wikimedia.org/mediawiki-core/master/php/html/MessagesEn__gb_8php_source.html. The latter appears to show all en-gb variants. Here is a possibly complete summary of differences between en and en-gb: uncategorized/uncategorised, "Add pages and files I [something] to my watchlist"/"Add pages I [something] to my watchlist" (don't know why files are omitted in en-gb but en/en-gb confirms the difference), "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/License. So for a few British spellings and different quotation marks, users with en-gb lose hundreds of customized messages at the English Wikipedia. That seems like a bad deal unless you are fanatical about British spelling, but then you would still have to live with lots of American spellings in articles. PrimeHunter (talk) 23:18, 4 August 2013 (UTC)
- Here are some I made earlier: en; en-gb; en-ca. --Redrose64 (talk) 21:43, 4 August 2013 (UTC)
- Only way I know is to go to Special:AllMessages, select the desired language, and Go. Custom messages are highlighted in light blue. -- Gadget850 talk 21:11, 4 August 2013 (UTC)
- Thanks for the stats. Is there ever any good reason to choose British English, for example American words a British user may misunderstand? Does anybody know stats on how many MediaWiki defaults are different for en and en-gb, and what those differences are? PrimeHunter (talk) 21:06, 4 August 2013 (UTC)
- British is the third most selected language, after Spanish. Then French, Brazilian Portuguese, Russian, Indonesian, German, Arabic, Chinese, Dutch. Only 277 users have Canadian selected. See Wikipedia:Database_reports/User_preferences. -- Gadget850 talk 20:43, 4 August 2013 (UTC)
- Users with British or Canadian English often miss important customizations of interface messages, for example links to English Wikipedia help and policy pages. I have restored [9] a warning at Help:Preferences but I suggest we also warn the users more directly. Users with en-gb or en-ca see MediaWiki:Preferences-summary/en-gb or MediaWiki:Preferences-summary/en-ca (both are currently blank) at top of Special:Preferences. Users with the default en see MediaWiki:Preferences-summary. I suggest we set MediaWiki:Preferences-summary/en-gb to something like: "For information about the settings on this page, see Help:Preferences. Your language setting British English is not recommended." Similarly for en-ca. PrimeHunter (talk) 20:28, 4 August 2013 (UTC)
Side discussion
As a side issue, as my updated watchlist entries are neither bold nor green what's the css to hide the line altogether? NtheP (talk) 09:19, 5 August 2013 (UTC)
- It doesn't have a class so I don't know whether CSS can hide it but this JavaScript in Special:MyPage/common.js uses its span id:
document.getElementById("mw-wlheader-showupdated").style.visibility = "hidden";
- PrimeHunter (talk) 10:05, 5 August 2013 (UTC)
Notice for RFC on VE
Two things on the sitenotice about the RFC on Visual Editor:
- I disabled the notice soon after reading it for the first time, a few days ago, but whenever I load any page (even Mediawiki:Sitenotice!), the notice displays for at least a second (sometimes more) before automatically disappearing. I can't remember this ever happening before, since notices normally don't appear at all once I've closed them; what's the difference here?
- Sometimes the [hide] link appears to the far right side, and sometimes it's centered above the notice. This was the case before I closed the notice; it's not just been over the past couple of days. Why wouldn't it always go in the same place?
I've been using Wikipedia from several different IP addresses since the notice first appeared, including one more than 400 miles (640 km) away from another, but it happens on all of them. Right now, I'm on the same address as I was when I made this edit, but things haven't changed in two days. Running IE8/Monobook/Windows 7. Nyttend (talk) 12:29, 4 August 2013 (UTC)
- Same on IE8 on Windows XP. I would assume they would tell you to update your browser, as IE10 is the latest supported browser for Windows 7. I can't, however, and it is quite annoying. Jguy TalkDone 13:24, 4 August 2013 (UTC)
- Support for IE changes daily, with CSS settings: Perhaps the IE browsers do not fully process all the *hundreds* of CSS classes which are downloaded now to display almost any WP page. The wp:Data hoarding of thousands and thousands of CSS classes might not inherent all the attribute values, or there might even be a transmission error in some dozen CSS classes, among all the thousands and thousands and thousands (plus thousands more) sent to your browser (it is freaking unbelievable when counting the CSS classes). Hence, the recent WP trash-the-interface actions include: the [hide] button shifts from right to center, the top page title disappears (often), the redlinks turn "blue" (neat feature), some bordered tables get double-thick lines, the wp:Tooltips pop-ups get stuck overlayed onscreen (IE8), the image-boxes lose the outer border, the town map locator-dots shift a few pixels out to sea, or the whole page loses the box style and scrolls down the page, and the page locks up. Thankfully, IE8 has been the world's most popular browser, or it would be difficult to show for years how Wikipedia looks like twisted crap in almost every building visited. -Wikid77 (talk) 18:38, 4 August 2013 (UTC)
Contributors link not working
I have been experiencing intermittent errors when trying to get a list of contributors of various pages on Wikipedia. It is now to a point where I am getting ready to throw the towel in and stop clicking the dreaded Contributors link (View history).
Here are a couple of different error messages I have been getting:
- Database Error: Can't connect to MySQL server on 'sql-s1' (4) on sql-s1/enwiki_p
- Database Error: User 'daniel_www' has exceeded the 'max_user_connections'
I hope someone here can explain why this continues happening - is this all tied to the mystical toolserver? Thanks in advance, XOttawahitech (talk) 16:41, 4 August 2013 (UTC)
- Yes; the fact that the URL begins http://toolserver.org/ is a bit of a giveaway --Redrose64 (talk) 19:13, 4 August 2013 (UTC)
Interlanguage automoronism
Sorry, I dont use that kind of lingo that I'm using now very often, but really annoyed.
Not sure this is entirely tech, but if it isn't, it's darn close. Please move if so required.
To be brief, Broom_(shrub) lacks a de: link. That used to be piece of cake in the past.
Now see what really happens here, as of today.
For one thing, I know that a Broom_(shrub) is a "Besenginster" in de:. (I found out by its latin name). So the thing to do is to add [[de:Besenginster]] to the page source, and be done. Simple and straightforward. Well, that it used to be.
Interlanguage links are not accessible for edit in the source. Not any more.
Instead some table-ish stuff presents itself to not much avail as it won't let me do what (I figure) should be done. Taking away my editor's freedom to do good, to say the least. Add to that, what it does do is give me a hassle.
Instead of letting me do the proper edit, some automatism behind the scenes insists that the de: link was already taken - that must be, for the opposite direction as there is no de: link in Broom_(shrub). Or anything the like.
The link in question supposedly involves Cytisus_scoparius.
Now while it's true that there is some (real-life) connection between Cytisus_scoparius and Broom_(shrub), some automatism behind the scenes shouldn't be keeping editors from doing what they see fit, this being just an example, after all.
Steps-to-repro again, for the sake of accuracy:
- Read Broom_(shrub). Edit. Look for (old-style) language links. Nope. Back to Read mode.
- Click "Edit links" in the toolbar, at "Languages". "Wikipedia pages linked to this item" shows up.
- Click "add" right under that table to add the de: link.
Which has become a lot more complicated in handling now. WTF. If that's mandatory to use that's pure, bloating, imposed, self-imposing, obnoxious overengineering. - type "de" for site. Resolves to decoded text in a pulldown. At least that works smoothly.
- type TAB. Well, somebody did their homework, for that matter.
- type Besenginster. Resolves to the present article in de:. So far, so good - or so I thought.
- click "Save" (and I find this does not work by hitting SPACE. That's in violation of a UI design rule, or used to be.) Watch the blurb bubble that's been sitting there and was blue, turn red and complain: "An error occurred while trying to perform save and because of this, your changes could not be completed." Well done.
- click "Details" on the blurb. Details are: "Site link Besenginster already used by item Q145781." Could have been told earlier in the first place, if it has to.
- "Besenginster" and "Q145781" turn out to be links in the Details. "Besenginster" is fine (links to the de: article). "Q145781" evaluates (links) to wikidata:Cytisus scoparius. Painstakingly copying the caption and inserting it into a (de? en?) WP search field... is not required, but only by reading the whole page and finding "Wikipedia pages linked to this item" (heading). Fair enough, but barely, considering all the hassle that I've listed to this point. Well...
- Seemingly, "Cytisus scoparius" as a Wikidata item links to "Besenginster" in de: and to "Cytisus scoparius" in en:. And that seems to be an 1:1 relation for each language.
As Cytisus_scoparius eclectically points out that this is the precise name for a family of brooms, and Broom_(shrub) is a common Broom in some parts of the world but a Scotch Broom otherwise, blah, blah... oh, very well.
But it's still perfectly rational, as "Besenginster" (in de:) is a common name and Broom_(shrub) is a common name (and there's no Scotch_Broom article, for that matter, apart from the occasional redirect) - so it's perfectly rational to interlink Broom_(shrub) with [[de:Besenginster]] and leave the eclectic stuff for the reader to click on where it says "Cytisus scoparius" in either article's text.
That's precisely what the automagicalism won't let me do, short of painstakingly restructuring it all (if I so dared). WTF.
Bottom line: I want interwiki language links back. As an option, if it has to be, but definitely. Period. Or anybody else has a better solution to come up with? That I'll appreciate. If you can tell me I just have to click this and that and be done, fine. But I still doubt it. Thanks in advance if you care.
In considering whether to reply, please keep in mind that it's not you I'm being angry at. I'll try to cool it. I'm just being really annoyed.
--217.81.139.17 (talk) 22:19, 4 August 2013 (UTC)
- Interwiki links still work during this transition period: I inserted "[[de:Besenginster]]" at bottom of page, to reduce frustration. Please note because there are 4.2 million articles, in enwiki alone among 30 million, the interwiki links still work during this transition period, until more millions of articles can be cross-connected, and Wikidata achieves its goal: "Nothing less than total world domination". Meanwhile, you might think you have discovered the Foundation's true secret mission: to destroy the profession of software development so that many educated people no longer think "computer science" was ever a real science, with logic and tested theories of how to develop reliable software capable of guiding airplanes or spacecraft trajectories. However, in reality there is no secret cabal named "Destroying Users Morale and Sabotaging Software" (D.U.M.A.S.S.), but instead it is just the way they implement peculiar plans in the Foundation. A typical ageing bureaucracy is likely to have multiple bureau departments which fight each other over control of data storage, or have two different menu options to edit the same page, with a menu branch for each part of the bureaucracy. That is normal bureaucratic activity, so do not worry unless you start seeing two menu options on every section of pages, as then you would know the goals of the bureaucracy have superceded the functionality of the system. -Wikid77 (talk) 02:13, 5 August 2013 (UTC)
Strange behaviour of Parser Functions
Hi there,
cannot find out the reason of strange behaviour.
I suppose that the construction:
[http://dlib.rsl.ru/viewer/01002921717{{#if:5|#?page={{#expr:5+2}}|}} test]
should give me: test.
Instead, I got: [http://dlib.rsl.ru/viewer/01002921717
- ?page=7 test].
Cannot find out why it adds a new line and thinks that the sharp sign starts it and how to workaround it... I need working URL-links with sharps!
Hinote (talk) 00:04, 5 August 2013 (UTC)
- The parser interprets the sharp character as a list point of an numbered list at this point. Can you rewrite the code to not contain it inside the parser function? E.g. --Patrick87 (talk) 00:33, 5 August 2013 (UTC)
[http://dlib.rsl.ru/viewer/01002921717#?page={{#if:5|{{#expr:5+2}}|}} test].
- (edit conflict) It's Template:Bug. Long ago, people complained that templates containing wikimarkup that's supposed to come at the start of the line (such as
*
or#
) were rendering wrong when the template wasn't itself placed at the beginning of the line (that was Template:Bug). Despite there being a workaround ("put a newline before the template!"), this was fixed by automatically injecting a newline before any transclusion of text beginning with those characters, which caused Template:Bug, which unfortunately has no workaround in many cases. Anomie⚔ 00:40, 5 August 2013 (UTC)
- Thanks guys for quick response!!!... Dammit!... So strange bugfixes and so strange behaviour in the parser code... Of course, I will rewrite the template and the link it contains, so that I have #if outside of the link, but it will require repeating the whole part of the URL which stands before the sharp... Hmmm... Hinote (talk) 00:49, 5 August 2013 (UTC)
- I don't know exactly in which situations this workaround works but in your example you can encode the number sign as
#
: test PrimeHunter (talk) 00:54, 5 August 2013 (UTC)- Should also work. Could not quickly find this html substitution code for the sharp sign... Thanks! Hinote (talk) 01:08, 5 August 2013 (UTC)
- Quickly see wp:CODES for HTML entity character codes (with accented letters), where I have repeated #= # (hashmark). -Wikid77 12:17, 5 August 2013 (UTC)
- I don't know exactly in which situations this workaround works but in your example you can encode the number sign as
"automatically accepted"
It seems that the article history is once again being cluttered up with stuff that appears to me to be of little or no use. This time, its the mention that a given edit is "[automatically accepted]" is tagged onto each line for each article in mainspace. The link just leads back to the article. I'm unaware of any recent discussion on why this needs to make a comeback. I think it should be removed unless there is strong consensus for it. -- Ohc ¡digame!¿que pasa? 03:07, 5 August 2013 (UTC)
- This is part of the Pending changes feature, which was re-enabled after a 2012 RfC. Graham87 06:12, 5 August 2013 (UTC)
Weird redirect behavior
File:Code of Honor.jpg displays like a redirect to File:ROH Code of Honor.jpg, but actually it is a redirect to (the deleted) File:ST-TNG Code of Honor.jpg, as can be seen by editing the source. Apparently the explanation is that the behavior is trumped by Commons:File:Code of Honor.jpg which redirects to Commons:File:ROH Code of Honor.jpg. This behavior is a problem because the local redirect is tagged for speedy deletion as a redirect to a deleted page, but the page is almost inaccessible. (Try accessing it with this ordinary link: File:Code of Honor.jpg.)
Perhaps the local redirect should just be deleted. (I bring it here because it is difficult to access it from Category:Candidates for speedy deletion.) Or maybe the difficulty should be explored first. —teb728 t c 07:36, 5 August 2013 (UTC)
{{CatAZ}}
I made it myself very difficult creating [[Category:Vessels by ENI number]] in Commons by using Category:ENI XXXXXXXX for each individual vessel. Mentioned template deviates by number. Is it possible to modify the template so that it does not use the term ENI and goes to a combination of numbers, like [[Category:Ships by name]] in Commons? --Stunteltje (talk) 08:17, 5 August 2013 (UTC)
- The unlinked items in your post are commons:Template:CatAZ, commons:Category:Vessels by ENI number, commons:Category:Ships by name. Are you looking for something like this:
- Preview the code at commons:Category:Vessels by ENI number to see how it works. 00 to 10 looks appropriate with the current category members but I don't know whether 11 to 99 will get far more members later. PrimeHunter (talk) 10:48, 5 August 2013 (UTC)
Sandbox ???
Hi, I was referred to you by Hillbillyholiday81 for helping with my sandbox. I'm having trouble formatting my categories correctly and trying to add this reference but keep getting errors. Here's my sandbox: http://en.wikipedia.org/wiki/User:GulfamUlRehman/sandbox Here's my new reference: http://heartbreakerrecords.com/artists/wem/index.html Really, thanks for your help! GulfamUlRehman (talk) 15:46, 5 August 2013 (UTC)
- I don't see an attempt to add that reference in the page history [10] so I cannot say what the problem is. If you save an edit then we can see what is wrong. The categorization of the page was deliberately inactivated by others (with two different methods [11][12]) because those categories are only for real articles. Your user sandbox shouldn't show up in Category:Hip hop and the other categories for readers of the encyclopedia. Category:Entertainment occupations and Category:Hip hop would also have been far too general for an article like that. It might have belonged in Category:East Coast hip hop musicians. PrimeHunter (talk) 18:31, 5 August 2013 (UTC)
redirect cat listed as subcat but shouldn't
I a redirect from a category to another category, with {{R from alternative name}}. The redirecting category is showing and counting as an empty subcategory of the destination category. This is useless. It should only redirect. While it being listed makes it appear available, clicking the subcategory name recursively brings the visitor back to the parent category. How do I keep the redirect but stop the redirecting category from appearing as a subcategory? Nick Levinson (talk) 16:04, 5 August 2013 (UTC)
- I think I fixed it. Chris857 (talk) 16:09, 5 August 2013 (UTC)
- So you did, and, even though I was amidst correcting my post above the same way when you did that, I probably wouldn't have thought of adding the colon to the redirect. Thank you. Nick Levinson (talk) 16:21, 5 August 2013 (UTC)
want a notice on a redirect page
A category has an unusual purpose that is not obvious unless explained, the category is already populated, and it simultaneously serves as a redirect to another category. All of this is within its purpose. It is a hard redirect; a soft redirect using the {{Category redirect}} template would add a notice for emptiness that is not appropriate to this particular redirect. A notice has been added to explain the purpose to visitors who click the link to the redirect, but it's not appearing even there. It should not appear at the redirect destination (and it doesn't) but if someone clicks the link to the redirect then they should see it. Right now, only a diff provides the notice, and it's unlikely that most admins or other editors would ever open and read the diff. Is there a way to make the notice visible to editors who read the redirect page? If not, should something be reprogrammed? Or do we need to add a parameter to the {{Category redirect}} template to make disappear its pro-emptiness notice, a parameter probably only for one-time use, and then add or keep the desired notice of the unusual purpose appear not just in the diff but on the redirect page? Nick Levinson (talk) 17:24, 5 August 2013 (UTC)
- You cannot make text appear on a redirect page, and apart from "(Redirected from ...)" the target page cannot display different text depending whether you got there via a redirect. If you don't want users having to edit the redirect page or examine the page history to find its purpose then the only option I see is giving it a special name like Category:This is a test of category redirects. PrimeHunter (talk) 18:48, 5 August 2013 (UTC)
- Please don't use hard redirects for categories, more at WP:R#CATEGORY. --Redrose64 (talk) 22:26, 5 August 2013 (UTC)
- Did you read the diff explaining the purpose? I think Wikipedia can live with one hard category redirect for testing. I already learned something from it: Category redirects are shown in italics.[13] PrimeHunter (talk) 23:17, 5 August 2013 (UTC)
- In fact, Category:X2 is the only category in Wikipedia that is a hard redirect without a {{category redirect}} soft redirect template, and it is that way solely for testing. I know it is the only one because my bot fixes any others that it finds. This category is the canary in the coal mine so that we are aware if something changes in the underlying software, such as the italics for redirected categories (which is a fairly recent development). --R'n'B (call me Russ) 09:33, 6 August 2013 (UTC)
- Did you read the diff explaining the purpose? I think Wikipedia can live with one hard category redirect for testing. I already learned something from it: Category redirects are shown in italics.[13] PrimeHunter (talk) 23:17, 5 August 2013 (UTC)
- Please don't use hard redirects for categories, more at WP:R#CATEGORY. --Redrose64 (talk) 22:26, 5 August 2013 (UTC)
"Mark all pages visited" button is disappearing
I have the feature where my watchlist marks for me any pages I have not visited that have edits. There's a button marked "Mark all pages visited" to remove the notations beside any unvisited pages. The button is appearing really briefly, and then is vanishing. This problem started when I logged on this morning. I am using a Toshiba laptop and running Vector skin on a Chrome browser. Any comments or advice would be welcome. Thanks, -- Diannaa (talk) 17:53, 5 August 2013 (UTC)
- I have it in Vector on Chrome. Did it happen before or after [14]? Do you see the button in MonoBook at [15]? PrimeHunter (talk) 18:16, 5 August 2013 (UTC)
- @Diannaa: Lemme guess, you are using Enhanced Recent Changes and you have made changes (enabled bolding gadget ?) to make the feature appear (Because the feature is disabled on en.wp when users use Enhanced Recent changes by default). For consistencies sake, this morning I also hid the button in Enhanced recent changes mode. That means I probably need to fix the "bolding" gadget to as well. —TheDJ (talk • contribs) 18:40, 5 August 2013 (UTC)
Something Visual Editor didn't do...
Does anyone know why this page is properly formatted, yet the links don't work? There is no hidden code in there, so any help would be great. Thanks! Kevin Rutherford (talk) 17:59, 5 August 2013 (UTC)
- Looks like it didn't like line breaks within wikilinks. -- cyclopiaspeak! 18:03, 5 August 2013 (UTC)
- Ah, I probably didn't even see that because of the size of my monitor corresponding correctly to the issue. Thanks! Kevin Rutherford (talk) 21:48, 5 August 2013 (UTC)
Need some template guru help
Can someone remove the deletion notice from Template:Infobox_rail for me? I looked at the deletion discussion and it was clearly a fail, but it seems no one closed it and the template still has the delete header on it. I would do this myself, but there was scary red text, so I back paged. Thanks! Maury Markowitz (talk) 18:28, 5 August 2013 (UTC)
- You could simply undo the most recent edit, which added the TfD notice. -- John of Reading (talk) 18:34, 5 August 2013 (UTC)
- Ohhh, duh… Maury Markowitz (talk) 18:36, 5 August 2013 (UTC)
- TfD's are normally open for at least 7 days and sometimes a little longer depending when somebody comes by to close them. Just wait. Most of the other discussions at Wikipedia:Templates for discussion/Log/2013 July 27 haven't been closed either. PrimeHunter (talk) 18:39, 5 August 2013 (UTC)
- Ohhh, duh… Maury Markowitz (talk) 18:36, 5 August 2013 (UTC)
How can an user without a Wikipedia account get the benefits of Mathjax rendering?
Having switched to Mathjax several months ago, I am now shocked at how awful the default math rendering is. So
- How about making Mathjax the default renderer?
- Alternatively how about providing some way for users who are not logged in to use Mathjax?
cffk (talk) 00:25, 6 August 2013 (UTC)
- See bugzilla:36496, bugzilla:48036 and mailarchive:wikitech-l/2013-July/070454.html. Helder 02:18, 6 August 2013 (UTC)
Aren't article talk pages meant to be no indexed?
See [16] Dougweller (talk) 00:32, 6 August 2013 (UTC)
- Nope. IIRC Google used to ignore talk pages on its own volition, but it obviously doesn't now. Graham87 01:15, 6 August 2013 (UTC)
- I have often wondered why Google ignores talk pages when we don't request it with noindex or our robots.txt at http://en.wikipedia.org/robots.txt. I notice that all talk pages they index now appear to have url's of form en.wikipedia.org/wiki/Talk%3A and not en.wikipedia.org/wiki/Talk:. I haven't found a way to specify the difference in a search but compare the green url's in site:en.wikipedia.org/wiki/Talk and site:en.wikipedia.org/wiki/Category. The former says "Talk%3A" in all examples I examined while the latter says "Category:". I wonder whether Google has on their own added "Talk:" to a blacklist, have indexed a site which says "Talk%3a" instead, and have then followed the links without realizing that it bypasses the blacklist. PrimeHunter (talk) 03:40, 6 August 2013 (UTC)
- maybe then we should NOINDEX them - I know I see a lot of BLP violations on them. — Preceding unsigned comment added by Dougweller (talk • contribs) 13:35, 6 August 2013 (UTC)
- I agree it's quite strange that Google used to ignore article talk pages but not userspace pages. The last community discussion on what should and should not be no-indexed was some time ago and probably needs to be updated; I'm not sure where is the proper venue for such discussion.
- Also on the subject of no-indexing, does anyone have any insight regarding the question I asked here? Thanks, Newyorkbrad (talk) 13:38, 6 August 2013 (UTC)
- There is a small difference between them. robots.txt means "don't crawl trough this part of my website". The no indexing part is a side effect of the not crawling. Robots.txt is useful to avoid excessive usage by Google of our resources, where it is of no use to them anyways. NOINDEX means just that "you are free to look at this page, as long as you don't make it part of your public index". It might be that information on such pages is still used for instance for pagerank algorithm scores of indexed pages (not sure about that, but I wouldn't be surprised). Since pages are often available with multiple urls these days, I think that is why google is advising the NOINDEX as the 'go to' technique. Plus they still get to analyze your page as a bonus :D —TheDJ (talk • contribs) 09:32, 7 August 2013 (UTC)
- I would support adding talk pages to robots.txt but not forcing a NOINDEX on each and every one of them. I would also support adding anything in certain project spaces such as WP:AFC drafts (although "most" should be covered by a full scale inclusion of all talk pages, there are a few that get misplaced in Wikipedia:Articles for creation/ (starting on page three)). Technical 13 (talk) 14:30, 6 August 2013 (UTC)
Subst with a template that invokes a module
I wanted to "freeze" some results from Module:Convert by using subst:
, but as the table below shows, it does not work. In this table, {{convert}} is a standard template, and {{convert/sandboxlua}} is a template that invokes the module.
Template | Result |
---|---|
{{convert|2|m}} |
2 metres (6 ft 7 in) |
{{subst:convert|2|m}} |
Template:Convert/mTemplate:Convert/track/abbr/Template:Convert/track/disp/Template:Convert/track/adj/ |
{{convert/sandboxlua|2|m}} |
2 metres (6 ft 7 in) |
{{subst:convert/sandboxlua|2|m}} |
[convert: needs a number] |
I can work around this (I'll use Special:ExpandTemplates), so I'm just wondering whether this is documented somewhere, or if I've missed something. mw:Extension:Scribunto/Lua reference manual#Returning text mentions subst, but I would need a couple more lines of explanation. Johnuniq (talk) 07:43, 6 August 2013 (UTC)
- Hmmm. Now that I've saved the above, an edit shows the last item in the table is:
{{#invoke:convert|convert}}
- So the subst applied to the template, but there was no attempt to call the module, and the bare
#invoke:convert
is causing the above error message. That's understandable, but not quite what I had hoped for. Johnuniq (talk) 07:48, 6 August 2013 (UTC)- I've added safesubst to {{convert/sandboxlua}} so it works now. -- WOSlinker (talk) 11:16, 6 August 2013 (UTC)
Template | Result |
---|---|
{{subst:convert/sandboxlua|2|m}} |
2 metres (6 ft 7 in) |
- Good grief, what magic is that!? When I've got a spare week I will study some docs, thanks. Johnuniq (talk) 11:48, 6 August 2013 (UTC)
- {|safesubst:} is very confusing even though it works, and yet another reason people dislike wikitext, similar to parameter syntax "{{{1}}}" when instead "#[1]" would have been easier to read when mixed with other double-braced parser functions "{{__}}". I have not thought how to redesign {subst:}, but perhaps re-read "Help:Subst#The_safesubst:_modifier" and then spend 2 weeks meditating in a Buddhist temple. When I meditated, I realized it could have been called "{|insanesubst:}" and made as much sense yet also warn the reader not to be expect obvious sanity. I suspect there should have been a live template-processing option, such as mythical {{MODE:subst=yes}} which would treat every embedded template as if prefixed with {{{{{|safesubst:}}}__}}" so that the end result would replace the template call with the processed results. While we are on the subject of peculiar template actions, I want to confirm that some markup inside templates will run differently than when copied into the same page (surprise!), but fortunately those cases are rare. Also remember that {subst:} does not work inside reftags "<ref>..</ref>" as parsed differently (unless temporarily renamed "<xxref>"), and people wonder what would be instant valuable improvements to WP instead of diverting resources to a VE used by 10% of people. Let's see: fix edit-conflicts, allow subst in reftags, create a "sanesubst" mode, etc. I guess military leaders learned how "division of command" can send the cavalry in the wrong direction when major help is needed elsewhere. -Wikid77 04:01, 7 August 2013 (UTC)
WikiMiniAtlas
Some time ago I added {{coord}}
to Martin Gusinde Anthropological Museum but the wikilink is still not shown in the WikiMiniAtlas. What must I do to show the article link on the map?. --Best regards, Keysanger (what?) 11:04, 6 August 2013 (UTC)
- The coordinates are parsed into a separate database so that they can be used for WikiMiniAtlas. I'm not sure how often this database gets updated. I think it used to be once every 3 to 6 months, but that was years ago. You should ask the maintainer of the tool. That would be Dschwen. —TheDJ (talk • contribs) 09:03, 7 August 2013 (UTC)
DEFAULTSORT and something else
Hi! I was wondering if there is some tool, which could help fing articles in some category, that don't have DEFAULTSORT? That was the first thing. The other is connected with templates. How to enable two ways of writing the parameter for images (to be ok, if it is written in form "File:Filename.jpg" and "Filename.jpg"), can't figure it out (for example this doesn't work: [[{{ucfirst:{{{image}}}|File:{{{image}}}}}|{{#if:{{{image_size|}}}|{{{image_size}}}px|200px}}|]]
). Thanks! --91.200.65.244 (talk) 14:33, 6 August 2013 (UTC)
- Question number one, I'm not exactly sure what you are asking. Question number two, the only way to do that logically is with string functions. These string functions only exist on the English Wikipedia in the form of the Module:String Lua module. It would make your template unduly heavy and I advise against it. Simply include instructions/documentation telling the user to just use the filename.img and leave the namespace off.
[[File:{{{image|Example.png}}}|{{#ifeq:{{{image_size|}}}||200|{{{image_size}}}}}px]]
should likely be your code... Technical 13 (talk) 14:50, 6 August 2013 (UTC)
- If you have infobox images in mind then see Module:InfoboxImage. PrimeHunter (talk) 15:03, 6 August 2013 (UTC)
- 1) for example there is category "American actors" and i want to know in which articles there isn't the defaultsort (to see each page would take a lot of time). 2) PrimeHunter, yes module is good, but it is actually not for en wiki. --91.200.65.244 (talk) 15:06, 6 August 2013 (UTC)
- Then which wiki? We need to know which features it has. This page is mainly for the English Wikipedia. PrimeHunter (talk) 15:26, 6 August 2013 (UTC)
- 1) for example there is category "American actors" and i want to know in which articles there isn't the defaultsort (to see each page would take a lot of time). 2) PrimeHunter, yes module is good, but it is actually not for en wiki. --91.200.65.244 (talk) 15:06, 6 August 2013 (UTC)
- Auto-insert "File:" by checking padleft of image-name: The other issue, about allowing people to omit "File:" can be solved by checking {padleft:|n|} of the image-name, against prefix "File:" or "Image:" as:
[[{{#ifeq:{{padleft:|5|{{ucfirst:{{{image}}} }}|File:
- | {{{image}}}
- | {{#ifeq:{{padleft:|6|{{ucfirst:{{{image}}} }}|Image:
- | {{{image}}}
- | File:{{{image}}}
- }}<!--endif prefix "Image:"-->
}}<!--endif-->|{{#if:{{{image_size|}}}|{{{image_size}}}px|200px}}|]]
- To check the middle of a name, then use Template:Substring to extract central text, or Template:Str_find to scan within the name. -Wikid77 (talk) 04:32, 7 August 2013 (UTC)
[edit source]
I don't like the new [edit source] links because of their additional length and because they make me think that I'm attempting to edit a protected page without the rights to do it. Is there any gadget or other method that I could use to cause these links to display as [edit] when I'm logged in? Nyttend (talk) 21:31, 6 August 2013 (UTC)
- Preferences → Editing → MediaWiki:Visualeditor-preference-betatempdisable worked for me. — Maile (talk) 21:36, 6 August 2013 (UTC)
User namespace shortcut
We have the "WP:" namespace set up so that WP:NPA redirects to Wikipedia:NPA. Is there any reason we don't do the same for "U:" to "User:"? — Preceding unsigned comment added by Pigsonthewing (talk • contribs)
- It was suggested a few years ago but not much discussion happened. Killiondude (talk) 22:33, 6 August 2013 (UTC)
- See also User talk:Wavelength/Archive 4#U: (June 2012) and Wikipedia:Village pump (miscellaneous)/Archive 38#U: (June 2012).
- —Wavelength (talk) 02:33, 7 August 2013 (UTC)
- Things like "User:" and "Talk:" are already rather short, so there's not much of a case on that front but "UT:" for user talk, and "Cat:" for the category namespace would all be pretty useful. "T:" for the template namespace would also be justified, except that most other users (I'm a bit of a templates gnome) would have little cause to ever use it. "CT:" for category talk is probably an edge case, although supporting "Cat talk:" would probably help a lot. VanIsaacWS Vexcontribs 03:05, 7 August 2013 (UTC)
- Also see Wikipedia:Perennial_proposals#Create_shortcut_namespace_aliases_for_various_namespaces. πr2 (t • c) 03:05, 7 August 2013 (UTC)
Template:Country geography
I'm trying to understand a template. It looks to me as if it should output something, so I'm wondering why it doesn't. In this article, the {{Country geography}} infobox includes parameter "km coastline = landlocked
" (where "landlocked" would sometimes be a number like 123 to mean 123 km). It looks to me as if the infobox should generate (omitting the html table stuff):
Coastline {{convert|landlocked|km|mi|abbr=on}}
If {{convert}} gets "landlocked" as its first parameter, it correctly complains loudly. I've tried the infobox wikitext in a sandbox, and "Coastline" never appears, even if "landlocked" is replaced with 123. Why not?
If anyone is curious, I'm investigating a similar template in a similar article which does output the erroneous "landlocked" text, with bad results. The article is bn:ম্যাসেডোনিয়ার ভূগোল, and the error message reads (according to Google Translate): 'Conversion error: Value "land-locked" must be a number'. Johnuniq (talk) 04:00, 7 August 2013 (UTC)
- It didn't even work with valid inputs before! I have fixed it, but there may be other errors in the template. And, since you're interested, it was fixed on bnwiki already. ;) πr2 (t • c) 04:14, 7 August 2013 (UTC)
- Does anyone else think that this template should maybe be implemented through the infobox framework? It seems like it's reinventing the wheel.VanIsaacWS Vexcontribs 04:40, 7 August 2013 (UTC)
- @πr²: Amazing, thanks. Hilariously, I noticed that strange syntax but because of some magic I was recently shown above, I imagined it was more of the same. You edited the article to replace "landlocked" with "0", but I believe the parameter should be blank (or probably just omit the "km coastline" setting as it's unlikely to be needed). With "0", the article shows "Coastline 0 km (0 mi)" (after purging). Johnuniq (talk) 06:03, 7 August 2013 (UTC)
"could not load twinkleoptions.js"
Hello all. I'm not sure if this is the right place to ask for help about this but I have been getting the message "could not load twinkleoptions.js" every time any WP page loads. It's getting a little annoying and I haven't been able to figure out why on my own. Does anybody know anything about this or what to do about it? I first noticed it after I disabled Visual Editor in my preferences yesterday, maybe it's a coincidence but it might help to figure it out. Thanks in advance for any help/suggestions.--William Thweatt TalkContribs 07:14, 7 August 2013 (UTC)