Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Line 192: Line 192:


'''Support'''. Should've been there in the first place if you ask me. It it's moved there, we could have an article about [[main page]]s.
'''Support'''. Should've been there in the first place if you ask me. It it's moved there, we could have an article about [[main page]]s.
*Still '''oppose''', as it is still a solution looking for a problem (we can change the tab name for all mainspace articles to "page" and nobody would blink), and per [[Tim Berners-Lee]]'s eloquent reasoning on this [http://www.w3.org/Provider/Style/URI here]. Even if we changed the name of the page, http://en.wikipedia.org/wiki/Main_Page would need to continue being an access point to the Main Page, negating the possible benefits. [[User:Titoxd|Tito<span style="color:#008000;">xd</span>]]<sup>([[User talk:Titoxd|?!?]] - [[WP:FAC|cool stuff]])</sup> 09:10, 25 July 2008 (UTC)


===Also move [[Wikipedia:Community portal]] to [[Portal:Wikipedia community]]?===
===Also move [[Wikipedia:Community portal]] to [[Portal:Wikipedia community]]?===

Revision as of 09:10, 25 July 2008

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla because there is no guarantee developers will read this page. Problems with user scripts should not be reported here, but rather to their developers (unless the bug needs immediate attention).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Proposal: Move main page to Wikipedia namespace

I would like to propose that we move the Main Page to Wikipedia:Main Page. This would offer a number of benefits, including:

  • Causing the top-left tab to read "project page" instead of "article"
  • Making it easier to make a mass-copy of Wikipedia's articles without picking up project-specific pages like the main page

There would of course be a redirect from Main Page to Wikipedia:Main Page, and we could even hide the "redirected from Main Page" notice using CSS, making the transition virtually seamless. The German Wikipedia has actually their main page to the Wikipedia namespace and it is working great for them. —Remember the dot (talk) 05:11, 17 July 2008 (UTC)[reply]

I find illogical that the Main Page be in the article namespace, too, but wouldn't this proposal belong to Talk:Main Page? --A r m y 1 9 8 7 ! !  09:46, 17 July 2008 (UTC)[reply]

It's been proposed a few times, never seems to go anywhere. Doesn't bother me much, but whatever, I could go either way. -- Ned Scott 02:13, 18 July 2008 (UTC)[reply]

