Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Petrus Adamus (talk | contribs) at 23:29, 27 October 2009 (→‎Question on templates: answer). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 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.

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.

Is our registration form user-friendly ?

Can't even see the registration form with a 1440x900 screen resolution. ;-)

Hello. When one is not logged in, and want to create an account, he sees MediaWiki:Fancycaptcha-createaccount. This message is so large, that the newbie may not notice there is a registration form under it. Come on, can't we summarize it a bit ? Is every word neccesary ? Should we move that message under the registration form ? Thanks for your attention. :-) Dodoïste (talk) 21:12, 19 October 2009 (UTC)[reply]

I agree that it should probably be trimmed/re-arranged. However, if we put it under the form, people are less likely to read it (we also have a bunch of other stuff down there already). Ideally, we would be able to put the text in the form itself, so the username information could come directly before the username input, the password info before the password input, etc. But the software doesn't currently support that. Mr.Z-man 22:01, 19 October 2009 (UTC)[reply]
JavaScript in MediaWiki:Common.js could dynamically add the text in the form itself, rather than having MediaWiki:Fancycaptcha-createaccount add the text. Kind of hackish, but it would work for all JavaScript-enabled browsers (and then the fancycaptcha page could stay as is, but surrounded with <noscript>). Just a thought. –Drilnoth (T • C • L) 22:17, 19 October 2009 (UTC)[reply]
MediaWiki:Fancycaptcha-createaccount is a wikitext message, so we couldn't use <noscript> there. Mr.Z-man 23:32, 19 October 2009 (UTC)[reply]
When I go to create an account, the form is at the top and there's no sign of MediaWiki:Fancycaptcha-createaccount... OrangeDog (τ • ε) 23:38, 19 October 2009 (UTC)[reply]
"When you are not logged in"! :-) Please log out, you'll see it. Dodoïste (talk) 00:43, 20 October 2009 (UTC)[reply]
The only important and useful information in this message is: "Unable to see the image? An administrator can create an account for you". The rest could be deleted, and it woulnd't create any problems doing so, because:
  1. The user don't want to read it and will try to skip it anyway. It's boring, and it's getting in his way.
  2. Worse, too much information or rules may discourage the user to create an account: "Oh gosh, do I really need to read everything before creating an account?" If one of you is familiar with usability testing, he'll understand how users can feel like.
  3. The user is lost : he can't see the usual registration form, and is disappointed. Where should he go to fill in those three fields? The user will probably scroll down, but it's too late: the user has been disturbed.
Thanks. :-) Dodoïste (talk) 11:53, 20 October 2009 (UTC)[reply]
I don't think that ignoring the basic usability of the form is a good idea. If poor design forces more of a burden onto the admin corps then we're doing something wrong. Chris Cunningham (not at work) - talk 12:38, 20 October 2009 (UTC)[reply]

Comment: the current version is (mostly) my redesign, which I posted here and got only one person commenting on. Suddenly everyone gives a damn?! Anyway the previous version was like this. I was focussed on making that clearer. And now, in response to the point that the form isn't visible, I've added "scroll down..." near the top. PS It had occurred to me that it would be much better, usability-wise, to integrate the instructions with the form, which is the very usual way to do these things! But I don't think we can do that without requesting a software change. Which we can do, of course... Rd232 talk 20:35, 20 October 2009 (UTC)[reply]

Sorry, I'm not very active on en.wiki, I didn't see your previous message. Anyway, I do agree with you: you made it clearer.
But now I'm talking about something else: is every information on that message neccessary? Couldn't we delete a few ? Dodoïste (talk) 20:52, 20 October 2009 (UTC)[reply]
Well the second bullet under Username could be punted to the "Username policy" boxout (I had it there originally, but it was said to not be visible enough). We could also do away with that bullet altogether if (a) the error message in those situations with forbidden symbols were clearer, and (b) the auto-conversion were flagged when it's done (don't think it is currently). In addition, the Email Address part pretty much duplicates the note in the form. We should really be able to merge those. How do we edit the email address message in the form itself? Rd232 talk 21:07, 20 October 2009 (UTC)[reply]
Most informations in MediaWiki:Fancycaptcha-createaccount could be useful, but the user may need it after he has created his account. Shouldn't we move the content to a help page, that the user could read whenever he needs to? Could we create Help:User account? Yours, Dodoïste (talk) 21:30, 20 October 2009 (UTC)[reply]
Well I think the information does exist elsewhere, but finding it may not be easy. If my proposal at WP:VPR#MediaWiki:Welcomecreation -> Welcome notice were accepted, there'd be an obvious, highly-visible place to link such information from in case it's needed. Rd232 talk 21:52, 20 October 2009 (UTC)[reply]

Reflection: Dodoïste makes a fair point and Rd232 is doing a good job as usual. But I think there's a contradiction at the heart of Wikipedia's user account policy that should be part of any new account signup/registration process:

  • Edits by anonymous users (IP addresses) are in general tolerated or even approved ("they catch our typos"). Because IP addresses may be shared by multiple individuals, edits are not usually tracked for long periods and in any case criticisms of edits are expressed in muted terms. An anonymous user is at liberty to edit from multiple IP addresses without any censure.
  • Edits by registered users are closely monitored and can be analysed in such detail that the user's interests and background can be inferred. It is easy to stalk the user, and criticism can be expressed directly and vigorously on the user's talk page or elsewhere. Once a user has started editing from a registered account, that user is implicitly forbidden from making any edits from a different registered account or from any IP address.

That's correct, isn't it? But these differences aren't mentioned on the "Create account" page (viewed when not logged in), the "Why create an account?" page or the "Welcomecreation" page. It seems to me that there's a drive to oversimplify registration: because if the true responsibilities of registration were known to anonymous editors they would mostly prefer to retain their anonymity. If that's correct, shouldn't any proposal to redesign the signup pages take account of it? - Pointillist (talk) 23:49, 20 October 2009 (UTC) updated 07:33, 21 October 2009 (UTC)[reply]

No, a registered user who wants to stop using a username can go back to using just an IP address, or can just drop their username and create a new one at any time. In general, nobody would even know. — Carl (CBM · talk) 02:12, 21 October 2009 (UTC)[reply]
You can retire an account in some circumstances, but policy says you can't use more than one account to contribute to the same page or discussion, and you mustn't repeatedly switch accounts. It seems to me that the registration process should explain the rules about creating a new account when you already have one. I'm thinking about a recent SPI where a user had created nine accounts that edited the same group of pages, apparently unaware of these rules. - Pointillist (talk) 15:37, 21 October 2009 (UTC)[reply]
If anything needs explaining, it's the increase in (average) respect shown to a registered account edit vs an anonymous edit (excluding obvious vandalism). Not pointing this out may be a WP:BEANS issue though... Rd232 talk 09:02, 21 October 2009 (UTC)[reply]
It's worth the odd reminder that research indicates that while the majority of edits are by the most active few editors, the majority of Wikipedia's content still comes from IPs and throwaway accounts. It's not just fixing typos. Chris Cunningham (not at work) - talk 10:15, 21 October 2009 (UTC)[reply]
Is there any more recent research on that? AFAIK those stats came from a July 17, 2006 snapshot. - Pointillist (talk) 15:37, 21 October 2009 (UTC)[reply]

