Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Red links
Line 859: Line 859:
I'm sure there used to be a set of options that came with a search that didn't find exactly what was typed - in particular the option to create a new page. Why has this disappeared (or why can't I still see it...). -- [[User:SGBailey|SGBailey]] 21:11, 29 December 2005 (UTC)
I'm sure there used to be a set of options that came with a search that didn't find exactly what was typed - in particular the option to create a new page. Why has this disappeared (or why can't I still see it...). -- [[User:SGBailey|SGBailey]] 21:11, 29 December 2005 (UTC)
:Do you see this if you enter something in the search box and click "Go", rather than "Search" (I do). -- [[user:Rick Block|Rick Block]] <small>([[user talk:Rick Block|talk]])</small> 23:10, 29 December 2005 (UTC)
:Do you see this if you enter something in the search box and click "Go", rather than "Search" (I do). -- [[user:Rick Block|Rick Block]] <small>([[user talk:Rick Block|talk]])</small> 23:10, 29 December 2005 (UTC)

== Red links ==

I don't know where to ask this at, but what do the red links mean?

Revision as of 02:39, 30 December 2005

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).

Please add new topics at the bottom of the page.

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.

Remove / increase recommended article size limit

Right now WP gives a recommendation to keep article sizes under 32kb every time you edit an article larger than that.

I know it once was a technical issue, but that is no longer so. While it is also true that large articles are better off broken into different subsections with the main article only listing summaries, still, even then 32kb is too little for good articles.

Another former reason reasonably valid 3-4 years ago when WP started was that not everyone has fast internet (many people still had 14,400 baud and 56k was considered good), but internet speed (like other computer-related measurable quantities) has increased exponentially in the last years, and now over half of internet users have cable/dsl for which downloading 100kb is nothing, and 99% of the rest have 56k which can also load a 50-100kb page reasonably fast.

About 90% of featured articles are WAY over 32kb. Except for really specific topics where one can cover it all in a smaller article (such as the recent shoe wax article), an article of 50 to 100kb is pretty much required to have enough material for featured status. Whereas before a good broad article was pretty much a collection of subpages with short summaries, the present widely accepted definition is an article which is strong and sound by itself, which can be informative on its own, and subpages would further expand on the subject for those interested in the particular subtopic, rather than being forced to go there just to understand the material of the main article.

And large article sizes are even more essential now when there is a big initiative to include lots of references and links.

You may say that its still not a big deal to have the reminder, but I'd argue that it may actually discourage editors (especially new editors) to contribute new material to an article which already contains quite a bit, but is still far off from FA.

In light of that, I propose to, either,

- Remove the warning at all, as irrelevant on both technical and editorial grounds, or

- Increase the article size reccomendation from 32kb to at least 100kb. Elvarg 04:19, 15 December 2005 (UTC)[reply]

I agree that instead of recommending any particular size, we should instead recommend that articles that grow to unwieldly lengths be broken up, where this term is subjectively determined on a per-article basis. Deco 04:26, 15 December 2005 (UTC)[reply]
I was under the impression the limit was first enforced because of a hard limit on the amount of text allowed in a editable text box in certain ld browsers. I think that that reason is now gone. I would support getting rid of the warning, and enforce common sense at the FAC stage. --Martyman-(talk) 09:30, 15 December 2005 (UTC)[reply]
Somebody mentioned the other day on the extra-long AfD that this is still an issue on handheld devices. Even there it's probably not a big problem, since you can edit individual sections (until you hit an edit conflict). Zocky 09:49, 15 December 2005 (UTC)[reply]

This is not only a problem with handheld devices, but also article style. Long articles tend to be daunting to edit and discourage further expansion. I think the 32k limit for a plain text simple article is already quite large. My suggestion is; create a new "Wikifeature" where long articles can be (like in most encyclopedias) and break up all articles longer than 40k into bits smaller than 20k. The only exception I can think of is the situation where the article is clearly too detailed already. Mozzerati 20:53, 21 December 2005 (UTC)[reply]

Are the figures of "over half of internet users have cable/dsl, and 99% of the rest have 56k" valid worldwide, or for a particular country? They sound a bit suspicious to me wrt many developing countries where poor quality telecoms are an ongoing beef. Given the potential value of WP in the Less Connected World, let's go easy on article length where feasible. JackyR 18:01, 28 December 2005 (UTC)[reply]

An article of substantial length, when properly organized, should have multiple sections, and thus each section is separately editable. I support removing the length recommendation/warning, or increasing greatly increasing it.--StanZegel (talk) 18:50, 28 December 2005 (UTC)[reply]

Image upload licensing line broken for IE

If you try to upload an image with IE, the handy-dandy licensing template button doesn't work - or more to the point, only the top three lines can be selected (no license, unknown licence, "image found"). Any useful templates you have to enter by hand. Can this bug be fixed, please? Grutness...wha? 12:33, 16 December 2005 (UTC)[reply]

No repro for me with IE 6.0.3790.1830 on Windows Server 2003 SP1 Standard. Deco 02:13, 17 December 2005 (UTC)[reply]

Well it's no go with 5.2 on Mac OS 10.2. Grutness...wha? 23:05, 17 December 2005 (UTC)[reply]

Please file it as a bug report on BugZilla if it's a reproducible bug, and provide clear information on the conditions under which it occurs, and steps for reproducing, if possible. Thanks. Rob Church Talk 04:00, 18 December 2005 (UTC)[reply]
Thanks - now listed as Bug no. 4313. Grutness...wha? 06:11, 19 December 2005 (UTC)[reply]
Whoops; the bug it's duped to is one I was aware of. Getting forgetful in my old age. ;-) 86.133.53.111 13:26, 22 December 2005 (UTC)[reply]
When talking about IE mac please state that from the start. When you just say IE people will assume IE windows which is build on a totally different rendering engine from IE mac. Plugwash 16:13, 25 December 2005 (UTC)[reply]
Whoops - yes, sorry. I did when I started to write this, but it got lost in my copyediting before I pressed save. Grutness...wha? 23:57, 27 December 2005 (UTC)[reply]

Telnet links

It seems that while external links to IRC servers (e.g. - [1]) and FTP servers (e.g. - [2]) link correctly, links to telnet servers (e.g. - [3]) do not get handled properly. I'd like to think this is a simple thing to fix, hence my posting it here. Comments? —Locke Cole 12:13, 18 December 2005 (UTC)[reply]

telnet is an obsolete protocol, and should not be encouraged to be used, there shouldn't be any links to telnet-servers from wikipedia at all AzaToth 13:33, 18 December 2005 (UTC)[reply]
IRC and FTP are obsolete as well, so the "it's obsolete" argument doesn't really hold a whole lot of weight for me. As for links to telnet servers, while they continue to disappear, there are still bulletin boards (for example) that operate on the internet that may be worth linking to. —Locke Cole 13:51, 18 December 2005 (UTC)[reply]
So we shouldn't be linking to servers that only support HTTP/1.0 either? How is whether or not the protocol is considered deprecated at all relevant to anything? (and AFAIK IRC at least hasn't been deprecated by anything) —Ævar Arnfjörð Bjarmason 14:03, 18 December 2005 (UTC)[reply]
Some might argue that IM has largely replaced IRC (especially where the IM protocol supports having groups of people together ala an IRC channel). But that's really besides the point and not something I want to debate: whether or not it's obsolete is irrelevant. Afterall, I note that the old gopher protocol is supported: [4]. So can something be done for poor old telnet? :P —Locke Cole 14:15, 18 December 2005 (UTC)[reply]
Define obsolete... Telnet is still is use, remote Linux shells, finantial institutions MUD games etc still use them, as well as remote administration of routers, printers and what not. Now granted there are no longer a huge number of public telnet services available, but still. It's usefull if you want to provide a direct link to for example a MUD like telnet://discworld.imaginary.com or whatnot...--Sherool (talk) 14:43, 18 December 2005 (UTC)[reply]
Yeah, in my case I was specifically thinking of MUD servers that are open to the public. And like I mention above, for whatever reason, the Gopher protocol is still supported. So telnet seems like a given. :P —Locke Cole 06:18, 21 December 2005 (UTC)[reply]

Since this won't hurt anything (it's not like people are using telnet:// for anything else) and it might be useful I've gone ahead and enabled it in MediaWiki. —Ævar Arnfjörð Bjarmason 06:29, 21 December 2005 (UTC)[reply]

Thanks Ævar! —Locke Cole 17:00, 24 December 2005 (UTC)[reply]

Google Web Accelerator causing problems?

I recently gave UrineForGas (talk · contribs) a {{usernameblock}} and managed to inadvertently block several other users.

It seems that they are using Google Web Accelerator and this seems to be acting as a IP proxy. As our article says it seems to cause administrative websites such as ours problems.

IP addresses mentioned are 64.233.173.85 and 72.14.194.19 -- both belong to Google web accelerator. See http://ws.arin.net/cgi-bin/whois.pl

Do we have a policy of blocking proxies on site because they cause problems with IP addresses? I know you can't edit through Babel Fish (website). Or not? — Dunc| 17:02, 18 December 2005 (UTC)[reply]

If anyone from anywhere on the Internet can use it as a proxy, even if it requires installing a specific program, it should be considered an open proxy, and indefinitely blocked. --cesarb 23:07, 18 December 2005 (UTC)[reply]
Open proxies are blocked when they allow editing, not when they simply read pages. It's very common for ISPs and countries to use read caching proxies and those are harmless. The potential for harm from the Google Web Accelerator is that it goes and loads pages which the user hasn't clicked on. It's proably insignificant at present. Jamesday 22:32, 19 December 2005 (UTC)[reply]
Yes, that's what I meant; I should be more careful in my phrasing. --cesarb 19:21, 25 December 2005 (UTC)[reply]
The official FAQ says it can be disabled for specific sites, which means it might be possible to block it with a message asking people to add wikipedia to the list. But this should probably be discussed at WP:AN first. --cesarb 23:10, 18 December 2005 (UTC)[reply]

