Jump to content

Wikipedia:Village pump (technical)/Archive 1

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Allocated portable IPs

Can someone clarify (with certainty) the meaning of "allocated portable" in terms of IP status? It's relevant to some blocks in this sockpuppet report. The Whois data is here. Thank you!--chaser - t 08:48, 15 October 2007 (UTC)

"Allocated portable" simply means that the address block was allocated directly by the national registry service, in this case APNIC, and is, thus, provider-independent. This means that the "owner" of the IP address can transfer it from one provider to another, as opposed to the typical model where IP addresses are "borrowed" from service providers and may only be used with that provider. The primary reason for acquiring portable IP addresses is to maintain the established reputation of an IP address when changing providers, and to ensure the flexibility to change providers without having to give up former addresses. I'm not sure, however, how this would play any role in determining whether two users are sock puppets of another, but that's your definition as requested :) AmiDaniel (talk) 15:45, 15 October 2007 (UTC)
Then allocated portable addresses tend to be more static than the average static IP?--chaser - t 20:49, 15 October 2007 (UTC)
Hmmm .. I certainly wouldn't jump to that conclusion, though I've not really thought about it in this sense. Whether an IP is "static" or "dynamic" is determined by the way that a service provider assigns addresses to subscribers, not by the way that the IP addresses are allocated by the IANA. All that "portable" means is that the IP address or block can be (not has been or will be!) transferred from one provider to another, and, in particular, the address cannot be resolved by provider due to this nature. What is usually (at least AFAIK) the case with portable IP addresses is that one company or provider subleases portable IP addresses from a higher-up provider with the condition that the subleasing company can maintain the same IP addresses when transfering to alternative providers if need be. Due to the expense, this is typically only done in regions with very competitive ISP markets (such as is certainly the case in many of the regions that APNIC services). The subleasing company will then provide connectivity to its customers through these IP addresses based upon its own internal allocation scheme--some may be provided to individuals, companies, servers statically, others may be used dynamically by one or many of its customers. For the most part, no individual will be the custodian of a single portable address. I would actually say that, quite on the contrary of being static, most portable IP addresses are likely shared by multiple individuals or entities, though this is also by no means compulsory. In short, you're far, far more likely to find out the exact nature of how this IP address is used by contacting Sri Lanka Telelcom than you are by asking me :) AmiDaniel (talk) 19:11, 17 October 2007 (UTC)
Thanks for your very helpful and informative answers, Amidaniel. I've learned a lot from this exchange.--chaser - t 20:56, 17 October 2007 (UTC)
Glad to help :) AmiDaniel (talk) 03:24, 19 October 2007 (UTC)

I have my preferences set to underline links, but until today I never noticed the navigation and interaction links on the left being underlined. Has something changed, or am I just going noticing this for the first time? I'm using IE7 for a browser. Coemgenus 15:53, 18 October 2007 (UTC)

They should underline when you hoover over them. That's being governed by Wikipeia's CSS styles (which does override your browser settings). — Edokter • Talk • 15:57, 18 October 2007 (UTC)
Yes, but I'm not hovering over them. They stay underlined all the time now. Coemgenus 16:02, 18 October 2007 (UTC)
OK, that is weird. Nothing has changed as far as I know. Have you tried clearing your cache? — Edokter • Talk • 16:11, 18 October 2007 (UTC)
Bypassed it, with no effect, then cleared it, also with no effect. This is kind of weird. Even the symbols and character links on the edit screen are underlined. Coemgenus 17:56, 18 October 2007 (UTC)

I believe this edit did it. Probably needs a partial revert. --- RockMFR 18:11, 18 October 2007 (UTC)

Yes, it was that edit (requested by me). Technically, if you set "Underline links: Always" in preferences, you want all links underlined. But since users are already accustomed to "normal" portlets and specialchars, this needs to be put back into Mediawiki:Monobook.css ∴ AlexSm 18:50, 18 October 2007 (UTC)
/* Not underlined links in portlets/specialchars even with pref "Underline links:Always" */
.portlet a, #editpage-specialchars a  { text-decoration: none }
.portlet a:hover, #editpage-specialchars a:hover { text-decoration: underline }
P.S. This setting takes effect through http://en.wikipedia.org/enwiki/w/index.php?title=-&action=raw&gen=css ∴ AlexSm 18:50, 18 October 2007 (UTC)
This should be fixed. WP:BYPASS or WP:PURGE as necessary. Sorry for any issues. --MZMcBride 03:33, 19 October 2007 (UTC)

Issue with Tnavbar-header template

Can somebody take a look as this issue and see if they can figure out what is wrong? The fontcolor parameter is applying itself correctly to the vde, but not the title and its negatively affecting many templates, such as {{University of Oklahoma}}. Its protected, so if you see the problem but can't edit the template, let me know. Thanks.↔NMajdan•talk 20:28, 18 October 2007 (UTC)

The problem is that the title is linked using [[ ]], which itself overrides any font color specified outside the [[ ]]. There is no easy fix for this, but you could try this as an (ugly) workaround in the University of Oklahoma template:
title=[[University of Oklahoma|<span style="color:#fff">University of Oklahoma</span>]]
— Edokter • Talk • 22:20, 18 October 2007 (UTC)
Thanks for the info. I was thinking that was the issue looking at the generated HTML. Unfortunately, that solution won't work for me. The {{University of Oklahoma}} template is actually generated from another template I made called {{Navigation with collapsible groups}}. I guess I'll just drop the vde until I find a better solution. Thanks.↔NMajdan•talk 13:01, 19 October 2007 (UTC)
On the other hand, wrapping the entire link inside a font tag also seems to work... — Edokter • Talk • 17:23, 19 October 2007 (UTC)