Simplifying account creation

How about drastically shortening and simplifying the message, to just advise people about the captcha? After all, that's the purpose of the message. Look at http://de.wikipedia.org/w/index.php?title=Spezial:Anmelden&type=signup as an example.

For more inspiration, take a look at:

Here's what I propose we do for now:

Registering a free account takes only a few seconds and has many benefits.

  • To help protect against automated account creation, please enter the words that appear below in the box, without any spaces. (more info)
  • Unable to see the image? An administrator can create an account for you.

That's all we need. Possibly we could re-add a box like is there currently, but it needs to be to the right of the form, rather than on top. We may need a software change (e.g. another system message) in order to do that. --Aude (talk) 22:52, 21 October 2009 (UTC)[reply]

Yay, that's exactly what I meant! I'm happy to be understood! :-) I support your proposal.
I like your idea to show references. Here is are a few advices from a usability expert: Usability of Registration Forms. Here is an example of a usability improvement of Ebay's form: Better Web Forms: Redesigning eBay's Registration. Yours, Dodoïste (talk) 23:26, 21 October 2009 (UTC)[reply]
Those are useful links. Also, I know that developers are working to refactor the user login and account creation code in MediaWiki. When that's implemented, it should be possible to build in some immediate feedback with Ajax. For example, as someone enters a username, we can do a check to see if (1) the username is available, (2) if it's on our username blacklist (see MediaWiki:Titleblacklist), (3) if they enter an e-mail address as their username, provide feedback to say that's not advisable or not allowed. We could also provide feedback on strength of the password (e.g. weak -> strong). --Aude (talk) 23:34, 21 October 2009 (UTC)[reply]
Aude, in the absence of a "wizard" step-by-step form with instructions at each stage, I'd be happier with a message more like this:

Registering a free account takes only a few seconds and provides a number of benefits.

  • You'll need to choose a nickname that satisfies our username policy and does not accidentally reveal your real-life identity.
  • In general, if you have already edited Wikipedia using another account, you should not create a new account (here's why).
If you've forgotten the password for your existing account, click here for advice.
If you simply want to change your username, request it here.
  • It's a good idea to provide an email address that can be used to send you a temporary password if you ever forget your real one. Other editors won't see your email address, and you can prevent them from sending emails to you if you wish (here's how).
  • To help protect against automated account creation, please enter the words that appear below in the box, without any spaces (more info). If you can't see the words in the box, ask an administrator to create the account on your behalf.
This is still fairly compact but covers the principal pain points. The change to "provides a number of benefits" aligns the text with the Username policy page and avoids over-selling the advantages of registration. What do you think? - Pointillist (talk) 00:43, 22 October 2009 (UTC)[reply]
  • Regarding the username, mentioning and linking to the username policy is reasonable. The part about using one's real name duplicates the text below the form (with red, bold text drawing attention to it).
  • The bit about changing account names is also provided below the form. The forgot password information is good, though perhaps could go below the form, making there be two bullet points (where it says "Already have an account?")
  • Also, I would eliminate the e-mail item, since there already is a place in the form (below the e-mail address box) for this.
--Aude (talk) 03:25, 22 October 2009 (UTC)[reply]

Looking at the German Wikipedia signup form, they've essentially got below the CAPTCHA/form what we have above it. We've focussed heavily on privacy issues below the form (which we have far more detail on). And they don't mention characters forbidden in usernames, and username policy is two lines. They do mention (which we don't) a 30-character limit on names, and a ban on ALL CAPS. I think there are drawbacks to putting all the info below the CAPTCHA/form, unless we can keep it really short - i.e. it won't get read. I think there are drawbacks too to ditching all the details we have, but Email Address can go, especially if someone can figure out how to edit the "email" message within the form. I've moved the tech details to the boxout, and commented out the Email Address bit, and merged the username/password headers. Maybe more radical changes should wait for the technical enhancements mentioned? Rd232 talk 11:28, 22 October 2009 (UTC)[reply]

Also, this seems a good place to spam a related idea, discussed at WP:VPR#MediaWiki:Welcomecreation -> Welcome notice. Rd232 talk 17:58, 22 October 2009 (UTC)[reply]

Perhaps we should change our attitude to registration. Instead of trying to get users to register as soon as possible—which apparently tempts us to exaggerate the "many benefits" of registering and to minimise messages about possible downsides—we might make it into a deliberate "rite-of-passage" for editors: the moment when an individual declares his/her commitment to the community and its policies (e.g. the prohibition against editing with multiple accounts).
On this basis, the essential "terms" of the commitment would have to be presented to the user before they click the form's submit button, e.g. as a summary in simple language above the form, with links to detailed explanations as appropriate. Once the user has registered a similar summary should be posted to their talk page as part of a welcome message. What do you think? - Pointillist (talk) 23:09, 22 October 2009 (UTC)[reply]
P.S. Dodoïste's example of the ebay registration form is worth examining. The ebay user agreement (here) is 8614 words (52776 characters) long, and under a paragraph saying "We expect you to read all of the linked documents carefully" links to eighteen additional pages, including strict rules on identities. So it is a much more overtly legal document than anything we are considering here.
Ebay's user agreement is the perfect example of a text that users will never read. It's a fail. I only wanted to show a few explanations and a design improvement. Ebay itself is quite unusable.
Aude, I do support a refactor the user login and account creation code in MediaWiki. Please try the yahoo account creation from, which many usability experts point out as a reference. Try to mess up with it, and see how it reacts. You might like to try picnik's website as well: click on "register" up right. Have fun! :-)
Aude, I can't help much with the coding. But I would be glad to help the developers to design a new form. I could help them to make a user-friendly form. How should I contact them? Yours, Dodoïste (talk) 01:21, 23 October 2009 (UTC)[reply]

FYI, I've revamped the related Wikipedia:Request an account. Second opinion on it would be welcome. Rd232 talk 09:49, 23 October 2009 (UTC)[reply]

Well done, it's much clearer than before. And that icon shows the right way, and is very attractive. I want to request an account too! :-) Dodoïste (talk) 11:12, 23 October 2009 (UTC)[reply]
Thanks :). Incidentally I've found the message which produces the email message within the form: it's MediaWiki:Prefs-help-email. Naturally, I've mucked around with it, based on what was in MediaWiki:Fancycaptcha-createaccount, but I also moved a line into MediaWiki:Signupend. Rd232 talk 19:18, 23 October 2009 (UTC)[reply]
Thanks for removing the e-mail text. Other things duplicated include the part about offensive usernames, as well as the part about promotional usernames and including domain names or e-mails in usernames. (in the bullet point, and in the box). For the part about non-permitted characters, I have started making some code changes to check for those. I'm making it so that you get a specific error message (once the form is submitted) if you attempt to include them. I think an error message would be enough. I think there are more ways to make the form more compact (as suggested previously), but let's consider things piece by piece and see what can be done. --Aude (talk) 01:19, 25 October 2009 (UTC)[reply]
Well, decent error handling would obviate the need to talk about those technical issues up front - that would be nice. The duplication about usernames is probably necessary, though - the bit on the left being the summary and the boxout being the detail. It's also the main issue users won't be aware of, so it bears making it prominent enough. Proper integration with the form might make that achievable without duplication, but that's longer term. Rd232 talk 15:40, 25 October 2009 (UTC)[reply]