Possible commiting fraud using signatures

If enabling raw signatures, and add to the signature ~~~~ and/or {{subst:template}}, then those will get expanded by the next editor, not the editor whose signature contains given strings AzaToth 16:17, 19 December 2005 (UTC)[reply]

  • Correct. If you know of anybody who does so, please notify us at the admin noticeboard. Disruption of this kind should be nipped in the bud. Radiant_>|< 16:24, 19 December 2005 (UTC)[reply]
    • It can be rather difficult, for example if someone combine this with hiding the content (pure css), and using a timed expansion (for example it only expand on fridays). It could be almost a week between the expansion and the original commit. AzaToth 16:29, 19 December 2005 (UTC)[reply]
      • Yes, I realize that. It may be worthwhile to ask the Devs (on Bugzilla) to disallow the ~ character in raw signatures. In the meantime, if anyone is doing this, they should consider that it either violates WP:POINT or is downright vandalistic. Radiant_>|< 16:35, 19 December 2005 (UTC)[reply]
        • (Azatoth's comment stricken - WP:BEANS - I'm sure you mean well but please don't create guides to vandalize Wikipedia) Radiant_>|< 16:46, 19 December 2005 (UTC)[reply]
          • Oops, sorry. What I ment is that signatures should escaped some chars ({}~), also, I don't understand what WP:BEANS says, is it some internal? AzaToth 16:48, 19 December 2005 (UTC)[reply]
            • In a nutshell, BEANS means: don't give potentially-malicious users ideas on how to do malicious things. android79 16:53, 19 December 2005 (UTC)[reply]
              • Hehe, it's tricky to describe a possible problem without give out the idea about the problem AzaToth 17:02, 19 December 2005 (UTC)[reply]
  • Yep. Please notify the developers at Bugzilla about this issue. That should help, given the signature crisis of last month. Radiant_>|< 16:57, 19 December 2005 (UTC)[reply]
This is something I thought of separately, although it's good to see my thoughts echoed here. It's now something we're aware of and will likely patch up soon. 86.133.53.111 18:06, 23 December 2005 (UTC)[reply]

New Cite extension (now installed on Wikimedia)

Note: This has now been installed on the cluster, happy hacking;)Ævar Arnfjörð Bjarmason 01:08, 25 December 2005 (UTC)[reply]

Following a discussion on my talk page I've written a followup to my Special:Cite extension, a specification and test page for it are avalible on my test wiki.

It basically adds sofware support for the {{ref|}} and {{note|}} hacks that are being used right now for citations, citations can be specified inline with it as <ref[ id]>Some citation text here</ref>, if you supply id you can reference it again as <ref id/>. There's no need for adding something like {{note|}} for each citation anymore because the citation section will be automatically generated on the page wherever the editors put <references/>. This improves workflow a lot because it's possible to edit an individual section adding <ref> tags in it and it'll automatically be referenced in the section where <references/> is. The output of <references/> is completely customizable through the MediaWiki namespace so editors aren't bound by what I cooked up.

I'd like to get some comments on how it works (and should work), some things that need fixing currently are to make the error output prettier (need some styling, any ideas?) and most of all, make it work with my mortal enemy, HTML Tidy. —Ævar Arnfjörð Bjarmason 01:24, 21 December 2005 (UTC)[reply]

Way frickin' cool! Someone built a telepathy machine and figured out what I was hoping for regarding footnotes! Yes, please add this into the code, exactly as you've got it specified, so I can start using it yesterday! Really, that's exactly the way I had envisioned a proper references system working, I just didn't have time to put my thoughts down into a statement more coherent than this spec. B-) Slambo (Speak) 02:20, 21 December 2005 (UTC)[reply]
I object to the abuse of XML-like syntax. It would be better to use <ref name="id">...</ref> and <ref name="id"/>. This is more similar to all other uses of XML-style tags on Wikipedia, and the use of "name" has a precedent on HTML forms (use of "id" as the attribute name would be confusing, since IDs are supposed to be used only once, while on HTML forms a "name" value is often used more than once). --cesarb 02:30, 21 December 2005 (UTC)[reply]
While I agree with CesarB's objection, I found one part of the extension a bit difficult to understand: the automatic numbering of the list doesn't correspond to the actual citations. So you clicked number "6" and you get sent to number 5. I understand that the way the system is built to handle multiple citations, this must be done, but it is confusing.
While I haven't thought about it much, I might propose keeping all reusable refs the same number. But whatever you do, I think you keep the list number matching the reference number. — Ambush Commander(Talk) 02:34, 21 December 2005 (UTC)[reply]
I was a bit unsure about how to handle that, articles like Alchemy currently use a b c d e f ... for that. That's a bit hard to handle in code though (remember that it has to handle every language out there), one way to do that would be to have a MediaWiki message with whitespace delimited tokens that should be used for that, .e.g "a b c d e f g h.." or "á a b é ..." depending on the language. Another way would be as you suggested to use the number of the actual reference, to do that properly however it couldn't use a HTML ordered list (<ol>), that's doable too, and that could easily be supported. —Ævar Arnfjörð Bjarmason 03:21, 21 December 2005 (UTC)[reply]
The convention for backlinks became a b c... simply to have symbols which are different for many backlinks. I thought it would be awkward to use numbers for both downlinks and uplinks. Maybe PHP could emit other symbols, although having them memorably sequential is helpful for tasks such as clicking on each one while checking refs. (SEWilco 04:55, 23 December 2005 (UTC))[reply]
Yup... it seems the numbers of the links aren't that important to you. Love the idea though. Absolutely awesome actually. — Ambush Commander(Talk) 02:36, 21 December 2005 (UTC)[reply]
I like the idea, but is this the 3rd or 4th footnoting system? Already putting urls in square brackets makes big numbers [5]. Then {{ref| whatever makes little numbers. There's some other system I think that forces you to number the references explicitly. And now this. I like it, but please can we kill off the other systems? Also I agree about the faux-XML syntax. It would be nice if it could conform to wiki syntax, like being <<ref id|url>> or ((ref id|url)) or something. Stevage 02:40, 21 December 2005 (UTC)[reply]
Discuss the multiple systems at the Talk page for WP:CITE. (SEWilco 04:55, 23 December 2005 (UTC))[reply]
Agree, I like the XML though, just use name instead of id. —Locke Cole 02:57, 21 December 2005 (UTC)[reply]
I chose to go with <ref[ id]> rather than <ref[ id=id] because it's quicker to type and there isn't a current need (and I can't imagine a need) for extra parameters, but even if extra parameters were to be added it would be easy to support them and the current system. Our extension paramters aren't XML anyway, not even close. —Ævar Arnfjörð Bjarmason 03:12, 21 December 2005 (UTC)[reply]
I would strongly suggest using <ref[ name=id]>. —Locke Cole 03:35, 21 December 2005 (UTC)[reply]
They aren't XML, but they are XML-style. You'd be having one style (key=value) for almost everything, and another (naked value) just for <ref>. I can also easily imagine a lot of extra parameters: class=, style=, dir=, id= (to turn it into an anchor), etc. Supporting both key and value pairs and a naked value can quickly become confusing. I also think it's better to use <ref [name="id"]> instead of <ref [id="id"]> due to the common implied semantics of the id attribute. --cesarb 03:39, 21 December 2005 (UTC)[reply]

Some valid suggestions above (I especially agree with the need for the inline-number to match up with the down-below-number, one way or another, in all cases: otherwise printed output is essentially broken, since you can't figure out which note is for what) but I'm mostly going to say this: PLEASE HURRY! THIS IS GREAT! :-) (Sorry for the shouting.) Oh -- why not dump all the notes at the bottom of the page if a <references/> tag isn't present? That would make it even friendlier to learn. —Bunchofgrapes (talk) 02:48, 21 December 2005 (UTC)[reply]

agreed. Despite it's learning curve (I figured it out in 2 minutes), it's better than what we have now. Broken S 02:53, 21 December 2005 (UTC)[reply]

There is very little in wikipedia where the code is XML-like and I'm not sure we want to encourage that. To borrow a page from Docuwiki, how about notation like ((footnote text)) and for repeated references ((name | footnote text)) with simply ((name)) being refered back to the defined footnote text. I realize such a configuration would be somewhat harder to write a parser for, but wiki code is meant to be as simple as possible on the writer, not the parser, right? Regardless an effective citation system would be a big step up for wikipedia. Dragons flight 03:20, 21 December 2005 (UTC)[reply]

Because for a parser it introduces possible ambiguity. OTOH, XML is a standard, and it should be embraced. —Locke Cole 03:31, 21 December 2005 (UTC)[reply]
Another possibility is to use a template as an interface so the template syntax is used. {{ftemplate|text}} or {{ftemplate|name=Time3|text}} could be used, with the template emitting the XML-like wrapper. (SEWilco 04:55, 23 December 2005 (UTC))[reply]

This is your brain | This is your brain on Tidy, Tidy completely messes up inline parser extensions for some reason and until that's fixed (or Tidy is disabled) it can't and will not be enabled on Wikimedia sites. I think tidy should be disabled anyway, it encourages sloppy and unportable syntax. It was disabled for a few days not so long ago and people whined to get it back;/ —Ævar Arnfjörð Bjarmason 03:26, 21 December 2005 (UTC)[reply]

I'd like to help, but I fail to see any difference between these two links. --cesarb 03:47, 21 December 2005 (UTC)[reply]
See these screenshots: without Tidy, with Tidy. —Ævar Arnfjörð Bjarmason 04:05, 21 December 2005 (UTC)[reply]
BTW, Avar, your site is consistently giving unknown page format errors on IE for me and wants me to save your content to disk rather than view it. Netscape is well behaved though. Are others getting the same response? Dragons flight 03:49, 21 December 2005 (UTC)[reply]
I think this is because the pages have no extensions, and so IE doesn't open them as html pages. I saved the spcs page to my hard disk, remnamed it to cite.html, and then (and only then) I could view it.DES (talk) 03:56, 21 December 2005 (UTC)[reply]
That's probably because he's using XHTML with the application/xhtml+xml MIME type, which older browsers do not understand. Using a more recent browser would fix the problem. --cesarb 04:02, 21 December 2005 (UTC)[reply]
Yeah, that's it, Internet Explorer doesn't support the reccomended MIME types for XHTML. —Ævar Arnfjörð Bjarmason 04:05, 21 December 2005 (UTC)[reply]
Firefox also seems to be happy (not surprisingly). My IE can't get any more current, and so as someone who does web development, I am a little surprised you'd rely on a format not supported by 80+% of the web browsing audience. Dragons flight 04:13, 21 December 2005 (UTC)[reply]
He's probably relying on the application/xhtml+xml MIME type because it forces the browser into a strict mode, where even the smallest misclosed tag will cause the whole page to fail to render with an ugly error message. Since it's a test site for his changes to the MediaWiki codebase, being more strict is useful. --cesarb 13:03, 21 December 2005 (UTC)[reply]
Exactly, keeps the code I write error free in that area. —Ævar Arnfjörð Bjarmason 13:59, 21 December 2005 (UTC)[reply]
If the files have an HTML or an XHTML extension IE will open them. I'm not sure if it then obeys the strict mode or not, but I presume that the browsers which do support this MIME type will still support it even if the extension is present. DES (talk) 22:32, 21 December 2005 (UTC)[reply]
Browsers do not use the file extension, unless the file comes from the local filesystem (i.e. a file: URI). They always use the MIME type supplied by the HTTP server. There are some obscure situations in which MSIE ignores the MIME type (thus breaking the specification) and tries to guess the file type, causing much grief to webmasters, but this is not one of them. So, what is happening is that, when you saved the page to your local filesystem, it lost its association to the application/xhtml+xml MIME type, and MSIE had to guess using the file extension (which being .html gives the text/html MIME type). --cesarb 14:50, 22 December 2005 (UTC)[reply]

Update: I solved the issues I was having with tidy, this might be enabled soon, brion seemed to like the idea. —Ævar Arnfjörð Bjarmason 04:43, 23 December 2005 (UTC)[reply]

Another update: Brion did a review of it and we found some issues with it, in particular it would break the static HTML dumps. Also there were issues with using <ref key> (could only use [A-Za-z0-9_] keys) so I went for <ref name=""> as suggested above. Just as I was about to fix all this stuff, commit & deploy it my hard disk broke down, so I won't be able to do it until sometime after Christmas, hopefully. Currently doing a backup over 802.11b hoping it'll keep spinning (all my MW work is backed up though). —Ævar Arnfjörð Bjarmason 20:18, 23 December 2005 (UTC)[reply]

Sorry to hear about your hard disk problems, glad to see this is close to getting implemented though. Nice work. =) —Locke Cole 17:10, 24 December 2005 (UTC)[reply]

I managed to get it working anyway, it's now installed, merry winter-holiday-thing;) —Ævar Arnfjörð Bjarmason 01:08, 25 December 2005 (UTC)[reply]

I don't think it is working properly, the numbering is all wrong... See Sant Mat. I have converted to the new system, but the numbering is not correct. ≈ jossi ≈ t@ 23:53, 26 December 2005 (UTC)[reply]
The numbering may be correct in the refs, but the numbering in the generated reference section do not match the inline citation numbers, specifically when you use <ref name=Myref /> to note an additional citatiion to a ref previously included. This problem is clearly visible in Sant Mat ≈ jossi ≈ t@ 00:08, 27 December 2005 (UTC)[reply]
Well that's because it wasn't designed to do that, i.e. not a bug. However people didn't like the way it was designed so I changed it, the numbers now line up perfectly. —Ævar Arnfjörð Bjarmason 22:49, 29 December 2005 (UTC)[reply]

I've enabled Special:Unwatchedpages for users with protect permission (that's sysop and above to those not familiar with the permission system), there 5000 rows generated on that page as opposed to the usual 1000, making that value larger is a bad idea since paging gets exponentially more expensive the further in one goes (that can be fixed though).

Having more people watch pages might help avoid something like the recent incidents, it's restricted so that it won't serve as a "vandalize this" list, currently approximately 27% of pages in the main namespace which are not redirects are watched (252502/906363*100 = 27.85881594901821896900). —Ævar Arnfjörð Bjarmason 06:07, 21 December 2005 (UTC)[reply]

It would be useful to know how many of these unwatched pages are categorized and how many appear in lists. It generally more difficult to find a page associated with a particular topic area if it is not included in that topic area by categorization, thus making it more difficult to find for watching. Also, some people monitor large numbers of pages for changes via the related changes function applied to lists; such monitoring can decrease the percentage of pages appearing on watch lists despite their being watched indirectly. User:Ceyockey 05:35, 23 December 2005 (UTC)

Watchlist

Is it possible to transclude my watchlist in User:Rschen7754/Tools just like the AFDs are set up? I'm not sure if it is but I thought I'd give it a shot. --Rschen7754 (talk - contribs) 08:27, 21 December 2005 (UTC)[reply]

Try it and see. 86.133.53.111 17:18, 23 December 2005 (UTC)[reply]

External Link Icon appears on every link

Within the past day or so, my browser has started showing the external link icon (box with an arrow) after every single link within articles, including internal wiki links. Its making WP quite annoying to read. Can somebody explain this? I haven't made any changes to my browser recently. --Mcpusc 12:33, 21 December 2005 (UTC)[reply]

Is your browser the Opera 9 beta? This is a known issue; report the bug to Opera. --Brion 23:44, 21 December 2005 (UTC)[reply]
Nope, its FireFox 1.0.7, which I've been using for months without this showing up. I can't recall making any config changes, but it this isn't a widespread problem, I guess I'll have to check that. --Mcpusc 00:24, 22 December 2005 (UTC)[reply]
I've been seeing this too, but only on links that I clicked to open in a new window or tab (so it's not exactly the same thing but looks related). I'm using Firefox 1.5. -- grm_wnr Esc 04:25, 25 December 2005 (UTC)[reply]