Needing the <references/> tag

Editing a section

Say you edit an article section to add a new <ref> item. When you Show Preview, the preview shows the article text but not the references, so you don't actually see the change you made. Or if you added text and a reference, you see part of the change you made, but not all of it.

When I run into this problem, I usually work around it by temporarily adding <references/> at the end of the section. Then I Show Preview, fix any errors, remove <references/>, and Save Page. But that's obviously error-prone, because one's instinct is to Save Page as soon as the errors are fixed, and it's all too easy to forget to remove the <references/> tag and have to go back and do it afterwards.

A technical workaround occurs to me. I suggest that if a section being edited contains a <ref> tag but not <references/>, the software should append a template reference like {{preview-references}}, which would expand to something like 

    ---
    ''The section being previewed contains the following references, which in ''
    ''the complete article will appear at the &lt;references/> tag:''

    <references/>

Of course, if you're editing only the text of the section and not the references, you don't really need to see them expanded, and they're just an annoyance. An alternative approach would be a separate Preview References button, but that seems like overkill to me.

Checking consistency

On a related point, for both a section and an article edit, it would be desirable to trap the case where the article contains one or more <ref> tags without a <references/> tag that will expand them, or where it contains two or more <references/> tags. (Experiment indicates that each <references/> expands all <ref> tags appearing earlier in the article, so there must be exactly one <references/> tag that is after all <ref> tags.) I suggest that when a Show Preview is done, a check should be done on the entire article as it would exist if Save Page was done at this point, and if any of these erroneous situations exist, a warning should be issued (either within the preview window or elsewhere, but prominent enough that it won't be missed).

I think this should be a warning issued at preview time, not an error message preventing the save, because you have to consider what happens when someone adds the first reference to an article. If they do it during a section edit, they don't want to be blocked from saving because they forgot to add a References section first. Similarly, someone doing a cleanup pass through an article from top to bottom in order might add several references, saving sections one at a time, before they get to the end and add References. But they need to be reminded to add that References section.

Or thinking bigger

Or, thinking bigger, perhaps there's a better approach -- although I guess I can't be the first person to think of this, so perhaps there are good reason why it isn't being used. But right now it seems to me as though the Right Thing is to forget the whole idea of explicit <references/> tags -- send a bot through Wikipedia to get rid of them and their associated sections -- and instead simply have the whole section 

    ==References==
    <references/>

appended implicitly to the wikitext of any article containing a <ref> tag, at the time when the wikitext is rendered into HTML. (Or some equivalent behavior.) And the same for any section when it is being previewed.

This change, of course, would address both of the issues covered in my other two points.

--207.176.159.90 23:09, 18 October 2007 (UTC)

On that last one, the only problem is that the references section is very often not the last section in the article, and really shouldn't be. The point of using the tag is to allow some flexibility in exactly where the references are placed and in formatting them. TCC (talk) (contribs) 01:26, 19 October 2007 (UTC)
However, if (1) one or more <ref> tags were encountered and (2) no <references/> tag was encountered in the wikitext, then it might be a good idea to add something like "ERROR!! No <references> tag was seen. ERROR!! - Cited references were:", and then to add an implicit <references> tag. -- Boracay Bill 03:00, 19 October 2007 (UTC)
A warning message, rather than an error, likely would be a useful and not particularly difficult feature to implement. The notion of auto-adding the references tag, however, leaves open a whole slew of problems, one of which Csernia above alluded to. The exact nature of how the references block is to be added to pages is quite intentionally not explicitly defined. Where the references block occurs in an article should be left up to the author of the article, to allow him the option to format it as he wishes. There are many cases where it is in fact correct to not have a references block -- consider a template or infobox that cites various sources; it is usually better to have the sources cited in this template included in the references block of the page in which the template is transcluded than in the template itself. In fact, I very much so believe that one of the greatest problems with Cite at present is that it does not allow editors enough ability to customize how references are used on a particular page -- this proposal seeks to make their usage even less customizable for the sake of alleviating a very minor inconvenience. One thing I believe to be quite imperative to implement is the ability to define different classes of reference types within a given page, such that, for instance, "notes" and "sources" can be separated from one another. I also believe it important to allow articles to make use of different forms of in-text citation, i.e. MLA, which the current system does not. Much discussion about a reform of Cite has taken place recently, and we will likely soon see some changes to the system. Worth reading would be this recent thread on Wikitech-l. AmiDaniel (talk) 03:21, 19 October 2007 (UTC)
Okay, if there's a whole slew of problems, forget that proposal. But I would like to see my first two subsections addressed in that case. --207.176.159.90 05:07, 19 October 2007 (UTC)
Your first two subsections are do-able. Unless there are objections, I'll try to implement something this weekend. In any case, Cite has a lot of problems that need to be addressed -- you've barely hit the tip of the iceberg :) AmiDaniel (talk) 06:33, 19 October 2007 (UTC)
AmiDaniel, are there cases where a <ref> tag has been encountered and yet it is still correct to not have a references block? In that situation, is it more useful to have the references expanded at the very end of the article headed by a warning message, to have the warning message appear but the unexpanded references remain hidden, or to have the unexpanded references remain hidden with no warning (current behavior)? -- Boracay Bill 05:46, 19 October 2007 (UTC)
Sure there have been. I can't think of one on enwiki off the top of my head, but I know that I have implemented templates of this style myself. The issue, however, is not about whether it should be okay to have a ref tag without a references tag; rather, it's about whether the decision of where or if to place such a tag should be made by the software or by the editor. IMO, the correct behavior would be to warn the editor, and the editor alone, following the saving of an edit that there are reference tags with no matching reference block. AmiDaniel (talk) 06:30, 19 October 2007 (UTC)