This would probably have a lot of opposition and discussion before it went anymore. I don't think it's such a big deal and it doesn't need to be changed. Gary King (talk) 07:49, 18 July 2008 (UTC)[reply]
I disagree with this. The main page is actually part of the encyclopedia, even though it contains a lot about the workings of wikipedia as well. --Apoc2400 (talk) 19:29, 18 July 2008 (UTC)[reply]
It will still be part of Wikipedia, just in a different namespace so that the software doesn't think it's an article. —Remember the dot (talk) 19:51, 18 July 2008 (UTC)[reply]
  • Oppose. I think this is more trouble than it's worth. I don't count either of those arguments as particularly convincing- knocking up some coding to change the tab to read something different (I'm fairly sure it used to read something else anyway) shouldn't be too difficult for someone who regularly plays with that sort of thing. As for the other issue- if someone is going to the trouble of copying our millions of pages, I don't think it would be too much trouble for them to filter out those that they don't want. In any case, that's hardly our concern. As for an argument for keeping it as it is- don't try to fix what isn't broken. J Milburn (talk) 20:13, 18 July 2008 (UTC)[reply]
    • We tried coding things specially around the main page, and the developers rejected it. See [1] and bugzilla:14267, which was closed as WONTFIX because any way we do it it just comes down to being a hack. Moving the main page to the Wikipedia namespace, on the other hand, is a much more elegant solution that shouldn't upset the developers. —Remember the dot (talk) 20:49, 18 July 2008 (UTC)[reply]
  • Support change to support for "Portal"; see below. I don't know how hard it is or whether it's really worth it; that's something that would need to be evaluated. But I do think it's clearly the right thing to do, if costs are not considered. Titles in article space are supposed to be about the concept (or at least a concept) standardly referenced by their names. Outside of a specifically WP context, no one considers Main Page to refer to the topics treated on the main page. So having it by that name in article space is incorrect. --Trovatore (talk) 20:20, 18 July 2008 (UTC)[reply]
What name space is say WP:NOPV in?Geni 20:23, 18 July 2008 (UTC)[reply]
Wikipedia space. --Trovatore (talk) 20:24, 18 July 2008 (UTC)[reply]
Hmm missed that change. http://en.wikipedia.org/w/index.php?title=Special%3AAllPages&from=CAT&namespace=0 this lot then].Geni 20:31, 18 July 2008 (UTC)[reply]
  • Is this important? Both of the advantages cited above are (in my mind, anyway) pretty trivial (regarding the second, since the Main Page is, to my knowledge, the only "non-article" page in mainspace, I have no idea what else would incorrectly be caught by a "mass-copy", and in any case this proposal won't fix those other pages). So, yes, I'll concede that the Main Page belongs, in a theoretical sense, in projectspace, but is this really worth all the time and energy it will take - assuming it will be successful - to make the change? Perhaps we could work, instead, on something else - say, the hundreds of thousands of stub articles, or all of the maintenance backlogs? -- John Broughton (♫♫) 21:27, 18 July 2008 (UTC)[reply]
    • It will actually take very little time and energy to make the change - moving the main page can be done by any administrator, and Main Page will be made into a redirect to Wikipedia:Main Page. To ease the transition, a simple CSS declaration will keep the "redirected from Main Page" notice from appearing. And since the change is so subtle, I suspect that most people won't even notice. —Remember the dot (talk) 21:40, 18 July 2008 (UTC)[reply]
      • They will also have to change Mediawiki:Mainpage. Algebraist 22:07, 18 July 2008 (UTC)[reply]
        • Yes, I know. I probably should have been more explicit about this in my last comment, but still, it's not hard. —Remember the dot (talk) 22:08, 18 July 2008 (UTC)[reply]
          • Then there are the subpages, the backup pages, the redirects... Then there will need to be the technical updates (changing what en.wikipedia.org takes you to) updating the various links (such as in the sidebar) and probably other things- I'm really not a techy. Please don't pretend that this is a simple two minute job. Also, it's ironic that you advocate "a simple CSS declaration" after arguing against my advice to use such a thing to change the tab claiming that it is "a hack". J Milburn (talk) 09:33, 19 July 2008 (UTC)[reply]
            • CSS is much, much different than JavaScript. If someone doesn't have JavaScript, then the change won't work at all. If someone doesn't have CSS, they'll just see the "redirected from..." notice and be slightly more motivated to update their links to the main page. —Remember the dot (talk) 23:35, 19 July 2008 (UTC)[reply]
de:Hauptseite - See the redirect in action. Neat! ~ JohnnyMrNinja 05:27, 19 July 2008 (UTC)[reply]
Support Portal:Wikipedia even more, as it is even logicaler. Also a great way to introduce readers to the idea of portals. ~ JohnnyMrNinja 17:48, 23 July 2008 (UTC)[reply]
  • Comment - Didn't the upper-left tab used to read "Main page" at one point? I'm sure, because I remember thinking how intriguing it is to see that different from every other page. Don't know why they changed it though. I really don't know what to think, I too could go either way on this one. --.:Alex:. 08:35, 19 July 2008 (UTC)[reply]
  • A simile: The Wikipedia space is made for editors. Placing the main page into the Wikipedia space forces casual readers into the background of Wikipedia, where they do not want to be. It's like placing the reception desk at a sports club in the manager's office- instead, it should be right in front of the door in an accessible place, pointing people to the facilities they want. Visitors should have to go into the manager's office only if they want to make a complaint or have some business of some sort with the club. Someone who has come along to use the facilities has no business with the manager and has no desire to be in his or her office. J Milburn (talk) 09:40, 19 July 2008 (UTC)[reply]
  • Oppose, there's not much point in this. The redirect will not be hidden for browsers and other pieces of software that don't support CSS, like mobile devices, old screen readers and text browsers. Also, as far as page history is concerned, the title Wikipedia:Main Page is problematic: it was the original title of the Community Portal, but now that is very difficult to figure out because of a page move to a very bad title which can only be undone by developers. I have filed bug 13729 to get the revisions where the page was moved to the Community Portal undeleted. If the move goes ahead, the page move revisions mentioned in bug 13729 should be undeleted and moved to the right place, and Wikipedia:Main Page and its talk page should be moved to a subpage of Wikipedia:Historical archive, so it becomes marginally easier to follow talk page conversations like this one by just following old links, logs and history. This may seem trivial, but there is no point in losing page history just because of a namespace conflict that wasn't even thought of four years ago. Graham87 16:23, 19 July 2008 (UTC)[reply]
  • Oppose - We're going to turn tens (hundreds?) of thousands of direct links into links to a redirect so we can have different text in the little tab (which we can change, and I believe did change in the past, using JavaScript) and to provide a minor convenience to people who download all the articles but don't want the main page (I don't think its been confirmed that most people who do this don't want the main page either)? I really don't see the point. Mr.Z-man 18:47, 19 July 2008 (UTC)[reply]
    • The JavaScript hack was even worse of a hack than the hack the developers rejected. The redirect will be transparent like the German Wikipedia has, and links will be migrated over. And Answers.com, for one, does not want our main page. —Remember the dot (talk) 18:56, 19 July 2008 (UTC)[reply]
      • As far as I can tell, the JS hack was replaced by a change to MediaWiki:Nstab-main, but when this was reverted for performance reasons, the JS hack wasn't put back in. So there was never even a discussion about leaving the tab as "article" AFACT. The JS hack was just a few lines of code, I can't imagine it was causing any issues. The bug was WONTFIX'd because it was deemed unnecessary (by 2 developers) to add such a feature to the core MediaWiki code just for a couple projects like ours, not because it was a horrible hack. As for migrating the links, how is this planned to be done? Mr.Z-man 21:00, 19 July 2008 (UTC)[reply]
        • Please reread the last two comments to bug 14267:
Comment #12 From Simetrical 2008-07-02 01:02:18 UTC
Reusing [[MediaWiki:Mainpage-description]] is definitely the wrong way to go
about this.  Reusing messages is usually a bad idea.  It's perfectly plausible
to want something different in the nstab and the sidebar, e.g., "Back to Main
Page" might be appropriate for the sidebar but not the nstab.  Also, if the
main page is in a namespace whose nstab description is appropriate, say
"project page" or just "page", there's no reason to change it, so any change
should be strictly optional.

Do keep in mind that with the default messages, there's no problem at all.  The
default nstab for namespace 0 is "page", which is totally appropriate for the
main page.  If enwiki wants to create problems for themselves by changing what
namespace 0 is supposed to contain and then refusing to actually stick to their
decision by leaving the main page there, that's not something we need to
consider supporting in software, IMO.  If they think the extra X lines of
JavaScript are superior to adjusting their other customizations, that's their
decision as site admins.  Lots of people do stupid stuff with the software --
we don't have to support it just because it happens to be a big wiki.  In the
software as shipped, this is a non-issue.

Suggest WONTFIX.
Comment #13 From ^demon 2008-07-02 01:11:56 UTC
(In reply to comment #12)
> ...If enwiki wants to create problems for themselves by changing what
> namespace 0 is supposed to contain and then refusing to actually stick to their
> decision by leaving the main page there, that's not something we need to
> consider supporting in software, IMO...

I agree with you fully here. Like I said, this comes down to being a hack.

> Suggest WONTFIX.
> 

You've convinced me. Marking as such.
As you can see, the developers clearly viewed adding special behavior for the main page as a hack and furthermore called the JavaScript hack "stupid". JavaScript is not a good solution here because it won't work for screen readers, text-only browsers, and search engines, and it also adds a very large about of overhead compared to changes in page content or changes in MediaWiki.
Anyway, I can help clean up the links using AWB, and if that proves too overwhelming then I can write up a script or a bot to do the job for me. —Remember the dot (talk) 23:23, 19 July 2008 (UTC)[reply]
So a couple people dislike the Javascript hack, instead of not caring, we're going to move the page, then run a script to make thousands of edits to update all the incoming links. I would hardly call a handful of lines of Javascript (which is cached anyway) a large amount of overhead. I'll ask again what I asked before: Have there been any complaints or comments from readers, such as on Talk:Main Page about the tab? I haven't seen any. This seems like a bit of an imaginary problem. As far as people downloading all of Wikipedia and not wanting the main page, how many are there? I just don't think this is worth the trouble. The benefits are minimal to non-existent, and one of the benefits doesn't even benefit Wikipedia directly. Mr.Z-man 23:40, 19 July 2008 (UTC)[reply]
But that's just the thing: you won't have to go through any trouble. Main Page will continue to work as before, and I will be working to transition the links over to Wikipedia:Main Page anyway. You just have to sit back and relax.
Another benefit is that moving the page to the Wikipedia namespace would also allow us to create an article at the location Main Page should the need ever arise. It's not a problem right now, but it could become one in the future. —Remember the dot (talk) 23:50, 19 July 2008 (UTC)[reply]
  • Oppose, the main page belongs in the mainspace along with the rest of the reader-facing encyclopedia pages. Project space is for pages that are related to the internal workings of the project. Christopher Parham (talk) 18:59, 19 July 2008 (UTC)[reply]
  • Oppose, basically agree with Z-man. And Remember the dot, as much as you insist that this is just a "technical issue," it's a much-debated and very contentious topic here, and I doubt you'll get consensus to make it happen. -Elmer Clark (talk) 20:19, 19 July 2008 (UTC)[reply]
  • Oppose. (now Neutral on Portal:Wikipedia.) Even if we were to move it, it's not a "project" page (i.e., one that deals with the administration of Wikipedia), it's a portal page.--Father Goose (talk) 22:01, 19 July 2008 (UTC)[reply]
    • It's easier to move it to the Wikipedia namespace than to the Portal namespace because it enables us to be more consistent with other Wikimedia projects that do not have a Portal namespace. The German Wikipedia, for example, has their main page in the Wikipedia namespace, and it would be good for consistency if we did the same. —Remember the dot (talk) 23:23, 19 July 2008 (UTC)[reply]
  • Comment - without reading earlier post, I can assure you this has been brought up several times, and either rejected or closed as no consensus on each occasion. With all due respect, RTD, this is almost certainly the wrong venue; wouldn't this be better as a(nother) requested move or at VPP? The Evil Spartan (talk) 23:46, 19 July 2008 (UTC)[reply]
  • Oppose, headache-causing solution looking for a problem. Titoxd(?!? - cool stuff) 01:59, 20 July 2008 (UTC)[reply]
  • Oppose — Not only would this proposal cause a number of technical headaches if implemented (omitted here for succinctness), but it also has questionable benefits: "project page" is not much better than "article" (indeed, I prefer "article" as it introduces the interface nicely for readers) and excluding the Main Page from an article dump is a trivial task. Further, it seems to me to be semantically less correct as well: as Father Goose mentions, Wikipedia-namespace pages are, semantically, for the administration of Wikipedia rather than for Wikipedia's content: the Main Page is much more of a content page regardless of its special status as pseudo-content. Personally I think the ideal would be to make the Main Page a Special-namespace page through an extension of some sort (while still using the name "Main Page"), but that's beyond the scope of this discussion. {{Nihiltres|talk|log}} 03:14, 20 July 2008 (UTC)[reply]
  • Oppose even if it was moved to the project space the title "Main Page" would always have to be a permanent redirect to the new main page just due to that fact that there are millions of on wiki and off wiki links to it and since the title of the page is not viewable except in the url it would really not change a thing. In short its useless work for the devs. - Icewedge (talk) 03:17, 20 July 2008 (UTC)[reply]
  • Support [edit: I support SamuelWantman's alternate proposal, below, instead] - There is nothing encyclopedic about the "Main" page. It is merely there to highlight the accomplishments of the project that is Wikipedia as a whole. If someone were to create a "Most interesting articles about topic X" page, it would quickly get moved from the article namespace. SharkD (talk) 03:24, 20 July 2008 (UTC)[reply]
  • Comment Wouldn't this make the title say 'Wikipedia:Main Page' rather than 'Main Page'? Isn't that, you know, much uglier than 'Main Page'? — Werdna • talk 08:04, 20 July 2008 (UTC)[reply]

Arbitrary break to the first mention of Portal:Wikipedia

  • Oppose Wikipedia:Main Page, might support Portal:Wikipedia I don't think it is a administrative page, so it does not belong in Wikipedia space. It is the portal to all of Wikipedia, so why not call it that? -- ☑ SamuelWantman 05:43, 20 July 2008 (UTC)[reply]
    • You're idea is intriguing, and I think it would be beneficial to, in addition, garner more attention toward portals, as a whole. I think if Wikipedia were refactored to project a more of a "Portal" atmosphere (e.g., wherein visitors' first destination when entering Wikipedia is a portal of some sort), it might be better. SharkD (talk) 06:03, 20 July 2008 (UTC)[reply]
  • Support, but I expect we won't do this until the day we need to have an article about a novel called Main Page. I encourage every novelist out there to write one to force us to do this move. Kusma (talk) 09:09, 20 July 2008 (UTC)[reply]
    To make it clear, I support moving out of article space, and don't really care whether the main page ends up in Wikipedia space or in portal space. Kusma (talk) 06:09, 24 July 2008 (UTC)[reply]
  • Support It's not an article. Taking it out of article space is long overdue. The "it's not broken" parochialists need to think about those who use our data dumps. -- Earle Martin [t/c] 10:03, 21 July 2008 (UTC)[reply]
  • Support The Main Page being in article-space is causing problems; there are more places where the Main Page has to be special-cased than you might think. (For instance: the 'cite this article' link in the sidebar, edit counts, the number of articles has to have 1 subtracted from it to allow for the main page, the namespace tab says 'article' by default unless fixed with JS (and the devs refused to fix it on the server because it would cause too much load), bots will treat the Main Page as if it were an article unless special-cased, and so on. Besides, think about which deletion process would be used to delete the Main Page: surely, it should be MfD, not AfD!) This isn't a difficult change to make, several other Wikimedia wikis have done it already, and the old name will continue to work (we can put a redirect there). --ais523 15:26, 21 July 2008 (UTC)
  • Support: per ais523. --MZMcBride (talk) 15:33, 21 July 2008 (UTC)[reply]
  • Support Portal:Wikipedia The Main Page doesn't really belong in either article space or Wikipedia space (as noted by others). However being in portal space does seem appropriate. Portal:Wikipedia sounds much better than Portal:Main Page and is exactly what the page would be -- a portal to Wikipedia. -- Imperator3733 (talk) 16:47, 21 July 2008 (UTC)[reply]
  • Comment I don't like how Portal:Wikipedia moves all the content down to accomdate for the Portal:Wikipedia title. If that could be gotta rid of, then I'd probably support (weakly). –xeno (talk) 02:26, 23 July 2008 (UTC)[reply]
  • Strong support. Portal:Wikipedia is a perfect name that would simultaneously resolve several issues (incorrect namespace, incorrect tab label, and the common complaint that the term "main page" is a misnomer). It also would help new users to understand our namespace setup (including the fact that only articles should lack a prefix) and draw more attention to the portal namespace.
    Arguments against a move are based on the incorrect beliefs that the current title causes no problems and that a move would be difficult to handle. (In actuality, Main Page would function as a redirect, and a bot could repair all of the double redirects in a matter of moments.) This really would be a significant improvement, and I don't see any real downside. —David Levy 03:47, 23 July 2008 (UTC)[reply]
  • Support Portal It does seem to be a portal, more than anything else. Really I don't think the main page is quite like anything else; strictly speaking it should probably have its own namespace all to itself, but that might be pushing people's patience. I would note here that I don't really care about the technical issue the original proposer brought up — I have my own software to write and don't have time to care about MediaWiki internals. I think users should not see Main Page as an article, because it isn't about any concept standardly called Main Page. --Trovatore (talk) 04:01, 23 July 2008 (UTC)[reply]
  • Question - Is there any reason that the redirect notice hasn't been taken off the main page anyways? Because if this change is made, then redirects like Portada will no longer show as redirects. If we don't want them to show, then why hasn't this already been fixed? If we do, then what do you propose to do about it after the move? ~ JohnnyMrNinja 04:43, 23 July 2008 (UTC)[reply]
  • Strong support. Moving the Main page to portal space also makes a stronger case to use a more inclusive portal design that incorporates aspects of the encyclopedia and the community that develops it. With the proper sprucing up for a consistent layout and palette, the main page redesign proposal, RichardF2, just as easily could be located at Portal:Wikipedia. RichardF (talk) 16:53, 23 July 2008 (UTC)[reply]
  • Support per David Levy and Trovatore. At this point, I honestly can't see any further valid objections to this outside of I(DONT)LIKEITs. —Dinoguy1000 16:54, 23 July 2008 (UTC)[reply]
  • Question - So, it seems pretty clear that a consensus for Portal:Wikipedia is forming. At this point, what exactly is the rest of the proposal? If I am clear, Portal:Wikipedia will be transcluded on the main page for a period of time, however long is felt is needed to make people comfortable. People will use bots or whatever to convert all the old links to the new links. Then the main page will then be redirected to P:WP. The redirect may or may not be hidden. Did I miss anything? ~ JohnnyMrNinja 17:35, 23 July 2008 (UTC)[reply]
    • Wouldn't a redirect be better than transclusion? SharkD (talk) 17:47, 23 July 2008 (UTC)[reply]
      • Not at first, if the idea is a "seamless" transition. If it is transcluded first, then every thing that links to it can be fixed before it is redirected with little headache. ~ JohnnyMrNinja 20:03, 23 July 2008 (UTC)[reply]
    • JohnnyMrNinja: No, there is not necessarily a consensus forming. That those who have opposed above the "Portal:Wikipedia" line have not reiterated their opposes below the line does not invalidate their opposition to such a change. {{Nihiltres|talk|log}} 19:37, 23 July 2008 (UTC)[reply]
      • Okay, but many of the arguments against the move were negated with the new title, as the main page is a portal, not an article or project page. My basic point was, a lot of people are now supporting this proposal, but as the proposal has changed, we should clarify what it is exactly. ~ JohnnyMrNinja 20:03, 23 July 2008 (UTC)[reply]

Support. Should've been there in the first place if you ask me. It it's moved there, we could have an article about main pages.

Also move Wikipedia:Community portal to Portal:Wikipedia community?

  • Comment / expanded proposal. I was thinking. If it makes sense to move the Main page to portal space, then it really makes sense to move Wikipedia:Community portal to portal space. Saying that, now seems to be an excellent time to take advantage of the current Main page redesign discussions and pull together these top-level pages into a coordinated redesign. As a proof-of-concept demonstration, Wikipedia:2008 main page redesign proposal/RichardF2, can be used to illustrate the direction this top-level Wikipedia portal can take. The final version would need consensus on content, layouts and palettes. Some of the key points follow.
RichardF (talk) 02:25, 24 July 2008 (UTC)[reply]

Portals are pages intended to serve as "Main Pages" for specific topics or areas. Portals may be associated with one or more WikiProjects; unlike WikiProjects, however, they are meant for both readers and editors of Wikipedia, and should promote content and encourage contribution. ...

The idea of a portal is to help readers and/or editors navigate their way through Wikipedia topic areas through pages similar to the Main Page. In essence, portals are useful entry-points to Wikipedia content. — Wikipedia:Portal

RichardF (talk) 16:50, 24 July 2008 (UTC)[reply]

Why not Portal:Main Page?

That's what some other wikis use (in their own language). (oh, and I support moving it into the portal namespace in any form) --Random832 (contribs) 20:14, 23 July 2008 (UTC)[reply]

It is literally true, and (I think) looks better. Also, Portal:Wikipedia puts it right in line with naming conventions. To the uninitiated, Portal:Wikipedia makes more sense than Portal:Main Page (it's a portal to the main page?). Wikipedia:Main Page looks like "Wikipedia - Main Page" or something, so that makes sense. The only reason (that I can see) to favor Portal:Main Page over Portal:Wikipedia is for nostalgia. ~ JohnnyMrNinja 20:25, 23 July 2008 (UTC)[reply]
"Main Page" doesn't comply with our style guidelines, and while "Main page" is an option, many users have commented that this term doesn't accurately describe the page's nature. —David Levy 20:20, 23 July 2008 (UTC)[reply]

SSL for UserLogin?

I read on WP:BN about admin accounts being hacked. Why isn't SSL implemented for Special:UserLogin? =Nichalp «Talk»= 08:50, 19 July 2008 (UTC)[reply]

There's always Wikimedia's semi-secure proxy server, though I too would like to see SSL more tightly integrated into Wikipedia. —Remember the dot (talk) 14:51, 23 July 2008 (UTC)[reply]
BTW, I don't think that's what happened in this case. Someone got a hold of two administrator accounts' passwords through some other means. Guessing correctly perhaps. We had several admin accounts compromised a while back because their passwords were "password" or "wikipedia" or something else that was easy to guess. —Wknight94 (talk) 15:51, 23 July 2008 (UTC)[reply]
The Secure server always throws errors when I try to log in, requiring actually strong passwords would be much better, but inthis case, it was just a user having a dumb password that would've satisfied most strength requirements. MBisanz talk 07:37, 24 July 2008 (UTC)[reply]

Template limit

I was recently told by two different people that, a) there is a limit on the number templates a page may have (including any templates used internally by other templates) and, b) the wiki will stop processing templates if it takes longer than 30 seconds to evaluate them. Which is true, or are both statements accurate? Also, does the 30 second limit apply to a single template or the sum of all templates in a page? Thanks! SharkD (talk) 23:50, 19 July 2008 (UTC)[reply]

The template limits are documented at Wikipedia:Template limits. There are limits on how long a page can take to parse and how much memory can be used in the course of parsing, but I don't know if they are documented anywhere. It's much more common to encounter the template limits first, since their goal is to prevent the most common reasons that a page might be too expensive to parse. — Carl (CBM · talk) 00:10, 20 July 2008 (UTC)[reply]
Thank you! I've noticed that this article takes a long time to load since I switched to using templates for the dates. Here is the message from the HTML source:

"NewPP limit report
Preprocessor node count: 196354/1000000
Post-expand include size: 297426/2048000 bytes
Template argument size: 122988/2048000 bytes
Expensive parser function count: 258/500"

I was wondering if I am maybe pushing it with regard to template use. Most of the values aren't really near the limits, yet the affect upon page load times is nonetheless considerable. Finally, within the template itself (Template:vgrelease tbl (backlinks edit)) I would like to replace some of the common operations with additional templates in order to simplify the source code. What effect will this have upon the above limits? Would you recommend this action? SharkD (talk) 01:23, 20 July 2008 (UTC)[reply]
Yes, you are pushing the limits. The important number in your data is the preprocessor node count, which at 196,000 is extremely high. The limit for that node count was reduced once in the past, then made larger again because of some complaints. I expect it will be made smaller in the future (much less than 100,000). Your 'expensive parser function count' is also high.
I would advise you to stop using templates for the dates, and switch back to the previous method. Just because you can make it work with templates doesn't mean you should, in this case. — Carl (CBM · talk) 01:43, 20 July 2008 (UTC)[reply]
Isn't one of the basic en-wp laws: "use as much templates as possible"? *scnr* HardDisk (talk) 01:47, 20 July 2008 (UTC)[reply]
Templates make maintenance much easier. SharkD (talk) 01:56, 20 July 2008 (UTC)[reply]
Yes, of course. In an ideal world we could use them as liberally as we want and never hit any issues. In practice, pages that have long tables with complicated templates in every row can overwhelm the mediawiki parser. So for pragmatic reasons we have to do things other ways, like hard-coding formatting. — Carl (CBM · talk) 02:02, 20 July 2008 (UTC)[reply]
Sidenote: I don't think there is a 30 second limit anywhere. I was able to get that page up to 35 seconds with profiling (seen here). I think the fist time limit you'll hit is a WMF squid error (looking sort of like this) if the apache backend or database server hasn't responded within 60 (?) seconds. But that is pretty rare with the new preprocessor/template/parserfunction limits and thumbnail resolution limits designed to stop that sort of thing. You might also hypothetically run out of memory with some thumbnailing or parsing issues, or get a general HTTP/500 error (I did, when trying to save a page with 15,000 unique links), much faster than 30 seconds. --Splarka (rant) 02:16, 20 July 2008 (UTC)[reply]
Could you maybe provide some specific optimization tips for this particular template? By turning the c parameter off in the template I was able to bring the preprocessor node count down to about 175000, but this is not a significant improvement. SharkD (talk) 02:19, 20 July 2008 (UTC)[reply]
If there were some way of storing local variables, I could bring down the number of calls to the parser functions considerably (I estimate by 90% in this case). Is there a "local variables" extension installed in Wikipedia? I found one in the WikiMedia help pages, but haven't seen it used here anywhere, so assume it hasn't been installed. SharkD (talk) 02:35, 20 July 2008 (UTC)[reply]
No, there's not, and there never will be. Even if there were, it would be pointless if your sole goal is to cut down on repeated use of parser functions like #if or #ifexist with the same arguments, since evaluating the variable declaration would probably be about as expensive. You might save something on #expr, I'll grant, if that's your issue. —Simetrical (talk • contribs) 17:34, 20 July 2008 (UTC)[reply]
I'm curious as to why you say, "there never will be"? Also, here's an example of one of the conditions:
{{#if:{{{ 3|}}}|{{#ifexpr:{{#ifeq:{{DATEDIFF2|{{{ 2}}}|{{{ 4}}}}}|0|1|0}}or{{#ifeq:{{{ 2}}}|{{{ 4}}}|1|0}}|/{{vgrabbrv|{{{ 3}}}}}}}
Maybe you could evaluate whether local variables would be beneficial in this case. SharkD (talk) 03:04, 21 July 2008 (UTC)[reply]
Note that the above line of code has changed to this:
{{#ifeq:{{#iferror:{{#time:c|{{{16}}}}}|{{{16}}}|{{#time:c|{{{16}}}}}}}|{{#iferror:{{#time:c|{{{18}}}}}|{{{18}}}|{{#time:c|{{{18}}}}}}}||}}
SharkD (talk) 04:43, 21 July 2008 (UTC)[reply]
I say "there never will be" because that's the sentiment I've heard expressed by at least one core developer. At any rate, in that statement variables would indeed be useless for performance.

First of all, note that you can make it look a bit nicer, and probably reduce the node count slightly, by using the fact that {{#iferror:A|B}} is the same as {{#iferror:A|B|A}}. So your code could become just {{#ifeq:{{#iferror:{{#time:c|{{{16}}}}}|{{{16}}}}}|{{#iferror:{{#time:c|{{{18}}}}}|{{{18}}}}}||}}, which removes any repeated expression that you could possibly make a variable.

Second of all, #time maintains a per-render cache of return values. The statement {{#time:c|{{{16}}}}} will be evaluated only once, and {{#time:c|{{{18}}}}} will be evaluated only once, even if they occur many times. Variables will not reduce that. They still have to be parsed multiple times to get the arguments and pass them to the correct function, and this increases various limits like node counts, but the same would be true of variables. —Simetrical (talk • contribs) 22:08, 21 July 2008 (UTC)[reply]

The issue is (mostly) not with regard to the number of repeated expressions within each line of code; rather it's with the fact that the same line of code, with few changes and with largely the same expressions inside, is used 200 times in the template. Note that the line of code also contains a call to another template, which I failed to show in the example I gave. Here's a more accurate example:
#if:{{{ 3|}}}|{{#ifeq:{{#iferror:{{#time:c|{{{ 2}}}}}|{{{ 2}}}}}|{{#iferror:{{#time:c|{{{ 4}}}}}|{{{ 4}}}}}|/{{vgrabbrv|{{{ 3}}}}}}}{{
And, thanks for the tip regarding the #iferror: statement. That was really helpful. SharkD (talk) 06:44, 22 July 2008 (UTC)[reply]
(de-indenting) I don't think a variable would be very much faster there either, although it would look prettier. If it's the same template being called over and over, I don't think it would make any big performance difference. I'm not an expert on the parser, though. —Simetrical (talk • contribs) 16:46, 22 July 2008 (UTC)[reply]

This whole template should be re-thought. What is the important functionality? I see a number of things that are being done, or might be planned:

  • Linking dates
  • Formatting dates
  • Collapsing dupe dates
  • Linking regions
  • Sorting

Sorting using template code is a really terrible idea, so if you're doing that, don't. Auto-linking regions is fairly simple and is quite useful, so that's good. Linking dates is ever a controversial practice. Formatting dates is likely beyond the scope of the template - if people can't format the dates consistently, they're likely not going to use the template correctly. This is easy enough for a human to do by hand. Collapsing dupe dates is very cool, but it can definitely be done better. Specifically, you should assume that the person using the template can tell that the dates are the same, and can somehow tell the template this knowledge (e.g., by leaving the date parameter after the region blank). --- RockMFR 03:31, 20 July 2008 (UTC)[reply]

I thank you for your comments. While, in its current form, the template might not be suitable for long lists or tables after all, the performance hit on an individual article shouldn't be too steep.

"NewPP limit report
Preprocessor node count: 372/1000000
Post-expand include size: 1703/2048000 bytes
Template argument size: 998/2048000 bytes
Expensive parser function count: 1/500"

The point is to unify the template so that it uses a single syntax in every case. Currently, the standard template for this purpose requires that it be applied in one of four or five different ways to achieve the same results.
Also, I was hoping you might provide more guidance along the lines of the use of local variables to store temporary values, as per the request above, as that will have an markedly greater impact than the suggestions you provide. I would appreciate any information in this regard. SharkD (talk) 06:35, 20 July 2008 (UTC)[reply]
m:Help:Calculation#Length_of_expressions says something about providing some of the functionality that variables offer.--Patrick (talk) 10:38, 20 July 2008 (UTC)[reply]
I don't know where your last report came from, but the article in question is getting worse instead of better:

NewPP limit report
Preprocessor node count: 200998/1000000
Expensive parser function count: 258/500

This really should be changed to a more efficient setup. — Carl (CBM · talk) 17:50, 20 July 2008 (UTC)[reply]
The quoted values were for a single instance of the template with two dates and regions passed as parameters. The count is still high, though using your suggestions I was able to lower it considerbaly. SharkD (talk)

Improved

I spent a few minutes making the templates more efficient for Chronology of tactical role-playing video games. The results:

NewPP limit report
Preprocessor node count: 31260/1000000
Post-expand include size: 153476/2048000 bytes
Template argument size: 73840/2048000 bytes
Expensive parser function count: 0/500
Served by srv60 in 8.341 secs.

I think the main culprits were some sorting code, and Template:ISO_3166-1, which is much too expensive. Here are a couple tips if this comes up again:

  • Don't use parser functions to sort. Expect users to sort the input.
  • Don't make a template that does the same thing to each entry or pair of entries in a variable length list. Instead, use the same template over and over, once for each entry or pair of entries.
  • Avoid nesting templates very deeply - if needed, rewrite templates to avoid it.
  • Avoid the ifexists call when possible - don't use them just to avoid redlinks to pages that will probably be created at some point.

— Carl (CBM · talk) 19:31, 20 July 2008 (UTC)[reply]

You're right, Template:ISO_3166-1 (or, rather Template:vgrabbrv which makes use of it) was the main culprit. By making it less likely for the template to be called, I was able to reduce the count (see User:SharkD/Sandbox2) to the following:

Preprocessor node count: 69863/1000000
Post-expand include size: 404395/2048000 bytes
Template argument size: 153574/2048000 bytes
Expensive parser function count: 258/500

Removing the "expensive parser function count" is the next main priority.
Note that your version is missing one of the main features added for the express purposes of sortable tables: the date should appear in YYYY-MM-DD format within <span style="display:none"></span> tags, as discussed in Template talk:Vgrelease. SharkD (talk) 02:34, 21 July 2008 (UTC)[reply]
Since only the year was typed into the page source, how do you get the month and day for the long date? — Carl (CBM · talk) 02:41, 21 July 2008 (UTC)[reply]
I was anticipating the article possibly listing the full dates instead of just the year at some point in the future. Also, the template wasn't designed to be used merely in a single article.
As for your individual points:
  • The template was designed to make automated input feasable. I.e., another template was supposed to be able to input values without having to handle different cases specially. I've since learned that parser functions are too expensive for this to be an advisable design goal.
  • I'm not sure what you mean here. I've externalized repeated functions as much as I was able (which, incidentally, seems to conflict with your next recommendation).
  • This is an unfortunate case.
  • I wasn't using them to avoid redlinks, per se. Rather, I was using it to determine whether the inputted date was a four digit year or a full date. I'll work on finding a better way of doing this.
SharkD (talk) 02:49, 21 July 2008 (UTC)[reply]
I think the issue here is entirely the conflict between clean design goals on one side and efficient use of mediawiki on the other. What I meant by the second point is that {{template1|A|B|C}} is more efficient as {{template|A}} {{template|B}} {{template|C}} if it operates on each input separately and has a variable length input list. Your sandbox version is down to 16 seconds to parse, which is much better than the original version. The time is at the very bottom of the html source. Until an actual server admin (I'm not) complains about the ISO template, your version is already an improvement over the one you originally had, so if you prefer that one I'm in no position to complain. I was just looking to see how lean I could make the page with the same user-visible output; I got it down to 9 seconds. — Carl (CBM · talk) 02:57, 21 July 2008 (UTC)[reply]
I'll keep tweaking it. I've thought of two more optimizations that I haven't implemented yet. If, after the modifications are completed, the loading times are still inordinately long, then I'll just have to resign myself to the fact that efforts along these lines are futile. SharkD (talk) 03:12, 21 July 2008 (UTC)[reply]
I managed to bring the totals down to these:

Preprocessor node count: 62798/1000000
Post-expand include size: 439473/2048000 bytes
Template argument size: 119961/2048000 bytes
Expensive parser function count: 0/500

However, if I leave the "Expensive parser function" as it was before, I can bring the preprocessor node count down to 50350. Which is more significant, 258 "expensive functions" or 12448 preprocessor nodes?
Also, how do I pipe the | character in an expression or condition? I tried wrapping it in the nowiki tags but received an error. Also, I looked for but could not find a template for this use, like there is for table rows (e.g., {{!-}}). Thanks! SharkD (talk) 06:11, 21 July 2008 (UTC)[reply]
That is not possible, the number of parameters in a template call is determined by parsing the explicit braces and pipes. so this cannot depend on a condition inside the template call.--Patrick (talk) 08:21, 21 July 2008 (UTC)[reply]
That's too bad. As an afterthought, I don't think it's possible in any of the other programming languages I've used, either. SharkD (talk) 06:44, 22 July 2008 (UTC)[reply]
Many languages support some form of varargs. MediaWiki templates do not. —Simetrical (talk • contribs) 16:46, 22 July 2008 (UTC)[reply]
You can compare the two different versions here: User:SharkD/Sandbox/2, User:SharkD/Sandbox/4. The load times vary wildly regardless of which page I load. The highest I've gotten is ~20 seconds, the lowest ~2 seconds. SharkD (talk) 06:28, 21 July 2008 (UTC)[reply]
The time to look at is at the bottom of the HTML source. It will say something like: Served by srv172 in 14.340 secs. That number is the time it took the server to generate the html, and will only fluctuate by a second or two depending on server load. Because of caching, sometimes the page will be served very fast once it is already generated. — Carl (CBM · talk) 13:48, 21 July 2008 (UTC)[reply]
That's the value I've been looking at. I've observed it fluctuating by the amounts I specified. SharkD (talk) 06:44, 22 July 2008 (UTC)[reply]

Current version

I brought the totals down to this:

Preprocessor node count: 46426/1000000
Post-expand include size: 342490/2048000 bytes
Template argument size: 84760/2048000 bytes
Expensive parser function count: 0/500
Served by srv132 in 10.020 secs.

This is roughly three times as expensive as Carl's version, and twice as expensive as the article minus any date templates at all (the original, minus the date templates, had a preprocessor count of 23674, and Carl's version had 31260). This is still pretty good, IMO. There's still a few tweaks planned that should bring the count down a bit more. SharkD (talk) 04:38, 23 July 2008 (UTC)[reply]

Down to 41927 nodes. SharkD (talk) 23:11, 23 July 2008 (UTC)[reply]

Why (hist) (diff) in "my contributions" tab?

Why "(hist) (diff)" in "my contributions instead of "(diff) (hist)" as elsewhere like "my watchlist" and "recent changes"? Why are they switched? Is this is mediawiki bug? Jason Quinn (talk) 01:53, 20 July 2008 (UTC)[reply]

It isn't a bug, in that both links work, and all the information is available on all 3. It is simply that the 3 do not use the same function to generate the links. It was reported over 3 years ago in 2971, so is probably considered nothing more than an aesthetic annoyance. --Splarka (rant) 02:05, 20 July 2008 (UTC)[reply]
Great thanks. Bugs aren't limited to broken features but the semantics don't matter. I just read bug 2971. That's what I was looking for. (Sigh) Another "user inertia" argument against changing something that should obviously be changed. Jason Quinn (talk) 02:22, 20 July 2008 (UTC)[reply]

I've fixed this in r37872, so it should switch soon if the change isn't reverted. —Simetrical (talk • contribs) 17:44, 20 July 2008 (UTC)[reply]

Which it was. Brion points out in Template:Bug/r37898 that the current behavior matches the non-enhanced recent changes, while the changed behavior matched the enhanced recent changes. Whichever one is decided to be preferable should be used for all of them. (And enhanced recent changes should be merged into normal RC, dangit.) —Simetrical (talk • contribs) 22:50, 21 July 2008 (UTC)[reply]

Thanks for your attention to this, Simetricial. This change will eventually make it. After they "look around at other things" they will eventually realize that it's the right thing to do and sort out whatever remaining issues there are. Now I at least have the information I needed to follow the development. It's funny, the only other Mediawiki bug I ever found was also with "my contributions" where it wasn't being bolded when selected. It took months for that to get fixed after somebody reported it to the Mediawiki bugzilla on my behalf. Jason Quinn (talk) 15:38, 22 July 2008 (UTC)[reply]

Line break before #switch

Because there's a line break that occurs before a #switch, I'm having trouble creating a reliable template that returns a colour, as having a pound sign at the beginning of a line causes an unordered list. For example: 

{| style="color:{{#switch:|#FF0000}};"
|-
| Test
|}

becomes

  1. FF0000;"
Test

I found that putting nowiki tags around the pound sign works (e.g. <nowiki>#</nowiki>FF0000) but I'm wondering if there is a more concise solution for the line break. —LOL T/C 05:36, 20 July 2008 (UTC)[reply]

This is a common problem, it can be circumvented by using {{!}} in pace of the bar. - Icewedge (talk) 06:38, 20 July 2008 (UTC)[reply]
I can't seem to get it working with {{!}}; could you please demonstrate the solution by modifying the example above? —LOL T/C 07:10, 20 July 2008 (UTC)[reply]
{| style="color:#{{#switch:|FF0000}};"
|-
| Test
|}
Test

Is that something like that you want? — chandler — 07:18, 20 July 2008 (UTC)[reply]

That would work for hex values but not for named colors e.g. color:red would fail if a "#" is added. It would not be unreasonable for a switch statement to contain a mixture of these. — CharlotteWebb 12:08, 20 July 2008 (UTC)[reply]
I've definitely considered putting the pound sign outside the switch, but I'd have to make changes to the template by converting all the HTML colour names to hex and modifying the pages that transclude the template. However, if that's the only solution besides the inconcise <nowiki>#<nowiki>, I'd prefer to do that. Thanks all for the input. —LOL T/C 16:45, 20 July 2008 (UTC)[reply]
If you change all the colors in the template to hex and put the pound sign outside of the switch, you shouldn't have to make any changes to the pages using this template, as far as I can see. --- RockMFR 20:46, 20 July 2008 (UTC)[reply]

You could use something like style="color:rgb(255,0,0)" and no "#" would be needed. This format would also be easier for users unfamiliar with base-16 but I have no idea whether IE supports it. Let me know if you don't see red. — CharlotteWebb 17:28, 24 July 2008 (UTC)[reply]

IE7 supports it, I have no idea of earlier versions though. —Dinoguy1000 19:26, 24 July 2008 (UTC)[reply]

User script idea

I posted this at WT:User scripts, but it doesn't seem to be very well-watched. Anyhow, my idea is thus: basically what it does is allows you to right click on a (user/wikipedia/article) talk page section and it adds a link-to-that-section to a user subpage of your choosing, to remind you to return to threads you're need to check back on. Whaddyathink? Any takers? –xeno (talk) 15:37, 21 July 2008 (UTC)[reply]

I'm not sure how to make it react to a right-click, but it would be easy to add a [bookmark] link next to the section [edit] link which would do the same thing, which is to automatically add it to some sandbox page in your user-space. Of course these links will fail if the == Headline text == of the section is changed, or if the section is sent to an archive, etc. Stepping back a bit, however, one could argue in favor of giving the current Special:Watchlist feature a major overhaul, especially if you don't want everyone and their pet poodle to know which threads you are watching. — CharlotteWebb 16:17, 21 July 2008 (UTC)[reply]
That would be great too. the watchlist thing seems like a can of worms I don't want to open. I don't really mind if people snoop on what I'm doing, heck I'm a talk page stalker myself =) –xeno (talk) 17:36, 21 July 2008 (UTC)[reply]

div background image

Hi all, I'm trying to specify a div background image for inclusion on a portal. Currently I am using the id="EnWpMpBook" parameter which displays an image of a book, but is it possible somehow for me to specify the image used? A url parameter of course doesn't work, but is there anyway I can code it so that a picture that is hosted on Commons can be used as the div background image?

Previously I have tried <span>, with z-index parameters, which worked OK but had issues with layers, and certain things overlapping things it shouldn't. Does anyone know about that method as well?

I'm trying to do this at User:Joowwww/Sandbox3. Many thanks --Joowwww (talk) 16:12, 21 July 2008 (UTC)[reply]

Sorry, no such feature. If it's really really important, you could request an edit to site CSS, which doesn't have url() stripped. -- Tim Starling (talk) 15:31, 22 July 2008 (UTC)[reply]

Firefox and Mozilla bug with wikimedia templates?

For some months I have seen templates and images overlapping or "crashing" together on wikipedia with Firefox 2 (and Netscape). See Template talk:Infobox Weather#overlaid by other templates bug?. I put this down to a Mozilla bug because Opera displays them correctly, but as the weeks went by and I upgraded to Firefox 32.0.0.16 only to see the "bug" persist, I wonder if there is some interaction between Mozilla parsing and the wikipedia HTML? Or is this a known problem with Mozilla? -84user (talk) 17:32, 21 July 2008 (UTC)correction., I had upgraded to 2.0.0.16 and not FF3!-84user (talk) 20:29, 21 July 2008 (UTC)[reply]

The problem appears to arise when wikitables are close to HTML tables with style="float:right;" so I posted this question on Help talk:Table. -84user (talk) 19:43, 21 July 2008 (UTC)[reply]

What I see with Firefox 2 or 3 or Netscape in Vista or Firefox 1 on DSL

I was mistaken, I had upgraded to 2.0.0.16 and not FF3! I have duplicated the problem with Firefox 1.0.6 under Damn Small Linux via QEMU on a Vista PC, and will soon try FF on Ubuntu, and maybe even really upgrade to FF3. -84user (talk) 20:29, 21 July 2008 (UTC)[reply]

I am now running Firefox 3.0.1 on Vista and the tables display correctly. I guess it was a long-standing problem as far back as Firefox 1.0.6.-84user (talk) 20:53, 21 July 2008 (UTC)[reply]

Should the 'resolved' template be substituted?

Here is an example:

Resolved
 – This is an example

At WP:SUBST we see lists of templates that should be substituted or not. {{resolved}} is not listed there. Since 'resolved' expands into something very large and ugly if it is substituted, I've always thought it should *not* be substituted. This is what gets added to the wikitext of the page when you add {{subst:resolved|This is a test}}:

<div style="margin: 1em;" class="resolved"><span style="border: 1px solid #aaa; background: #f9fcf9; margin-right: .5em; padding: 6px;">[[Image:Yes check.svg|20px]] Resolved. </span>{{#if: This is a test.<span style="font-size: 85%;">This is a test.</span>}}</div>

Adding 'resolved' has a useful function on noticeboards, as a way to express an opinion that an issue is resolved without having to box up the whole discussion using templates like {{discussion top}} that are forbidding and seem to reject any further input on the issue. Using 'subst' with 'resolved' explodes the wiki-text and is 'diff-unfriendly', since when you click on a diff where somebody added the 'resolved' template you need to go through a process of deduction to figure out what was added. Can anyone give a technical reason on whether 'subst:resolved' should be preferred to 'resolved' in this case? EdJohnston (talk) 19:51, 21 July 2008 (UTC)[reply]

There is no significant reason to prefer substing it to not substing it, technically. Just don't change it gratuitously, if it's used on many pages, and the servers will be fine. This kind of scenario is a large part of what templates are meant for. —Simetrical (talk • contribs) 22:14, 21 July 2008 (UTC)[reply]

There is a special optimisation in the parser for templates invoked with no arguments, because some such templates are very heavily used, such as {{·}}. So {{resolved}} is quite fast as long as you don't include a message. -- Tim Starling (talk) 15:50, 22 July 2008 (UTC)[reply]

Wikipedia password limits

Wikipedia's page for creating an account or logging in has a link to the article "Password strength". I have the following questions:

-- Wavelength (talk) 05:08, 22 July 2008 (UTC)[reply]
Question cross-posted to Wikipedia:Help desk#Wikipedia password limits. Please answer there. – ukexpat (talk) 13:32, 22 July 2008 (UTC)[reply]
  • Any UTF-8 character should be acceptable in a password. In fact, probably if you submitted any binary string it would be accepted, UTF-8 or not, since PHP is not Unicode-aware.
  • The allowable length is determined by the POST limit, last I checked. Probably something like 20 MB. I don't suggest you use a password that long, though.
  • No, the password is stored MD5-hashed (and salted with userid), so there's no need to truncate it.
  • Most people don't care whether they can submit passwords that contain Swahili characters or are 37 KB in length, so it's probably not useful to put any of this on the account creation screen. —Simetrical (talk • contribs) 16:52, 22 July 2008 (UTC)[reply]
He said answer on Wikipedia:Help desk, Simetrical. -- Tim Starling (talk) 18:09, 22 July 2008 (UTC)[reply]
That's why cross-posting should be discouraged - you end up with disconnected threads on several boards. – ukexpat (talk) 18:15, 22 July 2008 (UTC)[reply]

Is it possible to do nav bars that change color on hover on Wikipedia? I haven't yet found an example on site, and haven't yet trawled the css sheets to check. Hiding T 11:01, 22 July 2008 (UTC)[reply]

Would you want to? The project is tending away from darish use of colour in templates. Rollover effects wouldn't exactly be following that trend. Chris Cunningham (not at work) - talk 11:44, 22 July 2008 (UTC)[reply]
It's for a main page redesign. I like the fact you instantly assumed any use I made of it would be, I'm guessing, garish.  ;) 84.92.54.229 (talk) 16:11, 22 July 2008 (UTC)[reply]
It probably would be. --- RockMFR 16:47, 22 July 2008 (UTC)[reply]
I am so tempted to create a flashing sig now!  – ukexpat (talk) 16:59, 22 July 2008 (UTC)[reply]

You could do this with a change to MediaWiki:Common.css, for browsers more advanced than IE6 or so. For broader compatibility, my recollection is you'd have to use JavaScript, depending on what sort of element the nav bar is. It can't be done without editing an interface page, until browsers start implementing some version of CSS3 style attributes. —Simetrical (talk • contribs) 16:55, 22 July 2008 (UTC)[reply]

If you're testing something in your userspace, you can add a :hover element to your monobook.css file for testing purposes. Dunno what the exact class name for the nav bars is, but it's really easy to do. EVula // talk // ☯ // 02:13, 23 July 2008 (UTC)[reply]

Issue with search bar on the left

I dont know if this has been covered before, but I've just noticed that if, by way of example, you type this J. G. D in the search box, you get slightly different results than if you type this J G D It seems to me that the addition of full stops, after initials, should not affect the search results. Could this/Should this be corrected? Setwisohi (talk) 17:57, 22 July 2008 (UTC)[reply]

Good point, and worth mentioning. I would say that the search bar should ignore punctuation marks for this reason; the only non-letter/non-numeric character that should still be considered is the space. However, the problem with this is that it could put more of a strain on resources when searching. Gary King (talk) 19:57, 22 July 2008 (UTC)[reply]

Request

Hi, the portuguese wikipedia community made a votation and it was consensus to adopt this [wizard that's already translated, could you please make it start to appear for non registered people that want's to create an article? --Jack Bauer00 (talk) 00:31, 23 July 2008 (UTC)[reply]

If you're inquiring about the Portuguese Wikipedia, we don't have any control or say in their processes here at the English wikipedia. If you're proposing a similar process here, I'm afraid it's been discussed at length, on multiple occasions, and the consensus at this time is not to permit anonymous users to create articles. Sorry, UltraExactZZ Claims ~ Evidence 02:14, 23 July 2008 (UTC)[reply]
No, we were just asking advice about implementing the wizard in the portuguese wikipedia. We don't want to change anything here. GoEThe (talk) 10:26, 23 July 2008 (UTC)[reply]
My apologies, I mis-read that. UltraExactZZ Claims ~ Evidence 11:08, 23 July 2008 (UTC)[reply]
No worries, I made a request at mw:talk:developers. GoEThe (talk) 12:17, 23 July 2008 (UTC)[reply]

main page = blank?

I purged my cache repeatedly; main page is blank. Antone else? Ling.Nut (WP:3IAR) 02:02, 23 July 2008 (UTC)[reply]

It was a CSS issue that got fixed.[3] EVula // talk // ☯ // 02:03, 23 July 2008 (UTC)[reply]
Good, thanks. Ling.Nut (WP:3IAR) 02:05, 23 July 2008 (UTC)[reply]
That was my fault...I am honestly, very truly sorry. —Remember the dot (talk) 02:13, 23 July 2008 (UTC)[reply]

What's in a (ref) name?

Hello everyone.

Sometimes, when editing an article and, more specifically, adding references, the ref name instructions trip me up. Namely, I tend to type refname instead of ref name in both of the pieces of code where the words "ref name" are needed, which means that the article has these big error messages or has some code in it or something, meaning that I have to go back and look through it again and see what went wrong.

My request is this. Could you change the list of Wikimarkup instructions so that <refname = "x"> ... </ref> and <refname = "x"/> also work, just like {{Reflist}} and <references/> both work? It Is Me Here (talk) 09:40, 23 July 2008 (UTC)[reply]

I'm guessing the devs will say no. The idea is to be XML compatible I suspect. (I already find it annoying enough that it allows you to not include " around the actual name. Also, {{reflist}} is just a template that includes <references/>. The two situations are not comparable. --TheDJ (talk • contribs) 01:00, 24 July 2008 (UTC)[reply]
What do you mean? I did use quotes, didn't I? It Is Me Here (talk) 08:27, 24 July 2008 (UTC)[reply]
Yes, but you didn't have to. Allowing <ref name=foo> to work is bad XML. Algebraist 09:07, 24 July 2008 (UTC)[reply]
Well for better or worse we also allow quotes to be omitted for other tags like <font color=red/>, but I did notice that this is tidied up by the software (quotes around "red" are absent in the wikitext but present in the rendered html). — CharlotteWebb 17:14, 24 July 2008 (UTC)[reply]
And besides everybody knows that quotes in ref tags are bad juju . — CharlotteWebb 17:17, 24 July 2008 (UTC)[reply]
Well, guys, look, Wikipedia is about imparting knowledge to its readers, right? And, hence, the easier its editors' jobs are, the better. Moreover, Wikipedia does not set out to teach people XML (as far as I'm aware), and if you're a purist, there is nothing stopping you using the more orthodox commands. It Is Me Here (talk) 18:04, 24 July 2008 (UTC)[reply]

references in preview

Would a programmer please make the result of the preview button appear as if it were followed by "<references />"? The references themselves should appear below the previewed text, I should think, rather than the bottom of the page, unless there is already a references tag in the output.

This might need assignment at the start of the preview function and the "references /" tag, with a test to determine placement of references output and a reset assignment at the end of the preview output. Thank you. 76.231.191.217 (talk) 16:20, 23 July 2008 (UTC)[reply]

You wish to see references when previewing a section by itself? Temporarily adding {{reflist}} at the bottom of the section before hitting 'Show preview' will let you see what you want. Then just remove the added 'reflist' before saving. EdJohnston (talk) 16:40, 23 July 2008 (UTC)[reply]

This should be the default. There is no reason that people should need to figure out {{reflist}} before being able to proofread their references. Fortnight Wanderer (talk) 18:56, 23 July 2008 (UTC)[reply]

This is already requested: bugzilla:5492. — Carl (CBM · talk) 19:14, 23 July 2008 (UTC)[reply]
In the meantime, you might want to take a look at User:Anomie/ajaxpreview.js – quick AJAX preview, also displays footnotes in the preview when editing a section. -- John Broughton (♫♫) 15:28, 24 July 2008 (UTC)[reply]

maximum size of watchlist?

Is there an official maximum size of a watchlist? While it's in its early phases, I'd like to have all the pages associated with the Gene Wiki on my watchlist. I have 10,846 currently, but just realized that a recent change to improve readability (through template transclusion, e.g., [4]) increases the number of pages I want to watch to 19,693. When trying to add those pages, I get this error: 

PHP fatal error in /usr/local/apache/common-local/php-1.5/languages/Language.php line 242:
Allowed memory size of 83886080 bytes exhausted (tried to allocate 74 bytes)

Any thoughts? AndrewGNF (talk) 17:27, 23 July 2008 (UTC)[reply]

Try using Special:Recentchangeslinked instead of the watchlist.— Carl (CBM · talk) 19:16, 23 July 2008 (UTC)[reply]
Brilliant, this works perfectly... [5] Thanks much... AndrewGNF (talk) 19:39, 23 July 2008 (UTC)[reply]
Yes Recentchangeslinked is the next best thing to being able to use multiple watchlists on the same account, so that you can separate pages you actually care about from pages which where you revert vandalism because nobody else seems to be watching and the pages that you edited once to fix a typo. Unfortunately the lists of pages must be publicly visible. — CharlotteWebb 17:05, 24 July 2008 (UTC)[reply]

Weirdness

I was looking at the logs for a user who requested rollback on WP:RFPERM, and I saw this. I actually looked at my own logs to see if I had been sysopped by mistake, (and the tab in the background of the screenshot that says "error" is a result of me clicking on the "block" link to see if it would work). Am I supposed to be able to see that "block" link next to his "new user account" entry? It doesn't show up when I look at any other people's logs, just his. Have any idea what's going on? J.delanoygabsadds 20:39, 23 July 2008 (UTC)[reply]

It's there for me, too... No idea what might be causing it, though. —Dinoguy1000 20:43, 23 July 2008 (UTC)[reply]
Non-picture form. [6] No idea, though. ~ JohnnyMrNinja 20:50, 23 July 2008 (UTC)[reply]
It looks like this is a historical thing. All the creation logs have that up to June 2006, then it switched to just userpage/talk/contribs. Algebraist 20:52, 23 July 2008 (UTC)[reply]
OK, thanks. J.delanoygabsadds 20:57, 23 July 2008 (UTC)[reply]
Specifically, the 7th of July (though there's no precise cutoff). Possibly this edit did it. Algebraist 21:01, 23 July 2008 (UTC)[reply]

Something funny going on

I've noticed at the Communist Party of Great Britain article. It seems to miss out an entire paragraph of text in the 1940s and 1950s section. The text appears when you edit, but dissapears when you save it or look at a preview.

The text in question is suposed to be: (I've had to use <nowiki> because it does the same thing here)

  • The party's membership peaked during 1943, reaching around 60,000<ref name="To Build A New Jerusalem"/>. Despite boasting some leading intellectuals, especially among the [[Communist Party Historians Group]], the party was still tiny compared to its continental European counterparts. The [[Communist Party of France|French Communist Party]] for instance had 800,000 members, and the [[Italian Communist Party]] had 1.7 million members <ref name="To Build A New Jerusalem">. The Party tried, unsuccessfully, to affiliate to the Labour Party in 1935, 43 and 46.
  • In 1951 the party issued a programme called ''The [[British Road to Socialism]]'' (officially adopted at the 22nd Congress in April 1952), which explicitly advocated the possibility of a peaceful reformist transition to socialism - but only after it had been personally approved by Stalin himself <ref>Geoff Andrews, ''Endgames and New Times,'' Lawrence and Wishart, 2004, p 74, p 90</ref>. The importance of this document is that it implicitly renounces the revolutionary purpose for which the party was founded in the first instance. The BRS would remain the programme of the CPGB until its dissolution in 1991 albeit in amended form and even today is the programme of the [[Communist Party of Britain]] which claims political continuity with the CPGB.

But when you save it or preview it, it appears:

  • The party's membership peaked during 1943, reaching around 60,000[1]. Despite boasting some leading intellectuals, especially among the Communist Party Historians Group, the party was still tiny compared to its continental European counterparts. The French Communist Party for instance had 800,000 members, and the Italian Communist Party had 1.7 million members Cite error: A <ref> tag is missing the closing </ref> (see the help page).. The importance of this document is that it implicitly renounces the revolutionary purpose for which the party was founded in the first instance. The BRS would remain the programme of the CPGB until its dissolution in 1991 albeit in amended form and even today is the programme of the Communist Party of Britain which claims political continuity with the CPGB.

Anyone know what's going on? G-Man ? 21:36, 23 July 2008 (UTC)[reply]

One of the refs was missing a closing </ref> tag -- now fixed. BTW, the standard format is for the refs to come after the punctuation (periods, commas etc) - a bunch of those need to be fixed in this article. – ukexpat (talk) 21:44, 23 July 2008 (UTC)[reply]
Actually, there is no requirement for the reference to be after the punctuation, rather, usage should be consistent within an article. DuncanHill (talk) 21:46, 23 July 2008 (UTC)[reply]
Well there should be! Punctuation after the refs looks ugly and is certainly non-standard for print media, in my experience. – ukexpat (talk) 21:50, 23 July 2008 (UTC)[reply]
I prefer ref then punctuation myself, but it's not one of my pet peeves (of which, devoted readers, you may have noticed I have many). DuncanHill (talk) 21:52, 23 July 2008 (UTC)[reply]

I see, a simple little thing like a missing / huh! Thanks. G-Man ? 22:12, 23 July 2008 (UTC)[reply]

Problem with "Update any redirects that point to the original title"

Resolved
 – fixed in r37999. — CharlotteWebb 16:57, 24 July 2008 (UTC)[reply]

This is a great feature, but there's a bug - it screws up redirects to sections: [7] --NE2 00:43, 24 July 2008 (UTC)[reply]

You filed it as bugzilla:14904. — Carl (CBM · talk) 02:44, 24 July 2008 (UTC)[reply]

Right format fix

Hiya! Can anyone help me out? I tried to "shorten" a list (to put to halves next to each other instead of a long list) at the article about the New York dialect. I got a message from another use that now I messed up the format. Can someone help me out? Thanks in advance for any input! --Soetermans | is listening | what he'd do now? 19:56, 24 July 2008 (UTC)[reply]

Fixed. Chris Cunningham (not at work) - talk 20:08, 24 July 2008 (UTC)[reply]
Thanks for you help, Chris, but now I can't see the right half of the list. Does this have something to do with my system? --Soetermans | is listening | what he'd do now? 20:43, 24 July 2008 (UTC)[reply]
The {{Columns-list}} and {{Reflist}} templates do not render properly in IE, but they do in Firefox and other CSS3 compliant browsers. – ukexpat (talk) 20:58, 24 July 2008 (UTC)[reply]
Should be fixed now (at least insofar as the complete list appears in both IE and real browsers). The problem, as ukexpat has pointed out, is that the only elegant way to do this (CSS columns) doesn't work in IE. I'd seriously recommend punting that whole list to its own article. Chris Cunningham (not at work) - talk 23:28, 24 July 2008 (UTC)[reply]
Haha, funny you should say that! I did, to much criticism. Eventually it got merged back in. See the discussion here.
Anyway, I guess we'll just leave at this. Thanks for the help everybody! --Soetermans | is listening | what he'd do now? 23:39, 24 July 2008 (UTC)[reply]

Altering block lengths

Has anyone ever proposed an extend/shorten block function? It is a fairly often occurrence to see an admin unblock a user just to block them again. I think it would be a useful function and not that hard to implement. - Icewedge (talk) 05:04, 25 July 2008 (UTC)[reply]

  1. ^ Cite error: The named reference To Build A New Jerusalem was invoked but never defined (see the help page).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=227798166"