Please see [[Germanic_languages#Diachronic]], I'm trying to get rid of two cells' bottom margin in the 4th row (the one containing "Gothic", and the empty one bordering on "Old High Germanic"); any help from css pundits? [[User:Dbachmann|dab]] <small>[[User_talk:Dbachmann|('''ᛏ''')]]</small> 14:07, 8 February 2006 (UTC)
Please see [[Germanic_languages#Diachronic]], I'm trying to get rid of two cells' bottom margin in the 4th row (the one containing "Gothic", and the empty one bordering on "Old High Germanic"); any help from css pundits? [[User:Dbachmann|dab]] <small>[[User_talk:Dbachmann|('''ᛏ''')]]</small> 14:07, 8 February 2006 (UTC)
: I think I managed to make with work the way you wanted. -- [[User:Netoholic|Netoholic]] [[User talk:Netoholic|@]] 15:39, 8 February 2006 (UTC)
The technical section of the village pump is used to discuss technical issues. Bugs and feature requests should be made at BugZilla since there is no guarantee developers will read this page.
FAQ: Intermittent database lags can make new articles take some minutes to appear, and cause the watchlist, contributions, and page history/old views sometimes not show the very latest changes. This is an ongoing issue we are working on.
Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here.
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).
Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this
period the discussion can be moved to a relevant talk page if appropriate. After 7 days the
discussion will be permanently removed.
I wanted to direct some attention toward this seemingly forgotten page.
A lot of people have been reporting what they percieved were bugs, though it seems few people actually watch the page at all. The page was a terrible mess, so I can imagine that it thus didn't have a high priority. I have recently removed a lot of fluff, and have tried to improve the layout. Perhaps some knowledgeable people could have a fresh look at the listed Bugs. -- Ec561815:47, 29 January 2006 (UTC)[reply]
Can understand why people doesn't use that page, WP:BUG contains: # Providing technical details with our customized bug-reporting tool, MediaZilla., Wikipedia:MediaZilla contains first: Report it at Wikipedia:bug report - this is the easiest way. So it's a circular procedure to report a bug that way. If someone tries to post a bug there wheel stuck in a while-loop. →AzaToth15:52, 29 January 2006 (UTC)[reply]
There's too many of these scattered pages. In general I recommend these old pages be closed; it's misleading to imply that developers will read and respond to bug reports on some page we obsoleted with a bug tracker in 2002... --Brion23:15, 29 January 2006 (UTC)[reply]
How much does the Wikipedia software deviate from MediaWiki? Are there many changes, or is it essentially the same? Several of my recent questions might have been answerable just by looking at the MediaWiki source code, so I was hoping that there wouldn't be much difference between the two... ~MDD469620:31, 29 January 2006 (UTC)[reply]
It deviates almost nothing. The only deviations come from the fact that often code is first tried "live" on the site before being added to CVS, the configuration, and perhaps a few tweaks. Notice, however, that you have to look at the CVS HEAD, since it's the version closest to what's used on the site. --cesarb20:46, 29 January 2006 (UTC)[reply]
Not quite. Code is committed, then it's reviewed and tested on http://test.wikipedia.org to check for fatal errors before being synchronised to all our servers in one go. Wikimedia's wiki farm runs a more or less up-to-date version of CVS HEAD. Rob Church (talk) 23:32, 29 January 2006 (UTC)[reply]
In certain areas of the website, we are being overwhelmed with newbies uploading copyrighted images (copyvios) and images with uncertain copyright status (not usable). Naturally, newbies are generally unaware of our image usage policy, which has been thoughened considerably, incidentally. But the thing is, this is multiplying considerably the work of everybody else, in order to keep Wikipedia in compliance with both the law and our policy. Perhaps we should consider making the ability to upload images available only to accounts that are, say, a couple of months old? I don't know if that's even possible from the technical point of view, so I'm not even proposing this elsewhere before I find that out. Regars, Redux23:33, 29 January 2006 (UTC)[reply]
Possible, and not a bad idea. Autoconfirmed is an automatic permission users receive when their account has been registered for a specific period of time; the default for which is four days, and this is what we've got set on Wikimedia wikis. File a request on BugZilla and see what happens. Rob Church (talk) 03:55, 30 January 2006 (UTC)[reply]
Thanks for the feedback. But BugZilla? Isn't it supposed to be for reporting bugs? I believe this is more about a change in the MediaWiki, which might have to be supported by a policy change. Then again, I'm not really experienced in reconfiguring the software... Redux15:50, 30 January 2006 (UTC)[reply]
We use BugZilla to keep hold of bugs, feature, and site configuration requests. The correct product and severity for a feature request are MediaWiki and enhancement, respectively. Rob Church (talk) 17:29, 31 January 2006 (UTC)[reply]
I think it's a good idea, first thing to do will be to see if the community in general agrees, then if so file it on bugzilla (as far as I understand bugzilla is for all changes/improvements as well as actual bugs). Martin15:57, 30 January 2006 (UTC)[reply]
I'm not sure that a couple months is the right length of time. When I notice new users uploading problematic images, I will engage them in a discussion about the policies, what's okay to upload, and inform them about Commons. I've found that the new users catch on pretty quick and have become good contributors to Wikipedia. Granted that many of the images at [1] are probably copyvios, though many others are self-authored photos.
I think that Special:Upload has improved greatly at explaining what's okay and not, but could be made more clear and explicit. Many users that I engage in discussion are quite confused by Wikipedia:Image copyright tags and don't understand that well, which license to select. Maybe we could improve that page, and link it boldly to the line "Specify the licence of the file by selecting it from the drop-down list below." on Special:Upload? -Kmf164 (talk | contribs) 17:50, 31 January 2006 (UTC)[reply]
Just to point out an alternative here. We can also create permission groups which are explicitly denied the ability to do things, e.g. we could create a noupload group which denies upload rights to users. This could then be added by a local bureaucrat using a modified version of the current interface for granting rights, which I'm going to improve sooner or later. Rob Church (talk) 08:03, 1 February 2006 (UTC)[reply]
I believe that this idea is complementary, rather than an alternative. I like the idea, as a form of removing upload rights from whichever user (regardless of how old the account is) who shows a disposition for ignoring policy and uploading problematic images. Although I could suggest, if it's even possible from a technical standpoint, what if that could be done in a somewhat similar way to blocking a user? I mean, Administrators might be given the ability to suspend temporarily a user's ability to upload images. On the original suggestion, of course, two months was an original suggestion, it could be a little less, but I do believe that, given our policy, and our concern with keeping Wikipedia in compliance with the law, it has become somewhat difficult for the ability to upload images to remain as an automatic privilege of every new account. It's severely multiplying the work load of other users. Not to mention that some newbies don't respond immediately — nothing too strange, as new users aren't all that active in the beginning as a rule. Also, some newbies don't really know what's going on when we contact them about the images not being usable, and it takes them a while to catch on. As an alternative, I might suggest that, instead of making the ability to upload images available to new users after a predetermined period, we could make it available upon request. I don't mean any kind of "support/oppose" vote, the user would just have to answer a few standard questions, and if (s)he answers right, the ability to upload would be granted — and in order to answer right, that person will have to read up on Wikipedia policy. As a complement to that, future abuse could result in temporary suspension of the ability to upload images. Redux13:38, 1 February 2006 (UTC)[reply]
I have transferred the discussion to the talk page of WP:IUP. It's right here. The discussion preceding this post was copied and pasted there. I'm hoping to get the community feeling about the idea. Thanks, Redux00:34, 4 February 2006 (UTC)[reply]
The Wikipedia Help Desk mailing list (at helpdesk-l@wikimedia.org) received this very strange message:
"Dear user helpdesk-l@wikimedia.org, administration of wikimedia.org would like to inform you
Your account has been used to send a large amount of unsolicited
commercial e-mail during the recent week. Most likely your computer was infected and now contains a hidden proxy
server.
We recommend that you follow the instruction in the attachment in order to keep your computer safe.
Virtually yours,
The wikimedia.org team."
It also contained a zipped attachment, which I did not even attempt to open.
Yup. This is a classic and rather transparent trick to get you to open the attachment. It works a lot better for ISP e-mail addresses, where the last part reads for example "The aol.com team". I get these at a domain I own, and I'm very entertained to discover that my domain's "team" (which doesn't exist) is sending me security bulletins. Deco00:47, 31 January 2006 (UTC)[reply]
Thanks. I thought it was suspicious, we get lots of emails contianing viruses on the list, though this is the first one that looks likes it was specifically targeted TO the list. User:Zoe|(talk)19:13, 1 February 2006 (UTC)[reply]
I was just shown a very strange thing on the Dingbat page. If you view the page as a logged-in user, everything looks fine and dandy. However, if you are logged out, the top of the page has a big yellow box that says:
"This image is not an orphan—see Autofellatio
This image is needed as it is either linked from a text link or is otherwise useful, even though it appears to have nothing linking to it.
Please do not delete this image without verifying that it is really not needed."
Followed by:
"We want it noted that the image is provided by Hornyboy.com and copyrighted by RudeBox Media, Inc., but it can be used freely with this mention."
...and a copyright notice, etc. This only appears if you are logged-out when you view the page. We were able to view it from multiple browsers, networks, and OSes. So. What is happening here? I don't see it in the history, but I didn't look too deeply there. -- ManekiNeko | Talk23:28, 30 January 2006 (UTC)[reply]
I don't see such a notice. You say another editor is experiencing the same thing, on a different computer and account? Or does the issue occur on a single computer only? -- Ec561823:40, 30 January 2006 (UTC)[reply]
Four different computers, three different people. The other two don't have accounts (or weren't logged in, at any case), and were asking me why this appeared on the page; I didn't see the box until I logged out myself. When I logged back in, it went away again. The systems this showed up on were: two different Mac OS X computers on separate networks (running both Safari and Firefox), and two different Linux boxes on separate networks running Firefox. We were all communicating via chat and our computers aren't connected in any way to each other's. You don't see this when you log out? Very odd. --ManekiNeko | Talk00:09, 31 January 2006 (UTC)[reply]
Follow-up: just retried it in Mac OS X Firefox and it seems to be gone -- an edit by User:Sean_Black (9 minutes before your post) seems to have fixed it, though for the life of me, I can't figure out why. :) -- ManekiNeko | Talk00:18, 31 January 2006 (UTC)[reply]
Do you mean the browser cache? Because we all did that and it didn't work. (Also, I had never visited the Dingbat page before, logged in or not, so it couldn't have been in my cache.) Anyway, this particular one is fixed, but I'm sure curious to know what happened. -- ManekiNeko | Talk03:41, 31 January 2006 (UTC)[reply]
No, it's the page cache, the one you purge by using action=purge (get the edit link for the page and change action=edit into action=purge). --cesarb03:53, 31 January 2006 (UTC)[reply]
When the software gets confused. It's done automatically when needed (for instance, when the page is edited); however, if it fails, you get stale data on the cache, with sometimes strange results. This means you never normally need to do that; when you need to use it, it's because of a bug or other problem with the Wikipedia system. --cesarb15:04, 31 January 2006 (UTC)[reply]
Has there ever been discussion on fixing the Internet Explorer alpha transparency problem? This 18 line javascript fixes the problem and is very widely used across the internet. (See google results for: AlphaImageLoader Filter). You can very easily put it into your monobook.js as well, to test it use Internet Explorer and login w/:
There has been. It triggers ActiveX warnings on various versions of IE depending on security settings, and sometimes crashes. (Note that IE7 renders alpha-transparent PNGs just fine. If MS ever gets around to releasing it to the public... ;) --Brion06:16, 31 January 2006 (UTC)[reply]
Where are they? I'm trying to see what has been done, maybe I can help hammer out some of the problems. Even *when* MS releases IE7, we still have ~80% of our readership using IE5.5/IE6 —Achille2006-01-31 06:21Z
Hmm. Our software converts SVGs into PNG format before rendering. And PNGs don't work on IE (except the unreleased beta) if they use alpha transparency, but do work if they have binary transparency. Is it possible to alter the SVG renderer on the server side so that it uses binary transparency to render empty (100% transparent) areas of SVGs when they are converted to PNG format? I think this would fix most of the problems and without requiring any client side hacks. Crotalus horridus (TALK • CONTRIBS)06:26, 31 January 2006 (UTC)[reply]
File:IE-transparency.png...have a solid white background...Not true it depends - Here is a sample screenshot of an article rendered by the Trident IV engine. On TridentV/Gecko the LexisNexis logo looks fine. —Achille2006-01-31 07:03Z
IE7 fixes alpha transparency of PNGs. IE7 is included with Vista. All new computers come with the latest Windows, and average PC turnover time is 2 years. Hence, this problem will go away. Deco07:33, 31 January 2006 (UTC)[reply]
Unfortunately, it won't. Microsoft has claimed that they will only make IE7 available for Windows XP SP2 and above.
There are still tons of users running Win98 and WinME, and furthermore, many of them cannot upgrade to XP because their antiquated boxen simply couldn't handle its bloat. Trust me on this - I've worked phone tech support. Unless MS relents on this front, we will, unfortunately, be stuck with broken implementations of PNG for the better part of a decade to come :( Crotalus horridus (TALK • CONTRIBS)07:36, 31 January 2006 (UTC)[reply]
IE7 will be released under Windows XP and Windows 2003 too. Vista will just have a few exclusive additional features for security (basically the new parental control filter, and the separate VM for complete process isolation), but the new CSS2.1 engine and support for alpha transparency (and possibly correct management of embedded gamma correction or ICC color profile, because IE7 still manages them correctly, assuming incorrectly that sRGB means gamma 1.0 instead of 1/2.2 during its color conversion of PNG images with non-sRGB profile into the sRGB profile used in HTML and CSS and for final rendering). IE7 Beta2 Public Preview already runs on Windows XP. See: "http://www.microsoft.com/windows/ie/ie7/ie7betaredirect.mspx". But anyway, I don't see why the new PNG renderer would not run on Windows XP SP1 or retail, or in Windows 98/ME.
If Microsoft does not want to support a new PNG renderer for Windows 98/ME, may be it should specify the renderer interface, so that it can be implemented by an alternate third party component (mapped to the "image/png" MIME type). I think that such component, based on DirectX could be easily open-sourced, provided that MS specifies the security isolation that protect the IE rendering surface.
My tests on the new PNG alpha renderer works great (you can even view a video through a transparent PNG, including when the PNG image is moved with CSS and DOM, allowing new kind of interaction with video such as dynamic subtitles, or on-screen transparent control of display or sound in full-screen mode, without hiding parts of the video or without rescaling it, using PNG icons instead of plain GIFs or BMPs). Now that Microsoft made the most difficult with the alpha channel, correcting the gamma/ICC bug would be MUCH simpler as it does not interact with other components or with the final display. 86.201.239.17623:42, 3 February 2006 (UTC)[reply]
I find the highly dismissive responses very troubling. What do you mean by "in 2 years, hence problem will go away"? In two years there will be more technogies emerging that the TridentV engine will not handle. This can be fixed now with minimal repercussions. —Achille2006-01-31 09:08Z
You're misinterpreting me. I didn't say the problem will go away in 2 years. I meant that because computers turn over quickly, the problem will go away within say 5 years for a large percentage (maybe 70-80%) of our users. In the meantime, I don't think we should be using nasty exploits that aren't guaranteed to work with new versions of software. It'd be nice to fix this, but it's not our problem to fix and the images are still usable, if sometimes ugly. Deco18:06, 31 January 2006 (UTC)[reply]
nasty exploits that aren't guaranteed to work with new versions of software. Can you vouch for the truthfulness and the accuracy of that statement? —Achille2006-01-31 18:50Z
Nope. I'm just taking the word of Brion above, who probably knows more about web dev than me as a Mediawiki developer. Deco18:53, 31 January 2006 (UTC)[reply]
Hi there. I am trying to massage some census data (ooh, baby) so that we can import it via robot into the Esperanto wikipedia. A resource page at the gazeteer has a database of cities & towns with a county FIPS number. And there's a separate database with counties having a county FIPS number, but the two numbers do not seem to match up. I was hoping for the classic one-to-many relationship (one county has many cities/towns), but it doesn't seem to work.
Maybe this sort of census information can be found somewhere else. Would anyone know how I can match up a city to its county? -- Yekrats18:13, 31 January 2006 (UTC)[reply]
You didn't mention where you got the second database from, but if it is from census.gov there should be additional documents with it that describe the record files. I have had the good fortune (chuckle) of working with some of the demographic data lately for adding to congressional district and school district articles, and I have found the data to be well documented. —Mike07:19, 2 February 2006 (UTC)[reply]
And if we had a user with equals signs and spaces in their name, you'd have to write something like {{vandal|1=-= =DARK= =-|2=-=_=DARK=_=-}}. Eww. Are there any legitimate users with equals signs in their name, anyway? Should they just be disallowed? Doesn't seem like a common character to use in "real" names. —Ilmari Karonen (talk) 16:52, 1 February 2006 (UTC)[reply]
Another solution is to use the nowiki tag for the argument only: {{vandal|<nowiki>-=-=DARK=-=-</nowiki>}} produces [nil -=-=DARK=-=-]([[User talk:-=-=DARK=-=-|talk]] · [[Special:Contribs/-=-=DARK=-=-|contribs]] · [[Special:DeletedContributions/-=-=DARK=-=-|deleted contribs]] · [[Special:Nuke/-=-=DARK=-=-|nuke contribs]] · [[Special:Log/-=-=DARK=-=-|logs]] ·filter log· [[Special:Block/-=-=DARK=-=-|block user]] ·block log). - Liberatore(T) 19:55, 1 February 2006 (UTC)[reply]
All of the special characters (#, [, ], *, =, :) should be blocked for new users. They're not worth the trouble (the characters, not the new users). Superm401 - Talk04:42, 5 February 2006 (UTC)[reply]
Searching for articles
I have read Wikipedia:Searching and as far as I can see, there is no way to search article names rather than body text. Am I right? I would like to be able to search for (say) article titles +January +2005 -sports and to not get a list of several thousand pages which link to or reference the words. Is it possible? -- SGBailey16:39, 1 February 2006 (UTC)[reply]
You could use google (or your search engine of choice) searching for "site:wikipedia.org" or "site:en.wikipedia.org" and your search terms. Your example comes out like this, for example.--Cherryblossomtree17:58, 1 February 2006 (UTC)[reply]
I don't think this answers the question. The person wants to search only titles, not bodies. This is possible with a database query, but besides that I don't think so. Deco19:47, 1 February 2006 (UTC)[reply]
Actually you can, though it may not be totally reliable: [2] I'm afraid your search won't likely work, though, as the indexer seems to discard numbers. --Brion20:23, 1 February 2006 (UTC)[reply]
I just recently installed IE7 and the Wikipedia/Wikinews/Wiki* logo does not appear. I have not yet tested it on other machines. Can someone else verify on this? —Achille2006-02-01 19:27Z
This is correct. In fact, this occurs on all sites using the latest Mediawiki software. I have reported this to the IE team for investigation. Deco19:45, 1 February 2006 (UTC)[reply]
Ok, got public beta installed on XP. Confirmed that the classic alpha hack no longer works (it did on beta 1); I've changed the conditional includes so that it skips the IE workarounds JavaScript for IE 7 and later; the logo now displays properly, though I haven't checked out every feature to confirm proper functioning. --Brion21:29, 1 February 2006 (UTC)[reply]
For anyone interested here's a diff of the change. Thanks Brion, that was quick! —Achille2006-02-01 22:11Z
FYI, MS has been notified that we've fixed this issue and I got a response. Since we're skipping the workaround for IE7, my impression is that this isn't something they need to fix. Deco00:17, 2 February 2006 (UTC)[reply]
Well, it might be. If this breaks other sites using the alpha PNG hacks to make transparent PNGs display in IE 6... ---Brion00:29, 2 February 2006 (UTC)[reply]
It turns out that the list misalignment only happens under Monobook and Chick skins. I'm proposing fixing these two to conform to browsers' default rendering, and to the other Wikipedia skins. —MichaelZ. 2006-02-01 23:55 Z
non-breaking space in links
Tiny little problem: Is there a better way to do this? My goal is to have a non-breaking space in the link Leopold I (looks a bit strange if it wraps the line before the "I"). I have seen this occurs quite often (another example is World War I). --Adrian Buehlmann22:15, 1 February 2006 (UTC)[reply]
I see a problem with that template: it is not protected. If anyone is using it for any of the thousands of links which could be out there, it could present a problem if someone vandalised it. —Mike07:07, 2 February 2006 (UTC)[reply]
Yes, and the same is true of nearly every template. We don't protect things preemptively; it's only used for legal reasons or as a last resort against vandalism. This is the reason that some proposals for stable versions suggest substing all templates, though. Deco07:20, 2 February 2006 (UTC)[reply]
When the old version of Co-operation at [3]
was the current version, the link to footnote 1 did not work for me. The o-dieresis in the link label turned into something that didn't match the actual anchor. The upward link did work. I changed the label to use only ASCII characters, which fixed it for me.
Is this a problem with my environment (which sometimes seems to be a bit schizoid as to whether it's 8859-1 or Unicode), or a bug in Wikipedia's software?
This might have something to do with the fact that in the version you link to, the {{ref}} uses "Coöperation" but the {{note}} uses "dieresis", so they didn't actually match. It is possible that the back-link appeared to work because your browser simply jumped to the top of the page when confronted with a non-existent anchor, but I couldn't say for certain. HTH HAND —Phil | Talk08:07, 2 February 2006 (UTC)[reply]
Slanted Fonts
All of a sudden, nearly all ordinary text fonts on the wikipedia pages are slanted.
Same symptoms on IE and Mozilla. Button and typewriter fonts are still upright.
Is this just my system or do others see this as well?
Sounds like your system; everything's okay here. —MichaelZ. 2006-02-02 15:44 Z
Not seeing it; maybe it was a momentary glitch. Clean your cache, shift-reload (to load the CSS again) and see if that helps. --Golbez15:45, 2 February 2006 (UTC)[reply]
Yes, it's my system. Other pages are affected, too, but not all. For example, on the Google front page, even the fonts on the buttons are slanted. Looks like a problem with my system's fonts. Thanks for your replies.
Formulate a minimalist technical propoosal for U.S. congress & astroturfing issues
Allow IP ranges, i.e. Special:Contributions/156.33.0.0/16 would view all anonymous U.S. Senete contributions.
Add a "list" field for Special:Contributions which accepts a list of users or IP ranges, and displays specified contributions by all.
Add a "categories" field to Special:Contributions which accept a list categories, and restricts the search to any pages within those categories (ala the current namespace restriction).
Allow users to watchlist any such Special:Contributions's page (optional; main reason is that watchlists are private).
Allow admins to view registered users when viewing Special:Contributions by IP range (optional). No registered users IPs would be divulged. But this feature must either be restricted to admins and/or monitored by check users, as its possible to narrow down a persons IP quickly.
Such functionality would allow various groups within wikipedia to watch the contributions by outside groups, such as political staffers and advertising agencies; plus its obscure enough that outside groups never know they are being watched.
It shouldn't kill the servers, as it'd only produce the usual Special:Contributions server hit with a slightly more complex query, and the single result returned by the watchlist addition shouldn't add much overhead. If you omit the watchlist option, the changes require no additional database commits, meaning its easy to debug.
I think number 6 is too much of a privicy violation, unless we are prepared to change policy and in effect give all admins chekuser rights. If avaialbel it should be limited to people trusted enough to get chekuser access. #5 is not really needed, as if the other 4 are implemented, the URL to a special page can be saved off-wikli and pasted into a browseer (or even saved as a bookmark) which is even more private than a watchlist. Aside from that, i would like it. it sould also be helpful when an IP vandal is identified as being part of an IP range assigned to a specific source (say a school or a library) to be able to check other edits from the same range easily. Often th4e same user gets multiple IPs within such a range. DES(talk)16:55, 2 February 2006 (UTC)[reply]
How about putting a little (16x16) icon of the Capitol next to any edit that comes from a Congressional IP address? That sounds like the simplest solution by far from an end user perspective. On the server end, all you'd need would be a couple of lines of code, the icon, and a database of all the Congressional IPs. Crotalus horridus (TALK • CONTRIBS)21:44, 2 February 2006 (UTC)[reply]
That is IMO both too specific (it addreses onlyt this particular range) and too broad (It marks all edits from that range, even legit ones for all users, even ones not inquiring into this matter). The tools listed above (well 1-4 anyway) have more general uses (lots of school IPs, for one thing) and wait until soemone has a reason to use them. DES(talk)21:54, 2 February 2006 (UTC)[reply]
My original proposal had included a notion of "featured" Special:Contributions page, which would flag all submissions by such people. But there are three problems with this proposal: it increases server load, it exposes the feature to those we wish to monitor, and some will feel it violates privacy. For now, its maybe best to allow wikipedia to delevop its own more private monitoring systems, and that is the point of the first three options. JeffBurdges10:11, 3 February 2006 (UTC)[reply]
Okay, it sounds like 1-3 would get strong support if a patch actually existed, but that 4 is not worth the effort, and that 5 may be a privacy violation. Just for talking purposes, here is an alternative to 5 which might or might not aleviate the privacy concerns, but should alleviate the server load concerns.
5. Allow admins to view registered users when viewing Special:Contributions by IP range (optional, may exist already), and also allow check users to approve such searches for all users, i.e. anyone could discover who worked for the U.S. Senate if a check user felt this was appropriante (more optional). Such searches would never divulgue the IP of specific users, but check users would need to follow some policy for approving such searches, and use of this power would be minitored by other check users.
I've got no strong feelings on this, but it looked like an interesting compramise. It may simply not be worth the effort, as there are other ways to monitor specific accounts, and there should be ways to monitor large numbers of accounts coming from any range too. JeffBurdges10:11, 3 February 2006 (UTC)[reply]
Regarding number 4 specifically, I've been thinking for a while that a "Special:Userwatch" page would be useful, at least for admins. My idea was that it would work exactly like the normal watchlist, except that it would list latest edits from specific users rather than to specific pages. Or perhaps we should name it "Special:Wikistalk"? ;-) —Ilmari Karonen (talk) 10:52, 3 February 2006 (UTC)[reply]
Yes, I thought about this, but 2 alone provides this functionality, i.e. Special:Contributions with "list" set to your "user watchlist" provides the most recent edits by all of them, much more efficent than clicking Special:Contributions for each separately. JeffBurdges11:38, 3 February 2006 (UTC)[reply]
Bare diffs?
How hard would it be to be able to get just the wikicode diff instead of loading the whole page everytime? Most of the time in RC patrolling and looking through edits I only want to see the changes, and can figure out for myself what they will look like when rendered. That doesn't work for a few things of course, but it does for many so both the regular and the bare diff would need to be available-maybe a link from the bare diff to the full one. Not only would this really speed up RC patrol on slow connections, but I think it could reduce bandwidth useage. - TaxmanTalk19:50, 2 February 2006 (UTC)[reply]
We have "Use external diff by default" but, last time I checked, that requires both versions of an article to be downloaded. BTW, an option for seeing only the diff would be great. - Liberatore(T) 20:42, 2 February 2006 (UTC)[reply]
There is no facility for the editing of page summaries at present, other than direct database manipulation or selective undeletion of the article (which would wipe credit for that edit entirely). For an "unnecessarily brusque" edit summary, it isn't going to happen. Your regret at the summary is likely to be sufficient to heal any wounds it caused.-gadfium08:09, 3 February 2006 (UTC)[reply]
Even with selective undeletion, it's not gone forever. One can still redelete and then undelete the lot to get it back in public viewing. Without direct database manipulation, it's not going to happen; and it's not going to happen unless there's a damn good reason for it. Rob Church (talk) 19:21, 5 February 2006 (UTC)[reply]
Skin change?
Today when I logged on at Wikipedia, everything looks different. In the past, I have had tabs above the top of each article for "Article", "Discussion", "Edit this page", "History", "Watch", and "Move". Above the tabs were links to my userpage, my talk, my history, etc. Today, all these links are running down the left side. I did not change any settings or preferences in Wikipedia or in my browser (Opera 8.02 - never had problems before today!), so I can only assume that something changed in Wikipedia, but I can't find any relevant announcement. Cmadler13:51, 3 February 2006 (UTC)[reply]
It sounds as though your skin has changed. You probably want the monobook skin. Use preferences/skin to set the skin to monobook, or if it is already on monobook, set it to classic, then save, then set it to monobook and save. Why your preferences changed without warning I can't say.-gadfium21:05, 3 February 2006 (UTC)[reply]
It's happening to me too—in Firefox, but not in IE. I am not signed in on either browser, so I assume it is the default monobook skin. Firefox is putting all the toolbar and navbar/tab bar links at the bottom of the page for me. 66.101.59.1800:45, 4 February 2006 (UTC)[reply]
Thank you for the comments. It seems to have resovled itself (and yes, monobook was the skin I want, for some reason it was not displaying correctly). The skin I was getting seems like a combination of Simple and MySkin. Cmadler16:11, 4 February 2006 (UTC)[reply]
I am having this problem again. I have tried all of the above suggestions with no success. I have set my skin to Classic and then back to Monobook and cleared my cache, but I am still getting this odd display. The display is correct using IE and Firefox, but not in Opera (my primary browser). Any other suggestions? Cmadler00:00, 7 February 2006 (UTC)[reply]
PNG thumbnailing is not just merely bad, but actively horribly sucks
I didn't realize how bad PNG thumbnailing was until I uploaded some greyscale PNG images yesterday, and found (among other things), that the WikiMedia software always makes thumbnails as 48-bit color images(!!), even when the input source image is an 8-bit greyscale PNG or reduced-color indexed PNG. For example, the image Image:1913-Dictates-of-Fashion-Calvert-Life-cartoon.png which I uploaded for article "Fashion" is 155,878 bytes long, but the 280px-wide so-called "thumbnail" displayed in Fashion is 167,988 bytes long, despite being much smaller. To be precise, the source image has 155878 bytes / 553610 pixels (830 x 667) for a ratio of 0.2816 bytes per pixel, while the "thumbnail" has 167988 bytes / 63000 pixels (280 x 225) for a ration of 2.6665 bytes per pixel -- or almost ten times worse...
I don't know how difficult it would be to implement in programming, but if the following rules could be followed, it would improve the situation dramatically:
1) NEVER use 48-bit color or 16-bit greyscale (i.e. 16 bits per color channel) in PNG thumbnails.
2) If the input image is a greyscale, the output image should always be a greyscale.
3) If the input image is indexed color, then the output image should also be indexed color (and so will contain no more than 256 colors).
Also, I notice that JPEG thumbnails have an IJG quality setting of 85, when 75 is more or less the "standard" default setting, and the majority of small thumbnail images will give reasonable results with a quality setting of 55 or even lower.
Yes, there seem to be a bug in the handling of grayscale images. Color images get scaled down just fine, but grayscale images become 48-bit RGB. I've no idea what causes this, though. In the mean time, I suppose you could partially work around the problem by reuploading a version saved as RGB... —Ilmari Karonen (talk) 21:33, 3 February 2006 (UTC)[reply]
If the input image is indexed color, then the output image should also be indexed color (and so will contain no more than 256 colors). This isn't a good idea. Here's an extreme example: a black-and-white image of 2000 x 1500 pixels reduced to 100 x 75 would look like crap reduced to black-and-white, but looks quite nice at 32-bit and wouldn't be bad with an 8 or 16 colour palette. I think it's more reasonable to give the contributor explicit control over the number of colours to reduce to. A temporary workaround for these issues is to upload a properly reduced version for use in articles, put a big scary note on it that it's a temporary measure with a link to the bug (great place for a template), and interlink the big and small versions. Deco03:33, 4 February 2006 (UTC)[reply]
I didn't mean that an indexed-color thumbnail would have the same colors as an indexed-color source -- there could be dithering to an appropriate 256-color palette. Churchh15:18, 4 February 2006 (UTC)[reply]
"Here's an extreme example: a black-and-white image of 2000 x 1500 pixels reduced to 100 x 75 would look like crap reduced to black-and-white"
Yes thats why we need manual control over the process, Judgements about what color depth a scaled version needs to stay looking decent can only be made by humans. Plugwash13:53, 4 February 2006 (UTC)[reply]
I'd say the following ruleset would be better:
Never use more than 8 bits per channel in thumbnails.
Never use indexed color.
Make the thumbnail grayscale if the original is a) grayscale or b) indexed with only grays in the palette.
I mentioned the possibility of indexed-color output PNGs because exactly the SAME color pixel data will generally compress much better as an indexed=color image than if put into 24-bit RGB format. This same issue is seen in the Image:1913-Dictates-of-Fashion-Calvert-Life-cartoon.png example, where putting 8-bit greyscale data into a 48-bit RGB color format image greatly hinders compressibility. Churchh15:18, 4 February 2006 (UTC)[reply]
I strongly disagree with prohibiting indexed colour. I've created many images with 32 or 16 colours that were visually indistinguishable from 32-bit colour and were 10 times smaller. Let's give the modem users a break here. Deco23:49, 4 February 2006 (UTC)[reply]
If the image syntax was amended to allow specifying the color depth, that would be fine. But as long as thumbnailing is a one-size-fits-all process, quality should be given priority over compression. That's particularly true since there's no easy way to determine how many colors a thumbnail needs based on the number of colors in the original: as an extreme example, I can take any full-color photograph, scale it up 16-fold and quantize it to 8 colors without any loss of detail. Calculating an optimal palette for an indexed color image also requires an extra pass over the raw image data, which can be costly for large images; scaling down to RGB or grayscale, on the other hand, is a one-pass process that doesn't require keeping the entire image in memory. Finally, if you really need to optimize a particular thumbnail, you can always scale it down yourself and reupload it with a different name. Then just include a link to the original. —Ilmari Karonen (talk) 11:58, 5 February 2006 (UTC)[reply]
The 16-bit channel issue is fixed now, both by specifying -depth 8 on the command line and by switching to a Q8 version of ImageMagick. As far as I could tell, ImageMagick was not adding channels, 8-bit greyscale images were being converted to 16-bit greyscale images, not 48-bit colour images. Doing anything intelligent with indexed-colour images is difficult, without writing our own scaling routines. Converting them all to RGB is at least robust. -- Tim Starling06:18, 7 February 2006 (UTC)[reply]
small feature request - "hide talkpages"
On your watchlist page there is a "hide my edits" link. How about a "hide talkpages" link as well? Fairly obviously, this would only show edits caused to articles outside the "Talk:" namespace. Stevage22:25, 3 February 2006 (UTC)[reply]
This template uses "{{fullurl:{{FULLPAGENAME}}}}" to link to its reference. The result of that is that if the page is loaded from a redirect (e.g. PAGE → The Page) the REF links will still show up as "The Page#link", and thus clicking on one causes the entire page to reload (this time from its true name rather than the shortcut), rather than just causing the browser to skip down a few screens. Is there a reason for this "fullpagename" trick, and would there be any objections if I changed this? (cc: template talk) >Radiant<00:15, 4 February 2006 (UTC)[reply]
In Canadian federal election, 2006, in the section Results, there is a table giving the results of the election. Near the top of this table I see an edit link which edits a table of the results at Template:Canadian federal election, 2006. Yet this table apparently is not the same table that is in the original article. I edited it (to remove a footnote about a pending recount, which has now been completed) and the original article's table was unaltered. I then edited the original article and found a separate copy of the table in the wikitext, from which I was able to remove the footnote. (There is at least one other difference that I have left in place for now, involving another footnote.)
Does it make sense that the original article contains an edit link to a template but doesn't seem to use the template? It sure doesn't to me.
I need a list of all pages in the Wikipedia namespace - How is this done?
The Help Project is considering taking on the clean-up of Wikpedia namespace. We'd like to build a site-map, and in order to do this, we need a list of all pages in Wikipedia namespace...
I looked at Special:Allpages, but that only lists the pages one screen at a time, and without brackets. Is there a way to get a list of all of the pages in one step, and with brackets? I'd settle for getting a list in one step, with or without brackets. --Go for it!04:42, 4 February 2006 (UTC)[reply]
And won't this map be out-of-date even before it is started? :-) Seriously, I think a site-wide map of Wikipedia would be a great idea. I've been wanting something like that for a long time. The closest I've got so far is using Category:Wikipedia to drill up and down through categories, but that relies on everything being categorised. Oops. Looks like it's been reorganised. I meant Category:Wikipedia_administration, though that looks different. I was probably thinking of another category... Carcharoth10:55, 4 February 2006 (UTC)[reply]
The site map is so that we can see what we've got to work with. The goal, hopefully an achievable one, is the clean-up of the Wikipedia namespace. Currently it is a morass of misnamed, misplaced, disorganized, and repititious pages. --Go for it!
Is there a way to get Special:Allpages to list all the pages in a specific namespace all on one page? I would like a continuous list, without the need to cut and paste the thing one page at a time. Some of the answers above seem to imply that this is possible, but I went there and cannot figure out how to do it. Please help. --Go for it!
I have the January 25 db dump loaded on my computer, so should be able to help. I'm running the query now, but it's taking a while. Must be a really long list of pages. -Kmf164 (talk | contribs) 00:12, 8 February 2006 (UTC)[reply]
I'm going through the list now, weeding out the duplicate pages (e.g. WP:VFD, WP:POTD, ...), as well as redirect pages, and formatting the list. Right now, I have it down to 14,000 pages — still too many for any site map. -Kmf164 (talk | contribs) 04:32, 8 February 2006 (UTC)[reply]
Duplicate Categories
Sure would be nice if Wikipedia would automatically check categories on pages when they are saved to make sure there are no duplicates. Richard M. Daley for example is categorized (among others) as "Mayors of Chicago", "Chicagoans", "Chicago politicians", "Mayors", and "American politicians". The only one that should be there is "Mayors of Chicago". That is a subcategory either directory or indirectly of all the others. "Chicagoans" in particular is getting huge, even though most people listed there are also in its subcategories. Until this gets implemented, I think a bot should be tasked to strip off extra categories. --Pascal66605:26, 4 February 2006 (UTC)[reply]
When I upload coin images, I'm having trouble finding the dropdown that corresponds to {{Money-US}}, so I have to go back and add the tag afterward. Am I missing something? Or, if not, why isn't that included in the list? Crotalus horridus (TALK • CONTRIBS)07:18, 4 February 2006 (UTC)[reply]
Well, it's not there simply because no one added it to the list. I used to know where that list was maintained (I thought a Mediawiki page), but now I can't find it. However, it is very easy to customize. Even without the drop-down, though, you can add tags to the "summary" box ({{TAGHERE}}). It is not necessary to "go back" and do it afterwards. Superm401 - Talk04:31, 5 February 2006 (UTC)[reply]
Yes, it's at MediaWiki:Licenses; but please discuss any potential changes on the talk page. The upload page and the dropdown are intimidating enough to new users at times, we really tried to limit the number of entries on the list. As Superm401 said, experienced users may always enter any favorite tag from the list at image copyright tags (including dual-license tags) in the summary box. (I've now added a mention of that to MediaWiki:Fileuploadsummary, which displays next to the summary box on Special:Upload.) Hope that helps! — Catherine\talk03:57, 8 February 2006 (UTC)[reply]
Searching for "edit" on Wikipedia pages
For some reason (it's a long story) I was trying to find the word "edit" on a _large_ talk page. Unfortunately there are a lot of "edit" words on Wikipedia pages, namely the section edit links. Other than viewing and searching the source, is there anyway to exclude these wiki layout bits from a search? Carcharoth10:59, 4 February 2006 (UTC)[reply]
we get lots of emails to the Help Desk mailing list saying they can't figure out how to edit a page. There has to be some way to make "Edit this page" more visible. User:Zoe|(talk)00:52, 6 February 2006 (UTC)[reply]
Suggestion for reducing bandwidth and storage
Looking at the source for some pages on Wikipedia the other day, I noticed that a lot of headers have a space between the equal signs and the first and last letters of the headings yet they appear the same. After some testing, I found that the spaces were only there if you deliberately put them in, in other words, it was not automatic. This also applis to lists. Therefore I came up with the following idea. If a system was set up, as part of the parsing that happens before articles are stored in the database, you could save quite a few megabytes of storage and bandwidth. I know a few megabytes isn't much, but it is still cheaper. Anyway, here are the calculations:
Approximately 4 spaces are wasted per page in lists and headings (guessed from the fact that a lot of pages don't have editable headings, but those that do often have a lot).
There are approximately 3,000,000 pages on the English Wikipedia alone (including user-pages and the like).
Therefore, with 3,000,000 pages each wasting 4 spaces, 12,000,000 bytes (11.4440918 MB) of storage is wasted.
Also:
There are approximately 2,600,000 edits per month (as of December 2005).
Therefore, that is 10,400,000 bytes (9.91821289 MB) of bandwidth wasted per month due to unnecessary spaces being shown in edit boxes.
Therefore, 119.018555 MB of bandwidth is being wasted each year due to unnecessary spaces.
N.B. These figures are only the actual changes; many people look at the Wiki-source of a page without changing it, meaning that these figures should probably be higher. Plus, this is for the English Wikipedia alone, although figures for all WikiMedia sites could be found (at least all the various languages of Wikipedia could). 80.229.152.24620:42, 4 February 2006 (UTC)[reply]
Well, 12MB of storage and 120MB of bandwidth are really nothing... it's not even a drop in the bucket. I find that the spaces make the headings easier to read in the code. Sometimes the spaces are automatic though, such as when you upload an image. Then the Summary and Licensing headings are spaced. ~MDD469620:50, 4 February 2006 (UTC)[reply]
12MB of hard disk space is worth about a penny. It's less space than the margin of error in estimating hard disk usage. Definitely worth it for the improved readability. —MichaelZ. 2006-02-04 22:36 Z
12MB of hard disk space is actually worth nothing at all. Many of our webservers have 80GB hard drives because that's the smallest the supplier wanted to sell us. We only use about 5GB of that for software and temporary space. MediaWiki is now configured to put text exclusively in that distributed storage. So we have terabytes of storage space available for text which was effectively free. -- Tim Starling08:14, 5 February 2006 (UTC)[reply]
In that case, may I now suggest that there is an automatic script that makes sure that every header has spacings between the equals signs? As you say, it makes it more readable and seeing that you have confirmed that the space does not matter, I think it would be worthwhile. I could try and write a bot to try and change all the existing headers if you like (not much point I suppose, but I always wanted to try and write one in Python) 80.229.152.24618:18, 5 February 2006 (UTC)[reply]
Don't see a point in doing it. If an editor makes a change to a page and wants to space it out for clarity, let them. Writing a bot to alter something that only editors will see seems a bit pointless to me. Don't waste your time. Rob Church (talk) 19:17, 5 February 2006 (UTC)[reply]
Weird links problem
I have a problem where all the links within Wikipedia suddenly turn into links to the Chinese Wikipedia's main page. When I close my browser (Firefox) and start it again, the problem goes away. Anyone know what is going on? Carcharoth22:04, 4 February 2006 (UTC)[reply]
I now have a screenshot of this, and another problem that I raised in the News section of the Village Pump about www.wikipedia.org displaying in a funny way. I'm going to take both these problems to the Help Desk as well. Carcharoth08:55, 5 February 2006 (UTC)[reply]
Okay, the screenshot is here Media:Wikipedia_links_problem.jpg. It doesn't show the mouse cursor, but the cursor is to the right of the dotted line (which shouldn't be there!). Pointing the mouse cursor anywhere to the right of that dotted line produces the link to the Chinese Wikipedia Main Page (seen in the display bar at lower left). Sometimes, when this intermittent bug arises, I see the Korean(?) Wikipedia Main Page (ko). The links to the left of the dotted line work OK. Is this some form of incorrect rendering that is spilling out from one of the interwiki links at the bottom of the page? Does anyone know what is going on? Is has happened about two or three times a day over the past few days. It disappears when I restart my browser (Firefox). Carcharoth18:32, 5 February 2006 (UTC)[reply]
Potential virus on Wikipedia
I was browsing, and I think I may have found a virus on the Monday Night Football page. At least, it triggered McAfee to alert me of the Trojan-QtPICT. I wasn't sure where to put this, but I felt someone needed to know. - Mewtation00:45, 5 February 2006 (UTC)[reply]
As far as I can tell, Trojan-QtPICT affects PICT files, which I don't think are allowed on Wikipedia. Also, when I visited Monday night football I didn't get any warning. Maybe you have some sort of spyware on your computer? ~MDD469600:58, 5 February 2006 (UTC)[reply]
What links to www.wikipedia.org?
Is it possible to find out how many links there are from within the English Wikipedia to the webpage www.wikipedia.org? I have been proposing that it should be linked from the Main Page, as discussed on the Main Page talk page here. One of the concerns I raised was that many users may arrive at the language areas without realising that this sort of "meta-home page" exists. So is it possible to search the Article and Wikipedia namespaces (but to exclude the Talk pages and other areas) for a specific link? Carcharoth08:29, 5 February 2006 (UTC)[reply]
the en main page has crosslinks to all the other wikis anyway. afaict the only reason that meta home exists at all is because someone thought it unfair that www.wikipedia.org went to one particular language. Plugwash22:00, 5 February 2006 (UTC)[reply]
Wow. Thanks! That list is shorter than I thought, so it is possible to see how distributed that link is throughout the English wikipedia. It will be helpful to point to this list in future discussions. Will that list be updated at regular intervals? Carcharoth17:51, 7 February 2006 (UTC)[reply]
We have an externallinks table now, so queries like that are indexed. I can't see myself remembering to update that list at regular intervals, but I can imagine myself (or some other developer who likes HTML more) writing a user interface so that anyone can do it. -- Tim Starling23:53, 7 February 2006 (UTC)[reply]
www.wikipedia.org not displaying properly?
[Copied from the news page of the Village Pump - posted in the wrong place]
"I've recently been adding some links here in the English Wikipedia to www.wikipedia.org, the multilingual portal for Wikipedia. But when I visited that webpage recently, I discovered that it wasn't displaying properly. The lists of other languages below the main icon and languages don't seem to be displaying properly. Unless it is just a problem my end (I was using the Firefox browser to view it), is it possibly to notify whoever maintains that webpage? Carcharoth09:29, 4 February 2006 (UTC)[reply]
The glitch is back again! Is anyone else getting problems with that page? You might have to visit it several times over the course of a day to see the glitch (unless it is a problem at my end). Where would be the best place to ask questions about problems with the www.wikipedia.org page displaying correctly? Carcharoth21:38, 4 February 2006 (UTC)[reply]
Thanks. I was sure this was the wrong place, but I had a suspicion that the technical forums might be focused on stuff on the editable part of Wikipedia. I suppose I could also contact the people who maintain that webpage. The only thing that looks vaguely like contact information is the wikimedia button at the bottom, linking to the WikiMedia Foundation. Carcharoth08:17, 5 February 2006 (UTC)[reply]
Actually, I'm going to copy this to the technical page of the Village Pump. The the Help Desk looks more like where to ask questions about how to use Wikipedia, rather than raise technical issues. Carcharoth09:05, 5 February 2006 (UTC)"[reply]
[end quote]
I now have a screenshot of what the page looks like when it doesn't display properly. I am currently trying to find out where to upload it. Carcharoth09:08, 5 February 2006 (UTC)[reply]
Thanks. I've now uploaded a screenshot, which can be seen here Media:Www_wikipedia_org_problems.jpg. Compared to the normal page, the Wikipedia bit at the top is missing, and there is nothing off the bottom of the screen. No way to scroll down and see the other languages. Is it likely to be a rendering issue with my browser (Firefox)? All the links visible on the screenshot work fine. Carcharoth18:25, 5 February 2006 (UTC)[reply]
Offhand it just looks like the logo text image failed to load. (By the way there seems to be something weird about your screenshots; they are scaled up for some reason?) --Brion19:10, 5 February 2006 (UTC)[reply]
It wasn't just the logo text image. It was everything "below the fold". Nothing off the screen loaded (nothing to scroll down to), so did the browser "trip up" at the text logo loading point and then fail to load the rest of it? I was hoping others had experienced the same thing, but it looks like it is just me. As for the screenshots, I pasted a screen capture on to a "blank image" in some rubbish image software thingy and expanded the screen capture to fill the "blank image". There was probably an embarassingly better way, but that would explain why it looks "expanded"! Thanks for the answer. If it happens a lot, I'll try and find something to fix the problem, which seems to be at my end. Carcharoth19:28, 5 February 2006 (UTC)[reply]
Pipe Links in Redirects
When I put a pipe link in a redirect, the redirect just takes you to the top of the page. Often it would be much more useful, especially on long and meandering pages, if you could be directed to the most relavent part of that page. Can this be fixed so pipe links work? --Username13222:50, 5 February 2006 (UTC)[reply]
Just use the # notation in the left side of the pipe link. The right side can still be any text you want. You can also do it without the pipe to make the link clear in discussion, but this looks awkward in an article: #Duplicate Categories, or T-34#Table of tank models. —MichaelZ. 2006-02-05 23:05 Z
Sorry, that's not quite what he wants, what's wanted is to be able to make a redirect page that links to an article section, rather than just the article. See this edit to Amber codon which he wanted to redirect to Genetic code#Technical details but it didn't work. I'd agree with him that the ability to make redirects like this would be valuable. - MPF23:22, 5 February 2006 (UTC)[reply]
Why did they all turn into ugly little question marks? I don't even have an option in preferences to not have question marks anymore! Is this deliberate; did someone change their minds about redlinks in general? -Splashtalk23:13, 5 February 2006 (UTC)[reply]
It seems to be ok again now, although I didn't change anything. For a brief while, the tick box text just showed me the choice of a red question mark or a blue question mark. Now it shows me the redlinked words "like this" again. Either a serverflip or a quickly reverted change by a dev. -Splashtalk23:16, 5 February 2006 (UTC)[reply]
Is that piece of config stored on the server or in a cookie? If a cookie, using a different machine or browser might give different behaviour? Regards, Ben Aveling10:51, 6 February 2006 (UTC)[reply]
I'm working on the Main page redesign project and testing ideas in my monobook.css for making the left search box slightly more noticable to new users (in event, consensus goes against the second search box on the main page).
One idea is to slightly modify the background color for the pBody div box, which is nested inside the "p-search" div box. However, this pBody div tag lacks an id, so I can't make any changes just to this div box in my monobook.
I'm not sure who has access to the MonoBook.php file, but it would be a big help if someone could add an id to this div box (see proposed change below):
While spot-checking OrphanBot's edits, I've come across a number of images (Image:Protosquad2.gif, Image:Lovely-red-fox.jpg) that appear to have been uploaded with the {{no license}} tag pre-applied. Is this a change to the MediaWiki software, did someone do partial or incorrect deletions of the images, or do I not have the ability to view edit histories for image description pages? --Carnildo09:19, 6 February 2006 (UTC)[reply]
After this edit of mine, the talk page is becoming blank except for dispalying a part of my message. Can some one let me know what is causing this?? --Gurubrahma07:15, 7 February 2006 (UTC)[reply]
Each language is effectively a seperate site (different policies, guidelines, users), so having subdomains for each language is a lot more logical. I don't think that Wikipedia needs to worry about search engine rankings... the good Wikipedia articles seem to float up on their own anyways. And I don't mean to sound rude, but your favicon is awful compared to the current one. ~MDD469622:22, 7 February 2006 (UTC)[reply]
Not without messing about with the configuration of the entire wiki farm, which we don't have time for
There's a logical reason we have separate subdomains for each language version
Could a feature be implemented to allow links to AIM, under aim:// protocol? This would facilitate user communication and be very useful. Thanks, --Urthogie12:04, 8 February 2006 (UTC)[reply]