(next 50)

In the edit history page of every article, there are links like

(previous 50) (next 50)

Unfortunately, since the history is listed in reverse, the "next 50" in order of listing is the "previous 50" in chronological order, and once I get back past the two pages of entries, I always find myself clicking on the wrong link and going forward in time instead of further back.

Could another wording be found, such as

(50 older) (50 newer)

or

(next 50 later) (next 50 earlier)

or something like that?

--207.176.159.90 05:14, 19 October 2007 (UTC)

See MediaWiki talk:Nextn for an explanation of what goes wrong when we try to change them with the current software. I don't think the problem would be ridiculously difficult to sort out, but it requires developer intervention, and developers tend to be busy. --ais523 09:28, 19 October 2007 (UTC)

Articles I created

I heard that Interiot had a tool that indicated all articles created by a user but the script seems to fail and Interiot is AWOL. I'm not technically-minded at all but if someone who knows of an alternative and could ping my Talk page that'd be great Dick G 05:13, 11 October 2007 (UTC)

Heh, I just came to ask the same question. Special:Contributions doesn't mark new articles and Special:Newpages on Wikipedia at least doesn't go back very far. How hard would it be to get Special:Contributions to mark new articles like Specia;Recentchanges does? Thanks all. - Taxman Talk 18:07, 11 October 2007 (UTC)
There was another tool at http://tools.wikimedia.de/~escaladix/larticles/larticles.php but it doesn't seem to work either ∴ Alex Smotrov 18:25, 11 October 2007 (UTC)
I have a tool that can give user stats, see [1] for a list of the logs, Ill gladly run it for anyone who wants it. βcommand 20:36, 13 October 2007 (UTC)
I would like to know how to do this too. It drives me nuts when I want to go back to an article I created and cannot remember the article name, even though I try to keep lists, etc. --Mattisse 16:39, 20 October 2007 (UTC)

MediaWiki:Sitenotice not appearing

Over at the Kannada Wikipedia, someone tried to set up a new site notice, but the message does not appear at all now, no matter what it's set to. It's not the site notice ID because the message does not appear for anons either. -- Prince Kassad 12:59, 20 October 2007 (UTC)

The old sitenotice has been replaced for now by the central one for the upcoming fundraiser. --brion 18:57, 20 October 2007 (UTC)

Is it possible to customzize my monobook.css so it would display all interwiki links at the bottom of the page instead of a box on the left? Here is a random example from the mediawiki site. --(cubic[*]star(Talk(Email))) 13:55, 20 October 2007 (UTC)

Page linking to a redirect to itself

Hi!

I just edited MV Liemba to unlink Liemba which, of course, redirects to MV Liemba. Aren't there bots that do this, like for double-redirects? Or do they need a tweak? Saintrain 18:24, 20 October 2007 (UTC)

Nested tables class="collapsible collapsed"

If someone knows of a workaround for this issue, I'd like to know what it is too. I couldn't find anything for it in Bugzilla either.

I have some nested collapsible tables coded up roughly as follows: 

{|class="collapsible collapsed"
!Outer table header row
|-
| interesting information
|-
|
{|class="collapsible collapsed"
!Inner table header row
|-
| more detailed interesting information
|-
|
{|class="collapsible collapsed"
! Inner inner table header row
|-
| Even more detailed information that's not particularly interesting
|}
|}
|}

Here's what it looks like:

All of them should be collapsed by default. But when you expand the outer table, all the inner tables expand as well -- but their "show" links say "show". The Javascript apparently doesn't know they've expanded. When you click on "show" it changes to "hide", but doesn't do anything else. After that, the link works normally.

Any thoughts? TCC (talk) (contribs) 09:58, 1 July 2007 (UTC)

Looks like you aren't using it in the way it was intended. Looks like it doesn't support nesting. I'll take a look around and get you an answer and the correct code in a bit. —Andrew Hampe Talk 23:17, 1 July 2007 (UTC)
Just so you're aware then, one requirement is to be able to specify the initial state, which is why I'm using the table instead of NavFrame, etc. TCC (talk) (contribs) 01:33, 2 July 2007 (UTC)
You can hide the nested tables by putting 3 NavFrames inside one collapsible table, e.g. {{Calculus footer}}. Even if you're nesting only 2 or less, you can add an empty NavFrame div to make them hidden. I don't know of a way to make the nested NavFrames expand by default though, unless you're nesting 2 or less. –Pomte 18:55, 24 July 2007 (UTC)
That is kind of the problem with using NavFrames, yes. In fits and starts I'm working on a change to the scripting to see if I can get it to work. Going's a bit slow though, as this is my first time working with either Javascript or the DOM. TCC (talk) (contribs) 02:07, 10 August 2007 (UTC)

Sorted it. I'd made a silly mistake about the order in which scripts are executed on a page load. It's probably very klugy, so I wonder if someone experienced in JS and the DOM could have a look at it and tell me if I've done anything boneheaded? See User:Csernica/monobook.js. And what might be the chances of getting this into Common.js? TCC (talk) (contribs) 07:26, 15 August 2007 (UTC)