technical problem entry for "Contact Us"

I suggest that the "Contact Us" page list a subpage for technical markup problems, to call attention to pages where an amateur editor has either caused a problem or can't figure out how to fix it. —Preceding unsigned comment added by 70.18.239.210 (talk) 12:40, 20 October 2009 (UTC)[reply]

Well, er...this is basically it right here, as well as the Helpdesk and new contributors' desk...Intelligentsiumreview 23:15, 20 October 2009 (UTC)[reply]
Took a look, and saw the existing "technical problem" entry went to a "bug report" page, without clearly identifying that it was talking about software issues. Added a line "Request help with a technical issue with the wikimarkup of a Wikipedia page." linking to the Help Desk. Rd232 talk 15:47, 25 October 2009 (UTC)[reply]

Diff colors bad for colorblind people

Thought it might be a good idea to flag up a message posted on the reference desk that the bold red text in diffs is difficult for a user to read because he's colorblind. I'm not colorblind, so I can't really say what's neeed, but perhaps it could be different colors? Diffs do have red text on a green background, which is a common type of colorblindness. --h2g2bob (talk) 23:48, 20 October 2009 (UTC)[reply]

Looking at diffs through http://colorfilter.wickline.org/, I did not see any major issues. Some of the text was a bit harder to read, but I'd attribute to me not looking through the filter daily (rather than the colors). Perhaps we should create a colorblind gadget? I know for certain games they provide a setting for color blindness. — Dispenser 02:48, 21 October 2009 (UTC)[reply]
Perhaps we can use highlighting in our diffs, like they do on other wikipedias. Sample Or at least change the background colors to something other than green. -- Y not? 13:54, 21 October 2009 (UTC)[reply]
The French example seems to be a great improvement. Much more legible, and more consistent with the normal means for highlighting text. Ian Spackman (talk)
Another method, one that would probably get approval more easily than a sitewide change, would be for someone to write some javascript that would allow a user to view diffs in a different format (either the French format or some new one). That way, a colorblind user (or anyone else, for that matter) could log in to view diffs in this more personalized manner. Someguy1221 (talk) 09:26, 25 October 2009 (UTC)[reply]
As far as the French format, no javascript is needed. Just add these to your personal skin-specific css file:
table.diff {
 padding:.5em;
}
table.diff td { 
 vertical-align:top;
}
td.diff-addedline { 
 background:#D8E4F6; 
}
td.diff-addedline .diffchange {
 background:#B0C0F0;
 color:#001040;
 font-weight:bold;
}
td.diff-deletedline {
 background:#E4F6D8;
}
td.diff-deletedline .diffchange {
 background:#B0E897;
 color:#104000;
 font-weight:bold;
}
td.diff-context {
 background:#FEFEFE;
}
table.diff, td.diff-otitle, td.diff-ntitle, td.diff-context {
    background-color: transparent;
}
I believe this could be gadgetized easily enough if someone wants to deal with that. Anomie⚔ 13:10, 25 October 2009 (UTC)[reply]

Actions menu into tabs in Vector

I started using the Vector skin and I'd like the actions that are now in the drop-down menu (i.e. Watch, Purge, Twinkle stuff) to show as tabs as the rest of them (e.g. Edit, View history). How can I change my user JS or CSS to do this? Svick (talk) 12:41, 21 October 2009 (UTC)[reply]

