Wikipedia:Village pump (technical) Information & Wikipedia:Village pump (technical) Links at HealthHaven.com
advertise
add site
services
publishers
database
health videos
Bookmark and Share

search wiki for    ?
web dir firms image gallery news pdf wiki shop video 
about
toolbar
stats
live show
health store
more stuff
JOIN/LOGIN
Featured Results:
Alaris Pump s, Alaris Pump s, Alaris, Alaris, Pump Systems, Syringe,...
Alaris Pumps, Alaris Pumps, Alaris, Alaris, Pump Systems, Syringe,...
coast2coastmedical.com
 Tube Feeding Pump s - Enteral Feeding Pump s - Discount Feeding Pump s -...
Tube Feeding Pumps - Enteral Feeding Pumps - Discount Feeding Pumps -...
allegromedical.com
 TECHNICAL DATA IQUE PUMP S & HOT TUB SPA CONTROL SYSTEM Hot Tubs Outdoor...
TECHNICAL DATA IQUE PUMPS & HOT TUB SPA CONTROL SYSTEM Hot Tubs Outdoor...
iquehottubs.com
 
Village pumps: PolicyTechnicalProposals (persistent)Miscellaneous
Skip to: Table of contents | First discussion | Bottom of page
Centralized discussion
Treffpunkt.svg
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.
archive • talk • edit • history • watch
e · h · w · Stock post message.svg To-do:

Contents


[edit] Add link to search help