overriding class="wikitables"

I need to override the wikitables class. Specifically, I need to replace its charming #f2f2f2 table header with another color. I tried adding style="background:red;" to the header to the header row but it seems that the wikitables class takes precedence over my customized style. So how can I override the wikitables class? -- Миборовский 05:14, 21 August 2007 (UTC)

Put "class" before "style" so that it overrides properly. Anything more, and I'd need to see an example of what you're trying to do (you could set up a page in your userspace, for example). EVula // talk // ☯ // 05:17, 21 August 2007 (UTC)
Order of class and style attributes on an element should not matter. Anomie 14:02, 21 August 2007 (UTC)
Yes, it should; the "C" of "CSS" is cascading. Declarations that are made first are overridden by later declarations (ie: if Sheet X says that h2 tags should be green, and Sheet Z says h2 tags should be red, which ever sheet is included last will determine how it is displayed, but it can stille be overwritten by an inline style that says that that particular h2 tag should be blue). EVula // talk // ☯ // 19:35, 21 August 2007 (UTC)
But if Sheet W says SPAN tags should be blue and an inline style says orange, <span class="SheetW" style="color:orange"> and <span style="color:orange" class="SheetW"> are equivalent (i.e. orange). Something similar goes for your example: <h2 class="SheetX SheetZ"> and <h2 class="SheetZ SheetX"> are equivalent. Anomie 21:34, 21 August 2007 (UTC)
Here's an example. --MZMcBride 06:43, 21 August 2007 (UTC)
If you look at MediaWiki:Common.css, you will see that the background color is being applied to the TH elements. Thus, you will have to specify the style override on each cell rather than on the row. Unless there is a good reason (not just "I like it better in this color") for overriding the class, I would advise against doing this as it will prevent user preferences or skins from overriding the color. Anomie 14:02, 21 August 2007 (UTC)

Call me crazy, but..

..am I the only one who sees an (udnu) button in the middle of the sandbox history page? I checked, it's not in the edit summary, the software is somehow producing a backwards undo button, for this one specific revision!? Backwards AES, or is someone testing some weird javascript, css, or other in the sandbox?--VectorPotentialTalk 13:15, 19 October 2007 (UTC)

Ah, looks the editor just put in the 'reverse' unicode character in the edit summary, which is used in Arabic and such. — Edokter • Talk • 13:21, 19 October 2007 (UTC)
Never mind then. --VectorPotentialTalk 13:37, 19 October 2007 (UTC)

Can't upload files to commons

Can somebody help me here? For some reason, I am unable to upload image files to wp:commons. When I type into the "destination filename" gadget, this weird red light icon flashes next to the gadget, and when I hit the "upload" button, nothing whatever happens. I've tried uploading files from external websites and my own PC, makes no difference. The image copyright selection box is set to "US federal government" so that isn't the problem. Left messages at wp:images and wp:commons village pump but got no response. Thanks. Gatoclass 04:41, 20 October 2007 (UTC)

I think I have the answer, left a amessage on his talk page. Will know for sure when he gets back to me. TomStar81 (Talk) 05:28, 20 October 2007 (UTC)
Actually Tom's solution didn't work but I've figured out part of the problem. For some reason, when I try to upload jpegs directly from Navsource Online, or even when I save them to my PC and try to upload them from there, Commons won't recognize them. But if I take the same jpeg file and save it in MS Paint as a jpeg, suddenly Commons will recognize the file and I can upload it.
Trouble is, MS Paint is a rather limited program that doesn't seem to be able to handle pictures beyond a certain size and I don't have another paint program, so I'd still appreciate it if someone could figure out why this is happening. Gatoclass 11:31, 20 October 2007 (UTC)
You cannot upload images directly from another web site. You must save them to your computer first. As far as image editors, I recommend the GIMP. The GIMP for Windows can be downloaded from http://gimp-win.sourceforge.net/
There might be a problem with your web browser. What web browser are you using? —Remember the dot (talk) 20:20, 20 October 2007 (UTC)
Thanks for the tip re: GIMP, I'll take a look at it :)
I'm currently using IE 7. Gatoclass 04:32, 21 October 2007 (UTC)

Javascript question (I think)

I am using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 and Windows Vista. Recently I have been having trouble on Wikipedia doing simple things like getting the cursor to move in the text. Navigating while editing within the text of an article is more and more difficult and unreliable. Easily (and for seemingly no reason) all or parts of the text gets selected (turning blue or gray) and usually I have to leave the page and then return to alleviate this problem. Because I do not have this problem other than on Wikipedia, I am wondering if this is a Wikipedia problem. (Also, it is very easy to lose control - have the text jumping around or scrolling out of control - as if javascript (or whatever) is operating too fast. Am I making sense in this question? Thanks, --Mattisse 15:59, 20 October 2007 (UTC)

Are you editing long pages (i.e. pages with source text at or greater than 32kb)? That's been known to cause problems with some browsers. Nihiltres(t.l) 16:41, 20 October 2007 (UTC)
Easy way to find out if it is indeed a script causing your problems, is to disable Javascript in Firefox, then see if the problem still exists. — Edokter • Talk • 16:44, 20 October 2007 (UTC)
Yes, long pages probably. No problem posting here today. Also, often there is a long lag before something shows up. Yesterday I found I had signed twice several times because the first time nothing seemed to happen. But when I looked in Preview I saw two signatures. Also, I posted the same message three times on one user's page because I kept getting "Wikipedia is having a problem" messages and did not know it was posting, making that user very angry as he thought I had done it intentionally and called me "childish". Thanks for your response! --Mattisse 17:40, 20 October 2007 (UTC)
I know this is a generic response, but have you gone to Windows Update in the Control Panel and checked if there are any reliability updates that for some reason haven't made it to your computer yet? —Remember the dot (talk) 01:15, 21 October 2007 (UTC)

Technical feasibility of an IP block/range block for a specific article

So here's something I just thought of that probably (a) has been asked repeatedly, and (b) is impossible. Would it be technically possible someday to modify Mediawiki to be able to block a certain IP (or, even more usefully, range block some IP's) from editing a particular article?