I have a function in my vector.js that should do that for individual functions… crude work from a JavaScript newbie, but it works in Safari at least. (I ought to double-check that the code doesn't need any tweaking to match the current structure of Vector, too… there might be an unnecessary chunk of code in there.) I'd extend it to a full dropdown-menu-eliminator for you, but I'm a bit too busy at the moment. Take a look at User:Nihiltres/vector.js and you might get a few ideas on how to make it work for you… or perhaps someone will come along and polish my work into a usable form for you. Look for the moveActionOutOfMenu() function. {{Nihiltres|talk|edits}} 14:48, 21 October 2009 (UTC)[reply]
Thanks. After looking at your code, I wrote User:Svick/DropDownToTabs.js and it seems to work fine, except for Twinkle's action links. Twinkle adds them using addOnloadHook and I move them the same way, and my code apparently executes before Twinkle's. How can I fix this? Svick (talk) 17:08, 21 October 2009 (UTC)[reply]
The problem I had was, of course, caused by a stupid error in my code. The code works for me now in Firefox and anybody is welcome to use it. Svick (talk) 20:03, 23 October 2009 (UTC)[reply]

Programming idea

Instead of the current combination of recursive templates and primitive parser functions, would it be feasible to allow a secure subset of Perl to execute in templates? This should be faster to execute and easier to use than the current system.

I chose Perl as it is designed for text manipulation, has a flexible and concise syntax, and insecure keywords and variables can be easily filtered. OrangeDog (τ • ε) 13:41, 21 October 2009 (UTC)[reply]

This sort of thing has been discussed before on the wikitech-l mailing list in at least June and July 2009, although I don't think Perl was one of the contenders (Lua, Javascript, Python, and PHP were mentioned, as well as something based on the AbuseFilter language). IIRC, the general results of the discussion were that any serious candidate would have to be sufficiently resource-friendly, "readable", very secure, and available in a pure-PHP implementation so sites on cheap hosting without the ability to add extensions or exec other programs can still copy Wikipedia's templates (the last is the real killer). Bonus points if the language is particularly easy to learn or should already be known by a significant fraction of the community. Anomie⚔ 16:35, 21 October 2009 (UTC)[reply]
OrangeDog, there's been a bug for ages to enable StringFunctions, a set of ParserFunctions, essentially, that allow for easy string manipulation. The code is already implemented on the English Wikipedia, even, but it's disabled in the configuration. Vote for bug 6455, open a new bug, pester the devs, etc. and I'll support it, not least because the hacks we have are really, really ugly. {{Nihiltres|talk|edits}} 19:48, 21 October 2009 (UTC)[reply]
Hmm, looks like it'll never happen. I don't agree with the "cater for sites that don't install extensions" argument. Surely we shouldn't be using cite.php then? OrangeDog (τ • ε) 00:44, 22 October 2009 (UTC)[reply]
The issue isn't that sites can't install MediaWiki extensions, its that they can't compile PHP extensions (written in C), or shell out to some other program. The problem with StringFunctions is that, like ParserFunctions, it would probably just be a temporary fix. It would be fine until people start using it to make even more complex hacks, then we're back where we started. The issues we have now are the same as when ParserFunctions was developed and installed to replace templates like {{qif}} Mr.Z-man 01:35, 22 October 2009 (UTC)[reply]
Precompile a Perl/Lua interpreter (source available in C) into PHP extensions for multiple platforms and ship as MediaWiki extension? OrangeDog (τ • ε) 08:13, 22 October 2009 (UTC)[reply]
Not all users can include modules into their PHP configuration--back to the shared host argument. Either they can't edit php.ini or dl() has been disabled. dl() has also been deprecated, meaning including the module would require php.ini access or ability to compile it into PHP. Neither are possible on shared hosts, usually. ^demon[omg plz] 13:48, 22 October 2009 (UTC)[reply]
Can you explain again why that is different to other MediaWiki/PHP extensions that are commonly used (e.g. cite.php)? OrangeDog (τ • ε) 14:27, 22 October 2009 (UTC)[reply]
Installing an extension for Mediawiki involves adding a line to your LocalSettings to enable it (this is the case with ParserFunctions, Cite, etc), and possibly to configure it. Adding extensions to PHP require a lot more access, and we can't assume 3rd party installations of Mediawiki have that access. ^demon[omg plz] 16:19, 22 October 2009 (UTC)[reply]
Sorry if I'm being obtuse, but why could this not be implemented as a MediaWiki extension? OrangeDog (τ • ε) 09:09, 23 October 2009 (UTC)[reply]
Mediawiki extensions are PHP programs. PHP extensions are compiled programs from C and other languages. Dragons flight (talk) 11:29, 23 October 2009 (UTC)[reply]
The original idea can be implemented as a MediaWiki extension, it's just a ton of work. Were we able to use exec or PHP extensions it would be far less work. Anomie⚔ 11:32, 23 October 2009 (UTC)[reply]
So it's really a case of "can't be bothered". I wish people would admit that instead of making accessibility excuses. OrangeDog (τ • ε) 12:11, 24 October 2009 (UTC)[reply]
If by "accessibility" you mean the fact that a pure-PHP version must be available: No, the "accessibility" is the direct cause of it being so much work. Consider as an analogy the difference between just referencing a book and first having to make a perfectly localized translation so people who can't read the book's original language can read it. Anomie⚔ 14:58, 24 October 2009 (UTC)[reply]

What I mean is, the reason it won't be done is purely because no-one can be bothered, rather than it is intrinsically wrong or impossible to do it. Any arguments based on ability to install extensions are completely invalid - I have my own MediaWiki installation, but I can't install cite.php because my host won't allow me to change configurations, yet we're allowed to use it here. OrangeDog (τ • ε) 15:12, 25 October 2009 (UTC)[reply]

Yes, it would be a lot of work to create a sandboxed version of a programming language that's sufficiently secure, efficient, and doesn't lose any of the current functionality (especially parser functions like "ifexist" and "pagesincategory" that need to get information from the database), even if you don't include a pure-PHP version. However, if you can't even edit your own wiki configuration, and your host refuses to do so, I would suggest switching to a better host. Even crappy free webhosting on shared servers that don't allow shell access still allow you to install extensions like Cite and edit your configuration. Mr.Z-man 00:02, 26 October 2009 (UTC)[reply]
Ah, but I don't need it, and freely admit that I can't be bothered. OrangeDog (τ • ε) 21:07, 26 October 2009 (UTC)[reply]

CSS for xfd-closed

For closed XfD discussions, my current monobook.css is set to hide. The problem is, when I'm on the actual AfD discussion page (e.g. Wikipedia:Articles for deletion/AAAAA), when I actually want to see the discussion, it obviously doesn't show up. How do I configure my CSS to hide when on a log (e.g. Wikipedia:Articles for deletion/Log/2007 September 16) but show when on the discussion page? (If that's not possible, I can live with having both collapsed.) -- King of ♥ ♦ ♣ ♠ 03:33, 23 October 2009 (UTC)[reply]

You can do this with Javascript that checks what page you are on, and if it's the log, adds the stylesheet to the document. I have written the script User:Svick/hideClosedXfd.js (either import it or copy it to your monobook.js). Svick (talk) 11:46, 23 October 2009 (UTC)[reply]
It's working, thanks! -- King of ♥ ♦ ♣ ♠ 21:57, 23 October 2009 (UTC)[reply]

string functions

Are there any string manipulation parser functions? I'm specifically looking for a way to add an error check to User:Kww/singlechart so that if someone uses {{singlechart|Bulgaria|3|url=whatever}}, I can verify that the url does not contain charly1300 or apcchart, or, conversely, verify that it does contain bamp-bg.org.—Kww(talk) 12:55, 23 October 2009 (UTC)[reply]

Unfortunately there are only a few templates with very limited possibilities here. I don't think you could implement what you want very easily. — Martin (MSGJ · talk) 13:11, 23 October 2009 (UTC)[reply]
{{Str find}} looks pretty promising, actually. I'll play with it.—Kww(talk) 13:16, 23 October 2009 (UTC)[reply]

Yes, the devs seem to have some inexplicable resistance to including these string functions. The code exists, everyone wants it, the devs just don't want to let us have it. I think it was last discussed at Template:Bug. The excuse is performance issues (which I can't actually believe - if the server's got enough oomph to format dates and do math, then it can manage to detect one string inside another or measure how long it is); but anyway the workarounds we have to use (the string manipulation templates lined to above) are even more inefficient. All rather bizarre... --Kotniski (talk) 13:25, 23 October 2009 (UTC)[reply]

You linked to the bug discussion which explains why it's not bizarre. Pulling out one of the more relevant comments: "...The Lua extension requires installation of a PHP extension and/or the ability to use exec(). If it were enabled on Wikimedia, all templates would use it pretty soon, and anyone on shared hosting without either of these rights would be unable to use large chunks of Wikimedia content. PHP extension installation requires root access, and exec() is unsafe on shared hosts that have all PHP executed by a single user (using mod_php, FastCGI, etc.)." Keeping MediaWiki widely installable remains a significant objective. The bug discussion suggests we might one day get string functions based on the abuse filter structure, but who knows when (or if). Rd232 talk 13:56, 23 October 2009 (UTC)[reply]
Yeah but you don't have to do it with any fancy extensions. All right, I don't have the specialized technical knowledge to actually know for sure, but I really can't believe that doing simple string manipulation is any more difficult or resource-consuming than doing math or date formatting (even padleft and padright are more complex than saying what the length of a string is). Maybe that wasn't the most appropriate bug discussion to link to, but I had a very weird conversation with a dev at one point where he really did just seem to be saying "we don't want to let people have this because it's not something they ought to want". (And the devs haven't worked out how to do alphabetical order yet either... grr...) --Kotniski (talk) 14:08, 23 October 2009 (UTC)[reply]
The problem is that giving just string functions is that its, at best, a temporary fix. Wikipedia was able to get by just fine without parser functions until people developed some templates to do "if" statements, and then people started using them in tons of templates, so we got parser functions. Now people are using parser functions to build string functions. If we enable string functions, its almost a given that someone will start using them to make something even more complex. Ideally we could embed a real programming language instead of slowly turning wikitext into an ugly and inefficient one, but that has the problems that Rd232 mentioned. Mr.Z-man 16:44, 23 October 2009 (UTC)[reply]
Not sure what you're saying here. You're sounding a bit like the dev I talked to - apparently saying that we shouldn't have something that users will find useful because then they might start asking for even more useful things. Or that there's a more satisfactory solution which unfortunately has the drawback that it can't be used, so because of that we can't implement the slightly less satisfactory one that can.--Kotniski (talk) 17:00, 23 October 2009 (UTC)[reply]
I'm saying that we should consider more than just what people want right this very second. We should consider the long-term implications of slowly turning wikitext into an inefficient and difficult to use programming language. Mr.Z-man 17:12, 23 October 2009 (UTC)[reply]
Well yes, that's what it already is. But explicit string functions would make it a bit more efficient and easier to use, so again, I don't see the argument, unless it's "let's keep things worse than they need be so that we have a stronger argument sometime in the future when we want to replace them with something else." (And given that the devs are running close to a decade to solve alphabetical order, I don't expect a workable replacement for wikitext parser functions to be produced any time soon.) --Kotniski (talk) 18:04, 23 October 2009 (UTC)[reply]
Easier to use for who? The handful of users who write complex templates? The majority of users will never use such things. As for efficiency, if it the current hacks were creating a real problem, it would be installed (or the current hacks would be disabled), otherwise, don't worry about performance. As for alphabetical ordering (I presume you mean in things like categories), this is mostly a database issue, not a MediaWiki one. There's little that the MediaWiki developers could do about that. Mr.Z-man 22:45, 23 October 2009 (UTC)[reply]
Nonsense, of course they could solve this problem (at bugzilla they say that various solutions exist, it's just a matter of deciding which one to use). But because devs don't seem to care about what users want, no-one's doing anything about it. Your first comment is misguided as well; maybe only a few users will write complex templates, but many more will use them, and the sites that run off the software will improve for everyone as a result. Neither of these are huge issues (though it might be thought that alphabetical ordering is a pretty fundamental thing to get right when you're writing works of reference), but it's frustrating to see so much effort being put into this project by editors (and devs of course - I'm not complaining about any individuals) while continually seeing easy potential improvements held up due to - I'm not sure what to call it, systemic incompetence maybe - at developer level.--Kotniski (talk) 10:06, 24 October 2009 (UTC)[reply]
Yes, ignore all of the new features and bugfixes that are added all the time and point to 2 that aren't as an evidence that the developers are incompetent and "don't seem to care about what users want." There's one easy "solution" to string functions, but its at best a temporary fix. There really aren't any "easy" solutions to proper unicode collation. Mr.Z-man 16:53, 24 October 2009 (UTC)[reply]
All right, no point carrying on sniping at each other here, but I retain my impression that the system by which the devs operate (collectively, as a part of the system, not as individuals) is causing serious bottlenecks in this project. The main problem seems to be lack of proper channels of dialogue and unresponsiveness to users' actual needs. (And collation is trivially easy, even I know how to do it. And temporary fixes are better than no fix at all.) --Kotniski (talk) 17:45, 24 October 2009 (UTC)[reply]

Indented entries don't wrap

Ok so the subject isn't clear, so let me use an example rather than trying to explain it If I put a space before a line, it does a code or quotation box. Unfortunately the text never wraps and will cause a horizontal scroll bar if it isn't manually broken. Is this proper behaviour (I can't imagine there would ever be an instance when we want this) or is it a bug? - ʄɭoʏɗiaɲ τ ¢ 18:59, 23 October 2009 (UTC)[reply]

This is by design; it is used for short code examples. You indent with a colon. See WP:CHEAT. ---— Gadget850 (Ed) talk 19:02, 23 October 2009 (UTC)[reply]
So whats the purpose of it not wrapping if it messes up page layout? I know I can use colon, but that dashed outline makes the space indent very useful for quotations... Except for the nowrap part. The feature seems redundant if its only for short codes (Why not use the same markup for showing longer codes?) and it messes up the fixed widths whenever it is used for a code that is longer than the page is wide (Which if it does this, most people will avoid using it once the code breaks the page width). - ʄɭoʏɗiaɲ τ ¢ 19:07, 23 October 2009 (UTC)[reply]
Actually, part of its purpose is to never automatically break. It's to be used specifically for code snippets as they appear, which is rendered useless if the browser window adds a line break for readability. Although it's irritating when someone accidentally prefaces a talkpage comment with a space and just leaves it unfixed for six months. --King Öomie 20:09, 23 October 2009 (UTC)[reply]
Quotations should use the <blockquote>...</blockquote> tag, or one of the quotation templates. ---— Gadget850 (Ed) talk 20:37, 23 October 2009 (UTC)[reply]

Is there a variation/a template that I can use to make the box, but have it wrap (for quotations and what not)? (beat me to it Gadget) Or from a vice-versa perspective, can we make a template for code snippets and use the indent space for quotations (probably not at this point I assume)? - ʄɭoʏɗiaɲ τ ¢ 20:40, 23 October 2009 (UTC)[reply]

You can enclose it in <pre style="width:80%; white-space: pre-wrap;">...</pre>: 

If I put a space before a line, it does a code or quotation box. Unfortunately the text never wraps and will cause a horizontal scroll bar if it isn't manually broken.

But white-space: pre-wrap; is CSS3, thus very browser dependent; more at Making preformated pre text wrap in CSS3, Mozilla, Opera and IE

Or; you can use a table: 

{| style="width:80%; border: 1px dashed #2F6FAB;"
| row 1, cell 1
|}
row 1, cell 1

It might be worth looking at a pre option for {{quote box2}}. ---— Gadget850 (Ed) talk 21:07, 23 October 2009 (UTC)[reply]

Date calculations

As I continue on my quest to automate some of the record chart tables, I've come across an unpleasant problem. There are a few of the major chart sources that use relative time for the URLS: last week is week 1, the week before last is week 2, etc. That means that every reference people place has to be updated every week, and any reference my chart macro creates will have the same problem. Alternatively, I could calculate how many weeks ago a date was, and adjust the URL automagically. Does anyone know of any templates that do date math that I could use as a starting point?—Kww(talk) 23:47, 23 October 2009 (UTC)[reply]

mw:Help:Magic words#Date & time and Category:Date-computing templates should have what you need. Also you could ask administrators of those site to change the URL format, as it breaks fundamental web paradigm, that URLs link to a specific resource (as the name Uniform Resource Locator suggests). Svick (talk) 01:25, 24 October 2009 (UTC)[reply]
I agree that changing the URL every week is rather bad practice. If they really don't have any way of creating a permanent URL and aren't willing to do so, I would suggest using something like WebCite. Mr.Z-man 01:44, 24 October 2009 (UTC)[reply]
I suspect that they do it on purpose. Many of them take steps to prevent direct linking to interior pages, as opposed to coming in through the top. It's one of the reasons that keeping record charts accurately cited is such a pain. Using WebCite defeats my primary purpose, which is to make properly citing a chart easy so that novices can accurately do it. For most, tell me the country, artist name, and song title, I can generate an accurate URL to verify the information against. For a few, I need the date. My ultimate goal is to get the charts converted to using templates in a standard form, so that a bot can then be produced to read the templates and automatically verify them as a background task. Chart vandalism is a nasty problem, and I've gotten tired of manual verification and reversion. Looks like DATEDIFF2 will provide the core of what I need, with a little bit of divide by 7 logic and checking for Wednesday crossings (for Japan) and Sunday crossings (for the UK). This is easy compared to Billboard. I'm actually thinking of building an intermediate website that implements the Billboard API in another server just to give a usable URL format that doesn't require a magic and unpredictable number to identify the artist.—Kww(talk) 03:24, 24 October 2009 (UTC)[reply]
AFAIK there is an absolute-date syntax for Billboard charts (e.g. Oct 10, 2009), and as it still permits archiving that is a good route to automate if you can. This raises the wider question of whether Wikipedia should contain manually-synchronized copies of data tables from other sources, given that this offers all sorts of opportunities for sneaky vandalism (there used to be an editor who delighted in tampering with cities' climate tables, for example). Pointillist (talk) 18:43, 24 October 2009 (UTC)[reply]
Note that your link only provides the top 10 positions. The remaining 90 are there, just harder to get at. My first proposal at chart data was to simply eliminate it, for much the same reason as you've proposed. I gave up on that. Then, I spent over a year and around 15,000 edits trying to take care of the problem manually. I'm in the process of giving up on that. Now, I'm aiming for a standard format. If I can get the data to be entered via a standard set of templates and sourced to a standard set of sources, a bot can be written that verifies the data offline. At least that way, sneaky vandalism will get automatically corrected.—Kww(talk) 12:31, 25 October 2009 (UTC)[reply]

Can a warning be added to inform the user that the link is not verifiable when the user try to references unreliable source, for example, when the url contains wikipedia.org, baike.baidu.com or blogspot.com?--Skyfiler (talk) 23:18, 24 October 2009 (UTC)[reply]

The edit filter could be used to catch that, but I'm concerned there may be many false positives. You can make a request and see what people think there. Someguy1221 (talk) 23:35, 24 October 2009 (UTC)[reply]

WikiProject automatic listing & notification of deletion proposals

I'd like to have WP:CL's deletions page automatically updated to:

  1. add a {{subst:Adw|ARTICLE NAME}} for anything that is listed for AfD, CSD, or blanked;
  2. add an entry to the list of AfDs (in the Languages section of that page), or an equivalent

As is, manual tracking only does this very poorly, and as a result, articles are deleted or blanked without adequate notice to the WikiProject contributors, which is quite frustrating.

Similarly, it would be nice if we could automatically tag as {{WP conlang}} anything that is listed in certain WP:CL-governed categories, like Category:Constructed languages and Category:International auxiliary languages, since everything in those categories is necessarily of interest to the WP, and users may not know of the WP and how to correctly tag new pages for inclusion in it.

I think this functionality would be of significant utility to all WikiProjects, and could be done in a completely project-agnostic way (e.g. perhaps tied to {{WPBannerMeta}}).

How could it be arranged? Sai Emrys ¿? ✍ 07:10, 25 October 2009 (UTC)[reply]

You might find some tools of interest at WP:WikiProject Council/Guide/Technical notes#Automation. In particular, WP:Article alerts is somewhat similar to what you propose. It's currently in use by approximately 450 projects. --B. Wolterding (talk) 21:14, 25 October 2009 (UTC)[reply]
WP:Article alerts does exactly what I want for point 1. I've added a feature request to it for point 2. Do you know of any other bots that do the latter or similar? Thanks! Sai Emrys ¿?✍ 22:51, 25 October 2009 (UTC)[reply]

Images to commons

Could someone please move these images to Commons? Thanks. SharkD (talk) 08:53, 25 October 2009 (UTC)[reply]

MediaWiki:Searchmenu-new

See MediaWiki talk:Searchmenu-new#Breakage with fulltext search and Wikipedia:Village pump (miscellaneous)#Suffix: prefix:

Is there anything we can do or is a bug report needed? OrangeDog (τ • ε) 15:27, 25 October 2009 (UTC)[reply]

bugzilla. --rainman (talk) 17:12, 25 October 2009 (UTC)[reply]

template:MediaWiki messages

I've created {{MediaWiki messages}} (along with a page it links to, Wikipedia:MediaWiki) to get an overview of the key MediaWiki messages. I've also added that template to {{interface explanation}}, which is widely used (more widely than a couple of days ago...) on MediaWiki talk: pages. Only problem: I can't get {{MediaWiki messages}} to behave itself and be centered at 80% of the width, matching {{interface explanation}}. Can anyone make that happen? Rd232 talk 16:01, 25 October 2009 (UTC)[reply]

PS on a related note, I created {{editnotice explanation}}, as an equivalent to {{interface explanation}} for editnotices. It might usefully be applied quite widely. Rd232 talk 16:01, 25 October 2009 (UTC)[reply]
Width is now 80%. — Edokter • Talk • 16:12, 25 October 2009 (UTC)[reply]
Marvellous, thank you. Rd232 talk 16:14, 25 October 2009 (UTC)[reply]

Lost page histories

Anybody else notice that some old page versions are still gone? The 2005 Peer Review version of Technetium, for example, is blank. See [1] Related SignPost entry here. Anything been done about this yet? --mav (talk) 04:06, 26 October 2009 (UTC)[reply]

Sounds like bugzilla:20757. --MZMcBride (talk) 04:11, 26 October 2009 (UTC)[reply]
Thanks for the link. Good to know that the developers are working on this. --mav (talk) 04:21, 26 October 2009 (UTC)[reply]
Actually since all of these issues require identification for fixing, it's rather important you mention all these cases in that specific bugreport I think... —TheDJ (talk • contribs) 12:08, 26 October 2009 (UTC)[reply]
Yikes, there are heaps of them! I know of cases of this problem at piano for example, and many other articles that I can't remember at the moment. Bug 19990, which was another problem relating to corrupted history that I reported, was almost resolved without me having to mention the hundreds of pages where it occurred. I would've thought the devs would use database queries to find all (or almost all) the edits to fix in bug 20757, and not have to rely on editors finding them by accident. Graham87 06:26, 27 October 2009 (UTC)[reply]

Removing avatar or custom skins

How do I remove the white guy (or gal or blob) avatar from next to my user name? I prefer the default skin, browsed through others without finding better.

Is there a code to remove the avatar? Or change the avatar? Are there other avatars? Are there custom skins? Or ways to customize this one? --IP69.226.103.13 (talk) 07:23, 26 October 2009 (UTC)[reply]

See discussion at Wikipedia:Help desk/Archives/2008 March 23#user.gif and Wikipedia:Village pump (policy)/Image:User.gif: unintended bias? PrimeHunter (talk) 12:33, 26 October 2009 (UTC)[reply]
Thank you PrimeHunter, the first link had a specific suggestion for code that worked and allowed me to keep the classic skin! --IP69.226.103.13 (talk) 19:22, 26 October 2009 (UTC)[reply]
This is the first time I've even noticed that there! Now it bothers me! LOL –xenotalk 19:29, 26 October 2009 (UTC)[reply]
I didn't notice it until I tried Beta then switched back-Beta has a different one, a little more orange, maybe less offensive (not really). Sorry about that, Xeno. Try the monobook fix listed in the first link PrimeHunter posted, also the second link contains instructions for switching to a different image, and I think I'll go for a more representative of me one some time in the future. If you try that and it works, let me know. --IP69.226.103.13 (talk) 19:50, 26 October 2009 (UTC)[reply]

searching for ELs to a domain

I know I've seen people do this in the past, but I can't seem to locate it right now. Let's say I wanted to do a search in wikipedia for pages that have links to a certain domain (today my concern is geocities.com). How would I do that? --Bachrach44 (talk) 16:47, 26 October 2009 (UTC)[reply]

Special:SpecialPages > External links. ---— Gadget850 (Ed) talk 16:49, 26 October 2009 (UTC)[reply]
Exactly what I needed - thank you. --Bachrach44 (talk) 17:00, 26 October 2009 (UTC)[reply]

Question on templates

Is it able to use a parameter in template, so as it would be once showed as being used in <pre></pre> and next time normally? I need to enter ex. <font color="red">Example</font> as value of a parameter and receive the next result, it would be very useful for showing template function in documentation: 

<font color="red">Example</font>
 Example

Thank you, --Petrus Adamus (talk) 17:54, 26 October 2009 (UTC)[reply]

That's an interesting question but I don't think it possible because there is no way to expand a parameter without decoding the HTML. The only possibility I think is to use something like what I've got in my sandbox and separate the line into three, i.e.
{{User:MSGJ/Sandbox4
 |open=font color="red"
 |text=Example
 |close=/font
}}
produces

User:MSGJ/Sandbox4

— Martin (MSGJ · talk) 18:33, 26 October 2009 (UTC)[reply]
{{#tag:nowiki|wikicode}}, {{pre2}}, and {{testcase}}, although comments are stripped. — Dispenser 20:22, 26 October 2009 (UTC)[reply]
It seems to me, that the solutions presented aren't usable in my case: I need it for creating a survey of template function and would like to get rid of the necessity of entering the same parameter two times, once in <pre></pre>, next without it. For the result required, see Vikipediisto:Petrus Adamus/fontindiko. --Petrus Adamus (talk) 14:44, 27 October 2009 (UTC)[reply]
Dispenser gave you the solution, maybe I can explain it more: within the template, You can use {{#tag:nowiki|{{{1}}}}} when You want to show the code and simply {{{1}}} for showing the result of the same code. -- Codicorumus  « msg 19:50, 27 October 2009 (UTC)[reply]
Warning: this does not work for tag <nowiki> itself. -- Codicorumus  « msg 19:58, 27 October 2009 (UTC)[reply]
Thank you. Nevertheless, it goes ex. for ''text'' but not if you use a template as the parameter, ex. {{#tag:nowiki|{{date|2006-05-04}}}}. --Petrus Adamus (talk) 23:29, 27 October 2009 (UTC)[reply]

google custom skin

Google have created a custom skin that can be found here. The question is does that javascript tell google what pages a person views?©Geni 00:04, 27 October 2009 (UTC)[reply]

The best way to find out is to install Wireshark and search for something, then look at what was done. Chillum 00:06, 27 October 2009 (UTC)[reply]
Since it does a contextual search(ie bases the search not on just the word but also the context of the word) it must create a query out of elements of the page, or simply send the page name itself to google. Google will certainly either know which page, or have all the information needed to figure it out. I imagine this information is covered by their privacy policy. Chillum 00:26, 27 October 2009 (UTC)[reply]

Yes. The first line of the user script inserts a script file hosted by Google, which means they can collect any data they want on you. —Simetrical (talk • contribs) 02:23, 27 October 2009 (UTC)[reply]

In the end there is no way to use a search database hosted by Google without sending Google the information they need to process your searches. Of course there is no requirement to use Google, you can use the native Mediawiki search. — Carl (CBM · talk) 11:44, 27 October 2009 (UTC)[reply]

importScript

Shouldn't the directions on User:Csewiki use "importScript" instead of document.write? — Carl (CBM · talk) 11:43, 27 October 2009 (UTC)[reply]

Yes they should, unless they have stuff that needs to be loaded before pages are done loading. —TheDJ (talk • contribs) 13:10, 27 October 2009 (UTC)[reply]

Template variant needed

 Done

Hi - I'm an arbcom clerk and I need a variant of the Template:Discussion_top template. (I have no idea how to write templates and would break something if I tried).

Basically my problem is that in Arbcom cases there are often HUGE discussions that need to be closed off. They are also often adjacent, so when you are scrolling down it is hard to tell where one stops and the next begins because the discussion template gives them the same background colour. I have been switching between ((discussion top)) and ((archive top}} in order to get some colour differences, but the wording of these two templates differs and it's a bad look.

Desired template changes:

  • Wording changed from "The following discussion is archived..." to "The following ArbCom discussion is archived..."
  • A colour parameter (color=1, color=2 etc) to allow the background colour to be changed. Three colours would be plenty. Should default to the current colour (#f5f3ef).
  • A name of Template:Arbdiscuss would be ideal.

Being clueless, I'm not sure how this ties in with the ((discussion bottom)) tag.

Any help much appreciated Manning (talk) 00:44, 27 October 2009 (UTC)[reply]

I have created it: {{Arbdiscuss}}. You may wish to protect it. Intelligentsium 01:00, 27 October 2009 (UTC)[reply]
You are a scholar and a gentleman. (Or gentlewoman if appropriate). Much appreciated. Manning (talk) 01:21, 27 October 2009 (UTC)[reply]
Um, it doesn't seem to have the "color" parameter. Or am I missing something? (Sorry for cluelessness). Manning (talk) 01:24, 27 October 2009 (UTC)[reply]
Oh, I've spelt "color" "colour". I can change it, if you'd like (or I can explain how to change it, if you've already protected it). Basically, though, it is {{Arbdiscuss|colour=<desired colour>}}. For example, if I fill <desired colour> with, say, ivory, it would produce:
The following arbitration-related discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Cheers, Intelligentsium 01:34, 27 October 2009 (UTC)[reply]

Fantastic. Thanks so much. Manning (talk) 01:48, 27 October 2009 (UTC)[reply]

Preventing search engines from indexing certain commercial encyclopedia pages

Would it be possible to establish a list of encyclopedia pages, mostly about businesses and products, that are invisible to Google and similar search engines?

I've been trying to get rid of obvious spam pages, such as RTTS and Smartsheet (see Wikipedia:Articles for deletion/RTTS and Wikipedia:Articles for deletion/Smartsheet) but the AfDs always seem to get bogged down on "notability", and the claims that appearing in investment reports or minor trade awards constitutes notability.

Preventing the existence of these article pages from influencing search engine results would allow such pages to continue to exist, while denying them the advertising benefits of search engine manipulation that come from having a Wikipedia page. Having this capability might allow these issues to be resolved without having to resort to deletion process, which seems to be a flawed instrument when it comes to these issues. - Smerdis of Tlön (talk) 14:00, 27 October 2009 (UTC)[reply]

Don't AfD notices have {{noindex}} built in? I know CSD notices do.--Unionhawk Talk E-mail Review 14:08, 27 October 2009 (UTC)[reply]
Oh, the magic word in {{noindex}} is disabled in the article space...--Unionhawk Talk E-mail Review 14:09, 27 October 2009 (UTC)[reply]
I believe they do. On the other hand, I'm not asking about indexing of AfD discussions; rather, the underlying articles. Will simply adding that tag to the pages in question do the trick? And if so, should I start? - Smerdis of Tlön (talk) 14:12, 27 October 2009 (UTC)[reply]
The template {{noindex}} has no effect in mainspace (see the template for details). Also, policywise, if it did work, use in this way would be highly controversial. As to addressing the problem, this seems an issue of notability, which should perhaps be addressed at WP:COMPANY, which currently doesn't discuss awards. For me, the notability value of many industry awards is rather low. Rd232 talk 14:25, 27 October 2009 (UTC)[reply]

External links in Wikipedia have the rel=nofollow parameter, so these articles shouldn't raise search engine rank of the companies' websites, if that's what you are concerned about. Svick (talk) 19:43, 27 October 2009 (UTC)[reply]

Technically, my concern is that having a Wikipedia page is itself an advertising coup and likely to put a business with a Wikipedia page at the top of the list of search engine results on related subjects. It's usually trivial to follow the link from the Wikipedia page to a company's own site. Ideally, we could have pages on commercial products and businesses on businesses that pass notability guidelines, but without making the Wikipedia pages on them appear in web searches, so that Wikipedia would not be quite as attractive as an advertising venue. - Smerdis of Tlön (talk) 19:55, 27 October 2009 (UTC)[reply]
I see your point, but it really defeats the object of Wikipedia. The only solution is to re-examine the specific notability criteria for this area (WP:COMPANY), an area which is so much more vulnerable to spam than others (and the core notion of notability doesn't take account of that). Also, possibly, re-examine how those criteria are applied at AFD, where (some might controversially argue) a certain inclusionist tendency doesn't seem to care about the spam issue; any article on a minimally notable company is improvable to a neutral standard in theory, ergo keep - even though in practice this often doesn't happen, providing what I call a spamicle (cf Wikipedia:Requests_for_comment/new_users#Promotional articles...). Rd232 talk 21:55, 27 October 2009 (UTC)[reply]

There should not be promotional pages on Wikipedia. If there is a page in the article namespace that functions as unworthy advertising for a company or product (that is, not just presenting an encyclopedic coverage that describes a successful and ethical company), then that page needs to be rewritten or deleted, not merely hidden. Happy‑melon 22:13, 27 October 2009 (UTC)[reply]

Accidentally disabled mobile Wikipedia on iPod Touch

I accidentally disabled mobile Wikipedia on my iPod Touch. How can I enable it (without deleting all my cookies)? Thanks. —Preceding unsigned comment added by Nadavzn (talk • contribs) 14:15, 27 October 2009 (UTC)[reply]

Um... Delete all your cookies? That's all I can think of... There is a Wikipedia App that you can download (right?)--Unionhawk Talk E-mail Review 14:20, 27 October 2009 (UTC)[reply]
Is your iPod "jailbroken"? If so, it is possible [3] (see Sept 04, 2009 11:30 post). If not, sorry - you probably have to clear all your cookies. –xenotalk 14:59, 27 October 2009 (UTC)[reply]
I'll create a page tomorrow that will allow you to "unset" this. —TheDJ (talk • contribs) 23:23, 27 October 2009 (UTC)[reply]

Blocked AIV helper bot

Resolved

I just blocked one of the AIV helper bots for editing while logged out - see 208.86.225.40 (talk · contribs · WHOIS). Anyone know who is operating that one? Thanks. Wknight94 talk 14:47, 27 October 2009 (UTC)[reply]

Try WP:BON maybe? –xenotalk 19:51, 27 October 2009 (UTC)[reply]
See IP talk page. Cenarium (talk) 20:26, 27 October 2009 (UTC)[reply]
Cheers, marked resolved. –xenotalk 20:30, 27 October 2009 (UTC)[reply]

Minimal number of searches returning all articles

I think there's no special character returning all articles for performance reasons, so I've been looking for a minimal number of searches returning all of them - or almost all of them, at the time of the latest search index. Assuming any article should contain at least one word in English alphabet, we can do this with 'wildcards' in 26 searches, a* and so on. Can this be done in less than that ? Cenarium (talk) 20:45, 27 October 2009 (UTC)[reply]

They would probably all contain at least one period... ? And if that doesn't work, surely they would all possess at least one vowel =) –xenotalk 20:47, 27 October 2009 (UTC)[reply]
I don't know what are you trying to do, but if you want to list all articles, you can use Special:AllPages or the API. Svick (talk) 21:08, 27 October 2009 (UTC)[reply]
I'd like them returned through the search interface because of some new search features that could be introduced, such as sorting by date and size; which are already noted in search results. So that you can for example easily see which articles haven't been edited in ages, or of small size, without needing to make a database report and such. Cenarium (talk) 21:23, 27 October 2009 (UTC)[reply]
To see list of articles with small size, you can use the API like this. There is a toolserver tool that can list pages that haven't been edited for a long time, but is isn't working. Svick (talk) 22:42, 27 October 2009 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=322434948"