Talk page diff link

I really like the new diff link that comes up on the "New Message" bar. However, if I could request one small change: The diff link only shows the diff of the last person to edit the message. If it could show all the edits that were made since you last saw the page it would be a lot more useful. — Asbestos | Talk (RFC) 15:47, 21 December 2005 (UTC)[reply]

This would be helpful for watchlists, but not very feasible, as the MediaWiki software would have to know which pages you had seen. (huge overhead) — Ambush Commander(Talk) 22:35, 21 December 2005 (UTC)[reply]
I believe the proposal is simply to show changes since the last time that user had viewed their talk page (and only that page). This isn't unreasonable at all, only requiring the storage of the version of that page last seen by that user. Deco 22:45, 21 December 2005 (UTC)[reply]
Ah... that's right. Well... I'm just some lowly MediaWiki hacker with no arcane knowledge of MediaWiki's internals, so I really can't tell you if it's feasible or not. — Ambush Commander(Talk) 23:01, 21 December 2005 (UTC)[reply]
I coded something people like? I must be doing something wrong. Anyway, hmm...well, it's technically feasible, I suppose, but a bit more fiddly. Still, I'll have a play - nothing's impossible, after all. 86.133.53.111 13:37, 22 December 2005 (UTC)[reply]
That might seem like a small change to you but in fact, it is not. —Ævar Arnfjörð Bjarmason
Ævar, if it is you who coded the change, then yes I'd like to add that I think it's a great idea, and very helpful. I'd usually open the history right away to see what had changed, and this saves me several steps. Thank you for this excellent addition. — Knowledge Seeker 05:21, 26 December 2005 (UTC)[reply]
Nah, Avar didn't code it, but he did commit it, however, he was talking to me. I'm not sure what he's on about though, so I'll pester him later. 86.133.53.111 19:17, 26 December 2005 (UTC)[reply]

Rollback bug?

I ran across an odd edit at Troy. According to Master Jay this was the result of using "rollback" to revert this edit by 70.188.178.146 to the 20:44, December 18, 2005 revision of the article. But if you compare that version with the version produced by Master Jay's edit, you can see that in fact his edit, in addition to the intended reversion, introduced several other changes. Is there a bug in the "rollback" feature? Paul August 04:14, 22 December 2005 (UTC)[reply]

User:Master Jay isn't a sysop, so could not have used the rollback feature. If he used a local javascript hack, that hack might be buggy. --Brion 04:22, 22 December 2005 (UTC)[reply]
Let's cripple such hacks. 86.133.53.111 17:10, 23 December 2005 (UTC)[reply]

Semi-protection and George W. Bush

JosephBostwick (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log) is the first vandal of George W. Bush under semi-protection, and he did so 2 minutes after registering the username. Clearly, the time-delay aspect of semi-protection hasn't been implemented yet.

Probably we should introduce some artificial delays for registering an account... make them do captchas or answer skill-testing questions for about 30 to 60 seconds. Something that can't be automated: random obvious skill-testing questions like "how many legs does a dog have?" that any human can answer but would stump a registration bot. A set of several hundred randomly varying skill-testing questions might be preferable to captcha, because visually-impaired users wouldn't be affected.

This wouldn't be much of an annoyance to legitimate users (who only register one or a couple of accounts, ever), but would raise the hassle factor for large-scale throwaway account creation. It's like spam... if you could charge 1 cent per e-mail message, spam becomes uneconomical. Same concept. -- Curps 11:15, 22 December 2005 (UTC)[reply]

Let's just put the 4 days thing into effect...see if we can get the software to accept that...and just do that. --Woohookitty(cat scratches) 12:52, 22 December 2005 (UTC)[reply]
Not the whole mess, please. As to the problems - it's quite possible, as Brion appears to mention it's a configuration option, that he made the honest oversight of not enabling that option in the English Wikipedia's configuration. 86.133.53.111 13:19, 22 December 2005 (UTC)[reply]
Spelled it wrong in the config. :P Fixed. --Brion 23:56, 22 December 2005 (UTC)[reply]