I thought of it because someone using IP's in the range 41.242.xxx.xxx think this is the most hilarious thing they've ever seen, so they've added it to Libertarianism about 9 times in the last week, using 6 different IP's. If this continues, no solution is really satisfactory: it seems that rangeblocking would be overreacting, as it would block a big chuck of South Africa from editing; page protection isn't good either, as this particular article gets a lot of good edits from IP addresses; and just watchlisting and continually reverting each time and moving on (what I'm doing now) is getting annoying.

Now, if you could range block for just that one article, (or, put another way, protect the page only from a range of IP addresses) you'd only prevent a large portion of South Africa from editing one article for a while, instead of all 2+ million; not perfect, but damn close. Obviously this solution doesn't exist now, but my question is, would it be technically feasible to add this feature? If it's a stupid idea, I'll tuck my tail between my legs and go home; if not, I'll explore Bugzilla for the first time. --barneca (talk) 00:59, 21 October 2007 (UTC)

Well, if you are rangeblocking for just one article, why not protect the page? It will be a little wider in scope, but really who cares, it is one article, and temporary semi-protection. Prodego talk 02:57, 21 October 2007 (UTC)
Hi Prodego. Because I don't want to prevent other IP editors from editing the article. Right now, when we semi-protect an article, we kind of throw the baby out with the bathwater. In this particular article, there seems to be a slightly-higher-than-average level of participation from legit IP editors, and the vandalism probably wouldn't rise to the level required for protection at WP:RFPP. But even when there isn't much legit IP participation, and even when the vandalism is swamping the article, it's always seemed a shame to block all legit IP editors from editing an article because of one jerk on a dynamic IP. --barneca (talk) 03:22, 21 October 2007 (UTC)

Yet another apparent browser-specific css problem

The table in Douglas_MacArthur#Dates_of_rank looks fine for me using Firefox 2.0.0.8. Internet Explorer 7.0.5730.11 messes it up -- the vertical line goes through the text in the second column. Ain't CSS grand? -- Boracay Bill 01:59, 21 October 2007 (UTC)

While partially to blame on IE, the real cause was using left/center/right in image tags in a table, which is know to cause problems (divs in tables don't mix). Easily fixed. — Edokter • Talk • 14:42, 21 October 2007 (UTC)

Categories show up too high

I have a problem with categories showing up too high covering up some text at the bottom of pages. It only happens in IE6, not in Mozilla. It also only happens with this account, when I use another account in IE6 everything is fine. I checked if it was something in my monobook, but couldn't find it. Anyone has any ideas? Garion96 (talk) 14:30, 21 October 2007 (UTC)

I sometimes have that. Resizing the window ususally clears it. — Edokter • Talk • 14:45, 21 October 2007 (UTC)
Ok, now that is just plain weird. It worked! Thanks. Any idea what causes it? Just some IE6 bug? Garion96 (talk) 14:48, 21 October 2007 (UTC)
That's what I'm guessing... I'll have a look at the CSS that controls the Category box anyway. — Edokter • Talk • 15:19, 21 October 2007 (UTC)
Thanks, I hope you find something. It's strange though, it only happens since the last couple of days. So something in that period of time must have been changed. Garion96 (talk) 17:01, 21 October 2007 (UTC)

Unfortunately, catlinks is defined in main.css, so I can't touch it (can't see nothing wrong there either). The only thing I did find is this snipplet in IE60fixes.css: 

/* Rule 18 of /skins-1.5/monobook/IE60Fixes.css?100 */
#catlinks {POSITION: relative}

I don't know why, but this may be why the category box jumps up sometimes. — Edokter • Talk • 18:19, 21 October 2007 (UTC)

Internet Explorers list of CSS quirks is utterly massive. You've probably heard it before, but I highly recommend you switch to a better browser, like Safari or Firefox. At the very least, IE7 fixes a lot IE6's problems; an upgrade wouldn't be a bad idea. EVula // talk // ☯ // 03:22, 22 October 2007 (UTC)

Making it possible to import histories from the Nostalgia Wikipedia into here

It's late at night in Perth so this is just a brain wave ... would it be possible/feasible/desirable to make it possible to import page histories from the Nostalgia Wikipedia to this website? Some background: the Nostalgia Wikipedia is a read-only copy of Wikipedia from an 11 December 2001 database dump. However there seems to be some history in Nostalgia.Wikipedia that is not, and never was, stored in the English Wikipedia database. The germ for this idea came when I found the earliest history for saint in the English Wikipedia and compared it to the history in the Nostalgia Wikipedia, and found eleven edits that are stored in Nostalgia Wikipedia but not in the English Wikipedia. There are only 95,321 edits stored in Nostalgia Wikipedia, most of which probably don't need to be imported here. The only problems I can see are that it may mess up the revision ID's (very high numbers will be assigned to very old edits) and we may have problems with the old UseModWiki form of storing IP addresses like 127.0.0.xxx (obfiscating the last octet). Also there will be some CamelCase titles that may or may not be worth importing. Would it be worth it ... would it impact the servers much? And yes, Special:Export would work on Nostalgia Wikipedia. Graham87 15:25, 21 October 2007 (UTC)

