This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
There are several formats you can get the html table wrapped in (but note it is escaped in most of them), see the end of the api help. But no, you can't get the diffs in anything but the html tables that mediawiki uses. --Splarka (rant) 11:05, 8 September 2009 (UTC)
In case you're interested, this sounded pretty handy, so I put together a small script that allows you to filter the standard page history view by user. It adds a little box to the history page where you can enter a username, and it will display up to the last 500 edits that user made to the page. For monobook and Firefox/Chrome - dunno about the others, definitely not IE: importScript('User:Ale_jrb/Scripts/userhist.js'); // [[User:Ale_jrb/Scripts]]Ale_Jrbtalk13:07, 8 September 2009 (UTC)
Wikipedia's diff engine sucks; for instance, trivial changes cause the diff engine to give up and reproduce the older and newer versions verbatim. WikEd's diff engine fails in the other direction; for instance, look at this, and see how it reports a completely new section [Delimiting (grouping of digits)] as if it were a mish-mash of random words from two sections. Surely, somewhere in the world, someone has written a better diff engine. Can anyone point me in the right direction? - Dank (push to talk) 17:32, 12 September 2009 (UTC)
Diffs are tricky. Every diff engine I have seen has some fault or another. If you can find a better one that is open source I am sure it will be given consideration. Chillum17:43, 12 September 2009 (UTC)
The better diff algorithms have upper bounds of O(n4) which allow denial of service attacks since usable constants are harder to place. Also you may want to have a look at mw:Visual Diff. — Dispenser04:56, 13 September 2009 (UTC)
I just came across a vandal adding a speedy deletion template[1], and I'm wondering if there is any technical way to prevent that. It probably doesn't occur often enough to justify any nontrivial programming effort, but I thought it can't hurt to ask. — Sebastian03:08, 13 September 2009 (UTC)
How exactly do think should the software guess that it's a vandal? Any anonymous editor adding a speedy deletion template? Svick (talk) 09:11, 13 September 2009 (UTC)
What do you need that for? I don't think it would be a good idea to use popups in articles, if that's what you want to do. Svick (talk) 09:24, 13 September 2009 (UTC)
LOL you are the first person to ever ask why I want to do something on tech. Usually editors simply happily help me oblivious to the fact that they are complicit in my evil plans to take over the world. ;-)
Articles: absolutely not. this would apply only to subpages of a wikiproject.
What exactly are you intending to pop-up? :S It's not a question of it being 'enabled' - popups are a user JavaScript that makes a pop-up appear when you hover over any wiki link. If you want them, add it to your monobook or enable the gadget. Ale_Jrbtalk10:57, 13 September 2009 (UTC)
Scraped Google news result for current AFDs, but these pop ups would be on a subpages of a wikiproject, as mentioned above.
How would i go about making my own pop ups? is there documentation? I am familar with what monobook.css. thanks for your time gentlemen. Ikip (talk) 11:30, 13 September 2009 (UTC)
Yikes :P. Firstly, you can't really use the existing pop-ups as a basis here, as what you're trying to do is completely different. Secondly, you'll have to create (or get created on your behalf) a whole new script to do what you want. Finally, you will have to get anyone who wants to use it to install it on their monobook.js pages. Alternatively, you could get a bot created that does the scrapes and just posts the results - this would then need maintaining, but you wouldn't have to install anything; not sure what would be better/easier. Ale_Jrbtalk11:37, 13 September 2009 (UTC)
Yikes
Your telling me :) I could never do this myself! Way to complex.
Oh, the scraping part is no problem. I have a friend who is an expert on autohotkey thankfully working on this now. I would simply paste the generated info to the page.
The monobook.js part (having editors add pop script) is okay. I just need to find someone willing to do write the script. Where could I request help for this? Ikip (talk) 16:37, 13 September 2009 (UTC)
(reset indent) So you're going to copy and paste the scrapes of various Google pages onto a subpage somewhere, and you need a script that will display the information in a pop-up when a user does something. Hmm. It would be more efficient if the script itself did the scraping, but more effort for the script coder. The place to go for a script request is Wikipedia:WikiProject_User_scripts/Requests but the average response time is about never, so you'd be better approaching a coder directly - preferably one who would find the thing useful. Ale_Jrbtalk16:55, 13 September 2009 (UTC)
OK I found the wikED problem...I had turned off the toggle at the top right corner of the page.
I remain clueless about the user contributions and watch/unwatch links. I can still reach them by submenus...but did something change or did I "brokeded" it? :}
Any wisdom would be welcome.05:02, 14 September 2009 (UTC)
Linking categories outside Wikipedia Commons to file in Wikipedia Commons
I can't seem to use a category from Wikipedia English on a file that is in Wikipedia Common. Wikipedia Common says it is a non-existent category. But the category does exist in Wikipedia English (e.g. Category:Military operations involving the United States). I am hoping there is a way to do this.Mfstelmach (talk) 07:48, 13 September 2009 (UTC)
Note however that Commons has a separate categorization system from en.Wikipedia (and all other projects as well). Categorizing Commons content based on another project's category pages is a bad idea, just as it would be a bad idea to categorize things here based on Commons categories. That being said, I'm fairly certain that Commons has a similar (if not the same) matching category of their own already. Attempting to use the :en:Category link will only create a link, and not actually categorize the file, anyway. — V = I * R (talk to Ω) 12:40, 13 September 2009 (UTC)
Interesting ... Thanks for great technical information. However, wikipedia seems to need a significant expansion of capability in this area. Being able to only create a link between en.Wikipedia and Commons does not seem to be very useful. Why not allow categorising a file on Commons. Why is it a bad idea to increase category cross-references between Commons and other area. Maybe I am missing something. But it seems like we are trying to keep files in Commons hidden so they will never be found or used. Also, if it is so difficult to categorize and cross-reference files in Commons to content in en.Wikipedia then maybe it is better to put images and media outside of commons in en.Wikipedia. It seems like a quite a bit of work to replicate the en.Wikipedia categories in commons. But, it is impossible to replicate en.Wikipedia content in Commons. All of the fertile synergistic category cross-referencing between en.Wikpedia and Commons is lost. Seems like an incredible waste to me. I hope this is fixed soon. Best regards, Mfstelmach (talk) 21:11, 13 September 2009 (UTC)
Don't forget that English Wikipedia isn't the only one. And as its name suggests, Commons is common for all language versions of Wikipedia. Do you think it would be useful to have the same image categorized in dozens of similar categories, only in different languages? But I think that English Wikipedia category page could contain a link to corresponding Commons category. Svick (talk) 21:24, 13 September 2009 (UTC)
You are right. Thanks for your comment. This issue is not limited to en.Wikipedia. I believe it would be extremely useful to have the same image categorized in dozens of similar Wikipedia categories, only in different languages. Maybe some day this will be possible to do on Wikipedia.Mfstelmach (talk) 19:32, 20 September 2009 (UTC)
Some Wikipedia pages don't open but start a download
Sometimes (but not always!) when I click on a link to a wikipedia article the browser will not open the page but a window will open asking whether I want to open or download the page. If I click on open it will anyway start a download and not open the page. When I have Getright active, the download will be handled by getright, otherwise MS IE does the same thing.
It also happens when I search the term from the Wikipedia main page. It does not happen with all search terms, only with some, so I am not able to read these articles.
I am using IE8 and Windows XP. Can anybody tell me how to resolve the issue? I did not find it discussed in the Q&A yet.
Windows message:
Windows has the following information about this MIME type. This page will help you find software needed to open your file.
MIME Type: application/x-gzip-compressed
Description: UnKnown
Windows does not recognize this MIME type. --Toscanaman (talk) 13:10, 13 September 2009 (UTC)
I get this with FireFox occasionally. I think it occurs when my connection gets slow and the page is only partially rendered, thus FF does not recognize it as a web page and prompts to save it.---— Gadget850 (Ed)talk23:32, 13 September 2009 (UTC)
Technical Issue
I’m really unsure where to discuss this, so I’m leaving it here to be forwarded to the appropriate parties:
Look past the fact that this link is to a fictional person:
The discussion link above mentions that personal attributes such as those seen on any standard Personal Information Document (drivers licenses, wanted posters, etc) do not, in fact, appear on ANY page on individual persons (for example, [Ghandi|Mahatma GANDHI] in any orderly fashion; I submit that revamping the personal tables (where the picture usually is located) with exactly this information (height, weight, eye color, hair color, race, ethnicity, religious preference, etc) should be included, with “Unknown” or “Not Applicable” when appropriate (with Unknown as the default/placeholder entry). There will be those that say such information is irrelevant; I submit to you that it is precisely relevant. In GHANDI’S case, for example, his passive (non-violent) policies were sculpted by his experiences in early life (that violence only brought more violence in turn) and his religious upbringing. Those that feel it’s “not worth the effort” should leave their laziness elsewhere, and not waste other people’s time if they don’t wish to assist in the process. (Yes, I’ve seen that excuse before as well.)71.34.70.201 (talk) 19:29, 8 August 2009 (UTC)[2]
What have height, weight, eye colour, etc. have to do with career influences in childhood. How would you put "his passive (non-violent) policies were sculpted by his experiences in early life (that violence only brought more violence in turn)" into an infobox? Such things, if indeed relevant, belong in the text of the article, not trivially enumerated in the infobox. OrangeDog (talk • edits) 22:56, 13 September 2009 (UTC)
Mistakes made with AWB
Help? I made a really bad mistake using AWB. Because of a mistake in the creation of a regular expression I changed and unknown number of level three headers to become level two headers. There might be over a thousand pages involved. Is there a way to roll back that may edits. Waiting is only going to make things worse. I'll watch his page. --droll[chat]00:37, 11 May 2009 (UTC)
Thanks to all who responded I think I can handle it. I've fixed about 700 already. Only about 1 in 12 of the articles have a problem. I want to get it done ASAP. I should have it done by late tonight. --droll[chat]02:05, 11 May 2009 (UTC)
I'm working on an article and the subject of the article falls under 5 stub types. As I don't really want 5 stubs to show up on the article (the sub list would be longer than the article info), is there a way to hide the stub comment but still have the stub be active (not using a hidden comment)? I haven't been able to find any info in a short search. Thanks. OlYellerTalktome14:12, 19 May 2009 (UTC)
Maybe just adding the category added by the stub would be the best way as the rest of the stub template it just for show anyway. OlYellerTalktome14:16, 19 May 2009 (UTC)
The {{asbox}} template is fine for this, the main intention is not to have a lot of stubs in one page, nor keep icons, but have the correct categorization of the respective stub category. --Woglinde 02 (talk) 19:46, 28 May 2009 (UTC)
I'm trying to determine how many hits the page 16"/45 caliber Mark 6 gun got while up as a DYK, but I got a problem: every time I use this tool I get the results for the page 16. Can some one tell me how to fix this, or work around it, so I can see the stats? TomStar81 (Talk) 06:49, 23 August 2009 (UTC)
I think these stats are accurate. The tool works for the display of stats, but formats the link incorrectly if you then try to change the date displayed or click through to the article. At any rate, the stats for the article 16 are very different.-gadfium09:39, 23 August 2009 (UTC)
coloring 'legend' with css on 'my preferences' page
In my css I have the following:
fieldset {
background: #000000 !important;
color: #FFFFFF !important;
border: 1px solid #FFFFFF !important;
}
legend {
background: #000000 !important;
color: #FFFFFF !important;
border: 1px solid #FFFFFF !important;
}
This works for everything on the 'my preferences' page except the row of buttons. the source code looks like this: <!-- start content -->
<form action="http://en.wikipedia.org/wiki/Special:Preferences" method="post">
<div id="preferences">
<fieldset>
<legend>User profile</legend>
<fieldset>
<legend>Basic information</legend>
I deleted the portlets in the sidebar using the following css:
#p-logo,
#p-navigation,
#p-interaction,
#p-search,
#p-tb,
#p-coll-create_a_book,
#p-lang {
display: none;
}
Something that lists transclusions of all pages from a given category
I don't think such a function or template exists (most of this is currently done via bots), but we could have a template that would generate a list of transclusions of all pages in a category. This would be infinitely helpful with pages that deal with categories and statuses, like with WP:SPI for instance (which is heavily dependent on a bot which is currently down). Has anyone thought of this, or does such a thing exists in the software? MuZemike21:37, 13 September 2009 (UTC)
Postage Stamps Etc.: Software Patch to Track Sizing
I propose a software enhancement. Because some images must be size-constrained by law, many of those images are uploaded by contributors who do not realize the limits exist, and Wikimedia may be held legally liable for carrying the images in illegal sizes, I suggest two processes:
--- When someone tries to upload an image, s/he should be asked if it's one of the image types subject to limits. The single question can appear on the user interface for uploading. Answering in the negative can leave all other questions invisible, and the uploading can proceed unrestricted. If the answer is affirmative, the contributor would be asked "What is the actual or life size of the original from which the image is taken? If unknown, state a range for either or both dimensions. If the image is part of the original, state the size of the whole original, e.g., one postage stamp." Whether sizes legally depend on the design or the paper or stock for one stamp has to be determined. Allow selecting length units (centimeters, inches, etc.). Then allow a preference for enlargement or reduction for an image for which life size reproduction is forbidden. The Wiki software would then enforce the constraints. Wiki editors should be allowed to easily override the preference for enlargement or reduction by going in the other direction, as well as to update the information supplied by the original contributor, with reversion possible, as with article text. Where the life size is stated as a range rather than exactly for either dimension, life-size reproduction would be barred even if otherwise allowed, enlargement would be beyond the largest dimensions stated as life size, and reduction would be below the smallest dimensions stated as life size, all to ensure legal compliance.
--- A bot using similar code can review existing images. Those that might be of a type subject to the limits should be flagged for review. Editors could then mark an image as not being of a type subject to size constraints or enter the relevant size data and resize preference.
The single question: "Is this a postage stamp (including meter stamp), revenue stamp, U.S. bird hunting stamp (Migratory Bird Hunting Stamp Act), other U.S. or foreign government obligation or security, or bank or corpoation obligation or security? Yes. No. Uncertain. ('Uncertain' will be treated like 'Yes.')" Have a comment field, in case an explanation is offered (e.g., if it looks like a stamp but isn't), since the image can easily be separated from a Talk entry. For the first question's answer, only if the answer is Yes or Uncertain would other questions appear.
The questions that follow if the initial question is answered in the affirmative or ambiguously would be about whether the original is postally canceled and whether the image is in color or black and white and whether the image is a full or partial image.
An argument is that Wikipedia does not display in any size, that being up to the user's monitor. However, Wikipedia does rely on common expectations respecting normal size ranges for text, and a similar theory would applies to images, thus Wikimedia may be legally liable for mis-sized images if it doesn't address these expectations, and the prudent course in case of doubt would be to publish no images that have size restrictions, e.g., no postage stamps at all. It may be that life-sizing should be entirely barred in cases where near life-size reproduction is already barred, just to be safe.
If a user adjusts their computer or browser so that reproduction is in an illegal size, and is not advised or directed to do so by Wikimedia, I don't believe Wikimedia has any liability for the user's act. Therefore, the Wiki software does not have to handle that case.
The notice received when editing a new page, such as found when clicking a red link, no longer mentions or links to searching for the term. I am not imtimately familiar with the mediawiki namespace, but it would be appreciated if an admin more familiar with them could correct this oversight introduced by recent changes. Vassyana (talk) 07:25, 14 September 2009 (UTC)
I've thought of a new Beta feature for Wikimedia. We all know those little windows over some webpages that show Google Earth maps. I know that information is not admissible by Wikimedia, but there is OpenStreetMap, a Wiki community that designs free maps from all over the world. Is it possible to design a new feature that shows an interactive map from [3]. --Schumi4ever (talk) 16:23, 14 September 2009 (UTC)
The techies are way, way ahead of you on that one :) They expect to see returns in the next couple of months; for now you can click on the globe of a set of co-ordinates to get a separate (I think) but rough map. - Jarry1250[ In the UK? Sign the petition! ]16:48, 14 September 2009 (UTC)
So that feature is in developement. That's good, pretty good. But the maps we have now are blank with a red dot on the place you want. I mean an interactive map, in which you can zoom in and out, see streets, move to the North, South, East and West and so on... --Schumi4ever (talk) 17:12, 14 September 2009 (UTC)
You should click on the globe next to a set of coordinates once. It's called WikiMiniAtlas. And the openstreetmap work will also include this. —TheDJ (talk • contribs) 18:25, 14 September 2009 (UTC)
Changed layout?
Aside from the "vanishing" articles, did the software change the layout somehow?
My watchlist looks completely different (and not in a good way, IMO), and my userpage doesn't fit my screen any more (I did have it lined up in a way that I liked). — V = I * R (talk to Ω) 00:28, 17 September 2009 (UTC)
Yea, I just saw your post about that above. Does "hiding" it get rid of all of the spacing between entries in Vector, though? Anyway, that's only part of the problem, since whatever changed adjusted the size of a ton on other items (headings were all changed, I think). I really don't see this as something that I'll simply adjust to, the layout of multiple things seems to have been changed for the worse. — V = I * R (talk to Ω) 00:45, 17 September 2009 (UTC)
Well, the changes affect Monobook (and all of the others, I assume) as well. There appears to have been a change to common.css, I'm guessing. Is there a changelog somewhere, or a central discussion about the update at all (aside from this, of course)? — V = I * R (talk to Ω) 00:50, 17 September 2009 (UTC)
One of the big changes I see is a reduced fontsize by one point of the sidebar and personal links. Makes it a lot harder to read for me in Safari. —TheDJ (talk • contribs) 01:20, 17 September 2009 (UTC)
I think that is the key change, but it's not limited to Vector, it actually appears to be a global change. I don't know what actually changed though, because there doesn't appear to be any changelog that I can locate(?!), so this is all pure speculation. The heading have changed for sure, the "personal links" (the area with your username, watchlist, prefs, etc... links, normally at the top of the page in Monobook and Vector) are definitely smaller, the sidebar appears... different, and I think that the default size of the frame around images is larger now. Spacing around text seems to have changed as well, although that behavior is significantly different depending on the skin you use. It's really tough to evaluate what is actually a problem without knowing what actually changed though. Anyway, if I'm just going to get snipped at about saying anything, I'll leave it up to the rest of you. Time for me to watch a movie. — V = I * R (talk to Ω) 01:38, 17 September 2009 (UTC)
This is now fixed. Trevor went through a few iterations of how to properly set font sizes (eg without interfering with browser font settings or zooming), and what we last ended up with turned out to round differently between Firefox and Safari. It's now been nudged up a little (from 0.7em to 0.75em against the main font size) and is now more consistent. --brion (talk) 23:36, 17 September 2009 (UTC)
Hey, great! thanks Brion (and thank Trevor for me as well, please). I appreciate that you guys were doing this work, I don't want that to get lost in this... the other issue that (was here, I'm about to create another section for it) isn't really directly related to the underlying issue that you're talking about here. — V = I * R (talk to Ω) 00:36, 18 September 2009 (UTC)
The file to check is RELEASE-NOTES. The difficulty is that that file is based on Mediawiki version, not on when the code was last updated on the live site. So the following diff should have most of the changes, but may not have all of them: [4] — Carl (CBM · talk) 02:11, 17 September 2009 (UTC)
Wow, so there's no one creating changelogs at all? That's just... "ghetto". Amongst all of the writers here, including people who are ready and willing to volunteer time, no one has stepped up and created a changelog system yet? The little section in Signpost seems to at least be a start. Anyway, I'm trying hard not to sound like UncleDouggie here, but "I don't like this change!" is where I seem to be ending up myself almost by default. This release just doesn't appear to be well planned out, from this end of things. :( — V = I * R (talk to Ω) 14:31, 17 September 2009 (UTC)
That file (RELEASE-NOTES) is the changelog for Mediawiki. The problem is, we do not update the live site just when a new mediawiki version is developed. Rather, the changes to the code are tested on the live site long before the next version of Mediawiki is released for others to use. There is an svn revision control branch dedicated to the live site, so it is possible to see exactly what code it running on the live site. And the revision control logs for that branch give a summary of every change to it. So I was trying to give a way for someone who is not familiar with svn to get a list of changes. The developers have no trouble using the revision control system to see exactly how each file has been edited over time. — Carl (CBM · talk) 22:56, 17 September 2009 (UTC)
No, no, I understand what you're saying, I'm not... well, I am criticizing I guess, but I'm trying to be constructive about it. Part of this is just surprise on my part, as I've never really thought to even look for a en.wikipedia specific changelog (which is a good thing, really!). I knew right away what you were pointing me towards, since I (unfortunately) have some experience with svn/vcs systems. For the developers (including you?) that's perfectly adequate, and it should really be all that concerns them. revision control logs do not make for an adequate public face for software development progress however, even for a technically inclined audience. Wikipedia has a partially knowledgeable audience, but there is a significant number of editors and readers who have never been exposed to programming let along version control. Even amongst those of us who do have experience with programming and version control, I'm sure that most of us have had the experience of looking at an unfamiliar version control log...
Anyway, I'm volunteering for the job I guess. I'll need to begin digging into the live and development svn logs to familiarize myself with it, but eventually I'll start... Wikipedia:Software updates? I haven't actually thought of a name. I'll have to look and talk to whomever it is who regularly writes the tech column in the Signpost as well, of course.
{{resolved}}
I can't think of a better place to post this, but with the new software, user javascript/monobook.js pages cannot be deleted. For instance, a user has requested deletion of their monobook for technical problem reasons, and I'm unable to grant it. I wasn't aware of this type of change until now. If this will be permanent, perhaps it ought to be noted somewhere? Like at WP:CSD#U1, and elsewhere?
Alternatively, I don't see an advantage in blocking the deletion ability of personal .js pages. I understand the implementation of personal editing and disallowance of outsiders, but if a user javascript page is explicitly being requested for deletion, there shouldn't be a barrier in that. I could be missing something, but I don't exactly see the logic behind it. JamieS9300:48, 17 September 2009 (UTC)
The ability for sysops to edit css and js pages, as well as to delete them, was removed during the most recent coding update. At the very latest, we should get it back within 24 hours. For now, I think some of the m:Stewards, or at least the ones who have adminship on enwiki, (at the very least User:Shanel), are willing to help for urgent matters. NW(Talk)01:18, 17 September 2009 (UTC)
The code says sysops have the editusercss and edituserjs rights, so this should work fine as far as I know. There may be some bug related to the way those rights were split out from editusercssjs, don't know. --brion (talk) 01:29, 17 September 2009 (UTC)
{{resolved}}
After the updates it seems that if a page has only hidden categories on them and no non-hidden categories, then no categories will appear on the page regardless of user setting. Is this affecting anyone else or is it just me? FeinohaTalk, My master07:21, 17 September 2009 (UTC)
No idea where to post software failures in the middle of an update, but i am finding internet explorer 8 (my normal browser) goes away and eventually produces out of memory errors if I try to edit a page. This may be as it is trying to create a preview. Firefox works. (as witnes my being able to post this). My computer just gave me a friendly note saying it was increasing its virtual memory, which I interpret as it having used up the 4G or so available to it. Sandpiper (talk) 08:25, 17 September 2009 (UTC)
I've disabled the new edit toolbar for now until we get it resolved, which hopefully should be within a day; all our folks who can test and fix it on windows are out at the moment. :( --brion (talk) 21:41, 17 September 2009 (UTC)
Earlier this eveneing the problem was still there, but now explorer is doing edits (ie this one). I was using firefox this evening and that worked. I started out not using 'beta', though I gave that a try in case it helped, and it did not. The bugzilla description sounds about right. Sandpiper (talk) 01:12, 18 September 2009 (UTC)
Roan has committed a fix, and I've deployed it. Reports indicate that this is now resolved, and the enhanced editing toolbar has been turned back on. — Werdna • talk14:21, 18 September 2009 (UTC)
The "You may create the page "Foo", but consider checking the search results below to see whether it is already covered." text has been moved to below the search results. This is very annoying and makes creating pages harder. Is it an attempt to force people to read the search results first? If so, I think it is misguided. --Apoc2400 (talk) 10:59, 17 September 2009 (UTC)
I agree, the change seems to have been made in r55592. The article creation link is on of the important features of Special:Search and shouldn't be at the bottom. --rainman (talk) 12:07, 17 September 2009 (UTC)
Wikiblame currently appears to be broken. It returns "0 versions found" for any search (including pages I know have hundreds of versions). Is this connected with the server software update. SpinningSpark19:14, 17 September 2009 (UTC)
Guess it works for me; did a search for 'stuff' on history of 'Foo' and it came back with "50 versions found". --brion (talk) 00:11, 18 September 2009 (UTC)
That is actually a very confusing response, let me reword it so it is understandable. It isn't the tt tags themselves, it is what is in it, the tr tag. I'll fix that for you. Prodegotalk22:26, 17 September 2009 (UTC)
{{resolved}}
Under vector as well as monobook the option to turn on the new enhanced toolbar is gone from the preferences and it is not turned on when following the beta test link. Any ideas? Cacycle (talk) 00:22, 18 September 2009 (UTC)
{{resolved}}
Is there a way to hard-code a semicolon character within a template, to avoid having the template interpret it as wiki markup? I am trying to have some semicolons in User:Rjanag/zh, but whenever I transclude the template it interprets them as markup (and instead of outputting a semicolon, it makes a subsection header like semicolons do in wikitext). I know there are ways of hard-coding other characters, such as {{!(}} for [ and —/— for — . Is there anything like that I can use for semicolons? rʨanaɢtalk/contribs06:19, 18 September 2009 (UTC)
Is there any way to skip Toolserver's geohack page when a click on a geo-coordinate? I'd like a script that would take me to my favorite map site instead of taking me to toolserver.org's GeoHack page where I have to scroll down each time to click on the same link I want. --Gpaper (talk) 12:05, 11 September 2009 (UTC)
Since you don't say /which/ URL, we can't really guess, since they all seem to be handled differently. Regardless, it would require some clever parsing to change the formatted coordinates to the one your mapsite uses (which, without you telling is, would be foolish to try first). So instead here is an example script that will append an anchor to the URLs in these links, basically jumping you down the page automatically. You could modify this script to point to another section easily, or even modify it to point to your favorite map site (with some more work).
Thanks for the script. I'm a big user of Google's Satellite map, and that's what I always go to, but I tried to phrase the question so others would be able to use it for their own service. I inserted the script from above into my custom .js page, but it doesn't seem to make any modifications at all. Do I need to put it into a wrapper to make the browser run the script after the page loads? --Gpaper (talk) 00:50, 15 September 2009 (UTC)
The templates {{IMSLP}} and {{IMSLP2}} seem to be broken for names which contain diacritics; e.g. the code {{IMSLP|cname=Bartók|id=Bartók, Béla}} gives "Free scores by Bartók at the International Music Score Library Project (IMSLP)" which doesn't work. I believe the cuplrit is the shortcut scores: which is defined, somewhat incorrectly, at meta:Interwiki map — the target definition is currently http://www.imslp.org/wiki/ where it really should be http://imslp.org/wiki/ (without the wwww.).
Temporary workaround implemented using external links. But the maintainers of the website should be informed that their redirect system is broken. Oh, and they also don't recognize the + as a space character in urls. See another broken link —TheDJ (talk • contribs) 14:17, 14 September 2009 (UTC)
From:
Gary Knott
To:
info-en-o@wikimedia.org
Subject:
PDF files (and printing)
Created:
09/07/2009 23:56:19
Dear W., I have two suggestions that I think would improve
wikipedia.
(1) Provide a PRINT option on the text (dropping the side-bars, and
all the extraneous material outside article content. [Lots of sites
do this, and
it would help a lot of people a lot.
(2) Find a way to accept and present pdf articles. This is
particularly important
for mathematical text. This may be hard, but it would be worth it.
[I have several articles done with TeX and prepared as .pdf files that I would
submit if you could handle them.] - and pdf files based on TeX are far more
readable that the current wikipedia format.
Shalom, gary knott
He also is aware that I'm just posting here, nothing in particular can be done by email. It's just for dicussion and with this I move along. Keegan (talk) 21:33, 14 September 2009 (UTC)
Ad (1) Wikipedia has special CSS stylesheets for printing that work automatically, so that the printed version doesn't contain navigation sidebar.
When you click a redlink, there should be a link above the edit window to search for the title in case there's a place to redirect. Why is this gone? --NE221:41, 14 September 2009 (UTC)
I've put the search link back in its own list-item. Hopefully that will continue the emphasis on WP:YFA but still allow easy redirect searches. - Jredmond (talk) 14:00, 15 September 2009 (UTC)
I saw this post earlier this morning, and then just now I had my first real experience with the changed message. I'm trying hard not to say that I don't like it simply because it's different, but... To anyone with more then a couple of edits, I just can't imagine anything in that message aside from the search link as being important. If I could design that message for myself then the only thing that is would include would likely be the search link.
The thing is, I don't disagree with the idea behind the change. The problem is that this is one of those areas where helping the newer editors is negatively impacting those of us who are more regular contributors here. I don't know what the solution to the issue here is, but something should be done to balance the competing interests involved in this change. — V = I * R (talk to Ω) 20:05, 15 September 2009 (UTC)
I agree that, for experienced users, the search is probably the only useful part of the message. (Deletion logs and protection notices are kept in different MediaWiki: system messages, so they aren't really relevant here.) Unfortunately, there isn't an easy way to have the full YFA+search+cite+subpage message for newbies but search-only for experienced users, so (for now at least) we're stuck with a one-size-fits-all message.
Could anyone explain what F denotes in the new category listings? I can see that C denotes subcategory, P denotes page (such as an article page). What is F? I just saw this type of listing, in for example the Nature category in Category:Fundamental. --Ancheta Wis (talk) 16:07, 15 September 2009 (UTC)
Would it be possible for me to convert the sidebar lists (p-tb, p-navigation, etc...) to p-caction drop down menus? Has it already been done somewhere? How difficult would it be? Could it be done with css or would it require javascript?
You mean like the p-caction of the Vector skin ? That should be easy to do, i specifically asked Trevor to fix the CSS so that such would be possible (I was thinking of a Twinkle menu at that time). I'm not aware of any scripts that do this atm however. —TheDJ (talk • contribs) 15:11, 16 September 2009 (UTC)
There is a script that does exactly that. User:Gerbrant/hidePane.js I got the colors to work with my css but what I would really like to do is make the buttons stay in a fixed position at the top of the screen while I scroll. I tried everthing I could think of but nothing did anything except make the whole page not work. Lemmiwinks2 (talk) 18:12, 16 September 2009 (UTC)
Before I got a new hard drive, I had a Greasemonkey script installed that fixed the position of the sidebar when I scrolled. I had to select my favorite languages to show, but the rest were just cut off. It worked very well. I forget exactly what it was called, but if you use Firefox, try searching for Wikipedia scripts on the Greasemonkey website. hmwith☮20:27, 16 September 2009 (UTC)
Nested footnotes aren't workning when list-defined
Didn't there use to be a link from the search page (the one you get to by clicking Search) to some kind of help page (presumably WP:Searching)? Anyway, shouldn't there be? And is that page up to date with all the current options? Is there more current documentation at the MediaWiki site or somewhere?--Kotniski (talk) 17:01, 15 September 2009 (UTC)
Thanks for the link, but that's not really what I was asking about. I don't mean what you see when you click a redlink; I mean what you see when you click the "Search" button (with or without anything in the search field). Basically - where is our search functionality documented, and how are readers supposed to find it when searching?--Kotniski (talk) 06:51, 16 September 2009 (UTC)
All seems very counterintuitive. How do we get a direct link to help-on-searching onto the search results page? (Presumably there's a MediaWiki: page we can edit/create?)--Kotniski (talk) 08:56, 17 September 2009 (UTC)
Time-limited watchlist
My watchlist has been growing over years. I periodically clean it up, deleting the issues I lost interest, however I cannot arrest it growth no matter how I try. (I am sure many old-timers deal with the issue; your advice is welcome.)
Quite often I add an item to my watchlist after doing some important or significant changes in a tangential articles, to see how other editors react. I want to watch it only for 2-3 weeks; "until the dust settles".
Is it possible to add an option that an item is aded to my watchlist only for a certain time, similarly to blocks? The implementation does not need to be very exact: I don't care that the item is removed exactly after 6d 0h 0m 0s. THe cleanup may be done, e.g., at the login, or once a week, whatever.
Do you want this only for specific articles? I can think of some clever ways to do this for your entire watchlist (save your watchlist, then in three weeks use a list comparer to compare the saved list to your current watchlist, and then replace it with only the new items).
The way I keep my watchlist culled is by just unwatching stuff on a regular basis =) You could use something like importScript('User:Alex Smotrov/wlunwatch.js'); to add an instant unwatch button to your watchlist. –xenotalk23:47, 16 September 2009 (UTC)
This could be done by creating a list of those pages on a subpage of your user page and creating a bot that would check that page and delete old entries. The pages on that list wouldn't show up in your watchlist, but on "Related changes" of that page. Entries on that list could look like this: {{temp watch|Some page|6d}}.
Another option is that when you add a page to that list, bot would add it to your watchlist and remove it after the specified time. The problem with this alternative is that the bot would need to know your password to access and edit your watchlist. Svick (talk) 00:53, 17 September 2009 (UTC)
Apparently ditto with something over at Sarah Palin. I imagine it has something to do with: "Software updates are being applied to Wikimedia sites; there may be some brief interruption as the servers update." user:J aka justen (talk) 00:00, 17 September 2009 (UTC)
Just so you guys know, it is only occurring for me in Vector skin in both Firefox and IE. If I'm signed out, they render fine. About 1/20 articles are doing this for me, for ex. randoms Grzeszów, John Warner (half missing), Storm Shadow.
As User:Peace and Passion first noted at wp:an, logging out appears to have an impact, perhaps due to theme. I'm using Vector in Safari. When I log out, it's still fubar even in MonoBook, in Safari, perhaps due to some client-side cache. But when I browse from Firefox, which has no cache of Wikipedia, the articles specifically mentioned above are showing up fine. user:J aka justen (talk) 00:21, 17 September 2009 (UTC)
Twinkle/Friendly seem to also be broken by the update (at least for me in Firefox). Manual page tagging and warning is much harder than I remember. 700:24, 17 September 2009 (UTC)
Parser bug now fixed. It was a bug in an attempt to clean up extra whitespace around category links -- sometimes it would instead delete the entire article text. Woops! :) --brion (talk) 00:54, 17 September 2009 (UTC)
Hidden categories & printing
When printing an article should the hidden categories be output? It looks like they are always output regardless of user preference for their display. Keith D (talk) 00:23, 14 September 2009 (UTC)
Wikipedia is actually running revision "52088 plus numerous live hacks and single-revision merges" (as far as I can tell, anyway); since about 2 months ago the currently-running code has been published in a "wmf-deployment" branch, which has the side effect of rendering useless the comparison of Special:Version with the trunk revision of any fix to determine if it is live. Anomie⚔12:09, 14 September 2009 (UTC)
Is anyone else have trouble with Twinkle for the past hour or so? Some of the features are still working, but "csd" seems to just do nothing when clicked. I am assuming there is some sort of javascript issue, but I cleared all my caches, and even rebooted and can't seem to figure it out. Anyone? ConcernedVancouverite (talk) 20:01, 15 September 2009 (UTC)
I know I created a Wikipedia account, probably over a year ago, but I can no longer remember the user name.
I just had to create a new account in order to log in. Is there any way I can recover my old account's user name given the email address I specified when I created it?
If I do manage to retrieve the old username, can I delete the new one I created today?
Can you remember any articles you edited and approximately when? Go to the article, click on "history" at the top and navigate to the time. That might give you a reminder. The new user name can't be deleted, but you can abandon it. We can't reverse search on the email address, if you find the account, the email address means you can get a password reminder. ↪REDVERSThe internet is for porn10:30, 17 September 2009 (UTC)
This was duped to the older bugzilla:16129 which implies this is an older problem (though it may be 'spreading' as more UI messages are made flexible, so affecting more includable special pages). --brion (talk) 19:03, 17 September 2009 (UTC)
Pages are now missing the HTML type attribute. I ran Black Hawk War and some other pages through the W3C Validator about two weeks ago (you can find some subtle reference errors that way). At that time, it validated with no errors. Now, every page has errors about missing type attributes— Black Hawk War alone has 22 errors.
Yes, now there are typically six instances of '<script>' that should be '<script type="text/javascript">'. See, for example, the W3C report for Beauty. I've never had much luck with Bugzilla; perhaps someone with more skill can file a bug report? Eubulides (talk) 02:47, 21 September 2009 (UTC)
This was already fixed in r56601 but not yet applied on the live site. Basically, MediaWiki is transitioning from XHTML 1.0 to HTML 5 (which doesn't require the "type" attribute on script elements if its javascript). Right now we're trying to support both, so there might be an occasional validation problem such as this. (But if this does cause failure in some browsers, the fix should be synced quickly) Mr.Z-man05:16, 21 September 2009 (UTC)
To clarify, this was a bug: the type attribute is not required in HTML5 and will be dropped there (at least sometimes), but it should still be output in XHTML 1.0 Transitional (which Wikipedia is still using for now). This won't cause any actual problems, because browsers all assume that script is JavaScript and style is Cascading Style Sheets if no type is specified. So I'm not going to ask anyone to bother syncing the fix. —Simetrical (talk • contribs) 18:02, 21 September 2009 (UTC)
Fix has been deployed while I was in there, but as noted it only makes a difference to the validator. Keeping noise down to make it easier to find any real errors is helpful though! --brion (talk) 18:35, 21 September 2009 (UTC)
Ok, I get that it's useful to see "Legend: N - new page, m - minor edit, b - bot edit." for new users, but it's irritating me already. Is there a way to hide it? J Milburn (talk) 10:37, 17 September 2009 (UTC)
Why do you think they were added? Could it perhaps be in response to the hundreds of "what do those wierd cryptic letters on my watchlist mean?" questions we've had at the help desk?? They're not intended for experienced users; fortunately, those users are the ones who are able to easily hide them if they find them annoying. (also)Happy‑melon14:13, 18 September 2009 (UTC)
Their obviously not intended for experienced users, which is exactly the problem. Turn them on for IP's and newer users (less then X edits), but turn them off otherwise. That we must mess around with our custom CSS/JS for this is... rude. — V = I * R (talk to Ω) 15:12, 18 September 2009 (UTC)
Extra category divs on every page
Every page now has a #catlinks div, regardless of whether or not it is a content page. On action=edit, there are even two of them. Anyone know what's going on with this? — RockMFR03:14, 17 September 2009 (UTC)
The div is now always included - but hidden if it's empty - to make it easier for editing gadgets that are being worked on to dynamically add categories to the list while you work. (Otherwise the client-side code won't know where the category list belongs.) As far as I know this shouldn't cause any problems as such; what's the problem you're actually seeing? --brion (talk) 00:00, 18 September 2009 (UTC)
Well for one, there shouldn't be two elements with the same id. What's the reason for having two of them on the edit page? — RockMFR01:56, 18 September 2009 (UTC)
Aren't they? If it's available to all users, including logged out, then it should be available to blocked users too. I don't think Wikipedia is supposed to operate on some kind of "need to know" basis. --Apoc2400 (talk) 11:58, 18 September 2009 (UTC)
It's an attribute of the generic method used to check permissions (originally, the abuse log was intended for privileged users only, and so a blocked user shouldn't be able to see it). Could be fixed up if the community is so inclined... Bugzilla is that way. — Werdna • talk14:10, 18 September 2009 (UTC)
program feature idea
I'm posting this here to find out if this is plausible...
Highlight a term and then press enter to go to the wiktionary entry on that term.
1. Would this be easy for developers to add to the Wikimedia software?
2. What is the current proposal process for adding new features to the software?
I was sort of thinking about this myself, a while back. Why not simply interwiki-link to important words within body text? If it's an item that is directly relevant/related to the article topic, then a Wikipedia link would be more appropriate. If it's a more unusual word though, I wouldn't have an issue with a Wiktionary link being in the body text.
Putting the above aside and addressing the specific idea here though, the New York Times does this on their web site, and I see no reason why we couldn't either. I just don't see a compelling reason not to create interwiki-links, using the existing tools, is all. — V = I * R (talk to Ω) 23:17, 15 September 2009 (UTC)
Since this feature is useful on all websites, not just Wikipedia, it's better provided by a browser addon (of which several are already available) then by a Mediawiki feature. Algebraist15:47, 16 September 2009 (UTC)
I'd guess the best way to implement this would be as a Javascript gadget, something similar to Navigation popups. Then it would be available as an option to the registered users and wouldn't be forced upon everyone. Quibik (talk) 00:28, 17 September 2009 (UTC)
That's cool, then an optional gadget will be available to those who like this idea. It won't affect those have other solutions or those simply don't want this feature. --Quest for Truth (talk) 15:37, 19 September 2009 (UTC)
I'm having an epiphany. I'm betting you have selected british english as your en.wp language option. That hides many of the local system message customizations. —TheDJ (talk • contribs) 23:00, 17 September 2009 (UTC)
You're quite right! I've changed my settings to general English and the links are there. What are the chances of making those tools available regardless of the language setting? ~~ Dr Dec (Talk) ~~ 16:50, 19 September 2009 (UTC)
That's a pretty unhelpful response; I assume that if the person knew how to write JavaScript code, then they'd already be aware that it could be used to do this. I had written some code before to do this, but it adds a tab at the top of every page rather than in the toolbox; it does appear only on user pages, though, regardless if it's a subpage or not. Simply copy the following code to Special:MyPage/monobook.js:
HELP: How to change the size of font used in user page and arrange two images vertically in user infobox
< div style="font-family:Calibri,sans-serif;">
< /div>
I have put these two codes on top and bottom of my userpage to automatically change the font of the whole userpage to Calibri but since it is too small and hard to read, I tried to make it bigger by adding this part to the code,
font-size: 12pt
but unfortunately didn't work. Can someone help me how to fix this?
Also I tried to place two images vertically in my user infobox (two images don't have the same size but I tried to equalize them) but I didn't know how. Can someone help me with this too? Thanks. JuventusGamer (talk) 14:57, 19 September 2009 (UTC)
Note: my user infobox (shown below) has the same basic code as others.
{{resolved}}
I have recently reinstalled Firefox 3.5.3 on my computer. Now the links within Wikipedia are changing color after I visit the linked page. I am using the "Classic" skin and in Firefox>Tools>Options>Content>Colors, I have checked "allow pages to choose their own color". Is there any setting within Wikipedia were are can turn this feature off? I would like websites in general to choose their own color, but would not like to have the links change color within Wikipedia. Is that feasable? Thanks a lot in advance! olivier (talk) 06:17, 23 September 2009 (UTC)
It doesn't look like the classic skin sets a color for a:link, just for a:visited. But you can simply set one for both to make them the same. Add something like a:link, a:visited {color: #0000EC;} to User:Olivier/standard.css. --Splarka (rant) 08:08, 23 September 2009 (UTC)
Apparently the MW parser considers the <font> tag special, because when a <font> tag directly surrounds an <a> tag they will be turned inside-out so that it changes the color of the link-text. However this is not done for any other presentational tags, only the <font> tag (deprecated since HTML 4.01).
However since the link itself, the <a> element, is still blue by default, most browsers will still give the orange link text a blue underline (which looks really ugly).
Obviously the clean way to change the link color would be to add attributes directly to <a> tag, something like:
It is Tidy. Without tidy you get the <font> on the outside. You can see a similar affect with <span><pre></pre></span> -> <pre><span></span></pre>. --Splarka (rant) 07:18, 20 September 2009 (UTC)
It is because the <span> tag outside the <a> tag is not sucked into it the way the <font> tag was. Why these should be treated differently is beyond me. Notice on line 2 the color information is completely gone. I guess the parser does sometimes remove deprecated attributes but not deprecated tags. — CharlotteWebb13:45, 19 September 2009 (UTC)
But if it did exist, it would be deprecated in favor of style="color:orange;". That's beside the point however as this doesn't work either for changing the color of a link, unless we put it inside the link (which needlessly complicates the bracket notation and still leaves a blue underline, see line six). — CharlotteWebb14:03, 19 September 2009 (UTC)
Sample 2 doesn't work for the reason pointed out above: color is not a valid attribute of <span>. Sample 4 doesn't work because the style of <a> overrides that of the enclosing <span>. This is expected HTML behavior, and it's why the parser handles <font> as a special case to generate what the user probably intended: overriding the color style of the <a> tag. This was obviously added to the parser ages ago, before <span> became the accepted way of changing color; and a good case could be made for adding special handling for the <span> enclosing <a> tags. Elphion (talk) 14:44, 19 September 2009 (UTC)
Could a "good case" be made for adding some direct way to change the attributes of the <a> tag rather than needing to add an extra layer (the hierarchical order of which the parser/tidy functions may or may not quietly invert)? — CharlotteWebb15:11, 19 September 2009 (UTC)
Really, a better solution would be to not use custom styling on links at all. Unfortunately navbox has those damn style parameters... — RockMFR14:51, 19 September 2009 (UTC)
MiszaBot II is down. No bot archiving at ANI for two days
I suspect the pywikipedia core that powers my bots was somehow affected. But I don't have the time to debug it. Something about XML encoding when trying to save a page (the original, not the archive):
Traceback (most recent call last):
File "/home/misza13/pywikipedia/archivebot.py", line 606, in main
Archiver.run()
File "/home/misza13/pywikipedia/archivebot.py", line 519, in run
self.archives[a].update(comment)
File "/home/misza13/pywikipedia/archivebot.py", line 391, in update
self.Page.put(newtext, minorEdit=True, comment=summary)
File "/home/misza13/pywikipedia/wikipedia.py", line 1434, in put
newPage, self.site().getToken(sysop = sysop), sysop = sysop, botflag=botflag, maxTries=maxTries)
File "/home/misza13/pywikipedia/wikipedia.py", line 1466, in _putPage
newPage, token, newToken, sysop, captcha, botflag, maxTries)
File "/home/misza13/pywikipedia/wikipedia.py", line 1813, in _putPageOld
if self.site().has_mediawiki_message("spamprotectiontitle")\
File "/home/misza13/pywikipedia/wikipedia.py", line 5449, in has_mediawiki_message
v = self.mediawiki_message(key)
File "/home/misza13/pywikipedia/wikipedia.py", line 5417, in mediawiki_message
tree = XML(decode)
File "<string>", line 85, in XML
SyntaxError: undefined entity : line 663, column 145
is the typical stack trace. Puzzles me why nbsp would be recognized but until this is resolved, I have stopped my archiving bots. Миша1316:00, 19 September 2009 (UTC)
See this thread at pywikipedia-l, which reports 'All bots are broken.' One of the commenters in that thread says:
Fixed in r7267 by alexsh but API must be enabled in user_config.py with use_api = True since xml and php output is no longer supported.
An editor suggested I post my help request here: To whomever can help, I would like the Diderot and Jimmy Wales quotations on my userpage to have their references show up in a reference section at the bottom of my page, but I am for some reason not see them there. Could some please fix that? Thanks! Sincerely, --A NobodyMy talk17:37, 20 September 2009 (UTC)
The problem was in thank you from Benjiboi about the {{rescue}} tag. More specifically in the twice colapsed table "Articles tagged for deletion and rescue". I removed the table and it's ok now. I hope you don't mind I edited your userpage. Svick (talk) 18:07, 20 September 2009 (UTC)
(edit conflict)That's not really a bug, as the underlying article source has been changed. That being said, I could certainly understand how it could legitimately be perceived as a bug. My recommendation is to file a bugzilla engancement "bug" about it, and hopefully someone will take the time to add the requisite logic to the diff engine in order to change the behavior. — V = I * R (talk to Ω) 06:53, 24 September 2009 (UTC)
This is not the normal behavior I'm used to and am guessing this is the result of the recent software update. I see this as a bug because the diff reports there are spaces ( ) when they don't exist. Diffs are supposed to show the difference between two revisions, not the code under the software. Also, this is really confusing to users who have no idea what   even is. -- penubag (talk) 06:59, 24 September 2009 (UTC)
When looking in users' contributions, the contributions to deleted articles are not shown. This needs to be fixed ASAP. File a bugzilla report or somthing.174.3.110.93 (talk) 08:17, 19 September 2009 (UTC)
It would be helpful though to be able to see that an editor made an edit, even if you can't (for good reasons) see the edit itself.Nigel Ish (talk) 08:57, 19 September 2009 (UTC)
Firstly, I don't think that the MediaWiki software makes that possible (though some external edit-counters do). Secondly, I'm not sure it is that helpful. And thirdly, often the titles of pages, and edit-summaries, contain sensitive/copyrighted information. ╟─TreasuryTag►sheriff─╢ 08:58, 19 September 2009 (UTC)
You can see oversighted edits in the edit history, though you can't click on them. The same thing could be done with contributions to deleted articles, right? 99.166.95.142 (talk) 16:38, 21 September 2009 (UTC)
See mediazilla:12667 "User should be able to see the list of his deleted contributions". It was recognized as useful thing, but not useful enough to actually implement it. — AlexSm20:42, 21 September 2009 (UTC)
Yeah, I have no idea what's going on. Someone must have changed something with the API or something. So, until I get a chance to figure it out, it stays broken. I don't have time to play pin-the-tail-on-the-bug. --slakr\ talk /20:44, 21 September 2009 (UTC)
I've noticed this sort of thing before, within a similar time frame, on different articles. The obvious speculation is that some sort of database corruption occurred at some point, but I don't know the definitive answer. The actual histories are still there though, so I don't think there's any reason to panic. It's an unfortunate problem, but it shouldn't be Earth shattering. — V = I * R (talk to Ω) 04:19, 21 September 2009 (UTC)
Those are the bookend revisions and do show; the ones between seem to be the problem. I've assigned the bug to Tim to take a peek at, since we've seem similar things before -- some of our data migration scripts have occasionally gotten confused on old storage methods and mismarked the compression type so they don't load properly. --brion (talk) 18:38, 21 September 2009 (UTC)
Custom css
{{resolved}}
Any way to get extra links on, say, the navigation toolbar? In particular I'm wanting to put in one for RandomRedirect, but if there's a general way to do it for any link that would be nice. —thedarklordtrombonator05:17, 22 September 2009 (UTC)
The recent MediaWiki upgrade to the English Wikipedia contained a MediaWiki change that broke templates like {{flag}} that generate images designed to be invisible to the screen readers used by visually impaired people. Formerly, usage like this:
[[Image:Flag of the United States.svg|22x20px|link=]] [[United States]]
generated an image with no alt text, which caused screen readers to silently bypass the image, as intended (because it's just decoration; all the intended info is also in the adjacent text). But now it generates "United States", whose image contains the unwanted alt text "Flag of the United States.svg".
Before, editors could mark purely decorative images with "|link=" but now they must remember "|link=|alt=" (both are now required). More important, English Wikipedia must have hundreds of templates and/or articles that rely on the old behavior, are now broken from a WP:ACCESSIBILITY viewpoint, and will have to be fixed by hand if this software change is permanent. (As an aside, I'm mystified as to why the change was made in the first place; ordinarily a screen reader falls back on the file name if no alt text is specified, so why should MediaWiki clutter up the HTML with another copy of the file name?) Eubulides (talk) 23:01, 18 September 2009 (UTC)
I requested the change in this discussion at Code Review, which I found through this message on my talk page. JAWS 10 and later don't announce links to images properly if they have no alt text, even if the image has title text. Formerly they said "link graphic filename"; with JAWS 10 and later, they would've said "Link filename", which I found to be more confusing. I thought that rather than relying on the screen reader to automatically say the filename, it should be put in the alt text so screen readers have *something* to work with. Maybe a default alt text of "Missing alt text" or even "Image link" would be appropriate.
I didn't think of the case where the image doesn't contain a link; that behaviour should be reverted back to the way it was previously because the current setup is annoying when images are unlinked. I was going to bring that issue up, but you beat me to it. I'll drop a note at the above-linked Code Review page, as well as Simetrical's talk page, since he works with accessibility issues. Graham8710:40, 19 September 2009 (UTC)
I've tried to update File:Long_leg_hair.jpg with a better version but I get an error saying that there is a file with that name on commons but there isn't. I've tried it twice and it does the same thing. Is this just temporary because of the software update? Smartse (talk) 12:36, 17 September 2009 (UTC)
I've been having this problem as well for over a day now and it's getting seriously annoying – this has blocked me from uploading quite a few images. Quibik (talk) 14:00, 17 September 2009 (UTC)
Haven't seen the warning about files on commons, but I am seeing a 'failed to calculate hash' warning which was also reported on that bug, which should help us narrow down at least part of it. Michael's poking at it but hasn't been able to reproduce all the problems yet. --brion (talk) 18:59, 17 September 2009 (UTC)
Upload warning
A file with this name exists at the Wikimedia Commons. You can:
*go back and upload this file to Wikipedia using a different name.
*upload it to Commons, if your intent is to replace the image that already exists with a better version.
File:$1
$1
I noticed File:SuckerShirtFinalFlat.jpg, which is at excessively high resolution for a fair-use logo. So, I download it, reduce resolution, and attempt to re-upload by clicking the "upload a new version of this image" link at the file page. I get an error message telling me "A file with this name exists at the Wikimedia Commons. You can: * go back and upload this file to Wikipedia using a different name. * upload it to Commons, if your intent is to replace the image that already exists with a better version. ". There is no such image at Commons. —Kww(talk) 01:29, 20 September 2009 (UTC)
I am trying to upload new versions of the above images. When I do so, an error message pops up saying that the files exist on Wikimedia Commons and that I should upload there instead. When I go to Commons, the files never come up in searches, and I'm pretty sure they were never uploaded there in the first place. Any ideas? --Cryptic C62 · Talk18:50, 20 September 2009 (UTC)
Did more subpages get enabled in this last update, or did I miss it before? Specifically Help and Help talk. There was a request to enable subpages in several namespaces back in April. I didn't see it in the release notes. ---— Gadget850 (Ed)talk19:45, 20 September 2009 (UTC)
Enabling / disabling subpages is handled by shell users in the local settings, and as such would be uncorrelated with the main software updates. Whether anything has changed, I don't know. Dragons flight (talk) 19:50, 20 September 2009 (UTC)
Technically it was enable, but there was a MediaWiki bug, see the discussion. Anyway, they are enabled; was just wondering if it was in this update. ---— Gadget850 (Ed)talk00:51, 21 September 2009 (UTC)
Bugzilla:18437#c1. So what happened was, the customizations on WMF for namespaces with subpages define the entire array, and en.wp's probably has been there since before that namespace existed, so Help_talk was not given subpages since it was overwrit. So on June 1st it seems Rob simply disabled the en.wp line so that it used the defaults (which include both Help_talk and Help). --Splarka (rant) 07:33, 21 September 2009 (UTC)
Special:Statistics seems to show a massive backlog for the job queue; I've been checking it on and of all day, and I haven't seen it below 20,000. I'm guessing that it has everything in the backlog, but just hasn't gotten to it yet. –Drilnoth (T • C • L) 23:11, 21 September 2009 (UTC)
As many probably noticed, the current version of edit screen repeats a part of the Terms of Use: the notification about editing, usage and redistribution is mentioned twice in small letters and under the bold hat below, as well as the link to the Terms. I think this should be fixed in the nearest future by having just a single relevant grasp from TuU. The present tautology of notifications seems quite onerous, if not annoying. Brand[t] 00:33, 22 September 2009 (UTC)
Couldn't a template be made that basically encloses the xhtml tags within a wiki template? So you could use something like {{ref|name=Foo|(content)}} and then have the template itself contain <ref {{#if:{{{name|}}}|name="{{{name}}}"|}}>{{#if:{{{1|}}}|{{{1}}}|}}</ref> ? Heck, it could also enclose citation templates in it, so that instead of the unnamed parameter (which would contain a template like {{cite web}}, you could just use all the parameters of {{citation}} and then this template would pass them through to create a ref. –Drilnoth (T • C • L) 15:41, 17 September 2009 (UTC)
I'm all for that. The main holdup though is that the {{ref}} template already exists, and is (still!) used for non-cite.php references. There are a lot of people who learned to do citations without cite.php, and they don't seem to want to change. — V = I * R (talk to Ω) 16:01, 17 September 2009 (UTC)
Well, yes. 'Twas just a placeholder name. We could always just move the current template and have a bot rename all usages. –Drilnoth (T • C • L) 16:14, 17 September 2009 (UTC)
There are literally thousands of {{ref}} uses, and I don't see those editors who still use it regularly as being appreciative or supportive of a change. If you want to float a proposal about doing so though, I'll certainly support you (I'm just guessing that it'll float like a lead balloon, is all). One of the main tasks that my bot is (eventually) going to be used for is to clean up and organize refs, so this kind of thing is right in my bailiwick. — V = I * R (talk to Ω) 16:35, 17 September 2009 (UTC)
Do you have a better idea for a name? I'm completely open to suggesstions. {{Cite}}, perhaps? That wouldn't be nearly as controversial; a bot would just need to bypass the redirects. –Drilnoth (T • C • L) 16:43, 17 September 2009 (UTC)
I believe that this new extension of cite.php finally replicates the single most attractive feature of the{{ref}}/{{note}} system - that it keeps the citation information from cluttering the body of the article. But there might remain differences of opinion about other disparities in how the two systems function. Christopher Parham(talk)18:00, 18 September 2009 (UTC)
(e/c)Are there other reasons for doing this other than making ref tags more like templates? Using multiple systems like this breaks consistency between articles here and between other wikis, makes things harder to learn, and will likely also break any script or bot that works with or parses references. References are already one of the biggest bottlenecks in terms of parsing time due to templates like {{citation}} being so complicated and large articles having dozens of refs. Increasing the complexity will just make it even worse. Mr.Z-man17:25, 17 September 2009 (UTC)
The problem, I think, is that new users need to figure out two ways of formatting things... HTML-style and wiki-style. Only one should really be used, IMO, although for experience editors it doesn't really matter. It's just trying to get used to it for new users. I know that this is probably never going to happen because of parsing issues, breaking tools, etc.; I just thought I'd toss it out there as something which could be done. –Drilnoth (T • C • L) 17:37, 17 September 2009 (UTC)
It would be one thing if we switched to a template-based system, and then converted all existing uses to it (though we would still be inconsistent with other wikis), but using multiple systems seems like it would just be more confusing (and more likely to break things) than one "non-standard" system. When I started on Wikipedia, I learned how to do most things by example, from looking at other articles, only referring to guidelines and help pages when examples weren't clear. Mr.Z-man17:48, 17 September 2009 (UTC)
Ditto. I think it will take a while before list-defined references take off; heck, a lot of editors are still not aware of the groups feature. We need to document use at Help:Footnotes and include some guidelines. I will do some more testing on this and will update features on the help page as I discover them. ---— Gadget850 (Ed)talk17:58, 17 September 2009 (UTC)
Exactly. I wanted to mention a couple of relevant points here, however.
First, cite.php is an extension, and is therefore already non-standard (although, it's use is so widespread now that pointing out that it's "non-standard" admittedly seems strange).
Prior to the installation of cite.php people used {{ref}}, which is why that template already exists. I'm not sure if it's due to a lack of motivation or actual resistance, but it appears that there is support for retaining the "pre-cite.php" referencing.
In the vast majority of areas we already prefer templates over xHTML tags, and the main reasons to do so are ease of use, maintainability, and standardization.
Personally, I wouldn't have any issue with folding <ref></ref> tag use into {{ref}} and even {{Citation/core}}, which would require removing the <ref> and </ref> tags from around the majority of existing references. It's a large migration project, but I think that it would be helpful to most people, and it would certainly simplify the source wikitext in the vast majority of articles. As for the learning curve, once the conversion started I think that people would catch on fairly quickly. There would need to be a specific migration period that should last a while (2 weeks would be the minimum, I would think), but it could be done. — V = I * R (talk to Ω) 18:57, 17 September 2009 (UTC)
Nothing is stopping us from making the templates and let those who want to try it. I don't think we should organize a mass migration unless the new type is well-proven and well-liked. --Apoc2400 (talk) 19:11, 17 September 2009 (UTC)
I suspect that the xml-like syntax has not been replaced with a template yet because putting the other citation templates inside gets ugly: {{ref|{{cite book|author=...}}}}. With the new list-defined references that is no longer a problem. If we are going to puish for defining references at the end anyway, may I suggest an even shorter syntax in the body text:
{{ref|Smith2006}}
which would be the same as <ref name="Smith2006" />. This would make article text very readable once again. {{ref}} may have to be replaced with whatever template name we can aquire for this. --Apoc2400 (talk) 20:04, 17 September 2009 (UTC)
I think list-defined refs will make the body more readable for the casual editor and shorter syntax is always nice if it's understandable. I don't want to jump the gun on implementation, but may I also suggest a script to convert an article's refs into list-defined refs. I can see it becoming very useful if list-defined become the preferred method to cite. —Ost (talk) 20:11, 17 September 2009 (UTC)
Wow. Apparently I need some education as well. What is the preferred way to do citations? Is Help:Footnotes up-to-date? I'm curious if I'm doing it correctly. I took a bit of a hiatus from editing and just now started again and learned about the group feature yesterday.↔NMajdan•talk20:05, 17 September 2009 (UTC)
What is would really want is <<Smith2006>>. I think references are important enough to deserve their own wiki syntax. That needs code changes of course. --Apoc2400 (talk) 20:21, 17 September 2009 (UTC)
I think we need a more centralized discussion page for improvements to the footnotes system with links to the myriad of previous discussions. Much of this seems familiar, and indeed the recent change is due to a series of discussions that I finger at the moment. ---— Gadget850 (Ed)talk20:32, 17 September 2009 (UTC)
Geez... OK, hang on, let's slow down a bit. The "list-type references" came from a proposal originally made here, if I remember correctly. There have been several proposals to do similar things I'm sure, but someone finally motivated a developer to add in the list-type reference code. Anyway, references already have their own code, which is defined by the cite.php extension, and is (essentially) what we're talking about here. I don't think that creating {{ref2}}, {{Citation2}}, and the like, would be helpful in the long run because it would simply complicate matters even more (we would then be adding a third method rather then simplifying/standardizing on one method). As for a more centralized discusison, I can't imagine a more central place to discuss this. WP:FOOTNOTE is certainly not more central then the Village pump (although, we should move this to Wikipedia:Village Pump (proposals) if we're actually going to make this a change proposal). We could easily add an RFC to this and/or listing it on {{cent}}. It's probably a bit early for that though, since we're not even sure what the proposal is. — V = I * R (talk to Ω) 20:50, 17 September 2009 (UTC)
Actually, I meant we need a list of previous discussions— there have been so many that there are a lot of repeated ideas.
The simplest way to do this is to change {{citation/core}} add a parameter, let's call it |refname= that if defined, wraps the citation in <ref name=refname></ref>. Thus it is backward compatible as it only invokes the new feature if the parameter is defined. We could then create a template named redef for the inline cite. Frankly, I don't see any need to update {{ref}}. ---— Gadget850 (Ed)talk02:16, 18 September 2009 (UTC)
A potential issue with the proposals above to hide the <ref> within a template is that it will make it much more difficult for syntax highlighters and other tools that look at the page's wikitext to determine what is a reference and what is not. Instead of just searching for <ref> and {{#tag:ref}}, they'll also have to keep track of every random template people do this with. Anomie⚔13:26, 18 September 2009 (UTC)
I have been coming towards that point of view as well. Checklinks and refTools don't work with list-defined references— I have alerted their owners and hopefully we can get some updates for these valuable tools. I don't see how any tool could pull a reference if it is buried in a template. I did a proof of concept to show that it works, but I think it is more trouble than it is worth. I did a fix for another editor who was updating an article to LDR and found the problem by searching for the <ref> tag. ---— Gadget850 (Ed)talk13:48, 18 September 2009 (UTC)
I think the XML-like syntax is much nicer, and much more readable, and much easier to parse, than template syntax. Why do we want to use the horrific template syntax instead?
Advantages of XML syntax:
Matched opening and closing tags make it easier to see where a particular block ends and begins.
Familiar to people who are used to programming with the web.
Only slightly less brief.
More natural method of specifying arguments.
Fewer delimiter collisions (no need for ugly stuff like {{!}} and 1=).
For those of us who are familiar with HTML/XML you're absolutely correct. I've talked to several newer editors who aren't, however, and their always slightly confused by it at first. for those editors, the "ugly stuff" seems preferable, simply for consistency/ease of use.
Personally, I'm basically fine with things the way they are. It would be nice to just use {{Cite web|group=Note|name=Example|url=http;//www.foo.com|title=example}} instead of <ref group=Note name=example>{{Cite web|url=http;//www.foo.com|title=example}}</ref>, is all. It looks a lot neater in article source, as well. — V = I * R (talk to Ω) 15:02, 18 September 2009 (UTC)
This is a wiki. It should use wikicode. Yes XML is "cool" you can show off your fast typing skills or auto-complete software - but wiki is supposed to be quick. And XML can be horrendously long, because you always end up with another level of enclosing tags. I expect one day to see <character>a</character> nested in <word> tags ...
RE: "Stuffing this all into templates." If this is a direction you think should be pursued, {{sfn}} already implements some of the functionality you are wishing for. ---- CharlesGillingham (talk) 03:45, 22 September 2009 (UTC)
Using a template {{ref}} instead of <ref> for a ref with opening and closing tags saves all of 5 characters. For something like <ref name='Foo'/>, template syntax - {{ref|name=Foo}} - saves a whole 1 character. There's simplifying, and then there's excessive optimization, and change for the sake of change. Mr.Z-man04:11, 22 September 2009 (UTC)
The sandbox' iw link to the nn.wikipedia is incorrect (should be "Wikipedia:Sandkasse", not "Wikipedia:Sankasse"). Is there any way to correct this? Thanks, decltype (talk) 10:57, 21 September 2009 (UTC)
Yup, interwiki links are just added like categories, so the current interwiki link looks like [[nn:Wikipedia:Sankasse]], just change it to [[nn:Wikipedia:Sandkasse]]. Although you should note that the current interwiki links for the the sandbox are in the heading template: Template:Please leave this line alone (sandbox heading), and it is fully protected, which shouldn't be aproblem for you :) - Kingpin13 (talk) 11:04, 21 September 2009 (UTC)
I would argue that the parts containing the interwiki links should not be fully protected. Under normal circumstances, bots would update all interwikis as needed, and generally make fewer spelling errors. It is impractical for us to require admin intervention every time the editors of some new project decide to add a sandbox page.
{{pro-tip}} if we like this idea but are still worried about high-visibility vandalism, we could do something like this:
<div style="display:none;">
{{unprotected sub-template containing interwiki links for the sandbox}}
</div>
The interwiki stuff would still be visible as these links (as with categories) render outside the content area, but plain text like "JOHN SUCKS" would remain hidden. — CharlotteWebb14:37, 21 September 2009 (UTC)
I don't know of an easy way to do it on the site, but it can be done with a query on the Toolserver database. tools:~alexz/voabot.htm is the edits immediately before VoABot's last 500 edits, excluding user talk edits. Let me know if you want a longer list, more information, different format, etc. Mr.Z-man02:34, 22 September 2009 (UTC)
Thanks! I was going to offer this list to User:Crispy1989 for use in training his new Cluebot (which needs a LOT of examples of vandalism). Im going to parse the list for edits that User:VoaBOTII made against vandalism (it doesn't just do vandalism, therefore i need to remove the non-vandalism reverts). I think 500 is good to start off. But if it turns out that User:Crispy1989 wants them, then I might have to ask you to give me more. Thanks for your help! Tim1357 (talk) 03:04, 22 September 2009 (UTC)
External links no longer showing URL
Probably the same updates to MediaWiki that caused the alt/title tag problem in images, is also responsible for external link no longer showing the URL in hints; in IE, they do not even show up in the status bar anymore. This is quite serious, as I'd like to know where I'm going before I click on an external link. — Edokter • Talk • 16:57, 20 September 2009 (UTC)
I can confirm that the external link is no longer duplicated in the title attribute (the tooltip) in all skins. This is bad for full screened users. — Dispenser01:14, 21 September 2009 (UTC)
I see that the title attribute is missing, but both IE 8.0 and Firefox 3.5 still show the destination in the status bar. Which browser are you concerned about? Dragons flight (talk) 01:49, 21 September 2009 (UTC)
You have a good point. But how recently-tagged are articles which have been labeled with merge tags since 2007? @harej22:23, 21 September 2009 (UTC)
I am here to post about the job queue! But is Animal language in the queue? seems unlikely It is still odd though, the upgrade seems to have broken quite a lot. Wikia seemrd to do some upgrades that broke stuff too. ~~
Incidentally, it just got added to the category. I think there is a backlog of stuff that will be added now that I fixed a quirk in {{merge}}. @harej22:28, 21 September 2009 (UTC)
Ah, that's right. In other words, you're saying your change to the template kicked the articles out of the category. You're welcome! @harej11:20, 22 September 2009 (UTC)
Cologne Blue User Script failure
Cologneblue.js processing of user scripts has recently broken for me in Firefox 3.5. Specifically, addOnloadHook(func) no longer works in a user script for Cologne Blue, though it continues to work for Monobook. The hook function is never called.
The failure point traces to the onloadFuncts array, which contains entries loaded from addOnloadHook(), and has as its first function entry the function liveClock(). Unfortunately, liveClock() errors out under Cologne Blue for my machine and always has, due to liveClock.node being a null value. This liveClock() failure didn't used to be a problem. Now it is, since it stops further JavaScript processing, including my script's hook function (which here lives at the tenth subscript in the onloadFuncts array).
I can hack around the problem in a user script by forcing a valid function where the liveClock() hook lived by adding the line:
Remove whatever userscript is adding the liveClock() function? I don't think that's part of any of the global scripts. Mr.Z-man04:45, 22 September 2009 (UTC)
I have fixed the gadget to no longer generate errors, but it still doesn't work for the cologneblue skin (but there are many scripts that don't work in cologneblue). —TheDJ (talk • contribs) 09:55, 22 September 2009 (UTC)
Ahh, it's a gadget issue, I didn't think about that. I don't care if that particular gadget works when Cologne Blue skin is selected, but don't want the gadget breaking script processing if enabled for the user, since it's a universal setting separate from skin setting. Thanks. -- Michael Devore (talk) 18:08, 22 September 2009 (UTC)
External links no longer showing URL
Probably the same updates to MediaWiki that caused the alt/title tag problem in images, is also responsible for external link no longer showing the URL in hints; in IE, they do not even show up in the status bar anymore. This is quite serious, as I'd like to know where I'm going before I click on an external link. — Edokter • Talk • 16:57, 20 September 2009 (UTC)
I can confirm that the external link is no longer duplicated in the title attribute (the tooltip) in all skins. This is bad for full screened users. — Dispenser01:14, 21 September 2009 (UTC)
I see that the title attribute is missing, but both IE 8.0 and Firefox 3.5 still show the destination in the status bar. Which browser are you concerned about? Dragons flight (talk) 01:49, 21 September 2009 (UTC)
You have a good point. But how recently-tagged are articles which have been labeled with merge tags since 2007? @harej22:23, 21 September 2009 (UTC)
I am here to post about the job queue! But is Animal language in the queue? seems unlikely It is still odd though, the upgrade seems to have broken quite a lot. Wikia seemrd to do some upgrades that broke stuff too. ~~
Incidentally, it just got added to the category. I think there is a backlog of stuff that will be added now that I fixed a quirk in {{merge}}. @harej22:28, 21 September 2009 (UTC)
Ah, that's right. In other words, you're saying your change to the template kicked the articles out of the category. You're welcome! @harej11:20, 22 September 2009 (UTC)
Cologne Blue User Script failure
Cologneblue.js processing of user scripts has recently broken for me in Firefox 3.5. Specifically, addOnloadHook(func) no longer works in a user script for Cologne Blue, though it continues to work for Monobook. The hook function is never called.
The failure point traces to the onloadFuncts array, which contains entries loaded from addOnloadHook(), and has as its first function entry the function liveClock(). Unfortunately, liveClock() errors out under Cologne Blue for my machine and always has, due to liveClock.node being a null value. This liveClock() failure didn't used to be a problem. Now it is, since it stops further JavaScript processing, including my script's hook function (which here lives at the tenth subscript in the onloadFuncts array).
I can hack around the problem in a user script by forcing a valid function where the liveClock() hook lived by adding the line:
Remove whatever userscript is adding the liveClock() function? I don't think that's part of any of the global scripts. Mr.Z-man04:45, 22 September 2009 (UTC)
I have fixed the gadget to no longer generate errors, but it still doesn't work for the cologneblue skin (but there are many scripts that don't work in cologneblue). —TheDJ (talk • contribs) 09:55, 22 September 2009 (UTC)
Ahh, it's a gadget issue, I didn't think about that. I don't care if that particular gadget works when Cologne Blue skin is selected, but don't want the gadget breaking script processing if enabled for the user, since it's a universal setting separate from skin setting. Thanks. -- Michael Devore (talk) 18:08, 22 September 2009 (UTC)
Did Monobook change?
All of a sudden I'm getting colored backgrounds everywhere. I want my white backgrounds back! The new background colors make things hard to read. Elphion (talk) 08:12, 19 September 2009 (UTC)
I did not change the skin. I did click on "Try Beta", but did not click the implementation button there. (Color changes weren't advertised in the "What's improved" blurb there anyway.) I can't swear the colors weren't there before (and I'm not talking dark colors, just dark enough to make the text look muddy), but having noticed them I am now constantly aware of them. I now see them in IE as well (which I don't usually use and never sign in with). How hard would it be to modify the CSS to make the basic tab background white for content, even beyond the main space? I tried * {background-color:white} but of course that wiped out too much (but conversely did not hit elements with more complex combinations of ids and styles). Elphion (talk) 15:18, 19 September 2009 (UTC)
The local stylesheets on en.wikipedia.org have been putting lightly colored backgrounds on non-main namespaces in Monobook for several years. They are pretty light, though, so you may have not noticed them before -- some LCD monitors for instance won't even show the difference between the light blue and white if you have the brightness and contrast set relatively high.
You'll see the specs for this at the top of MediaWiki:Monobook.css in the "light blue section". You can copy-and-paste those bits back to your personal monobook.css and override them back to white if you like. --brion (talk) 18:49, 21 September 2009 (UTC)
Thanks for the info. My guess is that nothing has changed, and that my eyes were just tired. Sorry for the false alarm. I'm still amazed though at how much difference even very light background colors can make. Elphion (talk) 15:28, 23 September 2009 (UTC)
Image move re-enabled
Resolved
– For already-affected files, edit the redirect (not null-edit) or wait 24 hrs for cache to expire
For those who had not yet noted. As of today, it is again possible for sysops/administrators to move files and their corresponding pages, without having to reupload the images. Hopefully this time no bugs will pop up, but if you see any weird or unexpected behavior, please report it. —TheDJ (talk • contribs) 23:02, 21 September 2009 (UTC)
It's a bug where the redirect information gets cached incorrectly immediately after the rename. As a temporary workaround, you can edit the redirect page -- not a null edit, but add some text afterwards. This'll rebuild the image redirect cache entry for the page and the redirected image will start working again.
Michael Dale and I are taking a peek to see if we can figure out how the bad entries are getting in... it seems consistent here but isn't happening on our offline test environments yet. --brion (talk) 00:26, 22 September 2009 (UTC)
Ok, I've installed a temporary quick fix to re-clear the bad entry from the cache at the end of Special:Movepage. The cache was being polluted during the display of the post-move success text, which on en.wikipedia is pulling in a direct link to the original title... which then reads the redirect state from slave servers which have not been updated with the rename yet. Any remaining bad cache entries will expire within 24 hours (pages using them can then be re-rendered successfully), or you can do the edit-the-redirect trick to clear them sooner. --brion (talk) 00:48, 22 September 2009 (UTC)
Great. Do we have a guideline on dealing with the resulting redirects? Cause that make it a pain to figure where the image is used and if the backlinks are valid. ---— Gadget850 (Ed)talk01:09, 22 September 2009 (UTC)
This is a case of a Commons image with a local en.wp page. The local page contains a category, but this could also be a Featured image tag or something of course. After the file on Commons is moved, the following problems arise
bugzilla:20770 When going to the page description using the original link File:01123.jpg, there is no "redirected from" notice.
Due to the lack of the redirected from notice, the en.wp page is unreachable. You have to use a handcrafted url [14]
The en.wp page still adds the image to the category Category:Shinto_shrines_in_Taiwan, but the description page does not list this category.
The en.wp page with the category or the featured image tag is not moved, nor rendered.
These are important side effects that we will have to deal with. Some can be fixed, but others probably will require botwork to cleanup. —TheDJ (talk • contribs) 15:28, 22 September 2009 (UTC)
All these issues are bugs in the File redirects code apparently. They also exist independent of wether or not there the local page is still there. The other issues that is left, is that Commons moves will cause featured article and DYK banners to go broken. We might want to have a bot that checks for this sort of problem. —TheDJ (talk • contribs) 15:50, 22 September 2009 (UTC)
If the English description page is moved manually to the new title everything begins to work. This is a limited problem. Ruslik_Zero10:13, 23 September 2009 (UTC)
I know it is possible for an editor to check when editors email each other using wikipedia, but where is the policy on this? Ikip (talk) 19:10, 20 September 2009 (UTC)
I'm not aware of a policy that directly addresses it. The message when you send one lays the important part out: A private log of this action will be retained for the purpose of preventing abuse, and can be viewed by certain privileged users. This log does not identify the recipient, title, or contents of the e-mail. In cases of serious abuse, Wikimedia server administrators can verify the recipient account." By implication, you would have to demonstrate to a checkuser that there was reason to suspect abuse using the e-mail function, and he, in turn, would then have to convince a Wikimedia server operator to reveal the names of the recipients. If the question underlying this is "can editors organizing an RFC/U communicate with each other using the e-mail function?" then the answer is that I'm not aware of any policy or guideline prohibiting that, and believe it to be normal. The policy pump is probably a better place to ask.—Kww(talk) 19:22, 20 September 2009 (UTC)
As far as I can tell, it's not possible to tell after the fact the recipient / subject / contents of an e-mail sent through that interface, even for people with shell access to the servers. — Werdna • talk12:15, 21 September 2009 (UTC)
Is there a way to determine if a page is a redirect page from within a template? Is there a parser function for example?
{{#ifexists: . . .}} lets one check if a page exists (and, for example, avoid unnecessary red links), but when having templates link to existing pages I would pefere to avoid linking to a redirect page. I would rather link to the actual page.
Alternatively, is there a way of asking, for example, for the resolved redirect, that is, for example {{#resolve: 'name of page'}} returning the redirected-to page if the 'name of page' is a redirect page?
One big issue to keep in mind here would be WP:NOTBROKEN, which probably explains the lack of such a parser function. Of course, it depends on what links are being discussed, as links in navigational templates should show up as bold on the pages that they link to. — V = I * R (talk to Ω) 17:41, 22 September 2009 (UTC)
WP:NOTBROKEN does not really apply because I have the choice of defining and picking the better link in each case. So if the context is not improved by the redirect it would bebtter for me to pick the non redirect. But thanks anyway. I had not come across this wikitip before. Peet Ern (talk) 09:03, 23 September 2009 (UTC)
It may not be what you want exactly, but there are a few scripts available which will highlight any redirects on a given page. PC78 (talk) 02:44, 24 September 2009 (UTC)
Break it into more sub pages (one page for each table seems obvious). The current page is taking too long to render regardless, which is the reason why only so many tags will be rendered by the parsing engine in the first place. Since you're definitely running into a technical barrier, no one should seriously oppose a move to more pages, and the size of the tables makes the resultant subpages large enough to justify their existence. — V = I * R (talk to Ω) 00:45, 24 September 2009 (UTC)
sub-sub tables on the individual pages, then. I'm sorry, but that's really the only resonable solution that will be available as far as I can tell. As I mentioned above, there is a real, and important, technical barrier to removing the actual restriction that you are encountering here. In this instance the best course of action is to adapt to the limitations of the software. — V = I * R (talk to Ω) 01:03, 24 September 2009 (UTC)
actually the best thing to do is not use the template that calls #time. the limit is there for a reason. right now its got a 22.5 seconds to render which is just too high. βcommand01:22, 24 September 2009 (UTC)
(edit conflict) Subst the dts calls. That information is essentially static, so there is no reason to force the parser to evaluate it every time. Most parser limits can be avoided by substituting the rendered result for templated wikicode. This reduces the ease of future editing in exchange for being nicer to the parser. Dragons flight (talk) 01:26, 24 September 2009 (UTC)
Articles moved and thereby lost
A number of days ago I attempted to perform the following moves:
For purposes of this thread, we can ignore why the moves were performed or if they were justified or not.
After the moves were performed, the content of the articles disappeared. It was removed from the old article titles but the text was not moved to the new destinations. I have admin tools and I've fiddled around and tried to find where they have gone, but I am perplexed. If you go to Category:Bilateral relations of Peru, there is a link to blue link to Holy See – Peru relations, but when it is clicked on it does not exist.
Does anyone know what could possibly be going on here and/or how to get the text back? (I know we can probably get copies of the text of the articles from google cache, but it would be a real pain to re-code all the references, etc.) Thanks, Good Ol’factory(talk)01:51, 24 September 2009 (UTC)
– This false positive in upload checks has since been removed
I raised this at Commons, but only got one baffling response.
My question: "I'm trying to upload a MIDI file I made. In IE8 and FF 3.5 this ends with the message "This file contains HTML or script code that may be erroneously interpreted by a web browser." I have searched commons.wikimedia.org and en.wikipedia.org for that string and only found it regarding instances of SVG files. How can I find out what causes that message with a MIDI file, and how can I avoid it?"
My response: I've never heard of any such thing. A MIDI file is a binary file and content should not be interpreted, not as HTML or anything else, other than as MIDI instructions. There are some text elements in a MIDI file, like track names and composition title, but that's well within the MIDI specifications, and none of them contain anything resembling HTML. Previous MIDI files I uploaded contained those text elements, too. The file can currently be inspected at http://mbednarek.com/temp/maidensprayer.mid (13,635 byes, 3:05 minutes). For me, it opens and plays from there as expected in IE8 and FF 3.5.
I have also attempted to upload that file here at en.wikipedia.org, with the same result, i.e. the above error message. Where do I go from here? -- Michael Bednarek (talk) 14:07, 22 September 2009 (UTC)
Whenever a file is uploaded, a scan is done to try to guess if the file contains code that might be executed by web browsers. Some sort of test like this is necessary to prevent uploaded images from being used to attack people's computers. Your file is, unfortunately, coming up as a false positive under this scan. I looked briefly but I don't have time to find out exactly which part of the scan (in UploadBase.php) is being tripped. You should file a bug report at bugzilla.mediawiki.org, so that a developer can investigate the situation and fix the scan. — Carl (CBM · talk) 16:19, 22 September 2009 (UTC)
Thank you very much for that nice piece of detective work. BTW, the piece didn't get corrupted by your change, just slightly modified: you changed a "note off" event for an F5 note late in bar 2 to F♯5 (for which there was no previous "note on" event), so a F5 kept sounding until another "note off" event for that note occorred in bar 7; given the decay for a piano sound (and the flurry of notes anyway), that didn't matter much. One could also change the preceding value of 3Cx (<) to 3Dx (=) which would stretch the piece at that point by 1 MIDI tick.
See the wikitext of English Defence League for the new syntax, if you haven't seen this already. Note the ordering (of the wikitext) in the "References" section in particular for one convenient thing (for editors) that this new syntax allows. Uncle G (talk) 03:00, 24 September 2009 (UTC)
wp:ships has decided to discontinue using importance ratings on our project banner. I posted a notice here about a week ago and the issue is still open. Any help on this would be appreciated. --Brad (talk) 19:41, 28 September 2009 (UTC)
Reduced window widths can make a mess of any page on Wikipedia or other site. It's impossible to have a functional, well-designed layout that will look perfect on every resolution and very small window sizes. hmwith☮23:27, 23 September 2009 (UTC)
Yes, but they can at least be made to wrap around each other, or placed more out of each other's way. It doesn't take much to mangle this example, just using a non-widescreen display does it for me. OrangeDog (talk • edits) 00:17, 25 September 2009 (UTC)
This may be because the user creation log was only introduced in September 2005. That would mean he had an account for years without editing, which is possible if unlikely. Algebraist17:01, 24 September 2009 (UTC)
His user id is about 300,000 less than mine, and I was registered in December 2005, so this is probably the case. Mr.Z-man17:14, 24 September 2009 (UTC)
I recently tried to add a section for newpage monitoring on my userpage, but there was some sort of error with {{Special:Newpages}}, and a nonsense string, UNIQ42e98bee533bca26-h-0--QINU?, is somehow added to all the subtitles. This problem also occurs on Template:Dashboard. What could be causing it? I am pretty certain this is a recent development, as I would have noticed it on the DashBoard sooner. --Intelligentsium23:52, 24 September 2009 (UTC) (Moved from Help Desk)
Hi, I want to use {{subst:today}} in the accessdate parameter of the cite web template. It seems to work only when the cite web is not wrapped in a <ref> tag. Any ideas? See below for what I mean.
{{cite web |title=Lorem Ipsum |url=http://www.loremipsum.com/ |date={{date|9 September 2009}} |work=Test edit |publisher=Lorem Ipsum Inc |accessdate={{subst:today}}}}
gives the correct
"Lorem Ipsum". Test edit. Lorem Ipsum Inc. 9 September 2009. Retrieved 22 September 2009.
On the other hand,
<ref>{{cite web |title=Lorem Ipsum |url=http://www.loremipsum.com/ |date={{date|9 September 2009}} |work=Test edit |publisher=Lorem Ipsum Inc |accessdate={{subst:today}}}}</ref>
Uh, even if this were possible, this shouldn't be implemented. The specified accessdate should reflect the last time an editor actually accessed the material, not the current date. --Cryptic C62 · Talk21:51, 25 September 2009 (UTC)
I think you don't understand what subst: does. {{today}} shows always the current date (or more precisely the date when the page was last regenerated). But when using subst:, the template is expanded on save and never regenerated again. So if I add {{subst:date}} to a page today, it will be expanded to {{date|2009-09-25}} (which renders as 25 September 2009) and will stay that way forever. Svick (talk) 22:00, 25 September 2009 (UTC)
I'm wondering, is there relevant Monobook.js code to never watchlist a specific page, even when using the option to watch every page I edit? Using Twinkle to report to AIV floods my watchlist (incredibly active page- I'll see the user blocked anyway, they're on my watchlist from when I warned them in 99% of cases). Thanks! --KingÖomie13:47, 25 September 2009 (UTC)
He has probably in his settings that every page he edits is added to his watchlist, so it isn't Twinkle-specific. Svick (talk) 18:37, 25 September 2009 (UTC)
Some editors have been complaining that they can't see my font. I've decided to use the Baybayin script to promote is as a national heritage. So If anyone could help out in making it visible, would be really thankful.--ᜊᜓᜅ ᜅ᜔ ᜑᜎᜋᜅ᜔ ᜋᜑᜒᜏᜄ (ᜂᜐᜉ)Baybayin21:23, 25 September 2009 (UTC)
As images aren't allowed in signatures, I see no other way for you than to promote installation of appropriate fonts. I installed one of the fonts from page linked from Baybayin, and now I can see your signature fine. Svick (talk) 22:07, 25 September 2009 (UTC)
Those aren't images... they're just characters that people don't have installed. I think that the signature is perfectly fine under policy (no images, etc.), although I would recommend using a different one which either uses mostly common characters or use the Baybayin characters but also have User:23prootie linked to in more common characters. Perhaps:
I probably wasn't clear. I know he doesn't use images currently, I mentioned them as the only way I can think of how he could made his signature visible to most users, if that was allowed. Well, that or making people install the fonts. Svick (talk) 22:33, 25 September 2009 (UTC)
I agree with Drilnoth's assessment, and strongly suggest that you alter your signature to include your username in this alphabet. The font you're using isn't included by default in almost any operating system, so the number of users who can read it by default is slim. It's not really fair to force users to install a font (from an external site no less) to interact with you (and most won't). --KingÖomie13:22, 28 September 2009 (UTC)
He barely squeaks by under the hard cap, at 234 characters (minus timestamp). I didn't even notice; it appears grey (like all wikilinks) in WikiEd. --KingÖomie16:20, 28 September 2009 (UTC)
Diffs in raw
Is there any way to see diffs in the raw format (like how we can use action=raw for normal pages)? I want to be able to get diffs without using much bandwidth. Is there way to do this?ManishEarthTalk • Stalk00:53, 26 September 2009 (UTC)
The diffs are expensive to generate, so they are cached. The problem is: the diffs are cached as an HTML table so there is no rawness to get, really. The api will let you get just the diff's HTML, but only in an escaped container like xml (or yaml, json, etc). Also note, the API returns the diff cache, not the diff itself (but it sometimes generates the cache after a request or two, if none existed). You'll probably need an external tool or script to view it meaningfully. --Splarka (rant) 07:19, 26 September 2009 (UTC)
Several months ago, I drafted a policy for the use of the revision deletion function for administrators on the English Wikipedia. After consultation with a small group of users, I made modifications and changes (with the help of FT2) to better address the suggestions of these people. I have waited a while for the policy to become more stable before consulting the wider community, because it is in my belief that there is nothing worse than discussing a policy draft that still does not have the consensus of its drafters.
The policy in its current state is quite similar to the Criteria for Speedy Deletion policy, in that it defines very specific circumstances in which the revision deletion functionality can be used. The policy is defined so strictly to help allay some of the fears of potential misuse of the functionality, with deviation from the set criteria resulting in whatever sanctions are decided upon by the community.
I would invite all users to read the statement and FAQs that I have written at Wikipedia talk:Revision deletion#Community consultation regarding the functionality and then discuss on the talk page the merits of ratifying this policy, and subsequently enabling the feature for administrators on this project.
Thanks for listening and happy editing! ~fl05:44, 26 September 2009 (UTC)
Timestamp
Is there any easy way to find out an edit's timestamp?
(ec) The parameter image was specified twice in that infobox and in that case, the second one takes precedence. So if you tried to set the first image parameter, it had no effect. I alredy put the image there. Svick (talk) 17:45, 26 September 2009 (UTC)
Hello, the main page is currently in modern skin to me. The URL isn't changed at all, it's http://en.wikipedia.org/wiki/Main_Page. Any idea why that is? Dunno if it affects logged in users.
Can anyone tell me why the table at Wikipedia:Template messages is displaying oddly for me, with bullets followed by blank lines between the bulleted entries. Looking at the edit window, I can't see why this should be so; and I'm pretty sure it never looked like this before. Deor (talk) 19:24, 26 September 2009 (UTC)
Wow, that's one strange bug. It seems that whenever you have centered heading (=={{center|Heading}}==), then it somehow changes following tags in HTML so that they contain <span class="mw-headline" id="Heading">(usual text)</span> that they shouldn't. In case of unordered list (ordered list works the same as other tags) this causes insetion of <li style="list-style-type: none; list-style-image: none; list-style-position: outside;"><span class="mw-headline" id="Heading"></span></li> after every item. This probably shouldn't be visible, but Internet Expolorer seems to ignore that style. Svick (talk) 20:23, 26 September 2009 (UTC)
Would it be at all feasible to add a language option to the search feature on the sidebar, much like is on wikipedia.org? Or, if that's too complicated, a link to the entry page? An option to change search language when a search comes up empty? I often find myself annoyed that I need to retype the main website URL just to be able to search in a different language. I realize it's not an issue for people who use wikipedia in strictly one language, but as a multi-lingual user (I've used it in English, German, and Japanese) it really disrupts the flow of my reading. Eike (talk) 20:52, 26 September 2009 (UTC)
It's probably not exactly what you want, but if you don't want to search for a term, but directly go to a page on different language Wikipedia (e.g. Beispiel on German), you can enter de:Beispiel (de is language code for German) to the seach box and click Go or press Enter and you will get to the page de:Beispiel. Svick (talk) 21:30, 26 September 2009 (UTC)
Didn't know I could do that, so it's good to know, but I'm sure there are plenty of other users who had no idea that function was available. And I still think a link to a language-change page would be very helpful. Eike (talk) 16:48, 27 September 2009 (UTC)
Well such won't be added to the sidebar I think, it would clutter up the interface too much. But perhaps a selector or a "search all Wikipedia languages" option can be added to the results page. I'll ask the usability team and the searchengine guru (User:Rainman) —TheDJ (talk • contribs) 11:56, 28 September 2009 (UTC)
Yeah, I did think it might clutter things too much with a drop-down bar, but a quick link to a language change page would be a god-send. Thanks so much for looking into this. (-Eike, not logged in) —Preceding unsigned comment added by 199.79.165.18 (talk) 19:09, 29 September 2009 (UTC)
Knowing just the filename you can get the full image via Special:Filepath. This work as a link like: Special:Filepath/Wiki.png (or Media:Wiki.png), as a parser function like {{filepath:Wiki.png}}, and as a redirecting URL like http://en.wikipedia.org/wiki/Special:Filepath/Wiki.png (which can be linked to externally). Note that these return the full image which can be up to 100 megs in some rare cases. You can use thumb.php to generate a thumbnail, but it will fail in cases where the specified width is smaller than the image, or for non-thumbable media like gif and video/audio. Thumb.php also does not automatically resolve shared repository images like Filepath does. --Splarka (rant) 00:00, 27 September 2009 (UTC)
Is there any convenient way to add inline notes to an article? I could use the 'ref' tags but then the note would be indistinguishable from a mere reference and nobody would see it. Lemmiwinks2 (talk) 02:22, 27 September 2009 (UTC)
How does one remove the username suggestion on the login page? In Firefox, even after pressing Shift+Del when it's highlighted, the username is still suggested when one goes back to that page. Even Ctrl+Shift+Del and choosing "form and search history" doesn't help. --Espoo (talk) 10:36, 27 September 2009 (UTC)
I get no response from Eukesh who (maybe thinking it would be helpful) put this script on the Dzongkha and Tibetan Wikipedias which is supposed to allow one to type Tibetan or Dzongkha by using translitteration - however the script (based on one for Indic languages) may be well intentioned but was obviously written by someone who understood little about Tibetan & Dzongkha translitteration or the model used for encoding Tibetan in the Unicode standard - so the script is worse than useless. It is on by default and consequently this script has to be manually turned off via a checkbox with each and every edit. This is bad enough, but the template also affects input in the Search /Go To box in the left hand column making that useless. There is no obvious way to turn it off there, and without that search box being functional a Wikipedia is totally crippled. (Then people complain that no one is using Dzongkha and Tibetan Wikipedias - this could be one of the main reasons for that sad state of affairs.)
I have suggested to Eukesh that he correct the script - here - but that hasn't happened; I have also asked him several times to remove it - here, here, here and here - but that hasn't happened either. I would remove the script myself, but don't know how to - and anyway probably don't have sufficient rights. Does someone have any ideas or know who I should contact? I have raised this issue at the Help Desk - but they say they acan only deal with issues affecting English Wikipedia. There is obviously no Help Desk or Village Pump for Tibetan or Dzongkha Wikipedias - in fact I am one of the only active contributors there. Would appreciate any suggestions as to how to correct this.
To be able to install such a script Eukesh obviously has something like admin or sysop privileges on the Dzongkha and Tibetan Wikipedias. The fact that he installed such a script template without knowing those languages or the translitteration used for them; and has the script turned on by default - when even if it did work it should only be an option (as it grabs and modifies user input); and that he has not responded when I have informed him of the problems, is imo an abuse of such priviliges. Obviously no one is going to use Dzongkha and Tibetan Wikipedias if they cannot use the search function or easily edit pages due to the presence of this script. I am currently trying to encourage high school students in Bhutan to contribute to the Dzongkha Wikipedia but unless this Translit termplate script is removed or fixed that is very difficult. Chris Fynn (talk) 14:49, 27 September 2009 (UTC)
If you are unable to resolve this on these two Wikipedias, then contact a steward, either by using Internet Relay Chat (I suggest if you don't already know what this is, an emergency is not the right time to learn) or by posting on the talk page of a currently active steward.-gadfium02:05, 28 September 2009 (UTC)
In the latest MediaWiki update, an RSS feed was added for the watchlist (bugzilla:471). The only mention of this I can find anywhere in the interface is at Special:Preferences. Is this only half-implemented? Is there any way for a user to find a link to the RSS feed? — RockMFR22:48, 27 September 2009 (UTC)
It wasn't added in the latest update. You can find description of parameters on [17] (serach for feedwatchlist). Default form is http://en.wikipedia.org/w/api.php?action=feedwatchlist. I guess the new feature is the security token (before, you had to have a cookie set, just like when you are logged in to Wikipedia in your browser, which is pretty difficult to do in RSS reader). Svick (talk) 23:11, 27 September 2009 (UTC)
Yeah, there's a backend but no frontend for it yet. :P Could use a little lovin', I've reopened the original bug... --brion (talk) 22:39, 28 September 2009 (UTC)
It depends on the circumstance. There have been bots that move images to the commons. Im not sure why they arent active. However, bots should not resize images because the downscaling algorithms are not perfect and a human needs to make sure that the resized image is ok.Tim1357 (talk) 01:41, 28 September 2009 (UTC)
An admin should be checking re-sized images anyway, in order to delete the old versions. Surely the fail rate is low enough for bots to be of use in the actual slow re-sizing. OrangeDog (talk • edits) 01:46, 28 September 2009 (UTC)
Bot requests to do actual resizing have always been controversial for some reason; what if the bot gets it wrong? What if the image is actually free because of something like {{PD-textlogo}}? The move to Commons backlog does need human review, but I don't see why there isn't some "approved for bot move" template that could be added by trusted users. –Drilnoth (T • C • L) 02:14, 28 September 2009 (UTC)
I belive Wikipedia:Bots/Requests for approval/NeuRobot 2 is the most recent BRFA for an image-resizing bot, the commentary there may be enlightening. In that case, it seems that it wound up being approved as more of a script-assisted task (i.e. Neurolysis would review each resized image before uploading). Anomie⚔04:35, 28 September 2009 (UTC)
Not really; yes, the bot can check for that, but it can't determine whether or not its all accurate. There are plenty of valid images with missing information, but just as many copyvios that have all of them filled out. –Drilnoth (T • C • L) 02:14, 28 September 2009 (UTC)
(Not in direct reply to anyone.) To clarify the copy to commons bits, you can presently human check an article and mark it for transfer (by bot) to commons using CommonsHelper or, through that interface, do it yourself with reasonably little fuss. If you wanted "human checked" articles, a better bet than that category would be to look at the transclusions of {{Move to Commons}}, which are added by hand. There are also a few legacy bot categories - most notably JohnBot II - containing images which have been checked by hand but were never moved because the bot ceased to function. Due to the very recent updates, virtually all commons-related processes stopped working for a while (most are now working again), but in the long term, thanks to those updates the whole thing is going to become a great deal easier for everyone - perhaps so easy that we could (if we wanted to) decide to move all applicable images to commons en masse. - Jarry1250[ In the UK? Sign the petition! ]16:00, 28 September 2009 (UTC)
Display problem
I'm not sure if this is a problem with my computer or a Wiki problem. Under preferences I was using the Modern appearance setting and I noticed a display problem on the SS Eastland page. The lower half of the Infobox wouldn't display however the text was aligned like the infobox was still there. When I switched to Beta everything looked ok. Shinerunner(talk)10:18, 28 September 2009 (UTC)
Internet Explorer version 8 I believe. Operating system is Windows XP Professional service pack 3 and the display adapter is Nvidia Quadro4 750XGL. The display settings are 32 bit for color quality and 1024 by 768 screen resolution. Shinerunner(talk)12:01, 28 September 2009 (UTC)
Somewhere (I'm not sure where), someone implemented something to prevent the error message generated by MediaWiki for articles that contain references, but don't contain a reflist, from appearing when the article isn't in article space. This doesn't work completely: if you change your interface language on English Wikipedia to anything but English, the big red error messages show up. Talk:Selena Gomez is an example: with my interface language set to Dutch, I get "Citefout: De tag <ref> bestaat, maar de tag <references/> is niet aangetroffen" in great big red letters. Set it to English, and the message goes away.—Kww(talk) 15:59, 28 September 2009 (UTC)
This is done by changing a MediaWiki interface message. These are language specific, so for any language other than english (including british english), those changes are not visible. See for a list of the cite interface messages, this check. —TheDJ (talk • contribs) 17:32, 28 September 2009 (UTC)
I knew those messages existed, but never realized how they came into play. Since the language setting only affects messages, I'm not sure why you would want anything other than English on en.wiki. ---— Gadget850 (Ed)talk22:31, 28 September 2009 (UTC)
And it looks like if we start fiddling with the Dutch messages, then the Dutch Wikipedia would see those changes. I don't think I want to go there without a lot of cross-wiki discussion. ---— Gadget850 (Ed)talk22:40, 28 September 2009 (UTC)
System messages can be changed either globally, in the Mediawiki software, or locally, by changing appropriate Mediawiki: namespace pages. So we could change the dutch messages locally on en.wikipedia if for some reason we wanted to. Algebraist22:44, 28 September 2009 (UTC)
For those like me who had not yet heard. Brion is joiningStatusNet and will thus be leaving his current day job as CTO of the Wikimedia Foundation. He will not leave the community, but clearly he will have a lot less time for Mediawiki software work in the future. I congratulate Brion for taking a new step in his life and career and I hope he will continue to be a strong pillar for our community. We have a lot to thank Brion for, he has shaped much of the technology that we as editors and of course the readers, use on a daily basis. And he has done so on the smallest budget and with the highest personal commitment of any top 10 website CTO I gather. Thank you Brion. —TheDJ (talk • contribs) 21:14, 28 September 2009 (UTC)
This is the end of an era. Thanks, Brion, for keeping the motor running all this time. I hope your next project is as great a success as this one has been. Will Bebacktalk10:06, 29 September 2009 (UTC)
I just saw the notice a couple hours ago. At least he isn't fully gone,but he will be hard to replace. I never had personal interaction with brion, but I've seen his fingerprints, and as someone working on a decent sized IT project, I have sympathy for what you've put up with. Good Luck with your new venture, and I hope we can fill your shoes.SPhilbrickT20:16, 29 September 2009 (UTC)
The last couple of times when I have moved a page with the "Move subpages (up to 100), if applicable" option checked, I have got an error message. In both cases, the move of the root page succeeded but the subpages did not move. The exact error message was:
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "MovePageForm::moveToNewTitle". Database returned error "1062: Duplicate entry '10-ITN_talk' for key 2 (10.0.6.26)".
Unfortunately you cannot simply compare Special:Version and revisions linked on mediazilla anymore since WMF projects are now running on a separate "wmf" branch (note 1.16alpha-wmf in version name). This question gets aske over and over (I asked it myself on mediazilla), so maybe someone can add this information at least to WP:Bugzilla... — AlexSm15:20, 29 September 2009 (UTC)
Yeah, we had an extra bogus database listed in the system which confused the central user account system after we removed it. Trimming it from the database lists got things happy again. --brion (talk) 17:08, 30 September 2009 (UTC)
Edit not appearing in page history
{{resolved}}This didn't appear in the page history (note: link will be dead as soon as another edit is made to my talk page)... any ideas as to what is going on? –Drilnoth (T • C • L) 17:53, 2 October 2009 (UTC)
17:49, 2 October 2009 Drilnoth (talk | contribs | block) (6,527 bytes) (→Grosse Point Light and Chicago Harbor Light: Re)
12:31, 2 October 2009 7&6=thirteen (talk | contribs | block) (6,335 bytes) (Grosse Point Light and Chicago Harbor Light)
(edit conflict) It is now (for me), although I have had this same problem before myself. My guess is that this was just due to the lag, and the job queue. I find either purging or a null edit manages to update these kinds of things (or just waiting until Wikipeda updates automatically). Best, - Kingpin13 (talk) 18:00, 2 October 2009 (UTC)
(ec) I hadn't, but it is there now. Weird; I've never had to clear my cache to view recent edits in the page history before. Thanks! b–Drilnoth (T • C • L) 18:02, 2 October 2009 (UTC)
Dead Link Tag Bot
Hello,
I asked this a few days ago on the IRC, but I don't think i got an answer. I was wondering if anybody knew about a bot that goes around, finds dead links, and tags them. I know some bots do this as a secondary function (User:WebCiteBOT). However, I was want to find a bot with this task as its primary function.
There's is weblinkchecker.py which is used on the German Wikipedia. And their is also Checklinks tools (developed by me) which stores the dead links on the Toolserver, it allows users automatically tag links. I, however, feel that we should be spamming suggesting sites to not change their directory scheme every few month and more importantly provide information how to use three-hundred redirection and how to detect on using tools to detect dead links. — Dispenser16:46, 29 September 2009 (UTC)
I know about all of those, I was looking for a script that adds the dead link template directly in the article. I know CHECKLINKS does this, I want sure about Weblinkchecker.py, i know it does something on the talk page. Tim1357 (talk) 22:24, 29 September 2009 (UTC)
Firefox 3.5.3 problems
I've lost all the top menus - login/my talk, etc, and the tabbed menu. Thus Groans of the Britons starts with:
Groans of the Britons
An unassessed article from Wikipedia, the free encyclopedia
Jump to: navigation, search
Doh! I've cleared my Firefox cache, that did the trick. Maybe setting it to 30mb instead of 50mb will stop it from happening again. Or buying more memory (if Crucial makes it to fit my brain). Dougweller (talk) 05:12, 30 September 2009 (UTC)
I don't know what you mean exactly but in my opinion, we should first enable the passive part, to have time to get used to the system and have enough reviewers, so as to be ready when we enable the active, opt-in part. Also, if we have only the active part for the trial, we won't be able to see how they work together, yet both would be needed in an implementation, as they have different and complementary purposes, one local protection, the other global monitoring. Cenarium (talk) 17:54, 23 September 2009 (UTC)
Not sure what you mean by "passive part"; there'd be noting to show on pages that haven't had flagged mode enabled on them. --brion (talk) 23:58, 24 September 2009 (UTC)
By passive part, I mean 'patrolled revisions', reviewers can review any article, no sysop is required to enable this, but there is no precedence, so it's just for monitoring, kind of enhanced patrolled edits; there would be indeed nothing to show, it would be silent. Cenarium (talk) 16:13, 26 September 2009 (UTC)
In general, this page should be created and edited by (insert Anon IP)
So, I went to move a {{SharedIP}} 'plate from my talk page to my user page, as technically I use a static IP, and I get this message:
Unauthorized
Wikipedia does not have a user page with this exact title. In general, this page should be created and edited by User:209.6.238.201.
But, actually, anon IP's currently cannot create their own User page, AFAICT. So, "in general" I'd be happy to create it, but specifically, I can't.
Can some technocrat either fix the language of the internal template or fix the reality? I don't think I have a strong preference either way, but I'm pretty sure a year or two ago I could actually create my own user page and did so on previous IP accounts (which is especially handy when you have multiple IPs you want to declare, lest WP:SOCK accusations appear). Maybe this has been an issue with spammers or vandalism, I don't know, but the language is obviously out of whack. -- 209.6.238.201 (talk) 08:00, 29 September 2009 (UTC)
Anons haven't been able to create subjectspace pages since 5 Dec 2005, I believe. So since then you won't have been able to create your user page.
This situation can't be changed without a change to the software settings. There is T18642 open which requests that the restriction be lifted for non-article namespaces.
The message could probably be changed. I'm not sure which parser functions work in the interface (not many I think) but a {{lc:{{PAGENAME}}}}={{uc:{{PAGENAME}}}} check could possibly be used to detect when a page is an IP's user page and change the message accordingly.
There are many people whose usernames have no Latin letters, such as User:172 and people with unicode usernames, so the above code would have some nasty side effects. Graham8714:36, 29 September 2009 (UTC)
OK, thanks for looking into this, Martin. I expect the wording could be changed without worrying about parsing if only IP editors will see this, excepting some rare deleted/protected user pages for which it's not really important that someone else should be "creat[ing] and edit[ing]" it. I guess the message, were an IP to accidentally try to start someone-else's User page, is meant to sound nice about saying no. Anyway, I just thought it was an interesting oddity. -- 209.6.238.201 (talk) 00:10, 30 September 2009 (UTC)
Hopefully someone here will tell us where this message is held and then we can think about how it can be improved. — Martin (MSGJ · talk) 15:10, 30 September 2009 (UTC)
Not sure if this is the right place or not, but is the edit notice:
Please note
When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit our Sandbox instead.
Please post only encyclopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view.
Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.
Any text that you did not write yourself (apart from brief citations) must be available under terms consistent with Wikipedia's Terms of Use before you use it.
If you do not want your writing to be edited, read or redistributed by other people, then do not submit it here.
new or larger than it was before? Or is it in a different place? I've had to shrink my edit window by 10 lines (down from 40 lines) in order to be able to see the "Insert"/"Wiki markup"/etc. section when editing (and I use that a lot). — Bellhalla (talk) 16:40, 29 September 2009 (UTC)
I suspect that including any script which is hosted off WP would be a huge security risk and would be intentionally blocked by the interface. 706:17, 30 September 2009 (UTC)
That assumption is incorrect. Scripts can be loaded from any place (as allowed by the HTML standard) and responsibility lies thus with the author of the local .js file. —TheDJ (talk • contribs) 09:01, 30 September 2009 (UTC)
ImportScriptURI(url) is a JavaScript function that you can call from another JavaScript code. I don't know about a way to add JavaScript code to Wikipedia page that would work for all users, not just you, other than changing MediaWiki:Common.js which is exteremely unlikely to be accepted for this. Svick (talk) 19:40, 30 September 2009 (UTC)
If you do find a way to add javascript for all users (besides being an admin and editing MediaWiki-namespace pages such as MediaWiki:Common.js, of course), please report it to security@mediawiki.org. Anomie⚔12:26, 1 October 2009 (UTC)
Switch?
{{resolved}}
I'm obviously missing something in the usage of #switch. Probably pretty basic, since this is my first effort at a template. A simplified form of my template is at User:Kww/charttemplate, and, as you can see from the expansion at User talk:Kww/charttest, the parser doesn't even seem to recognize that I'm trying to use the switch control structure.—Kww(talk) 21:38, 4 October 2009 (UTC)
Now I'm wholly confused. Is the parser parsing the #switch after it has done things like link inclusion? Not before? Ouch. That's going to make my actual target output of
The problem in the code you gave now is that the parser can't know whether you mean "table |" or "#switch |". Fortunately, you can do this by using {{!}} instead of "table |". Svick (talk) 22:26, 4 October 2009 (UTC)
OK, I'm much closer now. Macro is at User:Kww/charttemplate2, test expansion is at User talk:Kww/charttemplate2. Serious problem, though: the contents of the references are being processed before the variables have been substituted, which defeats the purpose of the macro. Any way to change that order?—Kww(talk) 23:23, 4 October 2009 (UTC)
{{resolved}}
in a box, is it possible to change the size of an image?? for instance: please have a look at ("my") Chelo’s Burden: when you click to get the image file, you can see it's smaller than the one shown in the box and i would get it like this (145x188) + i tried to add |120px but it does not work + Template talk:Infobox comic book title does not comment --- thanks in advance kernitoutalk08:26, 5 October 2009 (UTC)
Quite often when I edit a fully protected page I receive, after a long delay, the Wikimedia Foundation Error notice. The edit always succeeds but the browser does not reload the page. I use Firefox 3.5. I was just wondering if this happened to anyone else? The technical output of the most recent occurence is below.
Request: POST http://en.wikipedia.org/w/index.php?title=Template:WikiProjectBannerShell&action=submit, from xxx.xxx.xxx.xxx via knsq23.knams.wikimedia.org (squid/2.7.STABLE6) to 91.198.174.39 (91.198.174.39)
Error: ERR_READ_TIMEOUT, errno [No Error] at Wed, 30 Sep 2009 17:55:13 GMT
The xxx bit is my IP address, hidden by me. Thanks in advance. — Martin (MSGJ · talk) 18:00, 30 September 2009 (UTC)
Is it possible that magic words (like lc:) might be returning stuff in ascii when the rest of wikimedia is using UTF8? Or anything similar to that scenario? RichFarmbrough, 20:36, 1 October 2009 (UTC).
Yes, possible. I know that PAGENAME behaves a little strangely with punctuation marks. For example
Lists arent indented very much and lists of lists with many subsections can be difficult to read. Is there any way to increase the indentation for a particular list? Lemmiwinks2 (talk) 01:18, 2 October 2009 (UTC)
You can't use wikitext list to do this, and have to use HTML and inline CSS. E.g:
<ul><li>
foo
<ulstyle="margin-left: 5em"><li>
bar
<ul><li>baz</li></ul></li></ul></li></ul>
foo
bar
baz
Note that the second level list has bigger indentation, but the third has default. You have to set it for every <ul> (or <ol> for ordered list). But make sure this is necessary, because it lowers readability of the page source for other editors. Svick (talk) 20:41, 2 October 2009 (UTC)
You can do a lot with WP lists but not alway what you expect
Part of the default thumbnail issue above stems from the technical limitation of not being able to use percentage widths for images. It should not be a big problem to automatically scale thumbnails widths to a certain percentage of the article width automatically. This would make the default widths independent of browser window sizes and zoom factors.
Therefore, I hereby officially propose to create and add such a rescaling script to the site JavaScript. E.g., the default relative rescaling width could then be specified as ~16% for the 180px user preference default. Adjustments can then be done by changing the preferences pixel width as usual. For users without scripting support the old pixel-based width would still work without change.
As for the finer implementation details, the script should run before image fetching because we neither want to let the browser to blow up the fetched images (because it would lead to artifacts) nor would we like to load different resolutions from the server for the same page (maybe this needs some server-side help). To keep the server-side image scaling and caching at the current resource level, the script would scale image sizes in the current steps of resolution (e.g. 180px, 220px...) Rescaling the browser window would either not change the width (to preserve the resolution - exactly as for the current implementation of fixed image withs) or would rescale (with possible artifacts) and then load larger sized images through a background server request (browser window resizing does not happen very often, so this would not have a noticeable effect on network traffic). Cacycle (talk) 02:29, 2 October 2009 (UTC)
Images are resized server-side on-demand, and that demand is dictated by the server-side MediaWiki code running on the cluster's Apache servers. The images are stored in obfuscated file directories and links are resolved internally as the page is rendered. You cannot use JavaScript to demand an image in an arbitrary size because 1) the image will not exist in the desired size until an Apache server has requested it in the 'normal' fashion, and 2) even if the image does exist, the JavaScript will not be able to find it unless it is told by an Apache where the image in that particular size is located. Neither of these problems are insurmountable, but they only scratch the surface of the problems with percentage-scaling of images, and raise the question: what advantages would percentage-scaling offer that are so bounteous as to justify all this effort? Happy‑melon15:37, 2 October 2009 (UTC)
Actually, those would mostly be easy to bypass. The directory is based on md5 hash of the filename; it doesn't change for different thumbnail sizes and there's no actual randomness. If an image doesn't exist at a request size, it will be automatically generated (see transformVia404 in mw:Manual:$wgLocalFileRepo). The main problems I can see are:
Small images. The server will not scale images larger than their actual size. If MediaWiki determines that the requested size is larger than the actual size, it puts the full image in the page and lets the browser scale it. But it will refuse to thumbnail it. This seems like it could cause problems for percentage widths where JS doesn't know the original image size.
Is it actually possible to run code after you know what images are on the page, but before the images are loaded?
Is it possible to determine the actual window size, or are we just going to get the screen resolution (does that work in every browser?) and assume people are using a full window?
if someone is using a mobile browser, but not the mobile site, will images even be usable? The iPhone has a 320×480 screen, so an image set at 16% is going to be at most 76px wide.Can you tell what this is without looking at the image name or clicking? I can't.
1. This might need a server-side software change so that the server send the original size image instead which would be displayed without browser rescaling. I do not think that this would break or interefere with any existing application. Alternatively, it might be possible to catch that error message and to dynamically load the unscaled image.
2. Yes, that is possible, the <script> tag must be in the header for that so that the code is executed immediately before page rendering. We might need some polling code that checks the incoming page code (?) and this might need some more detailed testing to figure out if it is possible to be faster than the requests and/or if the requests are somehow canceled by changing the url. Does anybody know more about this?
3. It is no problem in JavaScript to get the window size in px and all we want to do is to scale the images px-wise relative to the window (or the content element).
4 Since this is a JavaScript approach we can build in any intelligence and special-case handling it needs to work for every imaginable possible situation.
LiquidThreads is a next-generation discussion system for MediaWiki, which turns talk pages into a real forum, while maintaining the essential aspects of a wiki that make them so effective. It was originally developed as a Google Summer of Code project by David McCabe, and I've spent the last 4 months preparing it for deployment on Wikimedia sites, under contract from the Foundation.
Presently, we're waiting for the labs project to become relatively stable, and have all the features we need. Once that's been done, we will commence a staged roll-out of LiquidThreads on various Wikimedia sites. It should be noted that LiquidThreads has a mode in which it can be switched on or off per-page. My intention is to activate it on this site in that mode, and allow users to discuss pages that would benefit from the enhanced discussion management (I'm thinking of high-traffic noticeboards and discussion pages). Once it's been rolled out and people are familiar with it, we can think about the possibility of turning it on for all discussion pages.
LiquidThreads is very much a work in progress, and your feedback is essential for it to get to a point at which we can deploy it on this wiki. Please do send any and all constructive feedback to the feedback page on the test wiki, and I will do my best to accommodate it.
I'm very excited about the opportunity to bring this technology to Wikipedia, and to give our discussion pages a long-needed overhaul. — Werdna • talk09:16, 2 October 2009 (UTC)
If it means no more edit conflicts any more, then I'm all for. (Is any work being done in your labs on getting alphabetical order working? It's just that, well, this software is being used for dictionaries and encyclopedias and things, and it still thinks that AB comes before Aa...)--Kotniski (talk) 10:21, 2 October 2009 (UTC)
To little fanfare, the usability folks (who are, I suspect, either brewing an official announcement, or too modest to announce it) have deployed their latest usability improvements to English Wikipedia, code-named "Babaco".
The new improvements are:
Navigable TOC The "Navigable Table of Contents", a pane to the right of the edit window in which you can easily jump from section to section. (Activate in the "Editing" tab of preferences).
Content generation Content generation systems, which streamline common content generation, such as inserting links and tables. Also adds a powerful new search and replace system. Available for all users with the experimental editing toolbar activated.
Sounds great, but (another moan this time): is there some reason this sort of thing is not announced publicly via top-of-page or top-of-watchlist messages? Or perhaps it will be?--Kotniski (talk) 10:42, 2 October 2009 (UTC)
Why does this only appear when I am editing but not when I am browsing? When I edit, I edit one section, and so the "navigation" is somewhat trivial. — Carl (CBM · talk) 12:07, 2 October 2009 (UTC)
We already have a TOC for reading. This new editing-TOC will be best for newbies, who will often hit "edit" at the top of the page and go looking for the section they want. In a long article, that's useful even for veteran editors if there's a long article with problems across multiple sections. {{Nihiltres|talk|edits}} 13:03, 2 October 2009 (UTC)
The 'Enable enhanced editing toolbar' only works if wikEd is disabled—they seem to be incompatible. 'Enable help for adding advanced wiki text' does not seem to have any effect. 'Enable navigable table of contents' does not work for me. I tried several skins, but do not see any 'Navigable table'. Ruslik_Zero13:28, 2 October 2009 (UTC)
Unable to reproduce on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3. — neuro14:07, 3 October 2009 (UTC)
This may be the same problem I had: the announcement made me think this would be visible at all times, but it is only visible during editing. — Carl (CBM · talk) 14:13, 3 October 2009 (UTC)
I love thoses features.
Still, I wish there was a TOC on the right when browsing long pages. I use the TOC to find the section I want to read, then I may want to use the TOC again, to find another section I would like to read. I am obliged to return to the top of the page, and return to the article afterwards, and so on and so forth. A navigable TOC always on the right would be really helpful. Dodoïste (talk) 14:28, 3 October 2009 (UTC)
The 'Enable navigable table of contents' does not work for me either - there's just a black space to the right of the (narrower) edit window (IE 8.0.6001.18702, Windows XP).Nigel Ish (talk) 14:23, 3 October 2009 (UTC)
It does not work with IE 8.0 on Vista. Though I would say it's only normal to have bug with IE and people should stop using an outdated browser. It is working fine on Opera 10 and 9.64. Dodoïste (talk) 14:36, 3 October 2009 (UTC)
This is weird. My contributions say that an edit I made is not at the top of the page, when it clearly is. Checked 3 times, cleared cache each time, still the same.
Quite a number of revisions of United Parcel Service seem to have vanished. The problem starts about Jan 2005 and runs at least up to May 2005. The edit summaries are present, but the actual text of the revision (and correspondingly, the diffs) are missing. Is this something that can be solved, and if so, to whom and where should it be mentioned? 128.54.68.114 (talk) (really, User:JesseW/not logged in) 01:30, 3 October 2009 (UTC)
Resolved
[[|]]
United States", whose image contains the unwanted alt text "Flag of the United States.svg".
Moved to Wikipedia:Help desk
Unresolved
![[14]](https://en.wikipedia.org/w/index.php?title=File:01123.jpg&redirect=no){kind=link}