Adding CSS for metadata

I would like to add the following CSS to Common.css:

/* Metadata */

table.metadata {
        border: 1px solid #aaaaaa;
        display: none; 
}
.metadata-label {
        color: #aaaaaa;
}

This will help us to implement metadata schemes like the German Wikipedia does, which will open up a whole new world of possibilities for accessing Wikipedia data. For example, imagine being able to search for all Wikipedia articles on authors who died in 1954, or cities in Italy with more than 100,000 people. For more info on the German effort, see this article. The first step is being able to add hidden metadata to articles, which this CSS will make possible. The second step is to create metadata templates such as Template:Persondata. The third step is to take over the world! Muhahahaha! Kaldari 17:57, 22 December 2005 (UTC)[reply]

I've gone ahead and added the necessary CSS so that I can develop a proof of concept for the English Wikipedia. Stay tuned... Kaldari 19:39, 22 December 2005 (UTC)[reply]
If you'd like to keep track of my efforts, check here: Wikipedia:Persondata. Kaldari 23:56, 22 December 2005 (UTC)[reply]

View source and template list

When viewing source of a protected page, it would be good to be able to show a list of templates that the page includes, in the same way as you currently get when editing a page. Of course, there may be a case for those templates being protected themselves, but that's not a strong reason against having a list of them in a convenient form. TerraGreen 18:31, 22 December 2005 (UTC)[reply]

No more time delay for page moves either??

User:Guillermo con sus ruedas was created at 17:54 today and started pagemove vandalism immediately. A bunch of other socks followed. What happened to the time delay for doing page moves? -- Curps 19:12, 22 December 2005 (UTC)[reply]

  • I was wondering about the same thing as well. It seems that the page-move throttle may have been inadvertently removed during the recent software upgrade. --Ixfd64 19:16, 22 December 2005 (UTC)[reply]
It's a four-day delay on new accounts created since the upgrade. --Brion 23:48, 22 December 2005 (UTC)[reply]

new protection feature

I don't know if this is intentional, but for pages that are protected from editing by new users, the page protection link still shows as "protect this page" as if it's not protected. For example, see the penis article. --Ixfd64 19:14, 22 December 2005 (UTC)[reply]

It's not that different from pages protected against moves having the link show as "unprotect". --cesarb 22:18, 22 December 2005 (UTC)[reply]
IMO now we have so many different types of protection changing the text on that button has outlived its usefullness and it should just be marked "protection" and take the admin to a page showing the pages current status and letting them change it. Plugwash 23:11, 22 December 2005 (UTC)[reply]
It says 'unprotect' to me. --Brion 23:47, 22 December 2005 (UTC)[reply]

Huh?

I tried to move a page and was told my account was too new -- but I have been here for a few months now! Has moving broken somehow, are there new restrictions, or something? I haven't heard anything regarding this... --WCQuidditch 23:58, 22 December 2005 (UTC)[reply]

After seeing a question above -- is this an inadvertent side effect of a recent upgrade? --WCQuidditch 00:00, 23 December 2005 (UTC)[reply]
You're not the only one who is experiencing this problem. Perhaps it's restarting the count for everyone. -- Dissident (Talk) 01:05, 23 December 2005 (UTC)[reply]
That's fixed. --Brion 01:44, 23 December 2005 (UTC)[reply]

Problem with donations page header?

Just today, the little box at the top of each page which starts "You can help Wikipedia grow and improve by donating here!" has started appearing to the right of the page title, not above it like it usually does. If this is a bug, it's happening on every page I go to. If it is deliberate, I think it looks terrible :). So which is it? Raven4x4x 04:19, 23 December 2005 (UTC)[reply]

I bet some sysops are arguing over the best place to put it, so it's been schizophrenic. Try clearing your cache... if only I could find the page where this stuff gets edited. Personally, I don't like it floated to the right. Looks like some ugly ornament that was lackadaisically slapped on. — Ambush Commander(Talk) 04:21, 23 December 2005 (UTC)[reply]
The appropriate place is MediaWiki:Monobook.css. Titoxd(?!? - help us) 04:23, 23 December 2005 (UTC)[reply]

I've gotten fed up with the ugly popup box and have taken things into my own hands. Insert this code into your Monobook.css and the fundraiser notice will be waaay less intrusive (but still there).

div#siteNotice {float:none;border:0;background:inherit;margin:0;}
div#siteNotice * {display:inline;font-size:8pt;}
div#siteNotice img {display:none;}

Ambush Commander(Talk) 22:11, 23 December 2005 (UTC) [reply]


  • My suggestion is to add the following to your monobook.css file and get rid of it entirely:
#siteNotice { display:none; }
#mpbanner { display: none; }

JtkieferT | C | @ ---- 03:09, 25 December 2005 (UTC)[reply]

This, kiddies, is exactly what you should not do. =P Remember: you want to support Wikimedia! So leave the banner on! But feel free to get rid of the really annoying parts.
One last thing: setting siteNotice to display:none will prevent you from figuring out when the fundraiser is over, or when there's another important sitenotice to be read. — Ambush Commander(Talk) 03:20, 25 December 2005 (UTC)[reply]
oooOOOOooo... the ghosts of Wiki past, present, and future visit Jtkeifer in the night
:) rspeer / ɹəədsɹ 03:47, 25 December 2005 (UTC)[reply]

vandal edit summaries violating privacy policy

Could a developer please remove the summaries from the following edits? All of these edits are from the Jimmy Wales article:

All the times are in Pacific Standard Time.

I will post the links to the bad edits on the George W. Bush article (also badly-hit) shortly. --Ixfd64 05:23, 23 December 2005 (UTC)[reply]

All right, here are the bad edits I found on the George W. Bush article:

Again, all the times are in Pacific Standard Time. I'm pretty sure that similar edits also exist elsewhere. Unfortunately, I do not have the time to look for all of them. If anyone spots any similar edits, please take the time to report them here. Thanks! --Ixfd64 05:57, 23 December 2005 (UTC)[reply]

The bush links don't load for me (starts my browser spinning until I close the tab), but the edits to Jimmy Wales giving Jimbo's address are pretty harmless. His address is already readily available to anyone with 30 seconds of time on google; for example it is available here: meta:Articles of Incorporation. Thue | talk 18:13, 23 December 2005 (UTC)[reply]

Clickable maps

I've continued my quest to find a good way of creating clickable maps on Wikipedia. Using the new {{click}} I've put together a map of a prominent portion of Ottawa. It looks much better and is more precise than my previous ACSII art maps, and it would be even better if it had been done by someone with a modicum of artistic ability.

My main concern is that this technique, which uses dozens of very small images, will cause the image server to explode. If this process can be used, I'm also wondering if there is anyway to make it easier. The very small map at Wellington Street took many hours of work. - SimonP 20:49, 23 December 2005 (UTC)[reply]

This is the absolute antithesis of everything HTML is about. {{click}}, in my opinion, is just a horrible hack. Developer's help needed: what are the security implications of HTML image maps? — Ambush Commander(Talk) 22:14, 23 December 2005 (UTC)[reply]
{{Click}} is a bad idea -- it's critical to the GFDL that credit for the images be easily available, and this hack circumvents that. There were long arguments about enabling linked images just for the {{Sisterprojects}} template on the main page. Add comments to bugzilla 1227 if you want developers to work on providing proper image maps, but I don't think this is the way to go about it. — Catherine\talk 00:00, 24 December 2005 (UTC)[reply]

How do you turn on Uploading?

I have a Wiki site and for the life of me I can't figure out how to turn on uploading for pics and such. This is what I have in my LocalSettings.php file and it still doesn't work.

$wgEnableUploads		= true;
$wgUseImageResize		= true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";

Any ideas as to how to get it to work? Is this configured properly? Thanks and my email is bucklerchad@comcast.net I'm always online. Sniggity 21:45, 23 December 2005 (UTC)[reply]

Those settings should enable uploading. You have ImageMagick installed, correct? And, it would be helpful if you told us what the error message is, as well as your version of MediaWiki. — Ambush Commander(Talk) 22:12, 23 December 2005 (UTC)[reply]
that looks right to me. Does the upload link show and if so what happens when you try and use it? Plugwash 22:43, 23 December 2005 (UTC)[reply]
Alright, I downloaded ImageMagick, where would I install it? 69.250.106.39 22:54, 23 December 2005 (UTC)[reply]

I don't think I have it installed, at least I didn't install it. How/where would I install it if you don't mind me asking? Just upload it to my root folder via FTP? I'm brand new at this as you can probably tell. lol Also, the only thing is tells me is "Sorry, Uploading is Disabled" when one tries to add a picture to my site. The site is http:/www.wikibands.org/ if you'd like to try it out. There is still a lot of work that needs to be done, but it's hard doing it all alone. Thanks very much ! One more thing, I am using the most recent version of Wikimedia. Sniggity 22:46, 23 December 2005 (UTC)[reply]

no, the upload link doesn't show. Sniggity 22:46, 23 December 2005 (UTC)[reply]

Alright, I downl'd ImageMagick, where would I install it? Thanks Sniggity 22:55, 23 December 2005 (UTC)[reply]

Ah... nevermind with the ImageMagick. You probably already have GD installed, so there's no need to add another image editing software. Comment $wgUseImageMagick.
This may sound stupid, but make sure you've copied the configuration changes to the server. And it's MediaWiki (not Wikimedia). — Ambush Commander(Talk) 23:03, 23 December 2005 (UTC)[reply]

I scratched the ImageMagick, and now I have the following:

$wgEnableUploads		= true;
$wgUseImageResize		= true;
$wgUseImageMagick = false;
$wgImageMagickConvertCommand = "/usr/bin/convert";

Also, what does uncomment/comment mean? I uploaded it to the server and this is the page I get when I try to upload a picture. http://www.wikibands.org/index.php?title=Special:Upload Sniggity 23:50, 23 December 2005 (UTC)[reply]