However there seems to be some history in Nostalgia.Wikipedia that is not, and never was, stored in the English Wikipedia database. Oh but it was stored in wikipedia, but all history was lost in The Big Database Crash in 2002 (? Can't fint it! Needs a FAQ). — Edokter • Talk • 15:54, 21 October 2007 (UTC)

Displaying some of the more exotic languages...

There are several languages that display only as large blocks (either with some sort of character in it, which is completely repeated over and over and over, or just a blank "this character doesn't exist" block). I know that on at least one wiki, there were instructions in the sitenotice for how to display the text properly, but there are a slew that don't have such instructions, and I'd like to find out how what fonts I need to install so that I can view the language properly.

For those that are curious, here's what I'm talking about:

And along the lines of what I'm looking for is my:Wikipedia:Font, which is extremely helpful (though I'd rather not pay $30 just so I can casually edit in a language) or am:Wikipedia:Can't see the font?, or the links on lo.wikipedia and ti.wikipedia. EVula // talk // ☯ // 16:40, 21 October 2007 (UTC)

Most of these actually have site notices, but currently, site notices are disabled for all Wikipedias. Kannada Wikipedia has kn:Wikipedia:Kannada Support, Malayalam Wikipedia has ml:സഹായം:To Read in Malayalam, Gothic has got:Wikipedia:Gothic Unicode Fonts. Bengali has bn:উইকিপেডিয়া:Bangla script display and input help (which fixes Assamese as well, and probably Bishnupriya Manipuri). Dhivehi has dv:Tāna_Support (not very useful though). Khmer has km:Install Khmer Unicode fonts. For all the others, no font help seems to exist, however you could use Google to try to find fonts yourself. -- Prince Kassad 05:09, 22 October 2007 (UTC)
I know this is a terrible answer, but newer operating systems are coming with more and more Unicode support right out of the box. For example, Windows Vista comes with many international fonts for many languages: [2]. So, the problem will slowly resolve itself in time as people transition to newer software.
That said, a page that listed Unicode character sets with links to free fonts to that can display them would be nice. —Remember the dot (talk) 05:37, 22 October 2007 (UTC)
@Prince Kassad: I had no idea that the site notices were disabled. How come? That would certainly explain my confusion over how I could have sworn I'd seen some before... thanks for the links, too. I can't check them right now, since I'm a bit busy, but I'll do so when I get home.
@Remember the dot: Eh, I wouldn't consider that a terrible answer. I use Mac OSX, which has excellent Unicode support (even as I was compiling the list, I was able to remove a couple of the wikis by finding the fonts and basically just double-clicking them; pretty nice to not have to restart the browser to see the characters). That said, I'd be surprised if I installed *all* the optional languages when I first set up the computer, and I've got no clue where the system DVD is. :D I'm gonna poke around Meta to see if there's a Unicode set list; if not, that seems like the best place for such a list to go. EVula // talk // ☯ // 05:53, 22 October 2007 (UTC)

Why Does Wikipedia Use Obscure File Formats?

I'm wondering why Wikipedia recommends the use of obscure file formats such as SVG and OGG. I'm tech-savvy enough to know how to deal with these, but my family isn't. I know there has been an increased focus on improving the accessibility of these formats through built-in automatic rendering, but they're still not nearly as simple to use as the universally accessible JPGs, PNGs, WAVs, or MP3s. Shouldn't Wikipedia emphasize accessibility of information? —Preceding unsigned comment added by Cromulent (talk • contribs) 19:48, 21 October 2007 (UTC)

Well, SVG will never be a total replacement for the JPG format. Its purpose is for vector-based imagery, while JPGs are better for photos; there's no way that something like Image:John Thomas Griffith posing.jpg could be replaced with a SVG version. Similar argument for PNGs.
As for OGG vs. other audio formats, I believe (and I could be wrong) that it's because MP3 is a proprietary format (while OGG is not) and OGG compresses better than WAVs. EVula // talk // ☯ // 20:53, 21 October 2007 (UTC)
As I understand it, Wikipedia prefers formats that are formally documented and not encumbered by patents. PNG should threfore be perfectly acceptable for its purpose (i.e, pixel graphics, such as logos or cartoons.) SVG is an acceptable vector format, and OGG is an acceptable compressed music audio: both are unencumbered and openly documented. They are therefore preferred over encumbered formats, e.g. MP3 for audio or any of the dozens of proprietary vector formats. Vector formats are preferred over pixel formats when the underlying data is in vector form, because vector files can be losslessly scaled. This leaves JPG, which is a compressed pixel format used for photographs. We do not have a good unencumbered alternative, so we live with it. The reason Wikipedia prefers unencumbered formats is that in theory a patent holder can shut you down if you use a patent-encumbered format. This actually happened in the late 1990's with the then-ubiquitous GIF format. the Opensource community responded by creatingthe PNG format within a few days, but the conversion hassles were horrible. Those of us who hold a grudge will never buy from Unisys again. -Arch dude 04:17, 22 October 2007 (UTC)