(For previous discussion, see #Search page above.) We have now established which MediaWiki pages needs to be edited in order to ensure that the search results page contains a link to the help on searching (Wikipedia:Searching), so I've proposed doing it. I'd have thought this was a no-brainer, but there seems to be doubt, so please indicate if you support or oppose the idea. Namely that before the line that says either "There is a page named X on Wikipedia" or "You may create the page X but consider checking the search results", there should be a line that says "For full information on available Search options, see Wikipedia:Searching." (It pretty much has to go in that position; well it could go below the other line, I suppose.)--Kotniski (talk) 14:39, 31 October 2009 (UTC)

  • Support own proposal; completely obvious that there should be such a link, otherwise casual searchers have no obvious way of finding out about the sophisticated(ish) search functionality that we have.--Kotniski (talk) 14:39, 31 October 2009 (UTC)
  • Neutral - as I said, I don't think it is impossible for people to find help on searching, because it is exactly where one would expect it - among help pages on Help:Contents. But if you do add a help link, please keep the wording as short as possible. --rainman (talk) 12:38, 1 November 2009 (UTC)

I'm not convinced, based on that page being way too unfriendly to the average user. It's a shopping basket of everything related to searching; it doesn't highlight key things and hide complexity. It's too big and too technical. And some people are opposed to making these messages any longer than absolutely necessary. I'd rather use extra text for a link (on MediaWiki:Searchmenu-new) to the Article Wizard, but that change was rejected a month ago [1]. If a friendly Search help page existed, that would be different. Rd232 talk 14:46, 31 October 2009 (UTC)

You seem to be confusing two things: the other change was for one of the two messages to be made longer; this is to add another message above it. (I'd be happy to see the other change made too, but the two issues are not connected.) And if the help page isn't perfect, then having a link to it will have the other positive effect of getting more eyes on it and more people making improvements. Somehow it isn't penetrating my brain how anyone for an instant could oppose this change; it's one of the most obvious things I've ever had to ask an admin to do.--Kotniski (talk) 15:02, 31 October 2009 (UTC)
  • Support. But I would suggest Help:Searching as a better link, this page is more pertinent to the search button - as always needs a little attention. Failing that we could create and link to a dedicated help page. I would also suggest al we need is the a wikilink called 'help' next to the search button. Lee∴V (talkcontribs) 17:27, 2 November 2009 (UTC)
Yes, that would certainly be even more useful, but would probably involve huge discussion and then waiting years for the developers to change something (though I've asked for it at bug 21391http://bugzilla.wikimedia.org/show_bug.cgi?id=21391, just in case), whereas this proposal can be done now. I'm not sure that Help:Searching is better, since it doesn't seem to be up-to-date documentation, but it doesn't matter - that page can always be updated with the new information. (As I've suggested, the technical documentation could be at the MediaWiki site like most of the software documentation, then we could just have a single user-friendly help page on en.wp.)--Kotniski (talk) 18:23, 2 November 2009 (UTC)
Help:Searching should be merged into Wikipedia:Searching (or vice-versa), having two pages makes if harder for readers to know where to look for the best/more relevant info and it's more difficult to maintain. I'm not sure if the sections on External search engines, Browser-specific help and Searching with TomeRaider need to be there, it makes the page too big imo and isn't very useful globally, moreover it's the kind of things that grow constantly; they could be spun off. Cenarium (talk) 18:57, 2 November 2009 (UTC)
I just had a bash at tidying up 'help:searching' and after cutting out the chuff it really doesn't cover much if anything extra to the WP:searching, Agree that a merge is required - or just basically Move WP version over to help:. Also agree to seperating external searches to another page. I'll setup the merge request and then the move once that's done. I also have a merge proposal for 'Help:Go button' as it is very short and would add context. Note: not really bothered where the help link is, just that one is there somewhere !Lee∴V (talkcontribs) 19:10, 2 November 2009 (UTC)
Good, we should wait to have all this sorted out before linking it. Cenarium (talk) 18:45, 3 November 2009 (UTC)
  • As it's mostly unneeded, it may be too obtrusive if placed there, though a well-placed discrete link could be useful, but it'd require developer intervention. It should be possible to add a link in the advanced form of the interface, though, even when no search has been entered, (e.g. in the empty space below Check: All None.) Cenarium (talk) 18:57, 2 November 2009 (UTC)
I'm not sure what this refers to - what is "mostly unneeded", and where is "there"? (If you mean the link in the place that I'm proposing, then I disagree strongly - help on using a function is surely very needed by many people using that function, and there has to be a very transparently accessible link - ideally on the original search box AND on the search results page, but certainly in at least ONE of those places, and my proposed solution seems to be the only one we can implement ourselves without waiting months or years for the devs to change something - of course when they do, we can change our thing as well.)--Kotniski (talk) 08:30, 3 November 2009 (UTC)
If we put it at the top of MediaWiki:Searchmenu-new; readers will less likely read what follows, 'there is a page...'/'you may create...'; it would be too prominent for a link we need not all the time. I'd prefer a discrete link similar to what we have for Special:Contributions. I think we can do this with css. Cenarium (talk) 18:45, 3 November 2009 (UTC)
OK, how do you propose doing it? (But I don't think this link is any less needed than the message that follows - link to help on the function the reader's using is surely much more likely to be needed than the incidental message about creating a page, or the even more incidental message that there is a page of that title which the reader can see at the start of the search results anyway. It's those messages that need to be discrete, not the link that millions of readers might actually want to use.)--Kotniski (talk) 18:52, 3 November 2009 (UTC)
Well, I'm not sure. I've asked Rainman. Cenarium (talk) 18:58, 5 November 2009 (UTC)
Requested at bug 21391http://bugzilla.wikimedia.org/show_bug.cgi?id=21391. It has been assigned to the usability team. Cenarium (talk) 21:51, 8 November 2009 (UTC)

OK, so while that goes through the mechanisms, is there any remaining objection to my original proposal to add the link to the MediaWiki pages that we can edit? (The change is easily reversible once the devs come up with something better, but since that could take literally years, we have to do something to give readers the link in the meantime, and my suggestion seems to be all we can do at present.) --Kotniski (talk) 16:06, 9 November 2009 (UTC)

Well, in the absence of any objections, I'm renewing the edit requests at MediaWiki talk:Searchmenu-new and MediaWiki talk:Searchmenu-exists.--Kotniski (talk) 12:09, 11 November 2009 (UTC)
I still think it is unnecessary and too long, and makes the average user (again remember he just wants to find stuff, not to ponder on advanced ways of searching) another line of text to distract him... --rainman (talk) 12:17, 11 November 2009 (UTC)
Well if you can help (as a developer) get the help link placed somewhere more appropriate, as discussed then that would be great. But for now, this is the only solution we have (and I don't think anyone wants to suppress this link completely - that would be ridiculous).--Kotniski (talk) 12:24, 11 November 2009 (UTC)
In fact if anything's distracting and unnecessary, it's the line that says "there is a page on Wikipedia called..." Doesn't that page automatically show up at the top of the search results anyway? (If not then it should.)--Kotniski (talk) 12:26, 11 November 2009 (UTC)
Well I agree... but it was put there by usability people because, well, the exact match is not *always* the first hit (especially on default mediawiki install) and it amends to UI consistency, so that the user knows to expect an article creation link in that place when the article doesn't exist.. Which I guess is fair enough... --rainman (talk) 12:43, 11 November 2009 (UTC)

I don't object to the link in principle, but I think the target page needs to be improved first. It needs to be better organised, friendlier, and more focussed. It needs illustrative images too. Rd232 talk 12:43, 11 November 2009 (UTC)

Another reason for including the link, then - more eyes on the page means more potential improvers. (But I don't think the current version is so bad that we have to be embarrassed about it.)--Kotniski (talk) 13:14, 11 November 2009 (UTC)

Look, is anyone actually seriously opposing this, like to the extent that they think it would make things worse, not just that it wouldn't make things as good as they might ideally be? I consider it tantamount to vandalism to deprive users of the information they need on how to use a software function - it's still absolutely unbelievable to me that this wasn't simply done when first proposed. Just what are you guys hoping to achieve? If a help page has to be perfect before we link to it, then we'd never link to any of them.--Kotniski (talk) 17:59, 11 November 2009 (UTC)

For what it's worth, I support this proposal. — Martin (MSGJ · talk) 18:16, 11 November 2009 (UTC)
I've added bug 21391http://bugzilla.wikimedia.org/show_bug.cgi?id=21391 to WP:DevMemo. I think that's a better solution. But I suppose this will do in the mean time, and as Kotniski said, linking it prominently will make it more likely it gets improved. It really needs improving though - I'd do a complete rewrite and try and make it more like the WP:Tutorial perhaps. Rd232 talk 18:42, 11 November 2009 (UTC)

We should go ahead with the merge and split discussed at Wikipedia_talk:Searching#Merging.2C_renaming_and_splitting, before adding it - so it's stable. As for the link, can we add it through MediaWiki:Searchmenu-new and MediaWiki:Searchmenu-exists in the form of coordinates ? There's a bug in display for the help link at Special:Contributions in vector style and on IE which could happen here too. Cenarium (talk) 01:39, 12 November 2009 (UTC)

I don't understand - the proposal is just to add an ordinary sentence of text - why would doing it in the form of coordinates avoid any bug? More likely it would cause bugs.--Kotniski (talk) 11:29, 12 November 2009 (UTC)
I've been unclear: I inquire if we would have a bug if the link were added in coordinates there. I believe as before that the initial suggestion would make the amount of text too important between the search box and the search results, and that the "there is a page named.../you may create the page..." is important enough to not be removed. Cenarium (talk) 02:58, 14 November 2009 (UTC)

[edit] Script to convert wikitables to CSV?

Are there any scripts (browser or software) that will convert wikitables to CSV files? Thanks. SharkD (talk) 06:10, 6 November 2009 (UTC)

Copy table from browser, paste table into Excel, save excel file as CSV. Happymelon 07:48, 6 November 2009 (UTC)
You usually end up with a bunch of formatting junk when you do this. SharkD (talk) 15:32, 6 November 2009 (UTC)
Not if you are viewing the table in your browser. You have to do a Paste Special and select Text. You aren't trying to copy the markup are you? ---— Gadget850 (Ed) talk 15:37, 6 November 2009 (UTC)
I know what he means, links are still linked, bold is still bold, etc. To get round that, copy from Excel, paste into notepad, copy back from notepad and back into Excel: notepad discards all formatting but Excel still recognises the cell separations when it's pasted back in again; notepad's great for stripping formatting from anything. Sounds time-consuming, but actually it's the work of a few seconds to do Ctrl-A/C, over to notepad, Ctrl-A/V/A/C, back to Excel, Ctrl-V. Happymelon 14:21, 9 November 2009 (UTC)
In Excel, instead of a normal paste you need to do a special paste as text; this way you get rid of all the formatting. -- Codicorumus  « msg 18:26, 9 November 2009 (UTC)
It still doesn't get rid of the extra spaces that sometimes appear. SharkD (talk) 03:02, 12 November 2009 (UTC)
 while (<>){    s/\|\|/,/g;    if (/\|-/ || /\|}/){}    else {       s/^\|/;       print;    } } 

Fiddle until it works. Rich Farmbrough, 22:40, 15 November 2009 (UTC).

[edit] Category:Redirects

Yes, it exists... It's unsustainable though, so there's no real point in having it... except if the category is automatically added by the software. This seems possible, since it's done for example with Category:Noindexed pages. But it should be only for redirects in mainspace; or there should be a category of redirects for each namespace. So, do you think we should request this at bugzilla, for the mainspace at least ? Cenarium (talk) 00:02, 9 November 2009 (UTC)

I think a new special page (Special:Allredirects) or just a checkbox on Special:Allpages would be better. Mr.Z-man 03:51, 9 November 2009 (UTC)
Why do we need this at all? It seems to be categorization for categorization's sake (and a special page would be equally pointless, as far as I can see). But if people have some use for it, then the special page seems more in line with what the software normally does than an automatically generated category.--Kotniski (talk) 07:52, 9 November 2009 (UTC)
I personally don't see the point of such a category, too; though I expect some people might find it useful since it's been created. Special:Allpages should definitely have a way to exclude redirects, and also exclude non-redirects. Cenarium (talk) 18:55, 9 November 2009 (UTC)
One of the purposes is to keep track of the different kinds of redirects, including Category:Unprintworthy redirects, Category:Protected redirects and Category:Wikipedia soft redirects, all important information to have. Also, as far as I can tell, it is well-maintained. It is automatically populating the root category that would be unmanageable and of no use. OrangeDog (τε) 20:16, 9 November 2009 (UTC)
The category page even states that the category contains only categories and pages about redirects, and should not contain any redirects themselves. But 953 of the 1046 pages in the category at the moment are redirects. I could easily enough run a bot over the category to remove "[[Category:Redirects]]" from all those redirects and then repeat periodically to keep it clean, if there's consensus to do that. Anomie 22:08, 9 November 2009 (UTC)
Well, I'd be in favour.--Kotniski (talk) 09:42, 10 November 2009 (UTC)
They should be removed regardless of an an automatic categorization, manually it's untenable. Cenarium (talk) 04:28, 11 November 2009 (UTC)
I nominated for deletion the stunning Category:Uncategorized redirects. Cenarium (talk) 00:38, 15 November 2009 (UTC)

I have found some advantages in an automatic categorization of redirects though: we can see recent changes to redirects, on the category page it provides a link for new/inexperienced users who are often confused by them, and if bug 18596http://bugzilla.wikimedia.org/show_bug.cgi?id=18596 is resolved, we'll be able to know if a page is a redirect in the interface (so editnotice for redirects, useful for new users). Cenarium (talk) 04:28, 11 November 2009 (UTC)

So in light of this, shouldn't we request this ? Cenarium (forever) 16:25, 13 November 2009 (UTC)

OK some categories of redirects are useful - "with possibilities" is the one that springs to mind. Therefore screening all redirects to see if they are in that category is also useful. The use of an "uncategorized category" is a way to do that, as is maybe the category "redirects". Rich Farmbrough, 21:50, 15 November 2009 (UTC).

You well know that no bot would be approved by BAG to add Category:Uncategorized redirects to millions of redirects, so what's the point of having one with only a few thousands of redirects ? When bots add a category, they should check the database directly (and it doesn't really matter if the redirect has another category or not). Categories like 'with possibilities' (I agree it can be useful) can only be added by humans on a case by case basis, when you stumble across the redirect, it would be a daunting work to screen the category for them.
However, as I said, I would be in favor to make the software automatically add Category:Redirects to mainspace redirects (the category about redirects could be renamed 'Redirects on Wikipedia'. Because then, we can see recent changes to redirects, the category link is handy to help confused new user, with bug 18596http://bugzilla.wikimedia.org/show_bug.cgi?id=18596, we'll be able to know (at least in the interface) if a page is a redirect, and I suppose it can help bots and automated scripts. Cenarium (talk) 22:10, 15 November 2009 (UTC)
This remark is probably a bit late, but we have a Special:ListRedirects. Intelligentsium 00:31, 17 November 2009 (UTC)
This is fine but it doesn't give the advantages a category would (though it has others, too). Cenarium (talk) 16:27, 20 November 2009 (UTC)
Shouldn't this category be named Category:Wikipedia Redirects (since it contains pages about redirects, clearly a project related category) ? —Preceding unsigned comment added by 76.66.197.2 (talk) 04:25, 21 November 2009 (UTC)

[edit] Need big auto-move in CAT:SVG

Hi, all images in Category:Other images that should be in SVG format with the {{Non-free logo}} tag should be moved to Category:Fairuse images that should be in SVG format. I guess a bot is needed. This would really help the categorization. --Beao 14:52, 12 November 2009 (UTC)

Yes check.svg Done.
Well.. doing... Rich Farmbrough, 22:42, 15 November 2009 (UTC).

[edit] Bugs in categorization (still)

As I mentioned before, {{FormattingError}} can add pages to Cat:Pages with incorrect formatting templates use. However, I have been seeing a lot of random category assignments; I recently fixed all of them using null edits and made sure the category was empty. 5 minutes later I check again and many pages are added back to the category without any change to them in the mean time. This sounds like a bug in MediaWiki, but I have no idea what to file - I can find no reason for this behavior. Anybody know what's causing this or what I should put in a bug report? Thanks!     — SkyLined (talk) 16:57, 13 November 2009 (UTC)

  • It's not a bug, it's just a caching issue. You can force a reload on your end (if you're using FF, for example, simply pres [ctrl-shift-R] in order to force a page reload). The server should re-cache most pages when you try to edit them, so the null edit ought to have taken care of the potential server side issues.
    V = I * R (talk to Ω) 17:09, 13 November 2009 (UTC)

Unfortunately, that cannot be true: if this is a caching issue, one would expect a page to remain in a in a category after it has been removed from it. By refreshing/null edits/purge you could fix that. However, in this case the page is actually out of the category at one point and 5 minutes later it is back in the category, without there being any reason for it to be in it...    — SkyLined (talk) 00:11, 14 November 2009 (UTC)

Yes, this is looking weird. This query shows timestamps of yesterday around 16:50 for all of the pages in that category - does that mean the system did some kind of automated repopulation at around that time, and used out-of-date data for it?--Kotniski (talk) 10:50, 14 November 2009 (UTC)
(I've just done a null edit on Alpha particle, which successfully removed it both on the category page and in the results of the above query. Let's see how long it takes to reappear.)--Kotniski (talk) 10:57, 14 November 2009 (UTC)
Interesting... the theory that some sort of batch job may be changing things is probably a good one. I'm not exactly sure how to check on that, but I'm fairly sure that whatever it is would be on the toolserver. I have no clue what we'd look for, however.
V = I * R (talk to Ω) 11:28, 14 November 2009 (UTC)
I suspect it's something to do with the job queue, but I've no idea what to look for either.--Kotniski (talk) 11:57, 14 November 2009 (UTC)

Update - someone just made some unrelated edits to Foot-pound (energy), and that caused the page to disappear from the category (as expected). But the weird thing I've noticed is that User:Kathryn NicDhàna/Admin Toolbox has popped up on the category page a couple of times, then disappeared again, despite not having been edited recently. (Unfortunately that page won't load for me, so I don't know if it ought to be in this category or not.) --Kotniski (talk) 15:50, 14 November 2009 (UTC)

Now User:Pigman/Admin toolbox is doing it. I think I'm starting to believe in ghosts...--Kotniski (talk) 15:55, 14 November 2009 (UTC)
Yesterday I had May 10 and March 22 absent from Category:Days of the year. All very odd. Rich Farmbrough, 23:59, 15 November 2009 (UTC).
This all sounds like we have a hard-to-track down bug in the categorization of pages. Does anybody know who might be able to help track down the cause, file a bug, and/or get it fixed? Thanks!     — SkyLined (talk) 11:03, 16 November 2009 (UTC)

[edit] Mysterious added <p> in multiline <div>

This code:

 <div>a b c d</div> 

generates this HTML:

 <div>a <p>b c</p> d</div> 

Is there a reason for the added <p>, enclosing everything except the first and the last line? If the <p> wasn't there, it would solve some problems in Template:Navbox. Svick (talk) 22:38, 13 November 2009 (UTC)

The "<p>" is the equivalent of hitting "return". XHTML does not recognize manual line breaks (i.e., added by the use of the "return" button). Intelligentsium 23:54, 13 November 2009 (UTC)
The question, presumably, is why line breaks 1 and 3 cause the parser to open and close a paragraph element but line break 2 doesn't. Chris Cunningham (not at work) - talk 23:59, 13 November 2009 (UTC)
In wikicode, one line line break shouldn't create a new pargraph. Normally, you have to use two line breaks to crate a new paragraph (<p>). Svick (talk) 03:41, 15 November 2009 (UTC)
Wiki div tags have been a pet peeve of mine for awhile. It's not the linebreak that causes the p, it's the div; the linebreak is just a placeholder, so the paragraph markup will be placed at the 1st and last linebreak in the div. It would look less weird if you put the line breaks immediately after the div tag. To suppress it entirely, you'd need to change the div to something like <span style=display:block> which is just an ordinary html tag, without special wiki handling like div has. -Steve Sanbeg (talk) 23:02, 17 November 2009 (UTC)
Why does <div> have this very strange special handling? Svick (talk) 23:32, 17 November 2009 (UTC)

[edit] New Subpages

It would be very useful to have a way to see all new subpages of a given page. It could be used to see new XFDs, RFAs, Wikipedia books, spam bot reports, SPIs, portal subpages, articles for creation, etc. I don't believe we have a way to get new subpages ? If not, I'll fill a bug pointing here, for a special page Special:NewSubpages, or a way to filter Special:NewPages. Cenarium (talk) 01:24, 14 November 2009 (UTC)

Also peer review, WP:FAC, WP:FPC, WP:BRFA, etc. Cenarium (talk) 04:33, 14 November 2009 (UTC)
I don't know about some of those, but as for XfDs, PR, FAC, BRFA, RFA, and SPIs, new subpages of those are all transcluded on the main page, so there's already an easy way to see all the new subpages. rʨanaɢ talk/contribs 05:53, 14 November 2009 (UTC)
When they are transcluded, some are not (created by new users, oversight, etc). Orphan XFDs, RFAs and such are regularly deleted. Besides this, it's an alternative way to find new ones. Some of those (WPbooks, AFCs) are specifically categorized (except accident), but portal subpages, bot reports are not, so we have no way to find new ones. Cenarium (talk) 16:49, 14 November 2009 (UTC)

To add a Subpages link in the toolbox, add this to your JS:

 addOnloadHook( function () {   addPortletLink("p-tb", wgServer+wgArticlePath.replace("$1", "Special:PrefixIndex/"+wgPageName+"/"), "Subpages", "t-subpages", "See all subpages of this page"); }); 

---— Gadget850 (Ed) talk 13:20, 14 November 2009 (UTC)

I know how to see subpages, I do it all the time. What I mean is new subpages of a given page, a way to filter Special:Newpages to subpages of a given page. Similarly, it would be nice to have a way to filter recent changes for subpages of a given page. Cenarium (talk) 16:49, 14 November 2009 (UTC)
You can just sort a list like this by pageid parameter. Higher pageids are newer pages. As a generator you can also do some fun tricks with it (probably). --Splarka (rant) 08:20, 15 November 2009 (UTC)

[edit] How to keep nested <div> tags from messing with one another?

In things like

 <div style="something"> bla bla bla  bla bla bla bla <div style="something else">stuff stuff</div>  bla bla bla</div> 

the first closing </div> tag seems to close both of them. See, for example, this AfD close, where the div tags within a {{quote}} template caused the archiving (<div class="boilerplate metadata afd vfd xfd-closed" style="background-color: #F3F9FF; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px solid #AAAAAA;">) to close early—if you scroll down a ways, you can see that the nice blue box ends rather suddenly. Is there a way to stop div tags from behaving in this way?

(For a short-term fix on this particular page, I just changed the quote template to a <blockquote>. But it would be nice to be able to fix the problem instead of avoiding it.) rʨanaɢ talk/contribs 04:20, 14 November 2009 (UTC)

Mayhaps your problem is the same as that which I addressed at Wikisource:Wikisource:Scriptorium/Archives/2008-12#div needs to go on a separate line. Hesperian 04:58, 14 November 2009 (UTC)
I saw something like that on bugzilla, too.... in {{quote}}, putting the div on its own line seems to correct that problem, to an extent, but it introduces a new one (it makes the <blockquote> within that template stop working), so I don't know how feasible it is.
For what it's worth, the only reason that template has divs in it is to allow multiline blockquotes (without a need to type <br/> or <p>. But that might be more of a big deal than this one div issue, so I don't know if it's worth removing them just for that. rʨanaɢ talk/contribs 05:07, 14 November 2009 (UTC)
I think the problem in this case is that the opening <div> is at a different level of ":"-indentation from the </div>. That generates raw HTML tag soup something like <div><dl><dd><div>.....</dd></dl></div>; note how the </div> highlighted in blue is outside of the block that its matching <div> is inside. Tidy fixes by inserting an extra </div> (highlighted in red) as <div><dl><dd><div>.....</div></dd></dl></div>. But this leaves the </div> highlighted in blue to incorrectly close the archiving box. Anomie 00:49, 15 November 2009 (UTC)

[edit] Change in "Save page" behavior

When editing a section on the daily TfD pages, one used to be returned to said section after clicking save. Recently, however, clicking save returns you to the top of the page. Is this an intentional change? If so, why? Or am I missing something? JPG-GR (talk) 05:34, 14 November 2009 (UTC)

Just made a change to Template:Tfd2 that should fix this for future nominations. — RockMFR 12:40, 14 November 2009 (UTC)

[edit] ads not shown without javascript?

Is there a reason why ads are not shown when javascript is disabled? --87.78.20.139 (talk) 17:04, 14 November 2009 (UTC)

Yes. If they were simply embedded in the HTML, then varying the ads would interfere with the server-side caching of pages, which would be unacceptable. So Javascript is used to insert the ads as an alternative. Dragons flight (talk) 19:32, 14 November 2009 (UTC)
What ads? We don't have ads. OrangeDog (τε) 16:16, 16 November 2009 (UTC)
I think they meant ads for the "Wikipedia Forever" fundraiser. Svick (talk) 16:44, 16 November 2009 (UTC)
Urch. I wouldn't complain about them not displaying. For reference, disabling them in your preferences is probably more convenient than turning off JavaScript. OrangeDog (τε) 17:15, 16 November 2009 (UTC)

[edit] What's up with upload?

Is there some sort of trial system in operation at Special:Upload? There is loose code – "<fogg-for_improved_uplods><fogg-please_install>" – on the main page, trying to upload connects you to some prototype subdomain and gives you a progress bar entitled "<mwe-upload-in-progress>", stuck at 0%. Could someone fix this absolute joke of a usability initiative, or at least explain it? Thanks,  Skomorokh, barbarian  19:57, 14 November 2009 (UTC)

I don't see anything like that there right now. Maybe it was fixed? Svick (talk) 03:56, 15 November 2009 (UTC)
I tried a purge and upload and it worked fine. Can you take a screen shot next time? MBisanz talk 08:22, 15 November 2009 (UTC)
Skomorokh, were you using Safari or Chrome ? —TheDJ (talkcontribs) 15:30, 16 November 2009 (UTC)
I'll bet that's the case. I see loose code in Chrome all the time. Webkit needs to get its act together. --King Öomie 22:09, 19 November 2009 (UTC)

[edit] Infobox Template Coherence Proposal

proposal wiki page: RFC draft

Following the discussion at WP:VPT#DBpedia_Template_Annotations, an RFC draft for the topic was created. Please edit and/or comment on the page. We took the discussion input into account and tried to address the issues mentioned (apologies for our initial errors and the problems caused by them). We also made the page mostly self-contained such that everyone can comment without needing to read the entire discussion leading up to the RFC. The user Rd232 suggested to create a new thread here, since the old one has passed the WP:TLDR point and the RFC justifies creating a new one. We hope for a fruitful discussion and finally consensus on the proposal. Jens Lehmann (talk) 08:40, 15 November 2009 (UTC)

  • Given that there doesn't seem to be a particularly high awareness of the semantic web among wikipedians, I suspect that appropriate examples, (including pointers to third party semantic reuse?) in the template documentation are going to be very useful in getting people on board with these kinds of changes.Stuartyeates (talk) 06:07, 16 November 2009 (UTC)
We included some pointers in the demonstration of benefits section. Most significant semantic reuse happens in the background of third party tools (Open Calais, Muddy Boots, Faviki, Zemanta, LODr, Topbraid composer). --Jens Lehmann (talk) 11:12, 16 November 2009 (UTC)
That's exactly what I mean, Jens Lehmann. If templates have links (if necessary to third parties) with the data from that actauly template being reused, then it will help people see the point of the changes. Stuartyeates (talk) 00:35, 18 November 2009 (UTC)
I agree with you and technically it would be simple to generate two or three template-specific links, which show how the information in it is actually used. The problem is more a policy/political one. Some users argued against pointing to something not hosted on wikipedia.org or an officially related project. It could be seen as promotion of the "external" project (be it DBpedia or any other application using the information). I believe there is/was also interest in deploying DBpedia or DBpedia applications on the Wikimedia toolserver (which could be considered as strongly related, since it is run by the German Wikimedia with assistance from the Wikimedia Foundation). But even then, an application would probably contain a logo or project name, so each template would be at risk to be deleted as spam. What can be done in the short term, however, is to add a link from each template to a documentation page describing the template (the RFC could be seen as the starting point for such a page), such that users can read the page to find out more. That's not as good as having links specifically for a particular template, but a good compromise. --Jens Lehmann (talk) 09:02, 19 November 2009 (UTC)
Is the problem 'pointing to something not hosted on wikipedia.org or an officially related project' or is it 'being perceived as recommending one third party over another'? If it's the latter, we resolve this the same way we did with ISBN etc: we make a special page that takes as an arguments the page name and wikipedia namespace and gives pointers to the representation of this page each each of a set of third parties. Stuartyeates (talk) 19:31, 19 November 2009 (UTC)

[edit] Simple skin has no links to the disclaimers

Hi all. I've been using the Simple Skin on my BlackBerry Storm because navigation is easier with it than with Monobook on the device. At today's New York City Meetup someone was discussing the standard disclaimers - when I tried to show an example of how the disclaimer's linked to from every page I realized that there are no links to the disclaimer in the Simple skin. I am hoping someone could rectify that and maybe see if the issue exists with any of the other skins? Thanks! —Elipongo (Talk contribs) 05:59, 16 November 2009 (UTC)

Hi again. Could someone please address this? Not having links to our site disclaimers would seem to be a potential liability problem to me. —Elipongo (Talk contribs) 00:24, 20 November 2009 (UTC)
I assume they were left out for "simplicity". However, their omission is a problem. Also a legal issue too - the copyright statement does not appear either. This looks like a non-Wikipedia-specific issue: I suggest you file a bug at Bugzilla. — This, that, and the other (talk) 06:31, 20 November 2009 (UTC)

[edit] Signature Overhaul

Hi all,

I've been doing some discussion on the LiquidThreads feedback page about the future of user signatures.

Here's a summary of the discussion to date:

Signature vandalism is difficult to trace and prevent in LiquidThreads. This is compounded by the fact that at present, when a user changes their signature, it propagates across all threads they have posted. A few solutions have been proposed:

  • Allowing administrators to reset and lock a user's signature.
  • Resetting a signature when a user is blocked.
  • Limiting the customisability of signatures.
  • Technically limiting signature content.
  • Removing the functionality whereby signatures are automatically updated.
    • Storing the signature in the wikitext.
    • Storing the signature separately.
At present, the final option is considered more sane, but further feedback is being sought.

I'd like to solicit further feedback from the community on where we want to go with regard to signatures. Please leave comments in the thread on the LiquidThreads wiki, to keep things central.

Werdna • talk 12:16, 16 November 2009 (UTC)

Apparently no one cares?  ;-) On reflection, it seems like a potentially interesting feature to allow people to update their signature (useful for user renames and similar things). So, I think I am in favor of option 1. Perhaps put the signature code in an user space page that is automatically protected the same way userspace CSS and JS is, that way it could be edited / locked by admins in addition to editing by the user himself. My second choice is option five (i.e. having things fixed as they are now). That is certainly a reasonable option that would avoid surprises. Dragons flight (talk) 00:50, 18 November 2009 (UTC)
I would support option one. Having a dynamic signature is a great feature, it greatly simplifies renames etc. Putting the signature in a userspace page would be a good option (the revisions would help keep track of admin and self-vandalism of the signature), but putting in a feature in which the page will not save it is over a certain length would be advisable. The only thing that annoys me about the signature being in the userspace is the name of the page could overwrite already existing userpages (what if user "Q" already has a page called User:Q/Signature). Perhaps implementing the signature page as Special:Signature/Username would be better. ~fl 09:11, 19 November 2009 (UTC)
  • PSST: "Please leave comments in the thread on the LiquidThreads wiki, to keep things central."
    V = I * R (talk to Ω) 10:13, 19 November 2009 (UTC)

[edit] Odd links

I've noticed a few odd links and can;t puzzle out where they come from. A good example is this - I can see nothing in the source pages that would cause these links. If anyone has a moment to check, I'd like to be sure I'm not just being dim please. - TB (talk) 16:18, 16 November 2009 (UTC)

I don't see any articles that link to Help talk:Cite messages. I made a slight mistake on 21 September that caused such a link, but it should be clear by now. Purge any page where you might see such a link. ---— Gadget850 (Ed) talk 16:45, 16 November 2009 (UTC)
And lo, the problem was fixed. The ways of mediawiki are weird and wonderful. Cheers. - TB (talk) 18:58, 16 November 2009 (UTC)

[edit] Help required (user account)

I need ur help people. There is a problem with my wikipedia account User:Brainlara73. i get logged in, it logged in, and suddenly when i open my wachlist or any other page of wikipiedia, it is logged off automatically. I think it has been hacked or any other problem. Please Help me out.

Thanks. Talha

--121.52.145.185 (talk) 19:23, 16 November 2009 (UTC)

See the tips at Help:Logging in. PrimeHunter (talk) 19:28, 16 November 2009 (UTC)
The problem is probably that you don't have cookies enabled. Intelligentsium 00:10, 17 November 2009 (UTC)
cookies are enabled, i think they are expired, due to change of date(once i changed and forgot to chaneg back), Now what to do?

--TalhaDiscuss © 11:43, 17 November 2009 (UTC)

above edit of mine was made from lab, User:Brainlara73. --121.52.145.177 (talk) 11:47, 17 November 2009 (UTC)

[edit] Suppression of admin actions in watchlists

(Forgive me if this has been addressed before; I'm not a regular on VP. I didn't find any similar discussions after a brief search.)

Is it technically feasible to add a gadget or script to allow users to filter out administrative actions (such as protection/unprotection, revision deletion/suppression, and the like) so that they do not display on a watchlist? I'm imagining a simple check box such as the ones used for ignoring minor revisions, bot revisions, and the like? When our *favorite* </sarcasm> long-term vandal runs amok on the admin noticeboards, I end up with a page full of deletions, something which I really don't care to know about. Creating a new toggle to ignore them would be appreciated. Horologium (talk) 22:43, 16 November 2009 (UTC)

This would be nice. I'd like to also be able to filter out specific users. In particular, I don't really need to see Edwardbot deliver the Signpost to the 30-40 talkpages I have watchlisted. --King Öomie 22:05, 19 November 2009 (UTC)
Bot actions actually shouldn't "pop" pages up on your watchlist though. Of course, the bot needs an actual bot flag...
V = I * R (talk to Ω) 22:51, 19 November 2009 (UTC)
They do if you don't exclude them. (I ordinarily keep watch over minor and bot edits, because they sometimes mask other vandalism (or, in the case of Sinebot, obscure talk page queries). Horologium (talk) 23:08, 19 November 2009 (UTC)
Well yea, but you have to actively turn the option on. The default is to hide bot edits.
V = I * R (talk to Ω) 00:16, 20 November 2009 (UTC)

[edit] RecentChangesLinked in MediaWiki API?

I looked, but didn't find Special:RecentChangesLinked in the API. Did I just miss it? Is there a way to query this through the API? Here's an example query using RecentChangesLinked. tedder (talk) 00:59, 17 November 2009 (UTC)

Reedy pointed me to bugzilla:14869. --MZMcBride (talk) 01:07, 17 November 2009 (UTC)
Somewhat helpful, though it doesn't mention RCL itself. I think it might be possible to do it using 'links' as a generator to 'recentchanges', but I have yet to get it working. tedder (talk) 01:14, 17 November 2009 (UTC)

[edit] 3.5 times faster preview

Some days ago I found a user script that is so fantastic that I just have to share this with everyone:

It gives you about 3.5 times faster edit preview. This is especially useful if you have a slow computer or a slow Internet connection, but it is a noticeable improvement even on faster computers. The script works in most web browsers, and the documentation for the script is at User:Js/ajaxPreview.

Personally I placed this code in my personal /monobook.js:

 /* Shows both "preview" and "changes" with Ajax,     much faster than standard preview/changes buttons.     [[User:Js/ajaxPreview]]   */ importScript("User:Js/ajaxPreview.js"); ajaxPreviewPos = 'bottom';  //Buttons on the bottom, replacing standard buttons. 

You can place the same code in your personal /monobook.js too. Then you need to wait one minute, and then bypass your browser cache for the change to take effect.

There are many other user scripts here at Wikipedia, but this is one of the nicest I have used and it seems virtually unknown by other editors.

--David Göthberg (talk) 17:57, 17 November 2009 (UTC)

Works wonderfully. And is less of a load on the servers! Marvelous. Thanks for the pointer. -- Quiddity (talk) 20:02, 17 November 2009 (UTC)
As a note. This will be incorporated by default in the upcoming LiquidThreads discussion system, and it is also being looked at for the new editor (There are some problems with it listed here). wikEd has a similar feature. —TheDJ (talkcontribs) 21:17, 17 November 2009 (UTC)
How does this code deal with redlink-checks and template transclusion? I take it that its operation is completely offline. --King Öomie 22:03, 19 November 2009 (UTC)
King Öomie: No, most of it is done by the servers. If I understand the code correctly: The script calls a Wikipedia server and sends the content of the edit window (the text that you are editing), the server renders that with templates and all and returns it, then the script cuts away the preview area and instead inserts what it got from the server. This means the server only has to render the content of your preview area, not the surrounding menus and not the edit window, and it means less HTML to send over the wire, and less HTML for your browser to render.
The Wikipedia servers have something called the MediaWiki API which scripts can call. It can do all kinds of nifty things, like returning the raw page code (the wikimarkup) for a page, or even some simple database queries. Many of the bots use the API for most of their work.
--David Göthberg (talk) 00:25, 20 November 2009 (UTC)

[edit] Is this possible in any way?

I've created an imagemap (with appropriate alt texts for the visually impaired / the stubborn users of computers that are 20 years behind the time) of a jurisdiction, Southern Ontario. The image shows the outlines of all 40 odd counties making up the province, and the imagemap links each of those counties. My question is, if I were to put text links to the right of this image (sort of as I have done in my sandbox), is it possible to have the appropriate text link highlight or go bold when the cursor is over the corresponding area of the imagemap?

I imagine its not as it would probably be some sort of Javascript, but wondering if perhaps parser functions could pull off dynamic webpages? - ʄɭoʏɗiaɲ τ ¢ 21:11, 17 November 2009 (UTC)

Something like this CSS or jquery ? The problem is that it requires central css or js I think for almost any of the implementations, and it's unlikely we will do that if it is only usable in the fewest of locations atm. —TheDJ (talkcontribs) 21:28, 17 November 2009 (UTC)
Sort of, except that instead of the imagemap itself highlighting or showing text, I want the text link that is to the right of the image to become bold. - ʄɭoʏɗiaɲ τ ¢ 17:03, 18 November 2009 (UTC)

[edit] Statitics of donations decreasing??

Hello. I've been keeping an eye on http://wikimediafoundation.org/wiki/Special:ContributionStatistics for several days now. And recently, the statistics for previous days began to decrease. For example, on 2009-11-13, it was about "112,000$", and now it's less than half of it. It is also decreasing for other days. Does anyone know why those statistics are unstable ? Thanks ! :-) Dodoïste (talk) 22:50, 17 November 2009 (UTC)

Hello. We are working on all our reporting data from the beginning of the Annual Fundraiser. We had two problems...one of which is mostly fixed and the other is close to being fixed. I am not technical enough to explain why there is a slow decrease in our donation totals over time...but it is an illusion. We'll be rebuilding the table shortly and will continue to verify results as they come in. Public reporting and transparency is important to us. Rand Montoya (talk) 00:14, 18 November 2009 (UTC)
Erik mentioned a problem with how the new credit card process software was recording amounts when the original currency was not US dollars. The $112k was totally bogus. Dragons flight (talk) 00:31, 18 November 2009 (UTC)
Agreed. Those have been fixed and updated in our system. When we update, those should show correctly. Rand Montoya (talk) 00:35, 18 November 2009 (UTC)
Thanks for the infos ! :-) Dodoïste (talk) 00:38, 18 November 2009 (UTC)

[edit] Readability and accessibilty of lists

Hello. I order to improve the readability when reading and editing as well, I often find lists in the following wikicode:

 *Book 1: Preludietto, Fughetta ed Esercizio...  *Book 2: Preludio, Fuga e Fuga figurata...  *Book 3: Giga, Bolero e Variazione... 

The result creates a space between each item in the list, making it easier to read compared to previous version. The problem is, MediWiki produces a HTML code that is not accessible (see Wikipedia:Accessibility#Lists and This explanation from Graham87):

 <ul> <li>Book 1: Preludietto, Fughetta ed Esercizio...</li> </ul> <ul> <li>Book 2: Preludio, Fuga e Fuga figurata...</li> </ul> <ul> <li>Book 3: Giga, Bolero e Variazione...</li> </ul> 

MediaWiki produces three different list of one item, instead of one list of three items. Instead, MediaWiki should produce:

 <ul> <li>Book 1: Preludietto, Fughetta ed Esercizio...</li> <li>Book 2: Preludio, Fuga e Fuga figurata...</li> <li>Book 3: Giga, Bolero e Variazione...</li> </ul> 

In order to improve readability, MediaWiki could add a class to the lists, and add margin-bottom: 5px in a style sheet. Do you think it's a good idea? Is it feasible? Yours, Dodoïste (talk) 01:14, 18 November 2009 (UTC)

I don't see how adding classes and margins solves the basic problem that these things that should be grouped as a single list aren't. How about instead we provide a filter that warns users when their edits are creating starred items with unnecessary blank lines between them? —David Eppstein (talk) 01:46, 18 November 2009 (UTC)
Ideally, cleanup of these problems with the HTML code should be done by HTML Tidy. Both the solutions above sound interesting, but an edit filter might scare off new users unless it's carefully worded. Graham87 03:07, 18 November 2009 (UTC)
The first examples ARE three lists, so the HTML is correct. I don't see how the Sanitizer (tidy is something else) would ever be able to tell the difference between the intentional and the unintentional case of two consecutive lists. We can't guard in the core between incorrect usage of wikicode. An editfilter I can see being useful, but that's it. —TheDJ (talkcontribs) 13:22, 18 November 2009 (UTC)
Does anyone want to create a template containing the appropriate code (along the lines of {{*mp}})? — This, that, and the other (talk) 07:02, 20 November 2009 (UTC)

Fairly simple to scan for occurrences of bullet lists separated by blank lines. Rich Farmbrough, 09:47, 20 November 2009 (UTC).

Well there are 106 thousand such lists. Some are bulleted prose, some are spaced lists, some are lists with breaks. Rich Farmbrough, 10:08, 20 November 2009 (UTC).

[edit] SVG not rendering properly using internal renderer?

Have a look at this svg: [3]. As rendered by the internal MediaWiki renderer, the text is completely jumbled. Just look at the text at the top left of the image, next to the (big) red circle and the (smaller) pink circle: it's incomprehensible. (FYI it should read "Site de construction" and "Site logistique", respectively.) Same is true for many other labels on this map (Cadiz, Pauillac etc.) The same problems are present with the (thumbnail) version on a page, as here. However, here's the thing: when I open the svg file itself, i.e. [4], on my Firefox (3.0) it renders perfectly! All the text is perfectly readable, including all accents on place names. So the problem appears to be not with the SVG file, but rather with the renderer used to turn SVG into PNG in your current MediaWiki setup. -- 89.52.176.229 (talk) 05:03, 18 November 2009 (UTC)

Interesting; I also have this problem. ╟─TreasuryTagdraftsman─╢ 07:02, 18 November 2009 (UTC)
Yes, we know, the SVG renderer is lousy at text. Dragons flight (talk) 07:30, 18 November 2009 (UTC)
The linked SVG uses font-family:Arial but that is not one of the available fonts on the Wikimedia servers. Could that be the problem? —David Eppstein (talk) 07:32, 18 November 2009 (UTC)
Using a supported font improves one's odds but there are still a range of ways that text can come out poorly even then. If one can't get things to work otherwise, we recommend converting text to outline shapes. Dragons flight (talk) 07:38, 18 November 2009 (UTC)
Maybe it's time to propose that Wikimedia hire a programmer to fix this? Or find someone in the free software community willing to do it. --Beao 07:48, 18 November 2009 (UTC)
It's not a Mediawiki problem. It's an issue with the linux RSVG utility. RSVG was the best renderer option (considered across several metrics of output quality and performance characteristics) at the time we last reviewed the options. Dragons flight (talk) 07:55, 18 November 2009 (UTC)
It is well known that librsvg is pretty awful in certain areas. It's a compromise solution. Maybe the original poster should just upload a PNG version for the time being. — This, that, and the other (talk) 06:57, 20 November 2009 (UTC)
Or just convert the text to a path, as has been suggested above... ╟─TreasuryTagdirectorate─╢ 07:01, 20 November 2009 (UTC)

[edit] Missing talk page section

I've puzzled over this quite long enough! At the bottom of my talk page should be a section, "Hubert Latham". Why is it that I can see it in the diffs ([5] [6]) and I can see it when I edit the page, but when I view just my talk page, the last section is missing? It was there before, but, since my last edit to it, it seems to have disappeared. Do I just need to wait for . . . something? Maedin\talk 07:55, 18 November 2009 (UTC)

Nevermind, it's back. Ho hum. Maedin\talk 07:55, 18 November 2009 (UTC)
If something like that happens again, try purging the article. --King Öomie 21:57, 19 November 2009 (UTC)

[edit] Tool server bug ?

Is this a bug? File:Editcounttoolserverbug.jpg Why is the percentage over 100% ? -- penubag  (talk) 09:57, 18 November 2009 (UTC)

Try reporting that here. — This, that, and the other (talk) 06:55, 20 November 2009 (UTC)

[edit] suffixes

Is there a way to search for the ends of titles? Sort of an opposite for Special:PrefixIndex... a Special:PostfixIndex or Special:SuffixIndex ?

 SELECT pagename FROM pagenametable pnt WHERE pnt.pagename LIKE '%suffix' 


Or something like that, if Wikimedia's DB doesn't use SQL

76.66.197.2 (talk) 12:23, 18 November 2009 (UTC)


Not with the Wikipedia search engine. You can search using prefix, intitle or incategory parameters; see Wikipedia:Searching. ---— Gadget850 (Ed) talk 16:10, 18 November 2009 (UTC)
This has been brought up numerous times without resolution. See mediazilla:10808 for reasons for and against. — This, that, and the other (talk) 06:52, 20 November 2009 (UTC)
It seems to boil down to (A) it's very easy to do ; (B) it takes a few hours to set up ; (C) no one is willing to build a second index to pages, since it's a string reversed version of the regular index. 76.66.197.2 (talk) 10:41, 20 November 2009 (UTC)

Is the search box regexp compatible? 76.66.197.2 (talk) 10:47, 20 November 2009 (UTC)

[edit] JPG image render error.

Joel Rudnick, third picture in the gallery. --Beao 15:39, 18 November 2009 (UTC)

The would be File:TheLeap.png, whic is a PNG file on Commons. What is the problem? ---— Gadget850 (Ed) talk 15:46, 18 November 2009 (UTC)
There are no JPGs in that article... OrangeDog (τε) 00:29, 19 November 2009 (UTC)

[edit] local interwiki map?

This may seem like a dumb question, but it is possible to define local interwiki prefixes without having to add them globally at m:interwiki map? --Ixfd64 (talk) 18:53, 18 November 2009 (UTC)

It's possible, by directly changing the databse, as documented at mw:Manual:Guide to setting up interwiki linking. I think that for Wikimedia wikis, only developers can directly write to the database, so adding the prefix to the global map would probably be a better solution. Svick (talk) 20:10, 18 November 2009 (UTC)

[edit] PDF

When I download an article as a PDF file, the infobox is always centered at the top of the article. Is there a way to change this so that the infobox is to the right of the lead as currently in articles? --William S. Saturn (talk) 19:41, 18 November 2009 (UTC)

No, tables are always fullwidth in PDF view atm. You can give feedback hereTheDJ (talkcontribs) 01:43, 19 November 2009 (UTC)

[edit] New usability features; how can I mess with them?

Some new usability features that I've seen in previews appear to now be live on the English Wikipedia, at least in the Vector skin. The "watch" item now appears to be a star icon, and remains out of the drop-down menu, and if the screen width is, or becomes, too low, tabs will migrate back into the drop-down menu where applicable to prevent tabs from overlapping.

I'm slightly miffed at the star appearance of the "watch" action, not least because I objected to it earlier. I'd like to restore the earlier appearance for this: is there anyone else who would feel the same way; is there a case for a Gadget, here? I'd presume that it's as simple as a short routine to change some classes around (technically, the tab still has the text "Watch" or "Unwatch") but I'm leery of interfering with the system there, as I'll explain below.

Second, is there someone who knows enough JavaScript to understand the workings of the migration script that moves tabs in and out of the menu? I've been selectively moving tabs out of the menu previously (e.g. if there is a deletion template on the page, the "Delete" item pops out for quick access) but this interferes slightly with the migration routine, and appears to cause a few errors or oddities (but fortunately no serious breakage yet), noticeably that ones that my scripting moves out don't move back into the menu (presumably because they don't have the "collapsible" class at any point). Can someone please give me advice on that front? I know some JavaScript, but I'm a newbie for most purposes. You can also check out User:Nihiltres/vector.js if you want to see the pile of flaming code that I'm using at the moment (need to clean that up properly sometime :/).

I sincerely appreciate the work of the Usability Initiative, though I admit a certain amount of frustration here. {{Nihiltres|talk|edits}} 21:45, 18 November 2009 (UTC)

I think the use of a star for watchlisting is particularly unfortunate because the encyclopedia has been using stars for years to designate featured articles. 99.191.75.22 (talk) 21:11, 19 November 2009 (UTC)
There's a star? Is that what the mysterious blank tab next to the drop-down menu is for? I browse with images set to "on demand", so any purely image-based UI elements are unlikely to show up for me. --Carnildo (talk) 22:15, 19 November 2009 (UTC)
A random star that already means other things instead of anything that might symbolise or contain the word "watch"... what are we paying these usability people for? OrangeDog (τε) 23:09, 19 November 2009 (UTC)
I agree, unless the symbol is common usage in everyday situations (like symbols for "play", "pause", "stop" on media players), any symbol should be accompanied by text. Mr.Z-man 23:32, 19 November 2009 (UTC)
That was the first thing that I thought about when I saw the star as well. I've been wondering why it's not a picture of an eye, myself.
V = I * R (talk to Ω) 00:17, 20 November 2009 (UTC)
Star means featured ... sigh... Rich Farmbrough, 10:11, 20 November 2009 (UTC).

[edit] Some progress…

I see that people seem to agree with my assessment that a star was a poor choice of symbol, among other things… but the most important part of my question is "how can I change the behaviour of those new features?". I still don't have a complete answer to that. The JS2 used doesn't help me muddle through, in particular. As far as I can tell, I can call a few useful things, $j.collapsibleTabs.moveToCollapsed and $j.collapsibleTabs.moveToExpanded in particular being useful. I found these here. However, these functions don't work on cases where I move a new tab from the menu, e.g. I move out the delete tab if the page contains a deletion template or is a redlinked redirect. This seems to be because these tabs a) don't have the appropriate classes, since the function shuffles around which tabs currently have the collapsible class on them, and b) don't have collapsible tab data assigned to them.

I can easily fix the classname issue in a kludgy manner, and it wouldn't be excessively hard to do it nicely, but I'm lost on how to assign the right data to tabs so that the script knows how to move them. Can anyone help, please? It would be particularly useful to see how the data gets assigned to certain tabs in the first place. {{Nihiltres|talk|edits}} 14:55, 20 November 2009 (UTC)

[edit] Main space right-aligned title elements broken again

With the fund-raiser banners disabled in my preferences, the geodata and FA star elements have fallen over the title line and into infoboxes, etc. See Death Valley National Park in FF 3.5.5 for an example of both. OrangeDog (τε) 01:37, 19 November 2009 (UTC)

as expected. each year the banners are different and we cannot account for that. It's minor as far as I'm concerned. Alternatively, you can use the new Beta which has a bit better support, though it breaks in some other cases again. —TheDJ (talkcontribs) 01:41, 19 November 2009 (UTC)
I know it's expected, but I thought adjusting them to compensate was high-priority in mainspace. Anyway, is there any reason we can't ask the devs for some proper support for adding things outside of article content, instead of the volatile js and css hacks we have to use everywhere? OrangeDog (τε) 20:19, 19 November 2009 (UTC)

[edit] Scripts are down

User:Splarka/dabfinder.js, User:Shubinator/DYKcheck.js, and User:Dr_pda/prosesizebytes.js have all stopped working at the same time, so are there any scripts that still work? I use the Flock browser and Windows XP, but it isn't just me. When I try any of them, instead of giving results they say:

You are looking at the HTML representation of the XML format.
HTML is good for debugging, but probably is not suitable for your application.
See complete documentation, or API help for more information.

<?xml version="1.0"?>
<api />
Art LaPella (talk) 03:21, 19 November 2009 (UTC)

Same thing with OptionText.js over at Wikisource. Hesperian 03:30, 19 November 2009 (UTC)
User:Dr_pda/prosesizebytes.js is working fine for me. It most likely is not a global problem. Intelligentsium 03:33, 19 November 2009 (UTC)
I have javascript problems too. At first it was only when loading my watchlist while logged in to my main account (my admin account). But now I get it also on some article pages, and when using my other account (normal user). I have tried to blank my personal /monobook.js and turn of all gadgets, then wait a minute and then purge my browser cache, and even restarted my browser, but nothing helps. I use Firefox 2.0 on WinME and I get this message: "A script on this page may be busy, or it may have stopped responding." I haven't tested yet if I get these problems with my other browsers and when not logged in. There have been some really slow image loading the last few hours, so my guess is that this is some server problem. Or perhaps the donation banners are acting up again? :))
--David Göthberg (talk) 03:56, 19 November 2009 (UTC)
(ec)When I tried to use my prosesize script just now (I'm using monobook, Firefox, Linux) I found the same error (after seeing the expected result for a fraction of a section). However the url of this error is http://en.wikipedia.org/w/api.php?action=clicktracking&eventid=leftnav-monobook-t-page-size&token=38312dac78eac92ae09e436918a715dd&redirectto=javascript%3AgetDocumentSize%28%29
thus it appears to be due to/related to the Click Tracking feature which I think is part of the Usability Initiative. See http://www.mediawiki.org/wiki/Extension:UsabilityInitiative and http://techblog.wikimedia.org/2009/10/click-tracking-on-edit-toolbar-deployed/ So it probably is a bigger issue than a few scripts not working for a few users. Dr pda (talk) 04:02, 19 November 2009 (UTC)
It's working for me on Safari and Firefox now that I have removed the banners by using my preferences...Ed (talkmajestic titan) 04:22, 19 November 2009 (UTC)
Disabling the donation banners doesn't help me. And as far as I have seen the click-tracking is only loaded for some users, and not all the time. Which is consistent with that only some users have problems with their javascript today. And the click-tracking is also new code. So I think Dr pda is right.
--David Göthberg (talk) 05:00, 19 November 2009 (UTC)
Yep, you're right; just tried it again and it does not work. —Ed (talkmajestic titan) 06:06, 19 November 2009 (UTC)

I think I have resolved this issue. In future, when reporting problems, please be more specific, including what script you were using, what you did, what happened, and what you expected to happen. — Werdna • talk 10:46, 19 November 2009 (UTC)

Yes, it's fixed for me, thank you. Sorry I wasn't more specific, but I don't know how to accommodate you (I listed 3 scripts, I listed what happened, and the only thing I know how to do with a script is to click the link.) Art LaPella (talk) 14:56, 19 November 2009 (UTC)

[edit] Who or how many users are watching an article?

I know this was discussed here. I was just wondering whether there are news about this. Can I find out who is watching a page, or at least how many? Tomeasy T C 10:33, 19 November 2009 (UTC)

The number of accounts watching a page is partially available. If you go to the page history of the page you are interested in, you will find a line of (currently four) "External tools" near the top of the history display. These tools reside on the toolserver and the second tool from the right provides a count for the number of page watchers. It should be noted that for pages with fewer than 30 watchers there is a default response that does not provide an exact count. --Allen3 talk 10:48, 19 November 2009 (UTC)
Thanks a lot. Tomeasy T C 11:24, 19 November 2009 (UTC)
See also - Centijimbos  7  11:46, 19 November 2009 (UTC)
Ah - I looked at how many people are watching my talk page. Bad move. Rich Farmbrough, 10:17, 20 November 2009 (UTC).

[edit] watchlist sections Reference desks

It seems to me there ought to be a way to watchlist sections on the Reference desks that one wishes to follow. It is cumbersome to check back and very easy to miss changes in such sections even though one has watchlisted the Reference desk itself. Bus stop (talk) 14:03, 19 November 2009 (UTC)

[edit] A Semantic Media Wiki

I know there exists already an extension for Mediawiki to include semantic information in wiki pages. However, I have thought about another approach which tries to get the most out of the semantic world and combine it with wiki functionality. I illustrated my idea in a PDF document semantic-media-wiki.

The document does not discuss in detail how wiki functionality is used in the application, because the idea is more focused on the establishment of semantic structures. However, OWL supports histories through annotations, so OWL (as a notation) can be used to describe the wiki content. —Preceding unsigned comment added by 134.245.253.141 (talk) 15:43, 19 November 2009 (UTC)

[edit] enwp.org

Hi Everyone, I'm wondering who the admin of enwp.org is, and if anyone knows, do you think you could please pass this suggestion along to them?

enwp.org/ is currently a shortcut for en.wikipedia.org/wiki/. I have an idea to create a php file or something in the root directory, called s, such that enwp.org/s/ would be a shortcut for http://en.wikipedia.org/wiki/Special:Search/.

What do people think of this? Anyone know who the admin is or how to get in touch?

Thanks! 75.10.154.66 (talk) 01:57, 20 November 2009 (UTC)

The owner of that domain is Thomas Kjoerberg from Sweden. More information about him, including e-mail, can be found here. The addresses in the form of http://enwp.org/something seem to be redirects to corresponding Wikipedia articles (in this case something), http://enwp.org/s/ redirects to non-existent article s/. Svick (talk) 02:28, 20 November 2009 (UTC)
Information on enwp can be found at User:Tl-lomas/enwp.org. Hesperian 02:46, 20 November 2009 (UTC)

[edit] Random page

Is there a way to link to a random page in a given category? Intelligentsium 03:21, 20 November 2009 (UTC)

Select "Show link to random page" in the Action box at http://toolserver.org/~erwin85/randomarticle.php. PrimeHunter (talk) 03:40, 20 November 2009 (UTC)

[edit] larticles not working

larticles is reporting a 500 Internal Server Error. Is this a known problem? John Vandenberg (chat) 12:05, 20 November 2009 (UTC)

It just opened ok, for me. In my experience this often happens when editing a .htaccess file. Since it's quite noticeable, whomever usually fixes it quickly. Cheers, Jack Merridew 12:29, 20 November 2009 (UTC)
Damn; then I tried to use it and it failed. Jack Merridew 12:31, 20 November 2009 (UTC)
Based on a little poking on toolserver, I think you will need to contact the tool maintainer (escaladix). — Carl (CBM · talk) 12:53, 20 November 2009 (UTC)

[edit] Is this a bug?

User:UselessatScrabble shows up in Category:Miscellaneous_pages_for_deletion because it transcludes a deleted template that was once nominated at MfD. Do deleted transclusions with categories always cause this, or is this a one off thing? Gigs (talk) 16:34, 20 November 2009 (UTC)

I am guessing this was a caching issue. I don't see it in the category right now. Plastikspork ―Œ(talk) 17:01, 20 November 2009 (UTC)
Two months to update? Heh. Oh well. Gigs (talk) 18:30, 20 November 2009 (UTC)

[edit] Print/export section in sidebar

I suggest that the items in the Print/export section on the left side are reordered. Printable version is most commonly used, so that should be first. Then Download as PDF and last Create a book. Especially the "Create a book" item is known to confuse users who are really looking for something else, often create a new article. Actually, I don't think such a specialized tool should be linked from the sidebar at all. --Apoc2400 (talk) 18:50, 20 November 2009 (UTC)

This requires a software change -> bugzilla:TheDJ (talkcontribs) 14:46, 21 November 2009 (UTC)
Why would Printable Version be the most used? It doesn't do what most readers think it does— see Help:Printable. ---— Gadget850 (Ed) talk 15:35, 21 November 2009 (UTC)
It could be done with sitewide javascript. That would be pretty ugly, though. Algebraist 19:01, 22 November 2009 (UTC)

[edit] Computing reference desk not scrolling down right

Yes check.svg Resolved.

After I post, I start out in the right place, but then the computer decides to scroll down, without any action from me, to somewhere that seems random.Vchimpanzee · talk · contributions · 20:48, 20 November 2009 (UTC)

This sounds like something your browser does with no control from Wikipedia, maybe if the browser gets confused by a large page still being downloaded after initially placing you in the right place. You may be able to get back to the right place by clicking in the browser address bar and press the Enter key. After editing a section, the address bar should contain the character '#' followed by the section heading (possibly encoded if it contains special characters). This tells your browser to place you add that anchor name on the page, like if you click in the table of contents. The MediaWiki software automatically places an anchor at each section heading. See Help:Section#Section linking. PrimeHunter (talk) 21:37, 20 November 2009 (UTC)
Let's see if that works.Vchimpanzee · talk · contributions · 22:09, 20 November 2009 (UTC)
It does. Thanks.Vchimpanzee · talk · contributions · 22:12, 20 November 2009 (UTC)

[edit] MediaWiki messages

We need a single place to announce discussions about MediaWiki messages, since the "MediaWiki talk:" pages are not watched much. If you are interested in this, see Wikipedia talk:MediaWiki#MediaWiki messages.

Oh, and please don't start a discussion here, instead follow that link.

--David Göthberg (talk) 00:18, 21 November 2009 (UTC)

Meanwhile, since the current practise says we should use the Village pump for this:
I would like to add a CSS id to MediaWiki:Youhavenewmessages, so we can handle it better in JavaScript. See discussion at MediaWiki talk:Youhavenewmessages#CSS id needed.
--David Göthberg (talk) 02:47, 21 November 2009 (UTC)

[edit] reloading old page after saving a new edit.

whenever i save a new edit it reloads the old version of the page. i have to hit 'reload' to get my new version. this has been happening for days. is it just me? i've recently upgraded xubuntu to the newest version. could that be it? Lemmiwinks2 (talk) 00:41, 21 November 2009 (UTC)

I just checked and page caching has been disabled all this time, so that cant be it. I just now re-enabled it. I'll see if that has any effect. (nope. its still doing it) Lemmiwinks2 (talk) 00:45, 21 November 2009 (UTC)

[edit] Problems with keeping login & unified login...

I have noticed that since about 3 days ago, I have been having trouble staying logged into WP and the Wikimedia Foundation projects. I have unified login set up, and it appears to log me in to the Wikimedia projects, but I have to go and manually log in anyway. If I right-click on the icons that show the status of your unified login & click "view image", the corresponding logo's site will respond with a logged-out page stating:

Automatic login
Token is invalid or has expired

The login works on the site I logged in on, but none of the other sites. This "half-login" state lasts only one session, and on one computer (I have Mozilla FF 3.5.5 with Mozilla Weave, shared between my home and school server account). Is there some reason my login is having "technical difficulties"? Hmmwhatsthisdo (talk) 01:08, 21 November 2009 (UTC)

Do you have cookies enabled? Intelligentsium 01:46, 21 November 2009 (UTC)
Believe so. Is there a certain meta site that also needs cookies allowed, different from all the other WM Foundation projects? Hmmwhatsthisdo (talk) 22:04, 21 November 2009 (UTC)
I've been seeing this too. I don't think that there's any real problem, per se. I'm guessing that someone has been (possibly unintentionally) resetting something that causes login cookies to expire. Best guess is that it has to do with technical aspects to the fundraising campaign.
V = I * R (talk to Ω) 22:11, 21 November 2009 (UTC)
Does yours throw back an error when attempting to view those images in the WP login page (the little icons for the other WM projects that are all lined up) standalone? Hmmwhatsthisdo (talk) 22:36, 21 November 2009 (UTC)

[edit] Regarding vandalism only accounts

How hard would it be to code and create a "nuclear" option for dealing with vandalism only accounts? That is to say, the blocking admin could hit a button and rollback all the user's edits in, say, articlespace, that are currently the lead edit, or all within a certain timeframe, etc. RayTalk 02:20, 21 November 2009 (UTC)

Using a tabbed browser, I can roll back 20 edits in a few seconds. Most vandalism-only accounts don't get that far. It's a bit tougher with move vandalism - maybe someone else has a quicker way to do that. Otherwise, it's not worth the trouble to create such a function. I'd rather time were spent developing a better way to spot vandals in the first place. Wknight94 talk 02:45, 21 November 2009 (UTC)
Also, there's a script called the 'Mass rollback function', written by John254 that can be added to your monobook that does this. Nja247 07:26, 24 November 2009 (UTC)
Note: Link to script. Nja247 09:46, 24 November 2009 (UTC)

[edit] November 2009 Great Britain and Ireland floods

Can anyone explain why the November 2009 Great Britain and Ireland floods article is apperaring in Category:Flood articles needing a picture? The article has pictures, and no doubt more will be added over the coming weeks, but it shouldn't be in the category anyway. Mjroots (talk) 17:55, 21 November 2009 (UTC)

The category is added by {{Infobox flood}}. PrimeHunter (talk) 18:02, 21 November 2009 (UTC)
Ah, so if there isn't an image in the infobox then it adds the cat, regardless of how many images are in the article itself then? Mjroots (talk) 19:14, 21 November 2009 (UTC)
Yes, but it probably shouldn't do that so I have removed it.[7] Subcats of Category:Wikipedia requested images are normally filled by manually adding a template to the talk page of an article. See also Wikipedia:Requested pictures. If such categories were intended for articles and not talk pages then the categories should be hidden. PrimeHunter (talk) 02:12, 22 November 2009 (UTC)

[edit] Add Google Analytics to Wikipedia

Wikipedia has the potential to provide incredible information about the way people use the internet. I think by implementing Google Analytics and making the information public, a whole new knowledge base would be available to the world. It would show what browsers are popular, their resolutions... any hundreds of other metrics that could help web designers and people all over the world.

I would happily volunteer my services and help create a free, open source website that people can use to access this information and present it in a way that's simple and user friendly.

Jpony (talk) 00:28, 22 November 2009 (UTC)

This page is for asking questions. You want the place for making proposals. Intelligentsium 00:36, 22 November 2009 (UTC)
Disregard the above. MediaWiki provides a function for tracking page hits; it is disabled on en.wikipedia for a reason. We have a function for pages hits already. Intelligentsium 00:39, 22 November 2009 (UTC)
Between http://stats.grok.se and http://stats.wikimedia.org/ we already make a huge amount of information available. It doesn't cover everything that Google Analytics does, but it could be expanded further. For example: browser stats, operating systems. However, Wikimedia won't be using Google's service. The managing Wikimedia Foundation considers that to be a violation of our pledge not to give personally identifiable data (in this case IP addresses) to any third party (e.g. Google). So whatever stats we have will mostly be internally developed. If you'd like to work on that effort User:Erik Zachte is the one leading it. Dragons flight (talk) 00:52, 22 November 2009 (UTC)
"However, Wikimedia won't be using Google's service." Thank god for small favors!
V = I * R (talk to Ω) 01:15, 22 November 2009 (UTC)

[edit] Why languages?

Why do we have Special:Preferences → Language? As far as I can tell, the language preference changes only the interface messages. For example, when you modify your CSS, the English message at MediaWiki:Usercsspreview is:

But the British English message at MediaWiki:Usercsspreview/en-gb is:

Remember that you are only previewing your user CSS.' It has not yet been saved!

This is because the English message has been customized, but the British English is the default. Another example: reference backlinks use a ^ in English, but a ↑ in British English or German or an other langaue. There are 6412 messages and 355 languages. Each language has been translated. So— if you select one of the German languages, you will see German interface messages mixed in the English content.

We frequently get issues where someone from the UK has selected British English and does not see the same messages as everyone else. Why would you want to select German so that in English articles, the edit link shows as [Bearbeiten]? Browse through the languages at Special:Allmessages. ---— Gadget850 (Ed) talk 02:58, 22 November 2009 (UTC)

I find the language preferences useful when I'm editing a non-English version of Wikipedia, so it's easier for me to use the interface. They probably help non-native speakers of English when editing the English Wikipedia. I agree with you that the situation with British English is not ideal at the moment. Graham87 03:37, 22 November 2009 (UTC)
As Graham87 said, when you visit a Wikipedia in a language you don't speak, then you'll understand how good it can be to set the preferences there to some language you understand. For instance, I sometimes add interwiki links in other Wikipedias, and sometimes I'm asked to come check some issue with some template I built that has been transferred to another Wikipedia. I don't speak Russian or Greek, and I don't even have the fonts needed to see text on the Japanese and Thai Wikipedias. And I know we have editors who come to us to fix interwiki links, in spite some of them not speaking English at all, since I have communicated with them. Ever tried to have a wiki conversation with a Portuguese or Arab user, by using some automatic translation service and cutting and pasting in the text to his talk page? Its pretty hilarious, but it works if both users really are interested in it.
And regarding choosing British English when one visits a US based website: Then one is asking for trouble and should learn better. (And I say this even though I myself prefer British English.) Why do we even have the British English option? Our articles are in mixed English.
By the way, I wish that one could have some global settings in the global account. I would like to use English as default on all Wikipedias, except some where I speak the language. And it is annoying that my email address gets auto-copied to all the other Wikipedias, but not the setting to disallow emails from other users.
--David Göthberg (talk) 11:12, 22 November 2009 (UTC)
Your last request is bugzilla:14950. Algebraist 12:50, 22 November 2009 (UTC)

[edit] move table of contents to very top of page

is there anything i could add to my css or js page that would cause the table of contents to go to the very top of the page rather than at the first subsection? i can get my own pages to do that by writing __NOTOC__ __TOC__ at the very top of the page. Lemmiwinks2 (talk) 05:39, 22 November 2009 (UTC)

I don't know, but if you do this globally on a page, it breaks accessibility for screen reader users. Graham87 07:42, 22 November 2009 (UTC)
Adding the following code to your user JS should work (tested in Vector):
 addOnloadHook(function() {  var toc = document.getElementById('toc');  var jumpToNav = document.getElementById('jump-to-nav');  var bodyContent = document.getElementById('bodyContent');  if (toc)   bodyContent.insertBefore(toc, jumpToNav); }); 
Svick (talk) 11:14, 22 November 2009 (UTC)
Thank you but when i inserted it into my monobook.js page it made the sidebar links (which due to hidepane.js is in my browser at the very top of the page) not work. I had to remove it. The reason i want this is because i have made my toc float to the right and it sometimes is pushed very far down the page by infoboxes and stuff. Lemmiwinks2 (talk) 19:11, 22 November 2009 (UTC)
The code broke other scripts (like hidepane.js) on pages that don't have TOC, I changed the code above, so you can try it again. I hope it works this time. Svick (talk) 22:52, 23 November 2009 (UTC)

[edit] Collaborating all ones efforts together

Archival retrievalPtw007 (talk) 12:40, 22 November 2009 (UTC)

I'm sorry? Intelligentsium 00:40, 23 November 2009 (UTC)

[edit] France's Concert Records

Hello. I created the page for France's Concert Records. When you try to search for it, it does not come up directly. Also, when I try to put it with a link on my user page, it stays red and does not link. In both cases, it provides a "you may create the page" option. Thanks. Paradise coyote (talk) 18:48, 22 November 2009 (UTC)

You created the article at France’s Concert Records, with a closing quotation mark rather than an apostrophe. I've moved the article to France's Concert Records for you. Gavia immer (talk) 18:57, 22 November 2009 (UTC)

Thanks.Paradise coyote (talk) 23:22, 22 November 2009 (UTC)

[edit] db14 is replagging?

For at least the last few days I've looked [8], db14 looks to be an enemy of en:wiki. The lags bounce up into the 30's and it almost always shows some lag. I realize this is not the best place to discuss WMF server ops, but if anyone's in the data centre, could they check if there's smoke coming out? :) Franamax (talk) 01:59, 23 November 2009 (UTC)

Resolved at #wikimedia-tech. Probably a failed battery in the RAID array. Workaround is in place and maxlag is back to its normal behaviour. Franamax (talk) 02:47, 24 November 2009 (UTC)

[edit] Bug: IE5 displays anchors incorrectly

Anchors (<A> Content </A>) in Wikipedia articles are not being displayed correctly in my browser (Microsoft Internet Explorer Version 5.00.2314.100 running under Windows 95 Version 4.00.950 B).

Instead of displaying the content of an anchor inline where the anchor occurs, the content is displayed right-justified on the following line. The content of multiple anchors that occur left-to-right in a line are displayed on the following line right-to-left in reverse order. The individual words in the content of any anchor are not reversed.

The same problem affects the printable version of a Wikipedia page as well as the menus on the left side of a page and the instructions on the Village Pump page that I'm using now.

This problem started in the last few weeks.

This makes it really difficult to understand articles.

Thanks for quickly fixing the other bug that I reported a few months ago regarding incorrect HTML formatting under IE5.

Bill Park —Preceding unsigned comment added by 207.69.248.244 (talk) 02:44, 23 November 2009 (UTC)

I don't believe we use anchor tags in our articles; unless you mean something different? Intelligentsium 02:51, 23 November 2009 (UTC)
Our articles use a great many anchor tags. They're the standard way of making hyperlinks in HTML. Algebraist 02:54, 23 November 2009 (UTC)
Oh, yes of course; I had misunderstood. I thought the OP meant directly in the articles, as one would link or bold text (but we don't use <a href="..."></a>). To the OP: Your IE seems a bit outdated (IE8 is the most recent now, isn't it?). Intelligentsium 03:24, 23 November 2009 (UTC)
This is most likely due to the odd behavior of IE5 in parsing css. It will treat ">" the same as "," (the IE5 css engine predates child selectors). So a rule like div.somethingspecific > a {display:block;} will be parsed as div.somethingspecific , a {display:block;}, which then will apply to all anchor tags. This happened just a few months ago. So check the applied CSS for such a thing, find who did it, and file a bug (as it should also affect IE6, except IE6 will simply not apply the rules). --Splarka (rant) 08:06, 23 November 2009 (UTC)
Only case I have been able to find that does this is Usability CSSTheDJ (talkcontribs) 09:50, 23 November 2009 (UTC)
bugzilla:21603. Perhaps it's time we put IE5 users into a separate (text only/simple) skin ? —TheDJ (talkcontribs) 09:54, 23 November 2009 (UTC)
I don't believe upgrading IE is going to be an option for the OP. It looks like Internet Explorer 6 would require Windows 98. ---— Gadget850 (Ed) talk 13:10, 23 November 2009 (UTC)

[edit] <nowiki>producing nonsense text

Often when I use <nowiki>, odd text such as ":/nowiki!--_Do_not_include_the_""_or_"";_they_are_for_emphasis_--nowikiFile:Name_of_image (ctrl-click)">:!--_Do_not_include_the_""_or_"";_they_are_for_emphasis_--nowikiFile:/nowikiName_of_image (ctrl-click)">" appears for no apparent reason. Is this a known bug? If not, should I file a report? Intelligentsium 02:48, 23 November 2009 (UTC)

I often use nowiki and haven't seen this. It sounds like something which may happen if you use <nowiki> in a specific context, for example where something attempts to convert the characters '<' and '>' or to interpret them as belonging to something other than "nowiki". Can you give a diff to a real edit where it happened, and say whether you subst'ed any templates in the edit? In your example, I guess the two strings of form !--...-- originate from source comments of form <!--...-->, but at some point something "ate" '<' and '>' in the comments so the rest became displayed. Maybe nested nowiki's could cause things like this in some circumstances, or overlapping comments and nowiki's where none of them are completely included in the other. But if the source and not just the rendered text looks like your quote afterwards then it may have required use of subst, or a bug. PrimeHunter (talk) 03:33, 23 November 2009 (UTC)
My Wikipedia connection is extremely slow today so it's hard to investigate but I found your edit here. Did you copy the text to an external program while making that edit? Which browser and version did you use? It looks like something converted several non-letter characters. PrimeHunter (talk) 03:59, 23 November 2009 (UTC)
(edit conflict)For example, if I type some code (File:Example file) and hit the nowiki key (because I might want to bold text inside the File syntax) on the toolbar (maybe that's the problem?) it produces ''':'''example_filenowiki (ctrl-click)">[[File:example file]] Intelligentsium 04:04, 23 November 2009 (UTC)
And no, I did not copy anything to an external program. I was using the latest version of Safari (4.0.4, I believe). I have wikiEd enabled, though I used the standard toolbar nowiki. Intelligentsium 04:07, 23 November 2009 (UTC)
I don't have Safari but see Wikipedia:Browser notes#Safari_3. Do you have Check Spelling as You Type enabled in Safari? The browser note mentions "Control-click" and your bad edits add "(ctrl-click)" to the text. The browser note mentions underlining and your bad edits convert spaces to underscores. Maybe the spelling feature and toolbar can interfere. PrimeHunter (talk) 04:56, 23 November 2009 (UTC)

[edit] Turn on spellcheck in summary field

Firefox and Opera both support the spellcheck attribute (spellcheck="true", information) could we get this implemented here? — Dispenser 06:05, 23 November 2009 (UTC)

Oh yes, I'd like this too. I am not a native English speaker, so I have very good use of spell checking. It is very annoying to have to manually turn on spell checking every time I fill in an edit summary. Perhaps we can add the "spellcheck=true" attribute to the summary field by using JavaScript? Then this could for starters be a user script or even a gadget. What do our JavaScript gurus say, can we add that attribute with JavaScript? Here's how I think the code should look:
 /* Adds spellchecking to the edit summary field, if using Firefox 3,     or using Firefox 2 with dictionary add-ons. Perhaps works in Opera too. */ addOnloadHook( function() {   var wpSummary = document.getElementById( "wpSummary" );   if ( wpSummary && typeof wpSummary.spellcheck != undefined ) {     wpSummary.spellcheck = true;     // wpSummary.spellcheck = "true";   } } ); 
Not sure if it should be quotation marks or not around "true". Neither works for me, but I only have Firefox 2 with a spell checking plug-in.
--David Göthberg (talk) 10:10, 23 November 2009 (UTC)
I filed bugzilla:21604 for this. And yes, this could be done with Javascript in theory, though your if condition needed fixing. —TheDJ (talkcontribs) 12:24, 23 November 2009 (UTC)
Fixed - mw:Special:Code/MediaWiki/59360 Reedy 18:41, 23 November 2009 (UTC)
TheDJ: Thanks for filing that bug.
Reedy: Thanks for updating the MediaWiki code. So I guess that means it soon will be available here on Wikipedia. (That is, then we don't need to use the JavaScript above.)
But meanwhile: Oh, silly me, I had some junk in my personal javascript page that stopped the script from running. Now it works even for my Firefox 2 with dictionary add-ons! And it works both with and without the quotation marks. And already my simpler version of the code worked. But TheDJ's addition is good, if I understand it right it prevents the code from causing problems in other browsers.
So, all Firefox users out there, if you want this fix right now, then add the above code to your personal /monobook.js, then wait 30-60 seconds, then bypass your browser cache.
I have not tested if this works in Opera. But if anyone uses Opera, feel free to try the above code and report here.
--David Göthberg (talk) 21:17, 23 November 2009 (UTC)

[edit] Speed of Google listing new pages

My fellow Wikipedians, I am minorly concerned at the speed in which Google lists new articles into its search engine. I do a fair bit of new page patrolling and I tag a lot of pages as copyright violations. In order to find the source of the suspected violations I will copy and paste a few lines of the suspect article into Google. Invariably, the very first thing to appear is the article itself. I just ignore it and go onto the next until I find (or don't find) the source. However, I am just a tad concerned that Google is sucking in and possibly caching a large number of articles that will soon be deleted for a variety of reasons. So, does this present any issue? I think it would be a good idea to have a 12 to 24 hour wait on google listings, just to ensure that the article isn't speedily deleted or subject to other major modifications. Thoughts? Basket of Puppies 19:14, 23 November 2009 (UTC)

We supply Google with a feed. I think it might make sense to set up some technical jiggery to automatically {{NOINDEX}} unpatrolled pages. Jehochman Talk 19:16, 23 November 2009 (UTC)
Jehochman, I think that is a good idea! Delaying the Google feed until an article is patrolled sounds like a good idea. I'd also consider extending it to pages marked for Speedy Deletion. Basket of Puppies 19:23, 23 November 2009 (UTC)
Does the feed just cover new pages or all revisions? If it's the latter case, we might also consider delaying IP and new user edits (along the flagged revisions theme).LeadSongDog come howl 19:44, 23 November 2009 (UTC)
That's a slippery slope, as most IP edits are good. At least for new pages until they are patrolled, and possibly for those that are subject to CSD. Basket of Puppies 19:49, 23 November 2009 (UTC)
At the moment CSD tagged pages are NOINDEXed already (or should be), but it can take Google a while to update this sometimes. - Kingpin13 (talk) 20:09, 23 November 2009 (UTC)
{{NOINDEX}} doesn't work in mainspace, though, and that's a deliberate decision. Gavia immer (talk) 20:30, 23 November 2009 (UTC)
Yes, I see that NOINDEX does not work in mainspace. Is there a way to enable it. Or, more precisely, to enable it for only unpatrolled pages and CSD candidates? Basket of Puppies 21:38, 23 November 2009 (UTC)
Sure there is. Just convince the Foundation that they're wrong about that policy, convince the community that you're right about it, and convince the tech staff to change it. But this is unlikely to happen, of course. Gavia immer (talk) 23:28, 23 November 2009 (UTC)
The main issue with adding it to the CSD tags is that if you add it after the page has been indexed, it won't have any effect until they crawl it again, which might be hours or days. So you'd have to add the tag extremely quickly after creation, which is typically frowned upon. Mr.Z-man 23:44, 23 November 2009 (UTC)
Do we? I had gotten the impression from somewhere that Google chose to discontinue that relationship in favor of simply customizing the Googlebot to efficiently capture Wikimedia content directly. (I would guess by tracking recent changes, though I don't know that.) Dragons flight (talk) 22:31, 23 November 2009 (UTC)

[edit] Not logged in

Currently, you are prompted to go to the log in page when you reach a page requiring logging in. Is it not possible to just show the log in field instead of the prompt? Also, when you successfully logged in, it prompts you to go back to the original page. It should just force the redirect. --220.255.47.116 (talk) 22:59, 23 November 2009 (UTC)

It used to do the redirect, IIRC, so it's likely people wanted it changed. ♫ Melodia Chaconne ♫ (talk) 23:07, 23 November 2009 (UTC)
Users at Wikipedia:Help desk/Archives/2009 October 30#Automatic "return to" after login? reported different experiences about being redirected after login. It doesn't redirect for me. PrimeHunter (talk) 00:24, 24 November 2009 (UTC)
Wikipedia used to redirect the user to the original page five seconds after they logged in, but that was changed with bug 9153 in 2007. Graham87 07:07, 24 November 2009 (UTC)



Product Results (view all...)

search wiki for    ?
web dir firms image gallery news pdf wiki shop video 



↑ top of page ↑about thumbshots