There's no need to add a <br> to the start of your message.
Commenting looks like this: //this is a comment. It's the way the line looked like before you put it there.
I'd like to test something: write after that block, put exit;. — Ambush Commander(Talk) 23:57, 23 December 2005 (UTC)[reply]

I'm sorry, I don't understand what you mean, after what block? Also, this is what I have now for localsettings.php:

## To enable image uploads, make sure the 'images' directory
## is writable, then uncomment this:
# $wgEnableUploads		= true;
$wgUseImageResize		= true;
# $wgUseImageMagick = //
# $wgImageMagickConvertCommand = "/usr/bin/convert";

Sorry about all this, I hate being a noob at things. I learn fast though

Sniggity 00:08, 24 December 2005 (UTC)[reply]

If by block you mean the code, I now have this uploaded to the server:

## To enable image uploads, make sure the 'images' directory
## is writable, then uncomment this:
# $wgEnableUploads		= true;
$wgUseImageResize		= true;
# $wgUseImageMagick = exit;
# $wgImageMagickConvertCommand = "/usr/bin/convert";

It's still not uploading. BTW, I apprecaite your help very much. Any other suggestions? Sniggity 00:12, 24 December 2005 (UTC)[reply]

I found out what version of GD I have, it's 1.6.2 not 2.0. Does that help in your quest to help me?

Sniggity 00:39, 24 December 2005 (UTC)[reply]

I just did this code and it now works:

## To enable image uploads, make sure the 'images' directory
## is writable, then uncomment this:
$wgEnableUploads           = true;
$wgUseImageResize               = true;
$wgUseImageMagick = "";
$wgImageMagickConvertCommand = "/usr/bin/convert";

But now it's giving me this error message when I try to upload a picture and I CAN NOT FIX IT no matter what I try:

Upload file
From WikiBands
Upload warning
The file is corrupt or has an incorrect extension. Please check the file and upload again.

Sniggity 00:45, 24 December 2005 (UTC)[reply]

What's the name of the file? — Ambush Commander(Talk) 01:49, 24 December 2005 (UTC)[reply]

They're just pictures I'm trying to upload from my computer. Here is a screenshot before I try to upload a pic: http://static.flickr.com/38/76739253_930f120362_o.jpg and here is a screnshot after I try and upload: http://static.flickr.com/41/76739254_876d45bc52_o.jpg

I'm just trying to upload regular .jpg's. I've also tried .bmp .png. .gif and none of them will upload. I also have second computer and have tried different pics and different computers and it still will not upload. Does it upload for you? Any idea as to what is happening? this is very frustrating, especially being a noob at this. Thanks again ! Sniggity 02:18, 24 December 2005 (UTC)[reply]

Make sure mime magic is on the system... you may have to disable that. Also, make sure that the jpgs are not actually corrupted or named incorrectly. BMP files are not accepted by MediaWiki by default. — Ambush Commander(Talk) 17:22, 24 December 2005 (UTC)[reply]

Ok, I went and grabbed this code from defaultsettings and pasted it in my localsettings and uploaded it to my server:

/** Determines if the mime type of uploaded files should be checked
 * @global boolean $wgVerifyMimeType
*/
$wgVerifyMimeType= false;

/** Sets the mime type definition file to use by MimeMagic.php.
* @global string $wgMimeTypeFile
*/
#$wgMimeTypeFile= "/etc/mime.types";
$wgMimeTypeFile= "includes/mime.types";
#$wgMimeTypeFile= NULL; #use build in defaults only.

/** Sets the mime type info file to use by MimeMagic.php.
* @global string $wgMimeInfoFile
*/
$wgMimeInfoFile= "includes/mime.info";
#$wgMimeInfoFile= NULL; #use build in defaults only.

I changed it $wgVerifyMimeType from true to false and it worked, it let me upload a pic. But when I did, this screen popped up http://www.flickr.com/photo_zoom.gne?id=77073850&size=o so I hit refresh to take a screenshot as it loaded and to be able to read the error code and before it loaded, I got a screenshot of this error code: http://www.flickr.com/photo_zoom.gne?id=77076773&size=o I went to the Exif.php file and changed the print_r file from true to false and it still gives me that error. Everything else seems to be working, it's just that error code is showing up, any ideas on that? BTW, great advice on the Mimemagic being disabled, thanks !!!

This is very strange. It appears debugging is on. The code that's failing:
function debug( $in, $fname, $action = null ) {
		$type = gettype( $in );
		$class = ucfirst( __CLASS__ );
		if ( $type === 'array' )
			$in = print_r( $in, true ); 
	 
		if ( $action === true )
			wfDebug( "$class::$fname: accepted: '$in' (type: $type)\n");
		elseif ( $action === false ) 
			wfDebug( "$class::$fname: rejected: '$in' (type: $type)\n");
		elseif ( $action === null )
			wfDebug( "$class::$fname: input was: '$in' (type: $type)\n");
		else
			wfDebug( "$class::$fname: $action (type: $type; content: '$in')\n");
	}

You seem to be using a PHP version older than 4.3.0, because that second parameter was added in that version. Bug your webhost to get it upgraded. This is likely what was causing all the other problems: the PHP installation was poorly configured and mime.magic was not available. — Ambush Commander(Talk) 20:03, 25 December 2005 (UTC)[reply]

Tis very odd. I got it to work though, and here's how:

function debug( $in, $fname, $action = null ) {
                $type = gettype( $in );
                $class = ucfirst( __CLASS__ );
                if ( $type === 'array' )
                        //$in = print_r( $in, true ); 
         
                if ( $action === true )
                        wfDebug( "$class::$fname: accepted: '$in' (type: $type)\n");
                elseif ( $action === false ) 
                        wfDebug( "$class::$fname: rejected: '$in' (type: $type)\n");
                elseif ( $action === null )
                        wfDebug( "$class::$fname: input was: '$in' (type: $type)\n");
                else
                        wfDebug( "$class::$fname: $action (type: $type; content: '$in')\n");
        }

I commented out the lines with the print_r sentence using "//" and now it works great !Those lines are to store the data passed to the script in a debug log, so, if you are not debugging the PHP script it will not affect you.

Ambush Commander, I can't thank you enough my friend. I helped me out of a bind and you're help won't go unnoticed. If there's anything I can do for ya, don't hesitate to ask. I'm sure I'll have a few more problems, as we all with new sites, so I may be back. Again, thanks ! Have a great holiday season. Sniggity 00:27, 26 December 2005 (UTC)[reply]

No problem! Just be careful when upgrading (your patches will be overwritten). And don't forget to bug your host about the PHP version. Happy holidays to you too. — Ambush Commander(Talk) 00:58, 26 December 2005 (UTC)[reply]

Post-Image deletion

Since our policy change, images are being deleted without so much as a word to the uploader, or anyone else. The thing is, Admins often delete an image but then don't go through the articles where it was linked to get rid of the now broken links. Since nobody is contacted prior to the deletion, some articles are left with that gastly red link to the previous location of the image. Just now I found one. The image had been deleted on December 9. That's fourteen days with that link hanging in the article. So I was thinking that perhaps it would be a good idea to create a page similar to the one we get when we move an article, informing us to check and fix double redirects, etc. that might have been created by the page move. Except this one would remind the Admin to check the articles where the image was linked and delete the broken link as well. Naturally, this situation doesn't exist with orphaned images, but other than that...perhaps it could be interesting? Would that be technically possible to create, in any case? Regards, Redux 01:44, 24 December 2005 (UTC)[reply]

You mean putting a warning note similar to what is on CAT:CSD?
Always remember to check "What links here" and the page's history before deleting. Also remember to check "File links" when deleting images.
Zzyzx11 (Talk) 07:21, 24 December 2005 (UTC)[reply]
If no one objects, I have taken the liberty of adding a reminder to the system message [6]. Zzyzx11 (Talk) 08:09, 24 December 2005 (UTC)[reply]
Looks good to me. Thanks Z! Redux 14:29, 24 December 2005 (UTC)[reply]

Seizure-inducing external links

An article I am looking to edit references an external link for relevant information. However, the site that is linked to contains pages that I am concerned may induce photosensitive seizures.

Seeing that the external link is the primary source of credible information for the article, what course of action would be appropriate to address the aforementioned concern? (Folajimi 21:22, 24 December 2005 (UTC))[reply]