Blue

Is it just me, or have all non-mainspace pages turned slightly blue? - BANG! 04:09, 14 October 2007 (UTC)

They've always been slightly blue. —Remember the dot (talk) 04:12, 14 October 2007 (UTC)
I don't think so... Weren't they white before? - BANG! 04:16, 14 October 2007 (UTC)
No. Perhaps your computer's color depth was set too low previously, making the pages appear white. —Remember the dot (talk) 04:17, 14 October 2007 (UTC)
Oh. That explains it. Thanks! - BANG! 04:19, 14 October 2007 (UTC)
They are slightly blue! Wow, I actually never noticed that. Weird. Pyrospirit (talk · contribs) 04:04, 15 October 2007 (UTC)
Also, some screens I've used show very light colours as white; I couldn't see the blue background on those screens (or even the infamous pre-ambox 'pastel-shaded box' backgrounds). --ais523 08:08, 15 October 2007 (UTC)
Yep, but that can usually be fixed by twiddling with the monitor settings. BTW, the non-article space pages have not always been blue. They're a very light shade of blue in monobook since July 3, 2004.[3] Lupo 08:43, 15 October 2007 (UTC)
They all just went white for me for a few minutes, when the Wikipedia spam at the top just started, don't know if they are related. But it's back to blue again now. Gene Nygaard 23:18, 22 October 2007 (UTC)

Pic code not working

I tried putting my first image into an article today - a pic of USS Card into the Seattle-Tacoma Shipbuilding page. Unfortunately the code won't do what it's supposed to. It seems like it will only obey two commands but not three. Like for example, at the moment I've got it where I want it and the size I want, but it won't display the caption. If I get it to display the caption, I lose the size or the location parameter.

I'm using IE 7, don't know if that makes any difference. But the pics on all the other pages display fine, so why not this one? Gatoclass 16:03, 21 October 2007 (UTC)

I think you were looking for the 'thumb' parameter? See Help:Images on how to display images. — Edokter • Talk • 17:50, 21 October 2007 (UTC)
No, I'm not looking for thumb. Thumbs are too small. I want to have a 350px image on the right hand side, bordered with a caption. Everyone else seems to manage this without a problem, but for some reason the code won't work for me. I can't see that I'm doing anything different from anyone else, so it's really got me bamboozled. Gatoclass 17:54, 21 October 2007 (UTC)
Okay, I see you've edited it. Yes, that's what I wanted, thanks! However, the code is still not behaving the way it's described in the help pages, what if I want to put an image like this on the left instead of the right? Gatoclass 17:59, 21 October 2007 (UTC)
Then simply add the 'left' parameter (|350px|thumb|left|). Thumb images default to the right. — Edokter • Talk • 18:01, 21 October 2007 (UTC)

Easy when you know how! Thanks so much Edokter, I was getting very annoyed about this problem. It isn't clear at all from the help pages that you need to specify "thumb" as well as a pixel size, I assumed you only needed the one and that's what had me baffled. Gatoclass 18:14, 21 October 2007 (UTC)

Well, the "thumb" feature is completely optional, as is the size. The help pages could probably be a bit clearer on that, though. EVula // talk // ☯ // 20:55, 21 October 2007 (UTC)
The picture didn't display properly until the "thumb" parameter was included. So I don't think it's "optional" at all. Apparently it is a required field if you want to reduce the size of an image. Gatoclass 04:01, 22 October 2007 (UTC)
Not at all. You can always specify the size. The 'thumb' option only creates a border which displays the caption. But without a given size, thumb defaults to 150px. — Edokter • Talk • 14:09, 22 October 2007 (UTC)
Oh, okay, so you need the thumb in order to get the border and caption. That makes sense because I could previously get the reduced image but couldn't get it along with the caption, it was either one or the other.
Thanks once again for the clarification, Edokter, I think I'm finally up with the details now :) I think I will have to go and re-read the image pages though, because I don't recall reading any of these details and if they're not there then it's about time someone added them. Gatoclass 15:37, 22 October 2007 (UTC)
I think if you don't use "thumb" the caption text becomes alt text which is only visible when you put the mouse pointer over the image (without clicking on the image). (SEWilco 15:58, 22 October 2007 (UTC))

Yeah, I think you're right. Gatoclass 18:06, 22 October 2007 (UTC)

The skins Classic, Cologne Blue and Nostalgia don't have the links "Cite this article" and "Permanent link". Is that intentional? Help:Preferences#Skin says "Some links are not present in every skin", but doesn't mention these links. It seems impractical to not have consistent links. Wikipedia:Citing Wikipedia assumes "Cite this article" is there, and people asking for citation help at Wikipedia:Help desk are often told to click "Cite this article". PrimeHunter 00:25, 22 October 2007 (UTC)

It is intentional for the Classic and Nostalgia skins at least - they are throwbacks to how Wikipedia looked before the Monobook skin was invented - see Wikipedia:Mediawiki 1.3 and Wikipedia:Archive/Petition for the return of the Old Wikipedia for some discussion about, among other things, the then new Monobook skin. The permanent link feature was added in June 2005 and the cite this article link was added in November 2005, so adding those links to the nostalgia and classic skins would strictly be an anachronism. I'm not sure about the design of the Cologne Blue skin, but it was included in the first version of MediaWiki. I'm not sure how you would add the links either, seeing as different JavaScript files for each skin like MediaWiki:Monobook.js are deprecated. Actually, IIRC the three skins you mention don't even support JavaScript. Graham87 09:37, 22 October 2007 (UTC)

