The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at the BugZilla.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
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-man22:01, 19 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:
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.
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.
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.
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... Rd232talk20: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.
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? Rd232talk21:07, 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.
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... Rd232talk09:02, 21 October 2009 (UTC)[reply]
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.
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.
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? Rd232talk11:28, 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]
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 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. Rd232talk15: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]
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. Rd232talk15: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. — Dispenser02: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. -- Ynot?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]
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-man01: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]
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]
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]
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-man00:02, 26 October 2009 (UTC)[reply]
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]
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). Rd232talk13: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-man16: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-man17: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-man22: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-man16: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]
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]
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-man01: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]
Warning when adding links from a known unreliable source
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]
add a {{subst:Adw|ARTICLE NAME}} for anything that is listed for AfD, CSD, or blanked;
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}}).
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]
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. Graham8706: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.
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]
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:
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.
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 [2]. --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« msg19:50, 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. Chillum00:26, 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]
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.
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.
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?
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]
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. Rd232talk14: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...). Rd232talk21: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‑melon22:13, 27 October 2009 (UTC)[reply]
Some variant of this (for spam, BLPs, questionably notable subjects, etc.) is almost a perennial proposal. My response to all of them is: If we don't want the general public to be able to easily find a particular article, we should not have that article. Mr.Z-man23:50, 27 October 2009 (UTC)[reply]
Accidentally disabled mobile Wikipedia on iPod Touch
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 =) –xenotalk20:47, 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]
I cannot for the life of me get safari to view ANY on wikipedia properly. They show up as enormous files that can't be scrolled or zoomed so that you can only see a tiny portion, usually the extreme upper left corner. I'm using the latest safari, but my OS is Mac 10.4.11 on a late powerbook G4. I tried the SVG help page, but that's more for creators and I was directed here. Firefox works OK, with scrolling enabled, but it's a pain to switch browsers for a single purpose. Safari has supposedly supported SVGs for a while, but I'm not sure of the extent of that support. Any help would be appreciated. Thanks. 209.133.78.35 (talk) 23:55, 27 October 2009 (UTC)[reply]
SVGs should work fine in Safari, especially the latest one. It will be difficult to diagnose the problem for you unless you provide us with more information; I suggest you post a screenshot at ImageShack so we can see how it looks for you. Gary King (talk) 00:45, 28 October 2009 (UTC)[reply]
MediaWiki renders SVGs as PNGs in articles, due to lack of SVG support in some browsers... I don't know if that's useful or not here, but I thought I'd mention it. –Drilnoth (T • C • L) 01:51, 28 October 2009 (UTC)[reply]
Hi guys, thanks for the quick replies. I'll give you all the info I can think of. I'm on Mac OS X 10.4.11 using a Powerbook G4 17" 1.67, Safari Version 4.0.3 (4531.9). Intelligentsium, I could see that file fine. Couldn't register with ImageShack but if you take a look at this file: http://en.wikipedia.org/wiki/File:NJT_railmap.svg I can give you a good idea of what my screen cap looks like. It's all white with just the very end of the yellow line and the dot for Port Jervis in the left upper center area. No scroll bars of any kind or any other controls. I suspect it might be a PowerPC thing. Thanks again for all your help, at least I now know it's not a wide-spread Safari problem. (forgot to sign in last time) Armandtanzarian (talk) 03:21, 28 October 2009 (UTC)[reply]
mobile.wikipedia.org: If you search for "wp:rd/e" then instead of going to the Entertainment Refdesk, as you do on en, instead it comes up with some sort of search results page of articles that supposedly contain that string. Comet Tuttle (talk) 04:34, 28 October 2009 (UTC)[reply]
shows the right way, and is very attractive. I want to request an account too! :-) Dodoïste (talk) 11:12, 23 October 2009 (UTC)
Done
/Image:User.gif:_unintended_bias%3F){kind=link}
