[[Category:Non-talk pages that are automatically signed]]
[[Category:Non-talk pages that are automatically signed]]
[[Category:Pages automatically checked for accidental language links]]
[[Category:Pages automatically checked for accidental language links]]
</noinclude><!--
[[as:Wikipedia:ৱিকি মিস্ত্রিৰ দোকান]]
[[frr:Wikipedia:Tächnische frååge]]
[[mk:Википедија:Селска чешма (Техника)]]
[[ur:منصوبہ:دیوان عام/طرزیات]]</noinclude><!--
Please add new questions to the end of the page. The easiest way to add a question is to click the "add new topics" link, just before the table of contents.
Please add new questions to the end of the page. The easiest way to add a question is to click the "add new topics" link, just before the table of contents.
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
This is just a heads up to let you know that we have undeployed Moodbar and the Feedback Dashboard from the English Wikipedia. As an experiment, Moodbar was a fair success but we have come to the conclusion that it will require a fair chunk of development work (on the Feedback Dashboard side) to make it fully usable as a mechanism for new user engagement.
Additionally, we have new tools that we are planning to roll out and test that will operate in the same space and we want to avoid conflicts.
Atlasowa, thanks for posting a notice at wpnl. @Jorm: if it turns out we at wpnl would like to keep using Moodbar in its current state until the new tools become available, would that be possible? MrBlueSky (talk) 22:27, 9 February 2013 (UTC)[reply]
Absolutely. We are only undeploying it from the English Wikipedia at this time. It is conflicting with another set of work that we hope will bear greater fruit.--Jorm (WMF) (talk) 19:38, 11 February 2013 (UTC)[reply]
A reader wrote in to Wikimedia Foundation to report a problem with pdf exports. I know there are some general problems, but this one is troubling, because it appears to work, yet will produce results which are off by a factor of ten.
I'll copy the person's own words:
I would like to report a problem concerning exporting articles from
Wikipedia to pdf. The problem lies with the following code:
Since confusion can arise from this situation I think that a fix of the
problem should be found as soon as possible.
I didn't find the example above in the link provided, but this line:
"the masses of elementary particles become visible at energies above 1.4 TeV" in Standard Model
I'm still having problems with accessing *.grok.se. I can't connect from my site but can connect from others. Any reason why this would be? --Lydgate (talk) 10:42, 12 February 2013 (UTC)[reply]
RefToolbar
It says the Wikipedia:RefToolbar/2.0 page that the new Toolbar should be default for all English users(and I used to too) but for some reason I seem to have lost the "cite" option on my toolbar.
I don't seem to be using the "RefToolbar 2.0a" either because I have no {{}} icon featured. Could anyone tell me how I can get it back?! The cite tool is the only thing on there I actually need!!!
I tried a combination and between them, they seemed to work. Just for note, how can I stop the above happening in future? The same has occurred today and I've been wiki-ing for 9 months+ and nothing like this happened before... ---Brigade Piron (talk) 09:38, 10 February 2013 (UTC)[reply]
As you will have read, someone made a minor error. Your browser kept that error-version in its cache. You're the only one in charge of your browser, and nobody can predict the errors of others. So - first rule of thumb anywhere in the world when you have problems with a website: clear your cache (✉→BWilkins←✎) 10:37, 10 February 2013 (UTC)[reply]
I'm seeing something rather odd in the "Rate this page" box at the bottom of pages - instead of the numbers of ratings being displayed, something along the lines of "{{PLURAL:60|one rating|60 ratings}}" is being displayed. Prioryman (talk) 17:03, 10 February 2013 (UTC)[reply]
Here is the displayed text with nowiki tags so others can see what you mean (it has now been fixed above): {{PLURAL:60|one rating|60 ratings}}. It renders as "60 ratings" here in wikitext but apparently not in the ratings box. The magic word plural is documented at Help:Magic words#Formatting. PrimeHunter (talk) 17:19, 10 February 2013 (UTC)[reply]
Yes, I am seeing the same problem. That number shows how many people have voted, but it is appearing as what PrimeHunter said in the previous comment. Supercuty27 (talk) 06:43, 13 February 2013 (UTC)[reply]
Template:efn and <ref> tag error when no <ref> tags are used?
(edit conflict)Read that in too big of a hurry. Striking some. The problem is the URLs that use the = key. From the template documentation: "Remember that "=" cannot appear in an unnamed template parameter and "|" cannot appear in any template parameter. For "|", {{!}} can be used. For "=", {{=}} can be used or the parameter can be named 1= explicitly:
Constant server error when editing one particular article
I have an interesting problem with the article List of South Korean idol groups. Whenever I try to edit the page or a section and I push submit, I get the server error message of Wikimedia, the one we usually see when the servers are down. It doesn't happen with any other article, so I started to doubt this is a general problem with the website. The interesting thing is that my edits are saved when I go back to the page and check the history tab. I still get the server error screen right after saving. A friend suggested that i ask here as he thinks maybe a particular template is causing the problem, or perhaps the page is too big in size? 200,286 bytes at the moment, with almost 500 {{cite web}} templates. Any help or suggestion would be great小龙 (Timish)# xiǎolóng de xìnxiāng10:25, 11 February 2013 (UTC)[reply]
I've occasionally seen this happen elsewhere on very large pages: edits do go through (as evidenced by the history), but it takes a long time and often you see a server error page. I just made a small edit and got the same result.
Would it be possible for any template which uses social networking sites' tools for interacting with external websites (e.g. "Share this on Twitter!"-type links/buttons) to automatically be put in some Category; and for there to be a piece of user-JS/-CSS code that automatically hides all members of said Category? Current examples of such templates on en-wiki are Template:Share and Wikipedia:Signpost/Template:Signpost-article-start. I've recently added some CSS code to my page that hides {{Share}}, but what I'd really like is code that hides invitations to share WP content on social networks ipso facto, due to the potential for equivalent templates to appear under other names (as the Signpost example demonstrates). Thanks in advance for your help, It Is Me Heret / c13:41, 11 February 2013 (UTC)[reply]
Hello,
I'm familiar with how to get article stats at http://stats.grok.se/en/latest/article_name, however, I can only use that tool to view one article's stats at a time. Is there any way to feed multiple article names, say 25-30 article titles, to view them all at once? (That way I can know which is getting the most hits at a glance, rather than going thru them one by one.) Thank you for answer! Ihardlythinkso (talk) 15:29, 11 February 2013 (UTC)[reply]
Yes, affirmed. (And from your followup I understand there's no way currently to do what I wanted. With all the technical programmers at the Pedia, and the importance of stats ... I don't get it!) Ok, thank u. Ihardlythinkso (talk) 19:39, 12 February 2013 (UTC)[reply]
Feature Request. Make it so that rather than converting three, four or five tildes to the appropriate signature/time values, reject the edit if it takes place on a mainspace article (there are probably other spaces where this would be equally useful like template).Naraht (talk) 22:04, 11 February 2013 (UTC)[reply]
This could be done through an edit filter. Some time ago I asked about having a filter that would block this kind of thing, as well as many other features (e.g. '''Bold Text''' or <ref>Insert footnote text here</ref>) but I was reminded that it would be a bad idea because there are apparently many more times than I imagined that such things are needed in articles. Nyttend (talk) 22:30, 11 February 2013 (UTC)[reply]
What if someone wrote a large section or made a lot of modifications to an article but wrote "~~~~" at the end? The user would be discouraged by the edit filter warning, and might not try to add the text (s)he wrote again. πr2 (t • c) 19:24, 12 February 2013 (UTC)[reply]
Articles with a "/" character in their name
As we know, the "/" character tends to signify a change of directory or folder to computers. In its simplest form an article entitles A/B creates B as a sub page of A. Whether it is stored thus is immaterial. BUt this gives rise to some anomalies.
I noticed these with articles about the incidents known as "9/11 (things)".
Look, for example at 9/11 conspiracy theories, not for article content, but for article naming. It is a free standing article and does not present itself as if 11 conspiracy theories is a subpage of 9. Now navigate to the talk page with the talk tab. we arrive happily at Talk:9/11 conspiracy theories.
On line three, right at the top, just under From Wikipedia, the free encyclopedia is a link: < Talk:9. That takes us to Talk:9
Now I have no idea if Mediawiki has an error or a restriction, and Bugzilla is a place I am not headed towards. But I felt it to be interesting.
That least me to a question: "Do we consider this to be something that needs to be solved? If so, shoudl it be solved at Mediawiki level or by moving the articles to '/' free names?"
Subpages are disabled in main namespace, that is why in the case of 9/11 conspiracy theories, 11 conspiracy theories is not a subpage of 9. The example of Talk:9/11 conspiracy theories shows that subpages are enabled in Talk namespace. I agree that subpages maybe should be disabled in Talk namespace as well. Does anybody know whether there are any valid uses of subpages in talk namespace that disabling this would break? -- ToshioYamaguchi23:35, 11 February 2013 (UTC)[reply]
One example of why the subpage feature is useful for this: The move form for admins on articles with talk subpages has a "Move subpages of talk page" check box. PrimeHunter (talk) 23:56, 11 February 2013 (UTC)[reply]
In the early days of Wikipedia, we used subpages for subtopics, and many of these titles are still around as redirects for historical purposes. See Albania/History, for example. The problem with subpages in mainspace is the question of hierarchies: should History of Albania be located at Albania/History (i.e. Albanian history is a sub-topic of Albania in general) or History/Albania (i.e. Albanian history is a subfield of history in general)? This is largely why we developed the category system, since History of Albania can be put both in a general Albania category and in a general history category. Nyttend (talk) 03:23, 12 February 2013 (UTC)[reply]
Clarification:by "disable subpages" I meant "disable breadcrumb links at the top of the page and treat as if it didn't have "/" in its title. πr2 (t • c) 22:11, 12 February 2013 (UTC)[reply]
I've started an RFC for the MediaWiki software. The goal is to make it more practical to change the password requirements, and to allow configuring different requirements for different groups (e.g. admins, stewards, etc.)
No immediate change to Wikipedia is proposed, but this would make such changes possible. The goal is to have stronger requirements for accounts with extra rights, without inconveniencing regular users (though it is still advisable for everyone to choose a strong password). Superm401 - Talk06:05, 12 February 2013 (UTC)[reply]
I'm sure there was a discussion - can't imagine how obvious the change would have been anyway. The word "my" was a redundant waste of space (✉→BWilkins←✎) 12:56, 12 February 2013 (UTC)[reply]
It was several months ago, for the reasoning that it was inconsistent with the rest of the Internet to add the personal words of ownership. Which, it's hard to disagree with that as a statement of fact. --Izno (talk) 13:13, 12 February 2013 (UTC)[reply]
I absolutely don't care if it as a "my" or not. But... the fact is that page is *my* watchlist, not some global WP watchlist, not your watchlist, not John Doe's watchlist. It is my watchlist, the one I built and chose to have. - Nabla (talk) 13:31, 12 February 2013 (UTC)[reply]
Oh, were you talking about the title of the Special page? My CSS thingy changes the link at the top of the page. The title in the top of the content window can be changed with:
If you also want to change the html page title (the text that shows up on tab labels and the top bar of the browser), I don't think that can be done through CSS. It would require Javascript. Should be something to the effect of:
Maybe it's something on my end, but often as not, various Wikimedia pages aren't completely loading. I'm seeing this both here and at Commons. Sometimes the "skin" doesn't load, sometimes the Twinkle script doesn't load, sometimes the clock doesn't load etc. Doing a purge (server or local) sometimes clears up the issue. -- Gyrofrog (talk)16:27, 12 February 2013 (UTC)[reply]
Yes, the issues are WMF-wide including wikis that don't have wikidata yet. The servers that serve the JS and CSS are down and ops are looking into it right now. --Aude (talk) 17:14, 12 February 2013 (UTC)[reply]
Displaying Issues
Today, many pages seem to be using a different skin. Every time I tried to go to my Watchlist in the past couple of hours, it displayed it in a weird, bland skin (with just a bunch of links on the side, rather an spaced around the page like usual. (I always use the Vector skin.) This just fixed itself, but I'm still have the same issue with Wikidata:Wikidata:Project chat. Also, Special:NewPagesFeed is working on-and-off, and even when it's on I can't access the page curation tools. What is going on? (I'm using Firefox on a Dell laptop running Windows 7.) -- Ypnypn (talk) 16:29, 12 February 2013 (UTC)[reply]
I just pressed save page, and it went to that weird skin, but then I clicked edit (to add this comment) and I'm back on Vector. Help! -- Ypnypn (talk) 16:30, 12 February 2013 (UTC)[reply]
I can confirm there is some sort of problem. My vector.css is not taking effect as of today (it was working fine yesterday, and has been working fine for years). —SeekingAnswers (reply) 17:02, 12 February 2013 (UTC)[reply]
It's not a "different skin", but your normal skin where some or all of the CSS and JS files have either failed to be sent by the server, or have failed to be loaded by your browser. A hard refresh of the page may fix it; however, when I tried this, I found that a different combination of CSS/JS were failing. --Redrose64 (talk) 17:04, 12 February 2013 (UTC)[reply]
Just seconding the notion that my stuff has gone all wonky too...page loading taking *forever*, not loading completely (all pages missing the tab with the RPP/Welcome/Warning/Tag/etc), the rollbacker/'restore this page' feature is gone, hovering the cursor over editors' names doesn't bring up any of their information, and so on. Shearonink (talk) 17:10, 12 February 2013 (UTC)[reply]
It's not fixed yet; the GET requests that RE mentioned are failing at random, making each bit of Wikipedia (skin, user JS, site JS, whatever) work or fail independently from the others. What works and what doesn't changes from pageload to pageload, as different requests succeed or fail. Writ Keeper⚇♔17:24, 12 February 2013 (UTC)[reply]
I'm not noticing any issues now (I wasn't online when the problem was reported). Per the standard drill, please bypass your cache before reporting that you're still seeing a problem. You might be seeing it because of something cached by your browser that has since been fixed on the Wikimedia servers. – PartTimeGnome(talk | contribs)22:05, 12 February 2013 (UTC)[reply]
Is the default skin borked?
About every third page load today, Wikipedia refuses to load the default skin, and instead loads as raw HTML. It's been doing this for several hours now; not every time, but often enough to be annoying. Is this sort of intermittent problem happening for anyone else? --Jayron3220:06, 12 February 2013 (UTC)[reply]
Well, I think what you'd have to do would be to bypass the addition of the automatic timestamp. You could do this by simply typing three tildes instead of four. You could then amend your signature to end with something like {{subst:CURRENTTIME}}, [[{{subst:CURRENTMONTH}}|{{subst:CURRENTDAY}} {{subst:CURRENTMONTH}}]] [[{{subst:CURRENTYEAR}}]] (UTC). Of course, I have no idea if the incredibly temperamental signature thingy will allow you to actually do that. There might also be a simpler way to do this... the first person I can think of who might know is X! (talk·contribs), who keeps that cool .beat time in his signature. — PinkAmpers&(Je vous invite à me parler)19:28, 12 February 2013 (UTC)[reply]
Please note that date linking has been discouraged for some four years now (since December 2008, IIRC); also, dates in signatures normally follow the day-month-year format, so your month-day-year format may confuse certain scripts and bots (that's if they're not confused already by the linking). --Redrose64 (talk) 20:27, 12 February 2013 (UTC)[reply]
Duly noted. I've fixed a redundant pipelink, hopefully that makes the bots' work easier. If any major problem arises, I'll gladly change it back. InedibleHulk(talk) 22:01, February 12, 2013 (UTC)
I've pinged Misza13, the owner of User:MiszaBot I and its ilk, which can be quite fussy about the format of timestamps. MiszaBot II never archived this message, for instance. As implied at User:MiszaBot/Archive FAQ, this problem could be fixed by adding the timestamp in a normal format in an HTML comment (<!-- -->); for this you'd have to create a template like {{!}} to generate a less than sign, or something. The whole idea sounds like far more trouble than it's worth. Graham8704:37, 13 February 2013 (UTC)[reply]
A script on this page may be busy, or it may have stopped responding.
Sorry if this is a FAQ but I seem to have been getting this message recently when I look at diffs.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
I've merged the sections mentioned by Redrose64 (and also #Is the default skin borked?). I've not merged this section, however, since I'm not convinced this is the same issue. The "A script on this page may be busy" warning can only appear for scripts that have been loaded, and that section is about scripts (and CSS) not loading.
I'm not ruling out that the problems could be related, though. It is possible that a successfully loaded script was malfunctioning because of another script that failed to load. – PartTimeGnome(talk | contribs)22:05, 12 February 2013 (UTC)[reply]
That was my thought - along the lines of: page loads script a.js which depends on script b.js but server fails to return b.js; and browser doesn't want to wait forever, so throws error instead stating that a.js has hung. --Redrose64 (talk) 23:00, 12 February 2013 (UTC)[reply]
I've now tried a few other computers and can't reproduce this error elsewhere, so given the lack of people saying "me too" I suggest we blame my computer and move on. Apologies. --Northernhenge (talk) 13:31, 15 February 2013 (UTC)[reply]
I'm having major problems with the search function. Whether I'm searching for an existing article/template/page or for one that might not exist, rather than going to the article or the search page, I get sent to a blank search screen. It only happens some of the times. RyanVesey01:01, 13 February 2013 (UTC)[reply]
What Crisco said. The big problem is the search issue probably appears every 7-10 searches or so. Then I can't use the search bar for about the same number of searches. Then it will work again. Sometimes it will open some pages but not others. It's really glitchy right now. RyanVesey00:11, 14 February 2013 (UTC)[reply]
many flag icons in a big table
I have a less than entirely favorable view of the quality of the article Daisaku Ikeda, but quality aside, it's a slug to load. It contains a long table, which itself contains many flags, and which first grows, slowly, and then is collapsed in front of me while I wait for the page to load. I could experiment to see where the problem lies, but guessed that people here would immediately know from experience. (Of course, my particular choices of browser may make particularly heavy weather of the page.) Comments?
(Not strictly a technical matter, but I'm also not convinced that there's a rationale for the flag for each institution. [Adding them was not my idea.] Most of these institutions aren't national, in the narrower sense. Though OR tells me that even in the moderately democratic nations of Asia, municipal, privately financed and other institutions are thought of as representing their nations, or anyway as doing so outside those nations.) -- Hoary (talk) 02:15, 13 February 2013 (UTC)[reply]
Scribunto extension roll out planned for February 18
Wikimedia Foundation has been working on improving performance and adding features to template pages within MediaWiki. As a result of this WMF developed a new Scribunto extension for MediaWiki which enables Lua scripting language for templates. The developers are confident about the extension's maturity and it was decided that Scribunto is going to be deployed to this wiki in the first batch. The deployment will begin on February 18 and will simply add a feature. Please be so kind and spread the word about the deployment on your wiki. If you are interested in converting current templates to Lua, please see more information and submit your feedback to Lua page on Meta. Regards, Kozuch (talk) 18:04, 13 February 2013 (UTC)[reply]
Login/create account and watchlist now live on the mobile web
Screenshot of the mobile watchlist view
Exciting update from the Wikimedia mobile web team: we've just released the ability to log in or create an account, watchlist/unwatchlist pages, and see a mobile-friendly view of your watchlist on the mobile web (en.m.wikipedia.org – and the ".m" version of every other mobile Wikimedia project). See screenshot of my watchlist to the right :) The watchlist view comes with a full list of articles you've starred, as well as a filterable "modified" view; you can see the diff by tapping on any change. Check it out on your Internet-enabled mobile device of choice, and feel free to leave feedback for us on Meta, or visit us on our IRC channel, #wikimedia-mobileconnect
Next up, we're working on contributory features for mobile, including photo uploads and editing, so stay tuned for the mobile revolution, already in progress! :) Maryana (WMF) (talk) 20:50, 13 February 2013 (UTC)[reply]
Template question
For Audie Murphy an IP tried to insert a legitimate website address into the infobox. It didn't work for the IP address. I looked at the website coding for Template:Infobox military person, and it looks identical to my lay eyes as the website coding on Template:Infobox person. As a test, I switched out what the IP had added, and instead inserted the website URL template from Bill Gates, and the Bill Gates website did not show on Audie's infobox. I've changed Audie Murphy's to the URL template. It still doesn't work. Can anyone look at the Audie Murphy infobox and figure out why the website url does not work there? — Maile (talk) 20:59, 13 February 2013 (UTC)[reply]
I think the problem is in {{Infobox military person}}, where it uses header20 for the "Website" label and data20 for the url itself. According to the documentation at {{Infobox}}, the use of header20 means that data20 is ignored. Compare this with {{Infobox person}}, which uses header70 and data71 for its "Website" field - consecutive numbers. -- John of Reading (talk) 22:19, 13 February 2013 (UTC)[reply]
Despite what the {{infobox}} documentation says about leaving gaps, there are people who insist on having all the rows in unbroken sequence from 1 - which makes it a pain to insert additional rows later on, you first have to renumber those that are already there. Anybody here remember programming in BASIC with no RENUMBER command? We did everything by tens, because we knew that at some point, statements would have to be inserted.. --Redrose64 (talk) 23:57, 13 February 2013 (UTC)[reply]
Seems to work great, except that the "Show Wikidata edits by default in recent changes and watchlist" option in Preferences isn't working (and yes, I disabled enhanced recent changes to test it and bypassed my cache). Even with that box checked, I have to manually click "Show" on "Show Wikidata" on my watchlist to get Wikidata edits. jcgoble3 (talk) 23:14, 13 February 2013 (UTC)[reply]
Hmm... I seem to have the opposite problem from jcgoble3 above. I have "Show Wikidata edits by default in recent changes" turned off in my preferences, yet I still see Wikidata edits in my watchlist. I'm using Monobook for my skin. I am using an expanded watchlist, but not an enhanced watchlist. I've instead resorted to this one line of CSS to hide the Wikidata edits. – PartTimeGnome(talk | contribs)23:37, 14 February 2013 (UTC)[reply]
How does this affect Commons? – specifically, iwl links from Commons to the Wikipedias? Even more specifically, what about Commons categories that link to article pages? Andy Dingley (talk) 23:40, 14 February 2013 (UTC)[reply]
Are Wikidata-derived iwl links commutative? Specifically if fr:WP has a topic on fr:BigTopic, but not on fr:SubTopic, we may well have articles at en:WP on both en:BigTopic and en:SubTopic. Practice has often been that en:Subtopic would include an iwl to fr:BigTopic (as the best available, and possibly quite a good overview), but we need to ensure that fr:BigTopic links only to en:BigTopic. Andy Dingley (talk) 23:43, 14 February 2013 (UTC)[reply]
I believe I fixed that problem for you; see this edit. You didn't have the newlines enclosed in the parser functions, so all of the newlines in the code were showing up no matter what. However, I reverted myself because that broke the example in the documentation, probably because MediaWiki is stripping those newlines while parsing, which would break the template. You need to find a way to include the newlines in the parser functions, but not have them begin or end a parameter in the parser function, which would cause them to be stripped. jcgoble3 (talk) 00:48, 14 February 2013 (UTC)[reply]
I still haven't found the way to include the newlines in the parser functions.
I've added <br> after parser's slash. Also, added space characters. Have a look at the result and also check out the page's code. Will it work correctly in all browsers? And is it the right coding after all? All I know — it works with my Chrome browser. 217.118.78.80 (talk) 05:39, 14 February 2013 (UTC)[reply]
Parser functions are independent of the browser as they are processed on the WMF servers, and once they're parsed you're left with a standard wikitable, which the servers convert to basic HTML table code before feeding it to your browser, so it will work in all browsers. I removed some unnecessary stuff, which killed the last case of <p><br /></p>. The template should work now. jcgoble3 (talk) 06:44, 14 February 2013 (UTC)[reply]
Yes, it works! By the way, my question was about that <br> stuff, will it expand cells in some browsers? Thanks a lot for taking time and help me! --217.118.78.84 (talk) 16:15, 14 February 2013 (UTC)[reply]
I tested it in four browsers (Safari for Windows 5.1.7, Chrome 24.0.1312.57 m, Firefox 18.0.2, and IE 10), with no problems in any of them. jcgoble3 (talk) 19:48, 14 February 2013 (UTC)[reply]
Well done at getting this working! For future reference, here's a trick I like to use to stop trailing newlines and spaces being stripped from the end of a parser function: Place <nowiki/> after the line break(s), before the closing }}. For example:
{{#if:{{{show1|}}}|This is the first para.
<nowiki/>}}{{#if:{{{show2|}}}|This is the second para.
<nowiki/>}}
Will Wikipedia pay for my therapy when I suffer a major nervous breakdown as a result of having to post every edit several times against error messages and edit conflicts (even when postings are minutes apart)? The random loss of character spaces and appearance of unwanted linespaces after edits is also driving me crazy. Operations that use to be performed in a few seconds now take anything up to ten minutes. Please expedite ridding the system of its current gremlins, as they must be a serious deterrent to many people willing to contribute time and effort to improving Wikipedia. Kim Traynor00:34, 14 February 2013 (UTC)[reply]
I've been having issues with editing large pages for the past few days (and probably longer). For example, New York City. I takes 30-40 seconds simply to load the page. When I edit, it takes 40+ seconds then I get a timeout error and it fails to reload the page w/ my change. My edit *does* get saved though. I'll try poking the tech people about this though not sure of a simple, easy fix for this. Maybe introducing the Lua thing for templates will help or something. --Aude (talk) 04:22, 14 February 2013 (UTC)[reply]
I think it is the newer operating systems. Why I edit with my old 286 and go online with a 9600 baud modem then things move much faster.--Canoe1967 (talk) 04:26, 14 February 2013 (UTC)[reply]
Hmm.... well, I chatted with tech staff and they suggest 1) when we get Lua for templates (next week, planned), that will help a lot. 2) editors can try to remove some of the templates. There might be certain ones that are especially "heavy" (with lots of parser functions, recursively / nested additional templates) Or it might be a sign that some of the article content needs to be split into subarticles, to reduce the number of cite templates. 3) for template editors, some of the templates can probably be improved. They can't change the timeout period. For edit conflicts, there might be some additional issues going on and I am not sure the solution. --Aude (talk) 11:40, 14 February 2013 (UTC)[reply]
Yes, well even this edit threw the error in question, as did this one. The problem on that page is the massive RDT up the right-hand side, generated by {{Cross Country Route}} in the lead section. Even if you edit only one section, the MediaWiki software must still rebuild the whole page. --Redrose64 (talk) 21:04, 14 February 2013 (UTC)[reply]
I just ran some numbers New York City is 1491874 bytes (excluding images), at 1.4MB + files that is an extremely large page. With 389 references and a template depth of 32 I am surprised the page even renders. A good size for article size is about 1/3 that size. Werieth (talk) 21:06, 14 February 2013 (UTC)[reply]
Their email simply included Member for Fremantle Melissa Parke MP Profile Pic.jpg. If I enter that into the search box, I get the response:
There were no results matching the query.
The default search is articles only, but I have added a check box next to File. I thought that should search for a file with that name. I thought this did work, but I may be dreaming.
While it may seem simple to add "file:" to the search, I do this dozens of times a day. I think searching for a file named Member for Fremantle Melissa Parke MP Profile Pic.jpg should find that file, especially when I check the File box. Is there something wrong, or something I am doing wrong?--SPhilbrick(Talk)01:10, 14 February 2013 (UTC)[reply]
I think that's it. Which is very disappointing, because editors often file a permission statemnt the same day they upload, which mean it is quite common to have to struggle with the search.--SPhilbrick(Talk)14:04, 14 February 2013 (UTC)[reply]
Is it possible for a bot to cross check articles in dead people categories with infoboxes that don't have images? This way we could create a category to search for articles that we are allowed to add fair use images to.--Canoe1967 (talk) 02:43, 14 February 2013 (UTC)[reply]
Hello all: sorry if this is impossible, but does anyone else think that it would be a good idea to implement a search from the end of an article's name (e.g. I could search for all articles that ended in "Persei")? For what I'm working on with astronomy articles, it would be really nice to have such a function. StringTheory11 (t • c) 05:30, 14 February 2013 (UTC)[reply]
How to track the use of Australian War Memorial photos on Wikipedia
The Australian War Memorial is in the process of increasing the size of the images it makes available on its collection database. Many of these images are in the public domain and are used in Wikipedia articles, with the great majority being hosted on Wikimedia Commons and tagged with {{AWM-image}} there (which in turn places them into http://commons.wikimedia.org/wiki/Category:Images_from_the_Australian_War_Memorial ). The AWM is currently in the process of increasing the size of the images on its database by about a third, and when the Imperial War Museum made a similar change to its image database last year it (anecdotally, but clearly in my experience) lead to a large expansion in the use of IWM images on En-Wiki. Is there any way to measure the extent to which this change influences the use of Australian War Memorial images? (eg, can we take a snapshot of the usage of images with the {{AWM-image}} tag now and compare it to the figure in, say, six months time?). Please let me know if this is a question best asked at Commons. Thanks, Nick-D (talk) 09:54, 14 February 2013 (UTC)[reply]
Once it's in the tracking category on Commons, it's relatively trivial to get comprehensive usage data - well, as comprehensive as we offer. The best tool for this is glamourous. Feel free to drop me an email if you've any problems with it.
However, changes over time are pretty hard to do. Your best bet is to take a copy of the report now and save it for future reference; you can't easily go back and say "show me as of last January". Andrew Gray (talk) 21:57, 14 February 2013 (UTC)[reply]
Yes, something like that. I wanted my tables here look like one, but there are still bold line between them. I think this comes from the table global styles (wikitable, tiles). Is it possible to make the borders between them more thin, like it's one table? Thanks a lot for taking time and help! --217.118.78.35 (talk) 03:06, 15 February 2013 (UTC)[reply]
non-infoboxes, but *boxes
I understand the concept of the Infobox, and happy to see them, but i feel the need to complain about the apparently random naming, for i have found: Campaignbox, chembox, drugbox, Geobox, hockeybox, infobox, Kent_College_Infobox, Mtnbox, navbox, Pfam_box, Planetbox, Pwcompanybox, Quote_box, Reactionbox, starbox, superherobox, Superteambox, taxobox, WPMIXInfobox, and wrugbybox. Note i mention the "infobox" as distinct from "Infobox". I feel that making up new names for an Infobox is sabotage against sharing the data in the boxes, because in the search for the "Infobox" on a topic, "superherobox" is going to be missed.
I'd also like to rail against mentioning in the <comment> tag that a specific {{Infobox template was used, as a text search for the "{{Infobox" header will trip up on that mention.
Also, there is random use of the "|" divider, sometimes many on one line, some at the end of a line, some at the beginning of a line, and this makes parsing somewhat difficult if you are trying to not ignore the "\n" used inappropriately too.
I am also not fond of the nesting of {{ }} in each other, perhaps {2, {3, or {{ and {{{ can be used? I can parse the {{ blah Template:Foo Template:Blarrg bar bloof }} (i did not write Template:Blarrg in that nest, wikipedia added it there) out of the page ok, but the nesting gives me the crawly skin that something is going to go wrong with an unclosed }} somewhere, because after all, there's already unclosed "{{Infobox" within <comment></comment>.
I'm not into chasing statements like "this is the wrong place blah blah blah", so if anyone else thinks this is important enough to repost in the right place, feel free.
Many things to ponder: I can understand the frustration, but many people have promoted the "*box" names, such as "taxobox" or "navbox", as meaning specific types, or subtypes, of infoboxes. Typically, a wp:navbox is a horizontal box near the bottom of an article. As for the placement of the pipe/bar ("|"), I recommend to use bar-space "| " at the start of lines in an infobox, then indent by two spaces for nested infoboxes inside of other infoboxes. Much confusion has been caused by several Kafkaesque days of warped parser changes, over the years, when newlines were added to template parameters unless followed by an end-bar "x=45|"; however, I think people have realized to preserve end-spaces or newlines by passing a null-nowiki tag "<nowiki/>" around a parameter value (such as "x=<nowiki/> space-enclosed text <nowiki/>"). Also, URLs can be passed inside an wp:empty-name parameter (such as "{{{|http://x.com&q=what}}}") to allow an equals-sign in a web address. As for the overuse of multiple braces, a fix could be to extend the parser to treat bracketed "#[x]" as an optional syntax to get parameter {{{x}}}, while "#]" would be a literal right square-bracket symbol inside any "#[name]" parameter. Also, the parser could be extended to allow "#then" and "#else" to be "|" and "#endif}}" would be a token to ensure the matching end of a #ifeq (or such), whereas simple "}}" would be the typical pot-luck end of a parser function. Perhaps we need more essays about these issues. -Wikid77 (talk) 18:07, 15 February 2013 (UTC)[reply]
What is going on with the block log?
I specified a number of days (1001) when I blocked this IP, but the block log shows an amazingly precise 2 years, 270 days, 12 hours, 21 minutes and 36 seconds. I didn't specify an exact number of seconds, so I'm not sure where those 36 seconds have come from (1001 days is 3,603,600 seconds according to my calculator) nor why the log can't just display the duration I specified. I assume this is a software change; can somebody tell me where and/or why it was changed? HJ Mitchell | Penny for your thoughts? 21:13, 14 February 2013 (UTC)[reply]
So the answer would be that, rather than programming the software to know what day it is and to calculate what day it will be in 1001 days or whether or not there are any leap years involved, it just sees everything as a portion of a year and bases it on strict mathematics? Is that about right? Makes sense in a purely mathematical sort of way even if it is a bit weird. Then again I've never seen a block for 1001 days before either, so Harry is a b it weird too. Beeblebrox (talk) 03:18, 15 February 2013 (UTC)[reply]
Presumably caused by Gerrit:41209 (MW1.21wmf7) changing $durationIntervals in Language.php which affects the output from translateBlockExpiry() in LogPage::actionText(). User:Liangent's change refined year length from 365.25 to 364.2425 days, to reflect the long-term Gregorian calendar. Does the quirk only affect the display of existing blocks (a transitional problem), or are new blocks also being displayed inconsistently? — Richardguk (talk) 09:03, 15 February 2013 (UTC)[reply]
Google returns a multitude of hits for that class. It is inside <a>, so it is not rendered as a HTML element since <a> is not whitelisted through Sanitizer.php, but it does show the raw markup. The edit is detected by filter 345.[5] --— Gadget850 (Ed)talk00:05, 15 February 2013 (UTC)[reply]
custom code to prevent "Archived from the original" string from displaying?
I'd like to add some custom code to my common.css / common.js so that if a reference has an "active" archiveurl parameter (i.e. the deadurl parameter, if it exists, is set to "yes"), the "Archived from the original on [date]" string appended to the reference is not displayed -- I feel it adds unnecessary clutter to the reference. For example, I already have a bit of custom CSS that doesn't display the accessdate parameter: span.reference-accessdate { display: none; } Does anyone know how to do this? The best thing I can think of is some custom JS that looks for the text "the original" or "Archived from" in an element and just removes it. Thanks! Wingman4l7 (talk) 23:14, 14 February 2013 (UTC)[reply]
Removing Wikidata interwiki links and their reversal
There has been some great progress in removing interwiki links because of the new format used for Wikidata. However many many of these edits are being reverted by people not aware of the situation - is there a link to the topic (a talk) that can be added to the edit summaries to guide our editors to a page that explains whats going on? We cant have editwars over this - all we need is an explanation for all to see.Moxy (talk) 23:42, 14 February 2013 (UTC)[reply]
The above proposal failed, so there's nothing preventing people from removing the links. However please check to make sure all the links have made it over to Wikidata... most have but not all of them. --Rschen775400:30, 15 February 2013 (UTC)[reply]
I think most interlanguage links added after December didn't make it to Wikidata. It's a mess. I think it's too early to remove them. At least, not manually. I saw people in the Hungarian Wikipedia manually remove the links without even checking if every single one was moved to Wikidata (and it wasn't.) --Moscow Connection (talk) 00:43, 15 February 2013 (UTC)[reply]
Indeed, I did around 25 articles today (with two exceptions, one's I'd authored myself), and I believe 2-3 of them needed work, the rest were just fine. Fine if you're paying attention, but not ready for automated or inattentive handling. --j⚛e deckertalk00:57, 15 February 2013 (UTC)[reply]
Figured it out - you add mw.loader.load('//www.wikidata.org/w/index.php?title=User:Yair_rand/checksitelinks.js&action=raw&ctype=text/javascript'); to your .js file, edit a page, click the new button (on vector, it's in the drop-down menu next to the edit button), and hit save. It only removes links that are actually on Wikidata. --Rschen775401:21, 15 February 2013 (UTC)[reply]
I think bots are not ready yet. Maybe they can't work with Wikidata or don't have permission. For example, I created an article in the Japanese Wikipedia today, and ZéroBot linked it in all Wikipedias except the English and the Italian ones, and it didn't update Wikidata. (There's no Hungarian article, but it wouldn't add the link to the Hungarian Wikipedia too.) If you need to see an example, I'm talking about this article: ja:ワン・ポンド・フィッシュ, but don't look, it's a stub. :) There appear to be quite a lot of articles that aren't linked in the 3 above-mentioned Wikipedias because of this innovation. -Moscow Connection (talk) 01:28, 15 February 2013 (UTC)[reply]
I think people should be stopped from deleting interlanguage links manually. Really, if I were an admin, I would stop it immediately and revert. I see people removing interlanguage links, obviously without checking anything (cause they have 0 edits in Wikidata). And you surely know that there are many interwiki conflicts, so there are bound to be many links that are present only in the English Wikipedia and nowhere else. I think this is going to be a major problem. (Probably solvable by a special bot assignment to go through all articles, compare their old revisions with Wikidata, and add missing links back.) --Moscow Connection (talk) 18:30, 15 February 2013 (UTC)[reply]
It was just a figure of speech. Cause I said "if I were an admin", and the condition is not met. (I wasn't talking about you, I was worried about people who didn't see the thread and who simply believed that all interlanguage links had to be deleted immediately.) --Moscow Connection (talk) 20:01, 15 February 2013 (UTC)[reply]
(edit conflict) Okay. It was a figure of speech about reverting and prohibiting people from touching interlanguage links. :) Anyway, I'm worried. I think it's generally impossible to do it correctly without employing bots and scripts. (By the way, I haven't edited Wikidata myself, so I'm just a bystander.) --Moscow Connection (talk) 20:01, 15 February 2013 (UTC)[reply]
As is likely well known, since the Seigenthaler incident unregistered editors have been prohibited from creating new articles on Wikipedia. However, I came across an apparent method for bypassing that policy the other day, where Aristasia had been converted from a redirect - which it had been since it was moved and changed to a bio on the movement's main proponent in 2007 - into a full-blown (and highly promotional) article by an IP editor [7]. It has since been reverted back to a redirect (and protected as such), but I was wondering if this possibly needed to be looked at, as it essentially provides a way for unregistered editors to "end-around" the Seigenthaler rule. - The BushrangerOne ping only06:13, 15 February 2013 (UTC)[reply]
Technically, it's not bypassing, it's a loophole in our rules. A redirect is a page, and they aren't 'creating' a page, just adding to the redirect (and removing it in the process). Afaik, there's no technical way to bar new users from changing the redirect to an article (as of now), so it may be good to just have all redirects semi'ed until it's possible to implement a change like that? Or just leave it as is, and revert if necessary? gwickwiretalkedits06:21, 15 February 2013 (UTC)[reply]
There's a 1% joke in there somewhere... Semi-ing all redirects would be impractical (and prevent legit IP editors from fixing them as needed). I guess just keeping a sharp eye out is the answer, thanks. - The BushrangerOne ping only13:56, 15 February 2013 (UTC)[reply]
Self-generated edit conflict
The software appears to have changed in an unexpected way for me: if you examine my two most recent contributions before this request (accessible in my sig), you will see I was on a talk page. I entered a new section headline, wrote the entry, and got an edit conflict message with the usual two-part screen 1) actual text on wikipedia, 2) my attempted text.
My problem is that I was the only editor on that talk page at that time; so how is the software thinking there were two separate processes? To my thinking, that is new behavior on the part of the software. __Ancheta Wis (talk | contribs)06:20, 15 February 2013 (UTC)[reply]
Your mouse button apparently 'bounced'. Whenever I acidentally double-click the save button, I always get an edit conflict with myself. — Edokter (talk) — 10:55, 15 February 2013 (UTC)[reply]
Hi. My watchlist currently states "Below are the last 316 changes in the last 168 hours, as of 12:27, 15 February 2013". I've noticed this creeping up over the last 8hrs or so, but there's (at most) no more than 120 changes listed. Any ideas? Thanks. LugnutsDick Laurent is dead12:29, 15 February 2013 (UTC)[reply]
I'm not sure but it might be related to the Wikidata deployment here. You have a link in your watchlist to show Wikidata edits. Can you click that and check if that is it? --Lydia Pintscher (WMDE) (talk) 12:41, 15 February 2013 (UTC)[reply]
Ahh, yes, toggling that shows all the hidden Wikidata edits, such as "Aballay (film) (Q4663322); 11:36 . . Sk!dbot (talk | contribs) (A Wikidata item has been linked to this page.)". Would expect the total though to show non-hidden items, inline with hiding bot edits, for example. LugnutsDick Laurent is dead12:52, 15 February 2013 (UTC)[reply]
Can you file this on bugs.wikimedia.org please? I'm having a hard time properly formulating this for you unfortunately. (Alternatively write it here and I'll put it in bugzilla.) --Lydia Pintscher (WMDE) (talk) 13:21, 15 February 2013 (UTC)[reply]
How's this: My watchlist is currently showing the total changes including Wikidata edits, despite the toggle to show Wikidata edits being turned off. This should be the same as turning off bot edits or minor edits (IE, the total isn't included when they are set to hide). Thanks. LugnutsDick Laurent is dead13:32, 15 February 2013 (UTC)[reply]
Having remove the iw links from an article and adding the missing entry to wikidata the new entry does not show on the page, even after refreshing. Is there some delay in the propagation for new entries? Keith D (talk) 13:09, 15 February 2013 (UTC)[reply]
I created an article (Vyritsa) earlier today without iw links, then went to Wikidata and added the article to the entry there. The links were on the article not immediately, but within five minutes. Not sure what happens for completely new entries though.--Ymblanter (talk) 13:13, 15 February 2013 (UTC)[reply]
wikimedia.org.
Resolved – site was updated today --Nemo 09:46, 11 February 2013 (UTC)
Semi-ing all redirects would be impractical (and prevent legit IP editors from fixing them as needed). I guess just keeping a sharp eye out is the answer, thanks. - The Bushranger One ping only 13:56, 15 February 2013 (UTC)