Add a warning next to the link (for instance: *[http://www.example.com/ My credible information source] - ''WARNING: contains evil pages''). --cesarb 15:23, 25 December 2005 (UTC)[reply]

Autodetect page-blanking

Would it not be fairly easy to detect & override all attempts at page blanking?--JimWae 19:40, 25 December 2005 (UTC)[reply]

Yes, it's so easy to detect that the CVU already does it with their anti-vandalism bot. --cesarb 19:55, 25 December 2005 (UTC)[reply]

Well, I meant to say auto-detect AND auto-block --JimWae 19:58, 25 December 2005 (UTC)[reply]

Some instances of blanking are useful and should not be prevented. It's better to let a human do the determination. Besides, it makes a good and harmless canary. --cesarb 20:19, 25 December 2005 (UTC)[reply]
It's easier to fix if we don't stop them; if they knew immediately they'd been prevented from blanking a page, they'd just do something different. Perhaps WP:BEANS is relevant? -- SCZenz 20:35, 25 December 2005 (UTC)[reply]

Date linking

Since the only real reason to link dates is for preferences to work - yet since these links usually just appear as overlinking, couldn't date links be auto-detected & NOT appear as links. Perhaps using 3 brackets could force them to actually link - though there is likely no real need for such anyway --JimWae 19:40, 25 December 2005 (UTC)[reply]

Sometimes it is useful to link dates, but generally you are right, it is pointless and missleading. Martin 20:42, 25 December 2005 (UTC)[reply]
I fully agree. A sepeerate kind of wikmi-markup to activate date preferences would IMO be best. (This should be done by an auto-detect, becauase in soem cases, such as in quotations, we don't want formats adjusted to fit preferences. Alternatively a markup for "exclude from preference alteration" with all not so marked being subject to prefernces would do the job too, IMO.) DES (talk) 20:52, 25 December 2005 (UTC)[reply]
See Wikipedia:Village pump (proposals)#Creating syntax for date preference formatting that isn't linking DES (talk) 01:15, 26 December 2005 (UTC)[reply]

Making preferences work is not the only reason to link dates, nor is it even the most important reason. Linking to dates allows users to check on other things happening on that date. Why would you consider unlinking dates? This serves no purpose. User:Zoe|(talk) 01:25, 26 December 2005 (UTC)[reply]

  • I think it is an important form of cleanup, a way of reducing overlinking that makes useful ;links less visible, a way of increasing the Signal to noise ratio. That is why i spent several hours working on it today. I feel that Wikipedia:Manual of Style (dates and numbers) supports this view, and has done so for a long time, and this view has consensus. DES (talk) 01:32, 26 December 2005 (UTC)[reply]

Deleted history permissions

A couple months ago the software got tweaked to display history info (but not contained text) of deleted revisions to any and all random visitors. In the last few weeks we've gotten a rash of complaints about edits being made with private, embarrassing, vandalistic, libelous, etc stuff in the edit summaries etc, and of course deleting the revisions from the wiki still shows them to everybody.

For the moment I'm shutting off this ability (restoring the pre-August behavior) until we get more fine-grained revision deletion / scrubbing in place. I've added a permission key to control it, 'deletedhistory', so if there's a need to turn it back on this can just be added to the '*' pseudogroup in the config to restore the previous behavior. --Brion 20:02, 25 December 2005 (UTC)[reply]

This really sucks. It was incredibly useful to be able to see who deleted articles (as well as their reasons why), and in cases where an article was moved (with the redirect being deleted), this was an easy way to track down where a page went. —Locke Cole 23:13, 25 December 2005 (UTC)[reply]
I agree this makes it harder, but you can still track down who deleted a page through Special:Log. For instance, searching the log for Musterbation allows you to see that I deleted it as a copyvio. I successfully did this while logged out. --best, kevin [kzollman][talk] 22:11, 26 December 2005 (UTC)[reply]
Thanks for the tip kzollman, that'll work, even if it is a little more clunky. =) —Locke Cole 02:02, 27 December 2005 (UTC)[reply]
Deletion logs show why a page was deleted, it does not however, show why images are deleted. Could we have a deletion log for images? - Hahnchen 00:30, 28 December 2005 (UTC)[reply]
Was there any proper consensus or discussion about this? I've just found out about this, and have been looking around to find out why it had been changed. Anyway, I think this is a bad idea, because I do not think that the deleted history pages were libellous in any way. All it showed me was why the page was deleted, be it a CSD criterion or a link to an AFD discussion. I mean, all it showed were the edit summaries, and in general vandals don't concentrate their attacks on the edit summary, which was all that was displayed anyway. I would very much like this feature back, it may be minor, but it was useful having it there, and I'm sure Locke and I can't be the only ones who feel this way. - Hahnchen 02:45, 26 December 2005 (UTC)[reply]
We actually have been having a rash of vandals putting libelous comments into edit summaries, believe it or not. Things like people's home addresses and the like, too. —Bunchofgrapes (talk) 02:49, 26 December 2005 (UTC)[reply]
A very prolific vandal has been posting allegations of child abuse by Jimbo, along with his (more-or-less public) business address to various high-profile articles, leaving the nasty stuff in the edit summaries. This is a loophole that needs to be closed. I'm sure Brion will have a fix in place as soon as possible; consensus and discussion really don't apply to the devs as much as they do the rest of the project :-) android79 02:56, 26 December 2005 (UTC)[reply]
"Consensus and discussion really don't apply to the devs as much as they do the rest of the project" - that needs to change, and quick. Developers are quickly becoming the tail that wags the Wikipedia dog. In this particular case, why not just add the ability for admins to delete specific edit summaries, and those would then be replaced with a boilerplate phrase like "Libelous edit summary removed by User:Admin" or something of that nature. Firebug 01:10, 27 December 2005 (UTC)[reply]
Because your "why not just" is the "until we have more" part of my message above. That's the part that's more work than the temporary hack, which is why there's a temporary hack until that gets done. --Brion 23:23, 27 December 2005 (UTC)[reply]

Now there's a problem. In order to enforce accountability, we need edit summaries. But if edit summaries are submittable by all, theres no way to get rid of them. But if we allow people to edit edit summaries, there needs to be an audit trail for that to. And ad infinitum. WP:BEANS. — Ambush Commander(Talk) 02:55, 26 December 2005 (UTC)[reply]

If this feature is to be disabled (which sucks) we should at least see the edit user account names (attribution) and dates of the revisions, (even without the edit summary reasoning text). It seems GFDL requires that attribution be made available, since the contents of any deleted article could have been copied to another article (this is extremely common, and no tracking is done or possible). Regardless of any legal requirements (which I don't know/understand) in principal, we should never hide who contributed to Wikipedia. Also, on a minor note, why the heck am I redirect to the main Wikipedia page after five seconds? This makes no sense. When giving the error message, please make it longer, and give me time to read it. --Rob 21:47, 26 December 2005 (UTC)[reply]

I thought seeing these histories was a really useful feature, it's unfortunate to see it disappearing like so; can we not have some method of flagging an individual edit as edit-summary vandalism, making the summary text invisible from that view, as a solution? Or limit it to registered users, with appropriate warnings about the possible nature of the Summaries to be accepted, and a well-hidden option in "My preferences" or a manual edit to one of those User-specific theme .js or .css files before being able to review any deletion history log: still better than nothing... --Mysidia (talk) 04:59, 28 December 2005 (UTC)[reply]

Improper Merger

Someone has improperly merged the article entitled, "Gang Stalking" with the article "Gang Stalk Persecution Complex." The result is that, when you attempt to comment on the need to delete the "Persecution" article as being very unprofessional, you are immediately switched over to the "Gang Stalking" article, where your comments in fact are registered.

Please unmerge these two articles. I am not a software expert and am only now beginning to barely grasp your diverse instructions, so, your assistance in this matter will be very greatly appreciated. Thank you.

Julianne McKinney

--70.236.161.247 20:40, 25 December 2005 (UTC)[reply]

This is a dup request, responded to at Wikipedia:Village pump (assistance). -- Rick Block (talk) 23:23, 25 December 2005 (UTC)[reply]

unblocking long user names

I tried to unblock User:Thiswassostupidihadtocreatethisaccountjusttomakethisonecomment. The Block log indicated that the username was truncated to "Thiswassostupidihadtocreatethisaccountju". The original block seemed to be removed from List of currently blocked IP addresses and usernames. However, the block log for User:Thiswassostupidihadtocreatethisaccountjusttomakethisonecomment does not indicate that the user was ever unblocked. I'm wondering if there is a bug in MediaWiki for when unblock is performed on a long username. --JWSchmidt 21:40, 25 December 2005 (UTC)[reply]

I put a new block on User:Thiswassostupidihadtocreatethisaccountjusttomakethisonecomment. The List of currently blocked IP addresses and usernames is now incorrectly showing that User:Thiswassostupidihadtocreatethisaccountju was blocked, but the block log for User:Thiswassostupidihadtocreatethisaccountjusttomakethisonecomment correctly shows that user User:Thiswassostupidihadtocreatethisaccountjusttomakethisonecomment was blocked. --JWSchmidt 21:50, 25 December 2005 (UTC)[reply]

How do I get template info boxes on my site?

For instance, I want to put this onto my site, but it comes up as a red link at the very top of the page:

{{Infobox Guitar model|title=Gibson Les Paul
|image=[[Image:LPSHC.jpg]]
|manufacturer=[[Gibson]]
|period= [[1952]] — [[1960]], [[1968]] — present
|bodytype=Solid
|necktype=Set
|woodbody=[[Mahogany]], [[Maple]]
|woodneck=[[Mahogany]]
|woodfingerboard=[[Ebony]], [[Rosewood]]
|bridge=Fixed
|pickups=2 [[Humbucker]]s (originally [[single-coil]]s)
|colors=Various (often natural-type finishes)
}}

Here is a picture of what happens when I try to add an info box: http://static.flickr.com/38/77463394_d78d26239d_o.jpg

Thanks

It looks like you don't have {{Infobox Guitar model}} on your wiki. You need to copy it over. You may also need to copy over templates that it uses, although some may come as standard with MediaWiki.-gadfium 07:40, 26 December 2005 (UTC)[reply]

Know where I can pick up those modules?

It's not a module, it's a template. Just copy and paste the contents from Template:Infobox Guitar model to your corresponding page. Also, don't forget to sign your comments with ~~~~. — Ambush Commander(Talk) 20:23, 26 December 2005 (UTC)[reply]

Hey Ambush, sorry about that, but it's me, Old sniggity again. Thanks, it worked !

Sniggity 01:03, 27 December 2005 (UTC)[reply]

Upload overwrites limited

I've disabled the ability for brand-new accounts to overwrite existing files by uploading a new file with the same name. While sometimes legitimate modifications are made this way, vandalism in image replacements is common and relatively difficult to notice or track (and more importantly, caching of images with our current systems means the bad image versions sometimes still get shown after fixing); so this should cut down on it a bit until things get improved.

My general inclination is to make uploaded files immutable, so any new version always would go under a new name, but I'm not going to make such a change unilaterally. --Brion 07:29, 26 December 2005 (UTC)[reply]

How do you define "brand new"? Less than X edits? Less than X edits to articles? 'etc Raul654 07:30, 26 December 2005 (UTC)[reply]
I imagine it's percentage (newest X% of accounts), similiar to page moves and semiprotection. But that's just an assumption based on current technical measures.--Sean|Black 07:34, 26 December 2005 (UTC)[reply]
We dropped the percentage method when semi-protection support came in. :) 86.133.53.111 19:25, 26 December 2005 (UTC)[reply]
Currently, less than 4 days since registration. --Brion 07:40, 26 December 2005 (UTC)[reply]
I'd really prefer to be able to keep the various revisions of the same image all in one place. Image:Grapes.jpg is illustrative of both the pros and cons of the current approach. Backtracking through various pages, as you must to get to the original image from Image:Pomegranate03 edit.jpg, isn't terribly reliable. I don't suppose it's at all feasible to make overwritten images generate watchlist entries? —Cryptic (talk) 17:40, 26 December 2005 (UTC)[reply]
I agree that uploaded files should be immutable. I would also support the ability for admins to soft-delete them; i.e. they could be resurrected if desired. Of course developers could always hard-delete, though I can't really see a circumstance where they would need to. [[Sam Korn]] 19:44, 26 December 2005 (UTC)[reply]

CVU members list help needed with edit sections and ....

CVU members list show on WP:CVU had a problem where when there were numbers and sections for TOC and numbers were not reset editing a section did not have the text of that section. Because of this it was removed. People would like numbers back and edit sections working with text. Could someone fix this? --Adam1213 Talk + 12:51, 14 December 2005 (UTC)[reply]

Is that page doing a lot of transcluding? Fancier transclusions (and meta transclusions, the evil things) are known to break section editing and a few other things. 86.133.53.111 19:24, 26 December 2005 (UTC)[reply]

Editing monobook.css

How much does this file control? If I had the proper know how, could I, say, add new tabs to the top of the skin? TastemyHouse Breathe, Breathe in the air 08:54, 16 December 2005 (UTC)[reply]

Not with CSS alone, but in combination with some JavaScript in your monobook.js, you could. Lupo 08:59, 16 December 2005 (UTC)[reply]
What I specifically wish to do is to create a "edit article" and "edit talk" tab so that on any given article i am on i always have a tab for editing the main page and the talk page, so that i dont have to go "Talk -> article -> edit"


you know. saving me some time.


Would this require a lot of javascript / css knowledge? Please, don't do it for me, just tell me if its something that i can figure out how to do with a little digging. TastemyHouse Breathe, Breathe in the air 11:33, 16 December 2005 (UTC)[reply]

Yes you can add tabs to the top... I had it in my monbook at some point to add them on talk pages --Adam1213 Talk + 15:51, 23 December 2005 (UTC)[reply]

I put things that add to edit a users talk page in my monobook --Adam1213 Talk + 23:01, 23 December 2005 (UTC)[reply]
See WP:US. pfctdayelise 02:40, 29 December 2005 (UTC)[reply]

Cache tells me Access Denied?

When I try to access Wikipedia, I get this error message:

Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.
Your cache administrator is wikidown@bomis.com.
Generated Mon, 26 Dec 2005 22:06:27 GMT by bayle.wikimedia.org (squid/2.5.STABLE12)

The email address is apparently invalid, as emails bounce back. Can anyone point me in the right direction of the person to contact about the block? --Interiot 22:13, 26 December 2005 (UTC)[reply]

if it persisits contact noc@wikimedia.org or #wikimedia-tech on freenode. if it just happens from time to time its probablly just poor handling of what happens when the system can't cope. Plugwash 22:29, 26 December 2005 (UTC)[reply]
Another explanation is that this one is the message which appears when a "live mirror" is blocked (I've seen it before when checking these kinds of mirror). If so, it will not go away on its own; you should contact the developers. --cesarb 20:24, 28 December 2005 (UTC)[reply]
The live mirror message is different, and the developers are insidious enough to link to the actual page and do all the copyright stuff, except they don't give the actual article. I doubt it's a live mirror blocking issue. — Ambush Commander(Talk) 16:39, 29 December 2005 (UTC)[reply]

Prefix index buggy

If you for example type "user" as template prefix, you only get till "user c", then there is a redirect to "user cblah". You can never get "user f*" etc... by this search. AzaToth 02:35, 27 December 2005 (UTC)[reply]

Renaming images?

any way to quickly rename images or move them to a different name rather than the slow way of creating another image space and listing the old one for deletion? Jarwulf 06:32, 27 December 2005 (UTC)[reply]

Not really. I think this has, at times, been done by bots, does anyone know details on that? -- Jmabel | Talk 07:12, 27 December 2005 (UTC)[reply]
Is there any particular reason we don't have a "move image" feature though? Even though it would mean to manualy fix the image links afterwards (that could be done by a bot though) moving the image along with all it's revision history to a new name would be better than having to delete the old one and re-upload the image. If it's a security issue we could make it an admin only feature and do it though requested moves or something. --Sherool (talk) 00:19, 28 December 2005 (UTC)[reply]
Exactly...we already have a move function for articles...why not images? Jarwulf 07:43, 28 December 2005 (UTC)[reply]
I've tried doing it before, and surprisingly, Movepage will display Image:Whatever in the box, but then it will stop you from moving it to another page in the Image namespace. Perhaps it's an architectural problem? — Ambush Commander(Talk) 15:10, 28 December 2005 (UTC)[reply]
Well the standard move feature won't work. You need to add some code to "physicaly" rename the image file(s) on the server as they are not stored in the actual database, and I suppose find a way to mark the move event in the file history and such. I suppose a server "hickup" in the middle of a move operation on a image with many revisions might cause some "icky" results too... --Sherool (talk) 01:22, 29 December 2005 (UTC)[reply]

Uploaded image not displaying

Hi,

I just uploaded an image (Sergio_Marchionne.jpg) and although it displays on my computer, it only shows the placeholder on Wikipedia.

Primetime 23:09, 27 December 2005 (UTC)[reply]

Works for me. -- Finlay McWalter | Talk 00:06, 28 December 2005 (UTC)[reply]
Ah, on looking at the image's page, Image:Sergio Marchionne.jpg, user:Dbenbenn reverted your reupload, as the version was defective. Indeed, that version is broken - perhaps it didn't upload correctly. -- Finlay McWalter | Talk 00:08, 28 December 2005 (UTC)[reply]

Please allow Wikipedia users to configure their browsers to block ads

I just figured out why I've not been seeing images on Wikipedia for months now. It first happened when Wikipedia was in the midst of a big upgrade and I figured there were bandwidth problems. Now I see that the trouble is that images are coming from wikimedia URLs (IIRC), and I've configured my browser so that it does not load images that are not from the originating web site. Frankly, I'd recommend this to anybody as it means that I see hardly any ads. I've no desire what so ever to change my browser's configuration, but because the article images are not coming from Wikipedia URLs I see (practically) no images on Wikipedia.

I plead with the Wikipedia techs to create dns CNAME records that point to the wikimedia hosts and re-configure Wikipedia to source images from Wikipedia URLs. It seems a simple enough thing to do and empowers the users of Wikipedia with the simplest, and possibly most effective, ad blocking technique.

Thank you for your attention. (I would like this comment to be more permanent, but this seemed the most appropriate place to post.) --kop 07:15, 28 December 2005 (UTC)[reply]

Alas, on reflection it is not quite so simple. The squids would have to be configured to proxy the images as well. Regardless, I would welcome some solution that both lets me block ads in this fashion _and_ see Wikipedia images. Maybe somebody smarter than me can come up with a simple solution. --kop 07:40, 28 December 2005 (UTC)[reply]
What browser are you using? In Mozilla Firefox at least there's an option to allow certain sites to load these images, so if you allowed wikipedia.org, wikimedia.org and so on there wouldn't be a problem. Maybe.--Cherry blossom tree 11:33, 28 December 2005 (UTC)[reply]
I don't think this is going to get changed as it provides a valuable extra defence against scripting based attacks in the event they slip past the upload sanitizer. Plugwash 12:28, 28 December 2005 (UTC)[reply]
There are two things:
  1. Images are served from a separate web server which is optimized for serving static files. As we expand this may become a cache cluster itself, which will be separate from the one that serves wiki pages because it has different needs.
  2. Images are served from a different hostname to protect against JavaScript attacks that might get past our security filters.
If you want to block ads, feel free. But we probably will continue to serve uploads from a separate domain, as we have for over a year, and as many many large sites do, for the forseeable future. --Brion 14:13, 28 December 2005 (UTC)[reply]
So, basically what you're saying is, you'd like it so you could use Wikipedia and still be able to view other sites without the horrible burden of glancing at revenue-generating ads. The web thanks you. --Golbez 15:02, 28 December 2005 (UTC)[reply]
I, for one, don't see a need to block ordinarly, static ad images in sites. However, I'm getting increasingly annoyed with various sites' attempts to force annoying, intrusive ads on people via popups, popunders, and other techniques, sometimes crafted carefully to get through browser features designed to block these things. I hope Wikipedia never inflicts that sort of thing on us. So far, the most it's done is to get all "PBS" on us with these pledge drives. *Dan T.* 15:12, 28 December 2005 (UTC)[reply]
Use Mozilla Firefox, Adblock Plus, Filterset.G and Filterset.G.Whitelist. It will have the same, if not greater, effect of your current setup, and you will be able to see images. — Ambush Commander(Talk) 15:08, 28 December 2005 (UTC)[reply]
Except maybe those images that are randomly served from the /ad/ directory. --Golbez 15:09, 28 December 2005 (UTC)[reply]
And thus Filterset.G.Whitelist. I was having that problem a while back too. — Ambush Commander(Talk) 15:11, 28 December 2005 (UTC)[reply]

What the hell just happened?

All the links became nonsensical HTML entities. I've just reloaded, and it's OK. What happened? Sceptre (Talk) 14:07, 28 December 2005 (UTC)[reply]

Someone pressed the wrong button, I guess. Morwen - Talk 14:07, 28 December 2005 (UTC)[reply]
Typo in config, it's fixed. --Brion 14:08, 28 December 2005 (UTC)[reply]
Scared me for a second, though that FF had been infected with spyware. Sceptre (Talk) 14:13, 28 December 2005 (UTC)[reply]

??? Entrys

???? appear evrywhere instead of english links in mediawiki specific context like on the search button. Language is set to english en in preferences and its the en wikipedia. so there seems to be a problem here. Problem noticed on this page: here


helohe (talk) 14:10, 28 December 2005 (UTC)[reply]

It's fixed... everyone had it briefly, I think. Shimgray | talk | 14:13, 28 December 2005 (UTC)[reply]
I had this both here and on Commons for about 5 minutes yesterday. I got what looked like Korean characters rather than question marks though. Thryduulf 10:01, 29 December 2005 (UTC)[reply]

Image uploads

Since the implementation of the copyright drop down box, I have noticed a considerable increase in the number of images incorrectly/deceptively tagged as some variant of free use. A more useful inclusion for the uploader to be forced to include would be source information - that way image copyright tags can be verified more simply. Would there be any possibility of including a field on the upload page that prompts the uploader to include image source information?--nixie 16:15, 28 December 2005 (UTC)[reply]

No need to worry about images without sources - if they don't provide a source, after being asked, delete the images, no matter what the "license" tag claims. Simple as that. JesseW, the juggling janitor 21:21, 28 December 2005 (UTC)

MediaWiki:Youhavenewmessages' diff link doesn't work in Classic skin

The message itself is great, and works: you get a link to your talk page, but the diff link doesn't work at all. Instead, you get another link to your talk page. I'm going to go make a bugzilla report, but I figured I'd post here first in case someone had an idea about fizing it. Blackcap (talk) 17:11, 28 December 2005 (UTC)[reply]

I've listed the bug at bugzilla:4411. If anyone's had this happen to them or has any information on it, please post there. Blackcap (talk) 17:47, 28 December 2005 (UTC)[reply]

Fixed! Thanks to Brion and Rob Church for fixing it so quickly. Blackcap (talk) 22:26, 28 December 2005 (UTC)[reply]

AOL user trying to create accounts

We keep getting letters to the Help Desk mailing list from AOL users who are saying that when they try to create an account, they are told that they can't because they've already created 10 accounts. Is this new account counter keeping track of all AOL users? How often does it get reset, and is there something that can be done so AOL anons can create accounts without running into this problem? User:Zoe|(talk) 17:49, 28 December 2005 (UTC)[reply]

The whole problem is that AOL shares the same IP address for multiple users. Not only that but, from what I've heard, it changes the IP address with each request — but requests to the same page (by different users) often get the same IP address. That would make it look like the 10-account/day limit is being used for the whole AOL (when in fact it's per IP address). --cesarb 20:05, 28 December 2005 (UTC)[reply]

Deletedpage templates

This is sort of a minor point, but one that bothers me a bit. Is there any way to make deleted articles that have been protected with the "deletedpage" template still appear as redlinks? The illusion created that there are articles under that name is a bit misleading, and throws me off when I'm looking for recreations of deleted pages. I know little about the technical issues of WP, and I suspect that if there is a way to do this it's too complicated for such a minor issue, but I thought I'd throw the idea out there anyway, and also see if anyone has similar feelings. -R. fiend 19:59, 28 December 2005 (UTC)[reply]

Set your stub limit to 20 bytes or so in preferences and add a.stub { color:#CC2200; } to your user css? —Cryptic (talk) 21:40, 28 December 2005 (UTC)[reply]
A general fix is certainly possible, but would require a software change and would likely require a new option when deleting an article to disallow recreation. Feel free to enter this as an enhancement request at bugzilla:, but don't be surprised if it is not acted on very soon. -- Rick Block (talk) 21:43, 28 December 2005 (UTC)[reply]

Errors

Got a lot of errors now "Fatal error: Cannot instantiate non-existent class: outputpage in /usr/local/apache/common-local/php-1.5/includes/Setup.php on line 284" AzaToth 22:33, 28 December 2005 (UTC)[reply]

Likely another quick configuration/coding error that slipped past the devs. OutputPage is instantiated for all requests, so it's not surprising that's the one that failed. — Ambush Commander(Talk) 00:09, 29 December 2005 (UTC)[reply]
"instantiate "? User:Zoe|(talk) 03:22, 29 December 2005 (UTC)[reply]
Instantiate. --cesarb 15:10, 29 December 2005 (UTC)[reply]

White space, but how much?

I run several times a day each day into articles having too much whitespace between paragraphs, or at the top of the articles. Well, one may say that is no big deal.


I will argue however, that such whitespace makes the articles look unprofessional, especially that in some places the whitespace is wider than others (see above). And most of the time that whitespace is not created on purpose, rather by editor negligence. I have raised this issue before, but now I really want to ask a question:

Does anybody know why the wiki engine does not strip extra whitespace when converting to html, like html itself and LaTeX do? Also, does anybody know why it is convenient to allow users to insert whitespace like that, and why not just use <br> when it is absolutely necessary?

In short, would it be a good idea to file it as a bug at Bugzilla that in future versions of the software the engine strip all the extra whitespace, while still allowing users to deliberately insert whitespace with <br>? Oleg Alexandrov (talk) 05:29, 29 December 2005 (UTC)[reply]

Never underestimate the hideous complexity of Parser.php. I see the definite alternative you proposed, so I say go for the Bugzilla and see what the developers think (eg. Don't expect results). — Ambush Commander(Talk) 16:36, 29 December 2005 (UTC)[reply]
As to why whitespace is allowed, the wiki editing rules are meant to be extremely simple and not require any particular technical knowledge nor anything other than a text input box in a web browser to use. Knowledge of HTML or use of a WYSIWYG word processor, in particular, are not assumed. Plain text is simply too plain for most people's tastes, so some markup syntax is supported including limited use of HTML. Allowing any markup immediately hits a feature creep slippery slope, but understanding the original intent hopefully helps fight the notion that wikimarkup might as well be an XML. The markup is intended to be directly edited by humans. -- Rick Block (talk) 17:43, 29 December 2005 (UTC)[reply]

User talk shortcut at image file history

How to add the user_talk shortcut to image file history.
For ex:

(del) (cur) 03:39, 5 August 2005 . . Dtobias . . 182x71 (3396 bytes) ({{Logo}} AFGNIC logo (.af domain registrations: Afghanistan).)

into:

(del) (cur) 03:39, 5 August 2005 . . Dtobias (talk) . . 182x71 (3396 bytes) ({{Logo}} AFGNIC logo (.af domain registrations: Afghanistan).)
--borgx (talk) 06:33, 29 December 2005 (UTC)[reply]

Javascript I presume. Try Wikipedia:WikiProject User scriptsAmbush Commander(Talk) 16:38, 29 December 2005 (UTC)[reply]
User:Cryptic/addtalklinkstoimagepages.js. There's some not-so-good instructions for installation at m:Help:User style. —Cryptic (talk) 23:37, 29 December 2005 (UTC)[reply]

Problem with old browsers?

I've recently been editing from a 6 year old iMac running IE 5.1. Yes, I know it's ancient. It's a long and painful story as to why I'm not currently on my Tiger powered iBook G4, so don't ask.
The problem I'm having occurs when trying to revert long articles. Most recently it occurred on Julius Caesar. I think my browser might not be loading all the code into the edit window for some reason. Is having an old browser a possible cause? I know that there are special workarounds for it not being unicode compliant, but might there be other issues without workarounds? WAvegetarian (talk) (email) (contribs) 07:45, 29 December 2005 (UTC)[reply]

yep older browsers have problems editing longer articles. See Wikipedia:Article size. Just upgrade youyr browser (or edit only sections in long articles). Broken S 08:21, 29 December 2005 (UTC)[reply]
IE for Mac can't edit pages longer than 32kb correctly. If you have to use a machine too old to run Safari, try Firefox or a classic Mozilla release... --Brion 10:40, 29 December 2005 (UTC)[reply]
Thanks for the input. I just downloaded Mozilla 1.0.2, which is the most recent build that supports OS 9. I hope to be back up and running on my iBook tomorrow as it is due back from data recovery.
Warning: Fuming ahead...Ignore it if you want, that's why it's in small type. Directories are wonderful things until they get deleted. Do not, I repeat do not use AppleCare's provided disk utility program called TechTool if you got AppleCare before upgrading to Tiger. It will crash your machine and erase your directory information. Apple of course maintains that it's third party software and that data loss, even data loss admittedly caused by them, is not covered under warranty. :-t
WAvegetarian (talk) (email) (contribs) 11:28, 29 December 2005 (UTC)[reply]

"grabbing the back button"

We have had two people write to the Help Desk mailing list complaining that Wikipedia grabs their browser's back button and doesn't let them leave. I know it's not a function of Wikipedia, could it be some combination of browser and operating system? I've asked the most recent poster to let us know what they're working with. User:Zoe|(talk) 16:22, 29 December 2005 (UTC)[reply]

Hm. Do you know where they're coming to the site from? It could be they're directed to us via a mirror that either opens in a new window, or does something stupid with frames... Shimgray | talk | 16:33, 29 December 2005 (UTC)[reply]

"grabs their browser's back button"... never heard it worded that way before... — Ambush Commander(Talk) 16:35, 29 December 2005 (UTC)[reply]
I'll post more detail when the person reports back. If they do. User:Zoe|(talk) 19:33, 29 December 2005 (UTC)[reply]

MediaWiki 1.6 Release Date?

Is there any estimated release date for the first beta release of MediaWiki 1.6? Thanks, Deyyaz 20:35, 29 December 2005 (UTC)[reply]

May an admin delete this image as now in commons??

thanks,

de:User:Klever

What happened to Create new page in searches?

I'm sure there used to be a set of options that came with a search that didn't find exactly what was typed - in particular the option to create a new page. Why has this disappeared (or why can't I still see it...). -- SGBailey 21:11, 29 December 2005 (UTC)[reply]

Do you see this if you enter something in the search box and click "Go", rather than "Search" (I do). -- Rick Block (talk) 23:10, 29 December 2005 (UTC)[reply]

Red links

I don't know where to ask this at, but what do the red links mean?