Special:Whatlinkshere

How long does it take for Special:Whatlinkshere to update? Luigi30 (Taλk) 13:02, 22 October 2007 (UTC)

It depends on the length of the job queue - when a template is changed, updating the whatlinkshere table is one of the things added to that queue. However I don't know of a metric to compare the number of job queue entries and the time taken. Graham87 13:53, 22 October 2007 (UTC)

Problem loading refdesks

I've noticed a problem loading the refdesks over the last day(ish). I have to click several times on the link from my watchlist before they load. I haven't noticed this problem with any other pages. As something of a refdesk regular, this is rather anoying! Any ideas about what is happening or how to fix it? DuncanHill 15:15, 22 October 2007 (UTC)

In case it's relevant, I'm using Safari on WinXP. DuncanHill 15:28, 22 October 2007 (UTC)
I also have the same problem if I type the shortcut (eg. WP:RDE) into the search box. DuncanHill 16:08, 22 October 2007 (UTC)

{{PAGENAME}} uncapitalized: how?

Comment: modifying the title for CB3. Protecting the braces using &#123;&#123; ... &#125;&#125; rather than <nowiki>...</nowiki>.Pldx1 (talk) 13:38, 27 January 2016 (UTC)
Is there a way to pull a page's pagename but have it start with small case? If so, please tell me how.

Thank you.

The Transhumanist 22:37, 22 October 2007 (UTC)

see Help:Magic words. You probably want {{lcfirst:{{PAGENAMEE}}}} -- Boracay Bill 02:14, 23 October 2007 (UTC)

Secure login

On the login page toward the bottom, it discusses security and offers an SSL option for login secure.wikimedia.org. However, this url does not work and states "Wiki does not exist". It has been like this for a while. I tried it about a month ago and got the same error on a different computer (thought it was a temporary glich as I had used it in the past). Also, if this gets fixed, could you please link the url on the login page as it would make it much easier when browsing from my phone. Morphh (talk) 18:58, 22 October 2007 (UTC)

It's not a link; is says the domain should be secure.wikimedia.org. But a link would be nice. — Edokter • Talk • 19:13, 22 October 2007 (UTC)
The link is https://secure.wikimedia.org/wikipedia/en/enwiki/w/index.php?title=Special:Userlogin (which I've had templated at {{User:ais523/SecureURL}} for a while because the question comes up often enough that it's useful to have a stock response). Last time it was linked from the UI, though, it was changed back (see MediaWiki talk:Loginsuccess); that connection isn't very fast and has problems (clicking on any link that's hard-coded to en.wikipedia.org, rather than {{fullurl}}'d, will leave the secure connection and log you out, and there have been problems with the destination of the Upload file link). --ais523 07:57, 23 October 2007 (UTC)
Well it is very confusing and turning it into a link would be helpful. How is any normal user suppose to know that they're to paste that domain name into the current domain path to the userlogin page? Most are going to copy the url provided "secure.wikimedia.org" and paste it into the address bar and come up with "Wiki does not exist". Please link it to something as this is just plain confusing for the normal user. I'm a computer geek and I didn't catch it - I just moved on disappointed. If we're going to put it there, we should to make it easy to access. To the point of leaving the secure connection, I would actually prefer it. I only need it encrypted when sending my password throught the Starbucks wireless network or something of the sort. Encrypt my authentication and send me back to en.wikipedia.org - that would be fine with me. Morphh (talk) 15:01, 23 October 2007 (UTC)
That's easier said than done. Currently, the secure sessions are not exchangeable with the http sessions--meaning that if you log in on the secure server, you will be logged in only on the secure server. There is furthermore very, very little server resource dedicated to secure.wikimedia.org, meaning that if every user who logs in to Wikipedia in a day did so on the secure server, it would crash. This is of course the primary reason that the direct link to the secure server was removed from the login text, and the reason that the URL is intentionally quite difficult to find. Everyone would prefer to use https; unfortunately, it is not feasible at this time. On that note, I think it would likely be a good idea to remove all mention of the secure server from loginend, as it's clearly confusing to many. Those who know enough to find the secure server likely know enough to not get phished. AmiDaniel (talk) 19:14, 23 October 2007 (UTC)
Why have a separate server? Why not add the cert to en.wikipedia.org and offer the same access across 443 for authentication? Wouldn't this allow them to maintain session as you transition back to 80? On a similar note, how come we don't support OpenID? Morphh (talk) 19:38, 23 October 2007 (UTC)
OpenID is dependent on the implementation of Single-user login, a.k.a. Bug 57, which will be done sometime between now and the heat death of the Universe. Secure login in the regular en.wikipedia.org server, is rather hard on the virtual host setup that Wikimedia uses, and is rather computationally expensive, as described on Bug 225. Titoxd(?!? - cool stuff) 20:25, 23 October 2007 (UTC)
I think the last poster on Bug 225 got it right. You don't have to encrypt the entire thing and you don't have to offer it by default. I'm not sure how virtual servers are much different than physical servers. The host names should not matter much as the cert would use the alias name (en.wikipedia.org). I mean come on... we're a top 10 destination on the Internet and we can't even encrypt the authentication? If we can't afford the CPU cycles on the server get a SSL gateway or something. This should really be addressed. Morphh (talk) 21:10, 23 October 2007 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_1&oldid=1109563117"