Wikipedia:Village pump (technical)

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.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
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 have problems making your fancy signature work, check Help:How to fix your signature.

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.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Add link to search help

(For previous discussion, see #Search page above.) We have now established which MediaWiki pages needs to be edited in order to ensure that the search results page contains a link to the help on searching (Wikipedia:Searching), so I've proposed doing it. I'd have thought this was a no-brainer, but there seems to be doubt, so please indicate if you support or oppose the idea. Namely that before the line that says either "There is a page named X on Wikipedia" or "You may create the page X but consider checking the search results", there should be a line that says "For full information on available Search options, see Wikipedia:Searching." (It pretty much has to go in that position; well it could go below the other line, I suppose.)--Kotniski (talk) 14:39, 31 October 2009 (UTC)[reply]

Support own proposal; completely obvious that there should be such a link, otherwise casual searchers have no obvious way of finding out about the sophisticated(ish) search functionality that we have.--Kotniski (talk) 14:39, 31 October 2009 (UTC)[reply]
Neutral - as I said, I don't think it is impossible for people to find help on searching, because it is exactly where one would expect it - among help pages on Help:Contents. But if you do add a help link, please keep the wording as short as possible. --rainman (talk) 12:38, 1 November 2009 (UTC)[reply]

I'm not convinced, based on that page being way too unfriendly to the average user. It's a shopping basket of everything related to searching; it doesn't highlight key things and hide complexity. It's too big and too technical. And some people are opposed to making these messages any longer than absolutely necessary. I'd rather use extra text for a link (on MediaWiki:Searchmenu-new) to the Article Wizard, but that change was rejected a month ago [1]. If a friendly Search help page existed, that would be different. Rd232 ^talk 14:46, 31 October 2009 (UTC)[reply]

You seem to be confusing two things: the other change was for one of the two messages to be made longer; this is to add another message above it. (I'd be happy to see the other change made too, but the two issues are not connected.) And if the help page isn't perfect, then having a link to it will have the other positive effect of getting more eyes on it and more people making improvements. Somehow it isn't penetrating my brain how anyone for an instant could oppose this change; it's one of the most obvious things I've ever had to ask an admin to do.--Kotniski (talk) 15:02, 31 October 2009 (UTC)[reply]

Support. But I would suggest Help:Searching as a better link, this page is more pertinent to the search button - as always needs a little attention. Failing that we could create and link to a dedicated help page. I would also suggest al we need is the a wikilink called 'help' next to the search button. Lee∴V (talk • contribs) 17:27, 2 November 2009 (UTC)[reply]

Yes, that would certainly be even more useful, but would probably involve huge discussion and then waiting years for the developers to change something (though I've asked for it at Template:Bug, just in case), whereas this proposal can be done now. I'm not sure that Help:Searching is better, since it doesn't seem to be up-to-date documentation, but it doesn't matter - that page can always be updated with the new information. (As I've suggested, the technical documentation could be at the MediaWiki site like most of the software documentation, then we could just have a single user-friendly help page on en.wp.)--Kotniski (talk) 18:23, 2 November 2009 (UTC)[reply]

Help:Searching should be merged into Wikipedia:Searching (or vice-versa), having two pages makes if harder for readers to know where to look for the best/more relevant info and it's more difficult to maintain. I'm not sure if the sections on External search engines, Browser-specific help and Searching with TomeRaider need to be there, it makes the page too big imo and isn't very useful globally, moreover it's the kind of things that grow constantly; they could be spun off. Cenarium (talk) 18:57, 2 November 2009 (UTC)[reply]

I just had a bash at tidying up 'help:searching' and after cutting out the chuff it really doesn't cover much if anything extra to the WP:searching, Agree that a merge is required - or just basically Move WP version over to help:. Also agree to seperating external searches to another page. I'll setup the merge request and then the move once that's done. I also have a merge proposal for 'Help:Go button' as it is very short and would add context. Note: not really bothered where the help link is, just that one is there somewhere !Lee∴V (talk • contribs) 19:10, 2 November 2009 (UTC)[reply]

Good, we should wait to have all this sorted out before linking it. Cenarium (talk) 18:45, 3 November 2009 (UTC)[reply]

As it's mostly unneeded, it may be too obtrusive if placed there, though a well-placed discrete link could be useful, but it'd require developer intervention. It should be possible to add a link in the advanced form of the interface, though, even when no search has been entered, (e.g. in the empty space below Check: All None.) Cenarium (talk) 18:57, 2 November 2009 (UTC)[reply]

I'm not sure what this refers to - what is "mostly unneeded", and where is "there"? (If you mean the link in the place that I'm proposing, then I disagree strongly - help on using a function is surely very needed by many people using that function, and there has to be a very transparently accessible link - ideally on the original search box AND on the search results page, but certainly in at least ONE of those places, and my proposed solution seems to be the only one we can implement ourselves without waiting months or years for the devs to change something - of course when they do, we can change our thing as well.)--Kotniski (talk) 08:30, 3 November 2009 (UTC)[reply]

If we put it at the top of MediaWiki:Searchmenu-new; readers will less likely read what follows, 'there is a page...'/'you may create...'; it would be too prominent for a link we need not all the time. I'd prefer a discrete link similar to what we have for Special:Contributions. I think we can do this with css. Cenarium (talk) 18:45, 3 November 2009 (UTC)[reply]

OK, how do you propose doing it? (But I don't think this link is any less needed than the message that follows - link to help on the function the reader's using is surely much more likely to be needed than the incidental message about creating a page, or the even more incidental message that there is a page of that title which the reader can see at the start of the search results anyway. It's those messages that need to be discrete, not the link that millions of readers might actually want to use.)--Kotniski (talk) 18:52, 3 November 2009 (UTC)[reply]

Well, I'm not sure. I've asked Rainman. Cenarium (talk) 18:58, 5 November 2009 (UTC)[reply]

Requested at Template:Bug. It has been assigned to the usability team. Cenarium (talk) 21:51, 8 November 2009 (UTC)[reply]

OK, so while that goes through the mechanisms, is there any remaining objection to my original proposal to add the link to the MediaWiki pages that we can edit? (The change is easily reversible once the devs come up with something better, but since that could take literally years, we have to do something to give readers the link in the meantime, and my suggestion seems to be all we can do at present.) --Kotniski (talk) 16:06, 9 November 2009 (UTC)[reply]

Well, in the absence of any objections, I'm renewing the edit requests at MediaWiki talk:Searchmenu-new and MediaWiki talk:Searchmenu-exists.--Kotniski (talk) 12:09, 11 November 2009 (UTC)[reply]

I still think it is unnecessary and too long, and makes the average user (again remember he just wants to find stuff, not to ponder on advanced ways of searching) another line of text to distract him... --rainman (talk) 12:17, 11 November 2009 (UTC)[reply]

Well if you can help (as a developer) get the help link placed somewhere more appropriate, as discussed then that would be great. But for now, this is the only solution we have (and I don't think anyone wants to suppress this link completely - that would be ridiculous).--Kotniski (talk) 12:24, 11 November 2009 (UTC)[reply]

In fact if anything's distracting and unnecessary, it's the line that says "there is a page on Wikipedia called..." Doesn't that page automatically show up at the top of the search results anyway? (If not then it should.)--Kotniski (talk) 12:26, 11 November 2009 (UTC)[reply]

Well I agree... but it was put there by usability people because, well, the exact match is not *always* the first hit (especially on default mediawiki install) and it amends to UI consistency, so that the user knows to expect an article creation link in that place when the article doesn't exist.. Which I guess is fair enough... --rainman (talk) 12:43, 11 November 2009 (UTC)[reply]

I don't object to the link in principle, but I think the target page needs to be improved first. It needs to be better organised, friendlier, and more focussed. It needs illustrative images too. Rd232 ^talk 12:43, 11 November 2009 (UTC)[reply]

Another reason for including the link, then - more eyes on the page means more potential improvers. (But I don't think the current version is so bad that we have to be embarrassed about it.)--Kotniski (talk) 13:14, 11 November 2009 (UTC)[reply]

Look, is anyone actually seriously opposing this, like to the extent that they think it would make things worse, not just that it wouldn't make things as good as they might ideally be? I consider it tantamount to vandalism to deprive users of the information they need on how to use a software function - it's still absolutely unbelievable to me that this wasn't simply done when first proposed. Just what are you guys hoping to achieve? If a help page has to be perfect before we link to it, then we'd never link to any of them.--Kotniski (talk) 17:59, 11 November 2009 (UTC)[reply]

For what it's worth, I support this proposal. — Martin (MSGJ · talk) 18:16, 11 November 2009 (UTC)[reply]

I've added Template:Bug to WP:DevMemo. I think that's a better solution. But I suppose this will do in the mean time, and as Kotniski said, linking it prominently will make it more likely it gets improved. It really needs improving though - I'd do a complete rewrite and try and make it more like the WP:Tutorial perhaps. Rd232 ^talk 18:42, 11 November 2009 (UTC)[reply]

We should go ahead with the merge and split discussed at Wikipedia_talk:Searching#Merging.2C_renaming_and_splitting, before adding it - so it's stable. As for the link, can we add it through MediaWiki:Searchmenu-new and MediaWiki:Searchmenu-exists in the form of coordinates ? There's a bug in display for the help link at Special:Contributions in vector style and on IE which could happen here too. Cenarium (talk) 01:39, 12 November 2009 (UTC)[reply]

I don't understand - the proposal is just to add an ordinary sentence of text - why would doing it in the form of coordinates avoid any bug? More likely it would cause bugs.--Kotniski (talk) 11:29, 12 November 2009 (UTC)[reply]

I've been unclear: I inquire if we would have a bug if the link were added in coordinates there. I believe as before that the initial suggestion would make the amount of text too important between the search box and the search results, and that the "there is a page named.../you may create the page..." is important enough to not be removed. Cenarium (talk) 02:58, 14 November 2009 (UTC)[reply]

About Link FA

Recently I've found out that in Internet Explorer 8 if a particular non-English edition is featured, then the star next to the link can be shown correctly, but in Google Chrome 3.0.195.27 the star is now shown (but in both browsers the tooltip which indicate a non-English edition is featured can be popped correctly. I don't face this problem before when I use Google Chrome. Can anybody tell me why (the operating system I use is Windows XP Home Edition Service Pack 2)?--RekishiEJ (talk) 13:14, 5 November 2009 (UTC)[reply]

By the way, I don't counter this situation when browsing non-English Wikipedia. --RekishiEJ (talk) 13:20, 5 November 2009 (UTC)[reply]

Are you using monobook, or the new beta vector skin ? —TheDJ (talk • contribs) 13:54, 5 November 2009 (UTC)[reply]

I use vector on both browsers. And one month ago I use vector as the skin, and use IE8 and GC3 to view Wikipedia pages, and the FA star can be properly displayed when a certain non-English edition is featured there.--RekishiEJ (talk) 14:47, 5 November 2009 (UTC)[reply]

I updated GC later to 3.0.195.32, and the same problem still exists.--RekishiEJ (talk) 06:39, 6 November 2009 (UTC)[reply]

There are 2 problems here. The first is IE8. It is showing the list bullet/star for the languages, even though it shouldn't under Vector. That explains the difference in behavior between the two browsers. Basically the linkFA star is not supposed to work with vector yet, and that is why Chrome is not showing it. I'm thinking of ways to display the star without making use of a list bullet. —TheDJ (talk • contribs) 10:28, 6 November 2009 (UTC)[reply]

I hope I have this fixed now. Please clear your browser cache and see if there is an improvement now. —TheDJ (talk • contribs) 21:56, 6 November 2009 (UTC)[reply]

Now I use both IE8 and GC3 to check if the {{Link FA}}'s star is displayed correctly when using the new Vector skin, and now I found out both displays the expected result. The position of the FA star is somewhat now pleasing to look, though.--RekishiEJ (talk) 06:03, 9 November 2009 (UTC)[reply]

It's more the star that is the problem I think. With the new gray background it doesn't look as good. If someone wants to design a new one, I'd love to see some proposals. —TheDJ (talk • contribs) 12:47, 11 November 2009 (UTC)[reply]

MediaWiki:Spamprotectiontext

There's a thread at MediaWiki_talk:Spamprotectiontext#user-friendlier_message about rewriting that message, if anyone would like to comment. Rd232 ^talk 15:24, 5 November 2009 (UTC)[reply]

implemented now. Rd232 ^talk 00:55, 9 November 2009 (UTC)[reply]

Script to convert wikitables to CSV?

Are there any scripts (browser or software) that will convert wikitables to CSV files? Thanks. SharkD (talk) 06:10, 6 November 2009 (UTC)[reply]

Copy table from browser, paste table into Excel, save excel file as CSV. Happy‑melon 07:48, 6 November 2009 (UTC)[reply]

You usually end up with a bunch of formatting junk when you do this. SharkD (talk) 15:32, 6 November 2009 (UTC)[reply]

Not if you are viewing the table in your browser. You have to do a Paste Special and select Text. You aren't trying to copy the markup are you? ---— Gadget850 (Ed) ^talk 15:37, 6 November 2009 (UTC)[reply]

I know what he means, links are still linked, bold is still bold, etc. To get round that, copy from Excel, paste into notepad, copy back from notepad and back into Excel: notepad discards all formatting but Excel still recognises the cell separations when it's pasted back in again; notepad's great for stripping formatting from anything. Sounds time-consuming, but actually it's the work of a few seconds to do Ctrl-A/C, over to notepad, Ctrl-A/V/A/C, back to Excel, Ctrl-V. Happy‑melon 14:21, 9 November 2009 (UTC)[reply]

In Excel, instead of a normal paste you need to do a special paste as text; this way you get rid of all the formatting. -- Codicorumus « msg 18:26, 9 November 2009 (UTC)[reply]

It still doesn't get rid of the extra spaces that sometimes appear. SharkD (talk) 03:02, 12 November 2009 (UTC)[reply]

How much do links affect load times?

I know that having lots of transcluded templates or just lots of text increases the load times for a page. Does having a lot of links have a major effect?

I raised a proposal at WT:FAC#Link from main FAC page to individual FAC, which would add more links to a page that already has occasional load time problems. So I'm just trying to gauge how much 40-50 links would affect load time. Thanks, rʨanaɢ ^talk/_contribs 18:47, 7 November 2009 (UTC)[reply]

I don't think that adding 50 links to a page that already has more that 4000 of them would increase load time noticeably. But if the load time is problem, you could consider not transcluding all the discussions and only having links to them instead. Or you could have two alternale WP:FACs: one big and slow that transcludes them, and one small and fast that doesn't. Svick (talk) 20:23, 7 November 2009 (UTC)[reply]

Well, remember that templates affect initial parser and page generation time, but so long as the page is held in the server caches, they make no special difference to the subsequent load times, except the much lighter effect of having to download the content at all. I think the effect of adding several dozen extra wikilinks to a page is extremely negligible, both on parse times and load times, increasing the page size by only a few kilobytes. I mean, purging something like Wikipedia:Uncategorized biographies of living people/BLPPotential/12, which has 4½ thousand wikilinks, doesn't take more than 4 seconds. • Anakin ^(talk) 20:36, 7 November 2009 (UTC)[reply]

Adding links is unlikely to cause significantly slower loading. The only thing that will help you is making the page shorter (post-template expansion). That's also only material if there's a parser cache miss, like if the page was just changed (maybe by you) or you have certain preferences set differently from the default. —Simetrical (talk • contribs) 15:50, 8 November 2009 (UTC)[reply]

For your attention - DBpedia templates

I'm not sure where the best place for this is, but there is a discussion at ANI that some here may find of interest. I'm also going to post this at WP:VPP, but please feel free to move the discussion to the most appropriate venue. Thanks! TNXMan 19:18, 7 November 2009 (UTC)[reply]

That discussion should probably happen here, or perhaps even better would be the proposals page. Aside from not really being a matter for ANI, it would make things easier for most editors to conduct a central discussion at village pump, what with the larger loading time for the ANI page. This should be a broad community discussion. Equazcion (talk) 19:27, 7 Nov 2009 (UTC)

see below, please move, if not appropriate here SebastianHellmann (talk) 21:52, 8 November 2009 (UTC)[reply]

AWB RegEx

Say I am using AutoWikiBrowser and I am editing an album that is not wikified. Let's just say that it doesn't have a quotation mark after the number (wiki syntax #). What would be the RegEx code to put a quotation mark after every # sign? Btilm 19:44, 7 November 2009 (UTC)[reply]

Replacing # with #". No regex is needed, just find/replace. OrangeDog (τ • ε) 00:18, 8 November 2009 (UTC)[reply]

RegEx

For those of you that use AWB, would you help me test out a few RegEx codes? These two codes are designed to remove unnecessary carriage returns in a Wikipedia article, except when a category or template follows, where it will put two blank lines in between.

Find: \n(\n)+  Replace: \n(\n)+ Find: \n\n({{.*}}|\[\[:?[cC]ategory.*\]\]) Replace: \n\n\n$1

Thank you. Please get back to me on my talk page. Btilm 21:13, 7 November 2009 (UTC)[reply]

Those aren't going to work at all. For starters, you can't use quantifiers (+) in replace strings. In fact, AWB's genfixes does this for you so there is no need to write additional rules. OrangeDog (τ • ε) 00:21, 8 November 2009 (UTC)[reply]

And you don't need extra lines above navboxes. CSS rules now add whitespace above the topmost navbox. ---— Gadget850 (Ed) ^talk 15:53, 8 November 2009 (UTC)[reply]

Contributions

We should be able to see all the contributions to a article from an editor, weather it be on User contributions. Post on bugzilla.174.3.111.148 (talk) 03:41, 8 November 2009 (UTC)[reply]

You mean filter a page history by username (and/or a contribution history by pagename)? I guess that might be useful. There might already be an external tool to do this. Anyone? Rd232 ^talk 13:57, 8 November 2009 (UTC)[reply]

Yes, there is an external tool, Per-page contributions. You can also use the API for this purpose, as described at this archived discussion. Graham87 15:45, 8 November 2009 (UTC)[reply]

Found this handy link to get a handle on available tools: Toolserver tools by tags. Rd232 ^talk 16:24, 8 November 2009 (UTC)[reply]

MediaWiki:Fancycaptcha-createaccount

There is a discussion at MediaWiki talk:Fancycaptcha-createaccount#Simplicity on removing the summary of username policy currently presented on the right-handside of MediaWiki:Fancycaptcha-createaccount (which is the text presented to users on the signup screen, if they're not logged in). Some say the text is unnecessary, others that it has an important function in guiding users on choosing usernames. Rd232 ^talk 11:35, 8 November 2009 (UTC)[reply]

Border problem

I noticed the article content border is missing on 2009 flu pandemic timeline in Firefox (previous dicssuion). Further investigation shows this is dependent on the vertical dimension of the article's content, as is exhibited on this test page. Could someone help me report this if necessary as I'm not sure how to find if it's already been listed on BugZilla. --Pontificalibus (talk) 13:45, 8 November 2009 (UTC)[reply]

It seems to be a Gecko bug but it's present only in Firefox 3.0 and not 2.0 or 3.5. Not worth worrying about. • Anakin ^(talk) 14:54, 8 November 2009 (UTC)[reply]

In fact I'm pretty sure it's this and this, but again, it happens only in Firefox 3.0, and not its predecessor or successor. • Anakin ^(talk) 15:17, 8 November 2009 (UTC)[reply]

Borders can disappear in any version of FireFox if the zoom is not at default. Try Ctrl 0 to reset it. ---— Gadget850 (Ed) ^talk 15:46, 8 November 2009 (UTC)[reply]

Ah, you're quite right, I hadn't noticed that. Seeing that clearly in 3.5 at least. • Anakin ^(talk) 16:08, 8 November 2009 (UTC)[reply]

User Contributions Page

On User contributions, when User talk: pages are listed, the user's contributions need to be shown. Post on bugzilla.174.3.111.148 (talk) 20:28, 8 November 2009 (UTC)[reply]

Like on Special:RecentChanges? Don't see why not. Could be handy. Rd232 ^talk 20:37, 8 November 2009 (UTC)[reply]

Am I doing something wrong?

Please take a look at the edits I've made today (Sunday 8 November 2009). I had intended to undo vandalism by anonymous users. In at least one case I instead restored it. Have I done that systematically? Can anyone else who's already been through this tell me what I'm doing wrong and what I should do instead? Thanks. --Eldin raigmore (talk) 21:00, 8 November 2009 (UTC)[reply]

That anonymous user removed his vandalism and you undid that edit. Could it be that you saw a diff of an edit by anonymous user with the word "gay" in red and didn't realize that he removed it, not added? I think it's just that one edit. I don't think that you are doing something wrong, you probably just made a mistake. (We all do.) Svick (talk) 01:31, 9 November 2009 (UTC)[reply]

That's the explanation I hope is true. I'll assume it is until someone says otherwise. Thanks. --Eldin raigmore (talk) 01:44, 10 November 2009 (UTC)[reply]

monobook.js

Sorry, could you have a look at this: [2] Did i do sth bad? Guildenrich (talk) 21:28, 8 November 2009 (UTC)[reply]

No, your Monobook page looks fine. What are you trying to do? — The Earwig @ 21:53, 8 November 2009 (UTC)[reply]

Don't forget to bypass your cache after saving your monobook to see the effects. Cenarium (talk) 01:53, 9 November 2009 (UTC)[reply]

DBpedia Template Annotations

There is a new draft available, please comment/modify here: Wikipedia:Requests_for_comment/infobox_template_coherence SebastianHellmann (talk) 11:49, 12 November 2009 (UTC)[reply]

Dear all, let me give you a short introduction to DBpedia (official page), before I come to the core. DBpedia is a community effort to extract structured information from Wikipedia and to make this information available on the Web. DBpedia allows you to ask sophisticated queries against Wikipedia, and to link other data sets on the Web to Wikipedia data. The project exists since 2006/2007 and shares the structured data under the same licence as Wikipedia. The project is mainly driven by the University Leipzig, the Free University Berlin, and the company OpenLink Software. The core of DBpedia consists of the extraction of property-value pairs from infoboxes created with templates. For instance, if there is a property "population" in the infoboxes, you could query for all cities, which have a population count between 500.000 and 700.000 with a query in SPARQL, which is similar to SQL.

Immediate use for Wikipedia, two examples:

Structured search: try to find in Wikipedia all Musicians who play Guitar and come from Canada. This information is actually contained in Wikipedia, but can only be found by manually searching many pages. There are a total of 181 actually as you can see here in the facet based browser
direct access with the query language SPARQL. About a week ago there was a Datamining Infoboxes thread on the Wikitech-I mailing list, where a user said "I would like to find all Wikipedia pages that use Template:Infobox_Language and parse the parameters iso3 and fam1...fam15", which can very easily be answered using DBpedia, see: SPARQL query result
other applications

So there is a better way to query Wikipedia in general and it is possible to access the data (there is a public service hosting the data and the transformed dumps are downloadable).

Problem description

Properties of templates are not uniform in general. Some templates use bornIn, some birth_place, birthPlace, origin or hometown. To unify these properties, we originally created a database and created the mappings. As we are generally computer scientists, we can cover this domain quite well, but not others like medicine, pharmacy or linguistics. So the help of domain experts is needed.

Solution

We want to include annotation for templates at Wikipedia directly, so they are freely editable by anyone and belong exactly where they should be. The policy of DBpedia is to be as minimally invasive as possible. We were in contact with some members from the Wikimedia foundation, who proposed to include the Template annotations at the "doc" subpages of templates. With these template annotations it is possible to map existing template properties to uniform properties that make more sense and have a well defined meaning. For example the infobox musical artists has a property born, which is a mix of birthplace and birthdate. Note: we do not intend to change anything at the infoboxes or the templates, we just want to create a way to provide meta information, which says that the property "born" for example has actually two meanings, i.e. place and date. To give some idea, why this is useful, I would like to cite the same Wikipedia user from the Wikitech-I list, who entered this in our Bugtracker (see here: "Language infoboxes have language family fields fam1...fam15. The order of these fields encodes the heirarchy of the language family tree. DBpedia extracts the fields as as multiple "fam" elements in a random order with no sequence data." This information for example can be included into such a template annotation, e.g. as a parseHint=hierarchy which allows DBpedia to generate better data.

Some Notes on previous communication

We previously had discussion with Daniel Kinzler, where we came to the conclusion that the doc subpage of templates are the appropriate place. We were given access to live update stream by Brion Vibber (which means that we get updates automatically and do not have to do any extra calls to Wikipedia or crawl anything). There have also been some discussions about the exploitation of DBpedia for the toolserver. Nevertheless, we would like to have explicit permission that we can put the template annotations in Wikipedia (We already created a version and can provide examples). Former discussions have been on ANI, where a single user opposed our efforts. We would like to receive a broader opinion and hope to achieve fast consensus on this matter and are open for alternatives. On behalf of the DBpedia team SebastianHellmann (talk) 21:52, 8 November 2009 (UTC)[reply]

Discussion

Strongly Oppose as the one who first detected this concerted effort by several people from DBpedia folks to flood Wikipedia with these templates on a ton of infobox pages. Wikipedia offers its data for extraction, but it is not in the business of giving any one extractor, which is all DBpedia is, to adjust Wikipedia to make it any easier. This was done without any actual discussion nor permission. They were given access to the live stream. Any programming for scrapping should be done on their end and theirs only. By the OPs own remarks, they already had the appropriate programming. These templates only make it easier on their end, while glutting Wikipedia infoboxes with non-Wikipedia related content that has absolutely nothing to do with Wikipedia itself. And I object to the mischaracterization that I'm the only one who opposed the efforts. In fact, no one has supported them, which is why all of the additions have been reverted, and the accounts were all blocked, and only unblocked on the agreement that you all cease. I'm also not the only one who removed these inappropriate templates. I also object to this user modifying the ANI to claim the subject was "moved". -- Collectonian (talk · contribs) 22:05, 8 November 2009 (UTC)[reply]

To rectify one of your points: These templates do not make things easier for DBpedia. On the contrary, it's much harder to read DBpedia configuration from these templates than from local files. The goal of these templates is to allow Wikipedians to directly influence the way DBpedia works. They are not meant to make the extraction job easier. I know that this does not affect your other worries, but since you repeatedly raised this point I think it's important to be clear on this. Chrisahn (talk) 03:23, 9 November 2009 (UTC)[reply]

That is the obviously biased belief of those involved in this effort. Wowever absolutely nothing you nor the others did or want to do has anything to do with with improving Wikipedia at all. Adding bloated templates to the infobox doc pages purely for DBpedia's benefits does not aid Wikipedia. You can try rewording it all you want and continue trying to claim it helps Wikipedia - but it is purely for DBpedia's benefit. Wikipedia does not NEED those templates, it does NOT do anything to make our infobox templates more consistent, it does absolutely nothing for Wikipedia. Again, your methods were wrong and this entire thing is inappropriate. As several of you have repeatedly noted, you were extracting the data successfully. Adding these templates did make your lives easier as, by the explanations several have given, it would mean not having to continue to track the infobox inconsistencies. If you want to make proposals for Wikipedia's infobox parameters to be more standardized, then do that. But going around and making special templates with your logo and links prominently featured to benefit DBpedia to map parameters to your needs is not beneficial to Wikipedia.-- Collectonian (talk · contribs) 13:51, 9 November 2009 (UTC)[reply]

These templates will help Wikipedians to influence and improve DBpedia, so in this way they help DBpedia. But: DBpedia has a lot to do with improving Wikipedia, as mentioned above: it allows people to query Wikipedia like a database, it helps people find and fix inconsistencies in Wikipedia, it can be used to expand and compare Wikipedia data with other Linked Data sources, and last but not least, it places Wikipedia at the heart of Linked Data, which many (e.g. Tim Berners-Lee) think is the next big step for the Web. You are correct: Wikipedia does not NEED DBpedia. But Wikipedia does not NEED many other things it supports anyway because they HELP Wikipedia. Chrisahn (talk) 16:40, 9 November 2009 (UTC)[reply]

Oppose Until explicit consensus is developed that is appropriate. FWIW, I do not think this is appropriate, for the reasons laid out by Collectonian above. TNXMan 22:22, 8 November 2009 (UTC)[reply]
Support an improved version I couldn't actually fathom Collectonian's reasons for strong opposition though I did spot lots of invective, weasel words, rhetoric, and opinion: concerted effort, flood, ton, not in the business, all X is, scrapping [sic], glutting, inappropriate. It's obvious this user strongly dislikes DBpedia but it's not obvious at all why, at least not the technical reasons. Or perhaps I just haven't been informed of the evil behind DBpedia's intentions. Then again I'm not part of the Wikipedia cabal, just an old occasional contributor and a new discoverer of DBpedia which appears to be very useful and in the spirit of Wiki. — Hippietrail (talk) 00:56, 9 November 2009 (UTC)[reply]

I don't strongly dislike DBpedia, never heard of it before today and have no opinion on it one way or another. I dislike the actions they took over the last few days and strongly disagree with any website modifying Wikipedia to make their scraping of data (which is neither an invective, weasel word, etc, but the actual technical term), versus their adjusting their programming to meet their needs, same as the 100s of other data miners do. Or do you honestly believe we should add such templates to every page of Wikipedia for everyone else who extracts data from Wikipedia so its easier for them too? -- Collectonian (talk · contribs) 01:01, 9 November 2009 (UTC)[reply]

See above: The goal of these templates is to allow Wikipedians to directly influence the way DBpedia works. They are not meant to make the extraction job easier. Chrisahn (talk) 03:39, 9 November 2009 (UTC)[reply]

I read this in the way Chrisahn states, that DBpedia was adding an open way for Wikipedians to determine how DBpedia would read Wikipedia infobox data. I would like to see some mention of the format of these things. It is not clear whether or not they would be only useful to DBpedia or also to the "100s of other data miners". I don't quite see the applicability of the "massive intrusion" analogy given the Wiki policies of "anyone can edit" and "be bold", but then again if these were automated edits as I suspect that would seem to qualify as running a non-approved edit bot. One more thing, nobody has said what exactly a "template doc page" or "infobox doc page" is. Since this is supposed to be a technical topic in a technical forum I would like to see more technical details. The pros and cons of putting openly editable data extraction hints in Wikipedia, the actual proposed methods of doing so, and the pros and cons of this particular method. Then we can all judge better whether it's a good thing or a bad thing. — Hippietrail (talk) 07:55, 9 November 2009 (UTC)[reply]

To clarify: We were not running an edit bot, but performed the edits manually. Regarding the use of DBpedia: It can be used by other data miners (which in some cases now query DBpedia instead of performing an extraction themselves), but the primary purpose is to provide a different view on data in Wikipedia and allow to query it beyond what a standard search method can achieve. For instance, you can browse through browse persons born in the USA in 1971, query for famous German musicians born Berlin etc. The data is freely available and conforms to standards (RDF), so we do believe that they add some additional value to the work done by Wikipedia contributors. I agree with you that the technical aspects you mentioned should be discussed. Jens Lehmann (talk) 09:31, 9 November 2009 (UTC)[reply]

Now that I've seen one of these deleted things from an earlier revision I have to say they are very bloated and ugly, totally dominating the pages they were on. The enormous logo also gives a strong impression of spam. A more subtle approach would help your cause. Perhaps also putting them on their own subpage instead of invading the "doc" subpage. In principle I'm still in favour but I can see why these changes in their original form met with such hostility. I recommend making them more compact and with a less corporate look. Emphasize openness. Focus on how the whole public can make use of them besides just DBpedia. — Hippietrail (talk) 00:26, 10 November 2009 (UTC)[reply]

Oppose Apart from the points raised regarding whether the proposal is worthwhile, I am concerned by the approach of the proponents. Even after a massive intrusion with the effort required to revert, text such as "as minimally invasive as possible" is included above, without the slightest acknowledgement of the trouble caused. Such an attitude means that collaboration is unlikely to be helpful to Wikipedia. Johnuniq (talk) 01:38, 9 November 2009 (UTC)[reply]

You are right, we should have started this discussion before we started adding the templates. I'm sorry about that. I've been around here for a while, and I still find the Wikipedia rules quite complex at times. I didn't expect that adding a configuration template to some (about 400) template doc pages (not articles or templates themselves) would be seen as such a massive intrusion. I'm not sure though that the effort to revert was necessary. A notification would have been enough for us to stop. I also offered to revert some of the templates that Collectonian hadn't seen, but she did that work before I had the time. But again, I'm sorry that we acted prematurely. Chrisahn (talk) 03:37, 9 November 2009 (UTC)[reply]

I can understand your concerns. However, "as minimally invasive as possible" is meant relative to other methods, which allow Wikipedia users to align information from different infoboxes (such as significant extensions of the underlying MediaWiki software or modifying the infoboxes themselves). In our case, we extend the doc subpages of infoboxes, which is, according to previous discussion, the most sensible place to add this information. Maybe, we should clarify why extending those pages is seen as intrusion of Wikipedia (apart from the problem that we did not discuss this with the right people), such that we can adapt our method. The DBpedia templates contain additional information/documentation about infoboxes, which can help to improve the quality of Wikipedia (e.g. one could add preferred names for attributes like birth_place in Metawiki -- of course this would have to be discussed separately first). Jens Lehmann (talk) 08:02, 9 November 2009 (UTC)[reply]

Question - is there an estimate as to how many pages would need to be edited to support this? Mr.Z-man 02:12, 9 November 2009 (UTC)[reply]

When they did their edits, they edited roughly 300-400 infobox doc pages, creating some where they didn't exist. Doing a rough search, if the goal was to do this to every infobox on Wikipedia, then roughly 11,000[3]-- Collectonian (talk · contribs) 02:31, 9 November 2009 (UTC)[reply]

The search query above is not very useful. A few thousand results may be actual infoboxes, but the 11000 results also contain all sub-pages [4] and thousands of other templates [5]. DBpedia currently uses about 400 infobox templates [6]. Chrisahn (talk) 03:14, 9 November 2009 (UTC)[reply]

Support in principle, though with some reservations about method. On the face of it this seems a very sensible approach to making the information in Wikipedia more widely re-usable and for placing control over the details of mapping with the editors of wikipedia. older ≠ wiser 03:33, 9 November 2009 (UTC)[reply]
Support I think we should put the "damage" (if at all it should be called like this) in relation to the benefit: As I understood, one of the primary goals of Wikipedia is to improve quality, consistency and coherence. Currently, it is quite difficult and troublesome to identify factual inconsistencies (such as outdated population figures, conflicting birth days etc.) in Wikipedia. The suggested annotations of infoboxes would greatly help Wikipedia authors to identify such inconsistencies, since they e.g. connect the attribute born used in one template with birthday in another. In the short term, this will be a very powerful instrument for Wikipedia authors to cross check information on a large number of pages, in the medium-term this can evolve into more advanced search and querying interfaces and in the long-term establish Wikipedia as a central hub on the emerging Semantic Web. From my point of view, it would be very sad if this opportunities would pass because we object some minor annotations on a few hundred templates. --Soeren1611 (talk) 10:35, 9 November 2009 (UTC) (member of DBpedia)[reply]
Oppose Sounds like an intriguing idea, but I think, just like other outside projects that want to use Wikipedia's data, this particular project shouldn't be given any special treatment. I'm sure many projects would love to add code to our pages to make things easier for themselves; but we don't allow that, as far as I'm aware, and I don't see any special reason to allow it in this instance. I'm also concerned about the methods these people originally used, which causes me to doubt their future judgment. While we're at it, on a slightly less-relevant note, I'm not all too thrilled with whichever Foundation people were involved in this. Allowing access to the live stream, and giving permission to do mass-alterations of templates, without a broad discussion, or even a notification to the community beforehand? This wasn't handled correctly, IMO. Equazcion (talk) 10:51, 9 Nov 2009 (UTC)

I think you still misunderstand a little: the annotations of templates we proposed are not simplifying anything for DBpedia, but they create the missing link between bornIn in one template and born-in in another. Establishing this link should be in primary the interest of Wikipedia itself and actually would benefit Wikipedians in the first place and any mining/extraction project as well. If you are offended by the mentioning of DBpedia in the annotations we are more than happy to downplay or remove them. --Soeren1611 (talk) 11:40, 9 November 2009 (UTC)[reply]

The issue of "simplifying" versus "making possible" is a semantic argument. You want to alter Wikipedia pages for the benefit of an outside project, which is not something we generally do, and I again see no special reason to allow it here. I don't think Wikipedia editors shouldn't have to deal with code purely meant to aid an external project. If your goal can't be accomplished externally, then I don't think it should be done. Perhaps a more fundamental change to MediaWiki or template practices might be something to look into, in order to streamline data and have the added benefit of making data more available to outside projects in general; but to add code to Wikipedia's pages just to aid a specific external project is out of the question in my mind. Equazcion (talk) 11:49, 9 Nov 2009 (UTC)

If I read the previous discussion correctly, nobody gave them permission to do any alterations on English Wikipedia. Svick (talk) 11:55, 9 November 2009 (UTC)[reply]

One could view the project as providing an RDF view on Wikipedia, which is somehow related to Microformats already present in the doc subpages of infoboxes. In this sense, the annotations could be used by other projects as well. We could remove the references to DBpedia (although it is an open source, non-commercial project) and instead refer to RDF/OWL as Semantic Web standards. This way, the annotations would not be project dependant. (A disadvantage would be that it is harder for Wikipedia/DBpedia users to make the connection to DBpedia, which is a known project in the Semantic Web.) Jens Lehmann (talk) 12:42, 9 November 2009 (UTC)[reply]

Microformats are not in the doc page btw. They are integral parts of the Infoboxes and article content themselves. —TheDJ (talk • contribs) 14:52, 9 November 2009 (UTC)[reply]

Weak Support It would be nice, if all infoboxes used the same parameter names for parameters with the same meaning. Then, this discussion would be pointless, as DBpedia wouldn't need any additional information. But, unfortunatelly, this isn't the case and it doesn't seem that this would change in the forseeable future. So, we could create some standard, how to tell scrapers, what the parameters mean (similar to microformats, only for Wikicode). If this standard was managed by the Wikipedia community (maybe on Meta?), I would support it.
One of the problems I had with the templates DBpedia was adding, was that they were visually quite big and contained big DBpedia logo. If this template was hidden by default and didn't contain the logo, it would be much more acceptable for me. Svick (talk) 12:15, 9 November 2009 (UTC)[reply]

In previous discussions, we also concluded that Meta is probably the appropriate place for this. Properties like birthPlace and classes like Person have partially been added to Meta already. (There have been discussion with admins on Meta regarding the additions of those pages.) A significant amount of work has been done in the background such that we would be able to provide an initial version covering a number of imported infoboxes, which would then simplify further contributions from Wikipedians. Regarding the visual appearance, I think it is no problem to reduce the template size and remove the logo / replace it by a small icon (or even remove any reference to DBpedia if that is desired). Jens Lehmann (talk) 12:27, 9 November 2009 (UTC)[reply]

Comment, hmm, too bad they started adding without discussing with the community... That said, I love a more standardized approach towards the data in Wikipedia; however:

The method used should be a well defined standard, so that others can easily use the information as well.
If it is a standard, there is no need to spam dbpedia name around with templates
If possible, I prefer data functionality in the software core, over externalizing it. There are 2 ways, either this current approach becomes so popular that we NEED to implement it in the core, or because this works, no one will ever implement it in the core. I'm not sure which of the two is more likely. Then again, waiting out for "magic" to happen might not be the best alternative either.
There are two general accepted methods of implementing this. The first one is parameter mapping, like proposed here, the other one is microformats. Since we already implement many microformats, I'm not sure if it is a good idea to both. I understand the reason for making hard matches like dbpedia is proposing. It is a simpler method of "scraping" the data into their database. However ease of use for the database developers might not be the best basis for a decision on how WE can best present data in our project.

All in all, i want to see more, discuss more and think more about this. I welcome new developments, but we should consider what the en.wp endgoal should be. —TheDJ (talk • contribs) 14:43, 9 November 2009 (UTC)[reply]

Oppose. Wikipedia is a standalone project that should not have any external dependencies, entanglements, or implied endorsements. The question of whether this arrangement benefits DBpedia is irrelevant, because any such arrangement with any external entity is a negative for Wikipedia. Bear in mind, I support reusing our content according to the license, and if there are technical barriers that make reuse difficult, or that simply prevent it from being easy, then I support removing those barriers. That is to say, if DBpedia makes a case for rationalizing infobox features to help others reuse their contents, I would absolutely support doing so wherever it doesn't conflict with editability. I can't support this current use of Wikipedia's resources, however. — Gavia immer (talk) 16:23, 9 November 2009 (UTC)[reply]

any such arrangement with any external entity is a negative for Wikipedia? Jimmy Wales begs to differ... :-) Here are some examples of Wikipedia endorsing / cooperating with external projects:

Jimmy Wales announces cooperation between KDE Group and Wikimedia [7] [8]
Wikipedia alliance with Library of Congress and USHMM [9]
Jimmy Wales Announces $100 Laptop Partnership [10]
Wikipedia and Yahoo announce alliance [11]
Orange and Wikimedia announce partnership [12]
efforts to bring OpenStreetMap and Wikipedia closer together - Wikimedia Deutschland are providing funds of 15.000 Euro [13]

Chrisahn (talk) 17:33, 9 November 2009 (UTC)[reply]

Those are Foundation arrangements that don't affect on-wiki activity for editors. This is a very different sort of proposal. Equazcion (talk) 17:32, 9 Nov 2009 (UTC)

Yes, but all of those projects were developed outside of Wikipedia. None of them had to place their information on this website in order to make it work. TNXMan 17:40, 9 November 2009 (UTC)[reply]

Again: these templates do not make it work (they actually make life harder for DBpedia developers), they allow Wikipedians to control DBpedia (and one of DBpedias goals is to help and improve Wikipedia, as stated above). Chrisahn (talk) 18:18, 9 November 2009 (UTC)[reply]

That's twisted reasoning. There would be nothing to control if the code wasn't there. DBpedia would only work according to your vision if the code is in the templates. Therefore, the templates make it DBpedia work like you want it to. Consequently, our changes to the data in the templates would then affect your available data; but that does not then mean you can decide that this is a worthy benefit to us. Honestly, that's like attaching an ankle monitor to someone and telling him "Look, you now have the control to make my detector beep!" An extreme example, I know, but you get the general idea. Don't twist this around. You need the template code there in order to make your DBpedia work according to plan. Equazcion (talk) 23:42, 9 Nov 2009 (UTC)

No-brainer support. The goal of Wikimedia is to make knowledge freely available. We should make any reasonable accommodations we can to allow third-party sites to use our data as efficiently as possible. The proposed modifications don't interfere with the normal operation of Wikipedia in any way, and make it easier for computer programs to use Wikipedia data in a more structured format. It should be made clear, of course, that we don't specifically endorse DBpedia here, we're just trying to make our data more easily machine-readable in general, and DBpedia can provide useful help with that given their experience. —Simetrical (talk • contribs) 16:44, 9 November 2009 (UTC)[reply]

Comment Just want to clarify my position. I would absolutely be in favor of an effort to streamline template data for use by external projects (not to mention Wikipedia tools), as Svick describes above. I think he hit the nail on the head rather nicely. I just can't say I support the current proposal, to allow code that's just intended to help a specific external project; I think that would be a step in the wrong direction. Equazcion (talk) 17:41, 9 Nov 2009 (UTC)
Weak support - Ideally, things like template parameters would be stored in the database as part of MediaWiki, but we don't have that yet and its probably not coming especially soon. But I agree with TheDJ that if we do this, it should be with some well-documented standard, and not something specifically designed for DBpedia. Mr.Z-man 17:55, 9 November 2009 (UTC)[reply]
Oppose this implementation. I think that I support the underlying idea here (from what little of it I understand), but this implementation is just bad. The initial activity in beginning the implementation was obviously problematic, which I think everyone realizes now was a small mistake, but that's not my main concern. The main issue is that this should be implemented through a back end addition to the underlying software, with either a separate api or additions to the mediawiki api in order to access it. That may be difficult to accomplish, but difficulty is no excuse for using shortcuts. I don't understand how the idea to implement this through additions to the article space itself (through doc sub-pages, apparently) gained traction in the first place, since that content is so easily editable... this implementation is just bad for everyone.
— V = I * R (talk to Ω) 19:04, 9 November 2009 (UTC)[reply]

There was already an approach which demanded more servere changes to Mediawiki - called Semantic MediaWiki. Deployment of SMW on Wikipedia failed because the changes would have unpredictable effects the performance. Of course it would be nice if the template annotation approach would ultimately be supported by MediaWiki, but this can be easily achieved in incremental steps starting with the approach we proposed. --Soeren1611 (talk) 22:27, 9 November 2009 (UTC)[reply]

The fix the issue(s) with "Semantic MediaWiki". This reply simply reinforces my view that there is an attempt being made here to make an end-run around implementing this correctly, simply because doing so would be difficult. This is hurting both the English Wikipedia and the DBpedia project more then it's helping anything.
— V = I * R (talk to Ω) 23:00, 9 November 2009 (UTC)[reply]

Deployment of SMW has not "failed." It hasn't yet been installed due to unknown effects on performance but it is at most stalled due to lack of manpower to review SMW's giant codebase. It certainly has not been abandoned as an option. Mr.Z-man 23:46, 9 November 2009 (UTC)[reply]

So deployment of SWM has stalled, since the perceived benefits obviously do not yet justify the required efforts. That's exactly why the much less invasive template annotation approach is so important: Once it shows that semantic annotations make sense in Wikipedia and demonstrates the benefit to ordinary Wikipedians a deployment of SMW becomes much more realistic in the medium term. Actually, the DBpedia template annotation approach and SWM would work very well together: DBpedia template annotations create a critical mass of semantic content and with SWM finer semantic representations can be added directly within the Wiki texts. So you don't have to decide between one or the other - both together will be the winning team! --Soeren1611 (talk) 09:24, 10 November 2009 (UTC)[reply]

Comment/(basically Oppose) To put it simply, WP:NOTWEBHOST. Yes, these templates may affect nothing. Yes, they make make things easier for WP users who chose to make use of DBPedia. But all said and done, any extra data in WP itself that's not being used FOR WP itself goes against policy. And as others said -- it's a slippery slope. If we allow DBPedia's code, we would have to allow anyone else who feels like adding this kind of thing. It's just...not a good idea. ♫ Melodia Chaconne ♫ (talk) 19:15, 9 November 2009 (UTC)[reply]
Support. I think most of the opposition is based on a few minor misunderstandings (much of it due to arguing over semantics with these people who speak English as a second language). I Support per the reasoning given by Simetrical and older ≠ wiser and Svick particularly. -- Quiddity (talk) 19:46, 9 November 2009 (UTC)[reply]
- I think most people support the idea, but I also think that most people are not yet convinced about the technical implementation. It is the responsibility of the dbpedia people to convince us that this is the right way to do it, and it is our responsibility to be vigilant, investigate and eventually approve/disapprove. That process has been skipped, and it needs to take place. —TheDJ (talk • contribs) 19:57, 9 November 2009 (UTC)[reply]
  - I think that's right (if I understand you correctly): several steps have been skipped here. It's probably a good idea to have a general discussion about how to make Wikipedia easier to extract data from, and to develop ways that actually do that. DBpedia may figure strongly in that discussion as a lead example of a data extractor, but I don't think it's a good idea to basically let them do what they think is best within Wikipedia to facilitate their objectives, regardless of how those objectives fit with ours. Rd232 ^talk 20:40, 9 November 2009 (UTC)[reply]
Support Opposition is based on the idea that it is not good to make Wikipedia as accessible as possible to outside users just because the direct wikipedia editors who will be contributing, might not see a direct benefit from it. Why should wikipedia restrict itself to users who access the site using http://en.wikipedia.org/. The idea about not being a web host is just to restrict people using wikipedia as their website. Incase you didn't look, the DBpedia project runs a very big website itself. It is funny that people refer to the use of Wikipedia's resources as if they know exactly how many watt hours are being spent in computer processor usage in this effort, and the expense is not worth the benefit to the editors here so it should be scrapped. Readers won't notice it either way, so it is only editors that are really feeling left alone. Slippery slope or not, the ultimate goal of wikipedia should be emphasising the benefits of free content, not trying to make it look like wikipedia is a big data silo that you can copy verbatim but you can only try to do extra things after you fork the project temporarily. Dbpedia has done that so far, but they thought it would be a useful idea to have the people who know how the infoboxes are designed actually have expert input into the process. Maybe that was the wrong thing to do, maybe not. For what it is worth, a common idea in free content that your only real right is to fork is a bit limited if the ultimate goal is to benefit as many people as possible with the data. Why is this discussion so completely tied up about the idea of Wikipedia being an entity that has to protect itself from outside influences as if free content was designed to be a closed box.
For what it is worth, the example I saw of the annotations was clear to me, but it might be good for more people to debate alternatives here instead of having a simple vote where some people who would otherwise support have only provided limited summaries for why they have opposed the implementation of the idea. The idea of having this information put into the MediaWiki core is a pipe dream btw. *Everything* in MediaWiki is done using wikitext of some form, why would template annotations be an area that should be only able to be done some other way? Ansell 21:02, 9 November 2009 (UTC)
Ansell, I don't think anyone it's saying it's not good to make WP as accesible as possible, but rather adding stuff to WP for the express purpose of helping out one entity is an antithesis to what WP is about. In other words, DBPedia is free to make use of WP's data all they want, but they aren't free to chage WP just for their own sake, any more than a user is allowed to use their user page as a personal website. Then again, maybe I'm missing something in the entire discussion... ♫ Melodia Chaconne ♫ (talk) 21:16, 9 November 2009 (UTC)[reply]
Oppose this particular implementation per TheDJ and TheDJ's reply to Quiddity, but I think we're doing a terrible job of explaining our message to the DBpedia people, who are only here to help. Here's the message: you're at least the 10000th organization that wants to add your logo somewhere on en.wikipedia in recognition of your special contributions, and at least 100th that claims or suggests that you have the blessing of the Wikimedia Foundation (if we include sister sites) ... so I totally understand your confusion at what seems like a harsh response, but it would be hypocritical of us to allow you to add your logo and claim a special relationship with DBpedia when we've denied that recognition to every other organization, including in many cases other Foundation sites. However, don't give up hope ... it's not out of the question that the DBpedia name will get wider recognition around Wikipedia over time, but if it's going to happen, it will take a long time and a lot of work, and it's never going to happen that we display your logo on Wikipedia pages (other than at DBpedia) or mention your website in a prominent way. Start off slowly; get involved in discussions about standardizing the language in infoboxes and make the case that this adds semantic value to Wikipedia pages. When people don't want to standardize language, there are many options for hidden tags that could accomplish the same standardization; a simple one would be {{anchor}}, which would have the advantage of letting us treat the metadata as a section link. - Dank (push to talk) 21:08, 9 November 2009 (UTC)[reply]

Its very disappointing that so many of you think the primary interest of DBpedia is to get its logo on Wikipedia or act in its own interest. So far, we thought of ourselfs more of being part of Wikipedia. Most of the issues raised here are easy to solve: We already removed the DBpedia logo from the template annotation template and removing DBpedia from its name is easy. We will try to draft a more comprehensive proposal and explanations. The resulting template annotations will benefit everybody - extraction projects as well as ordinary Wikipedia authors alike. --Soeren1611 (talk) 22:08, 9 November 2009 (UTC)[reply]

Thanks for your explanations and encouragement. We already removed the logo and we can also remove any reference to DBpedia and instead e.g. emphasize the role of RDF and OWL as W3C standards instead, so that DBpedia is only one specific implementation using the annotations. Promoting DBpedia was not a goal in this effort. We will use all input in the discussion so far and create a new proposal soon including explanations how we, as Wikipedians, can benefit. (I realize that Sören replied already, but leave the comment here.) Jens Lehmann (talk) 22:30, 9 November 2009 (UTC)[reply]

As I said, I think you guys are here for the right reasons, and thanks for understanding our strange ways. It sounds like you're on the right path. - Dank (push to talk) 23:51, 9 November 2009 (UTC)[reply]

Weak Oppose I love what DBpedia is trying to do in making structured Wikipedia data machine-readable and queryable, but I share concerns about this not being the right implementation. It should be done in a more integrated fashion; MediaWiki really needs better support for structured/tabular data, which would both make editing and verifying the data easier for us and extracting the data easier for DBpedia and others like it. Any implementation should not be DBpedia-specific (although they and those like them certainly would be worth consulting on any implementation); Non-mainspace non-Wikimedia-related content does not belong on Wikipedia; no playing favorites (not that DBpedia is evil/commerical/monopolistic or anything like that, it's just the "sacred" principle of independence and neutrality we run on)]. For the time being, such mappings belong firmly on DBpedia. Software support would be a good request to make in the strategic planning process: WP:STRATEGY --Cybercobra (talk) 23:08, 9 November 2009 (UTC)[reply]

Besides two things (the logo and the references to DBpedia), which are easy to change the implementation is not at DBpedia specific. Everybody would benefit, if the link between synonymous template attributes would be established. Please also see my comment responding to Mr. above: once we can show the benefit of this minimally invasive solution it can be incrementally refined into a more advanced approach later - we were working on and discussing this strategy for more than a year. In particular a combination with SWM would make much sense in the medium to long term. --Soeren1611 (talk) 10:28, 10 November 2009 (UTC)[reply]

There is a new draft available, please comment/modify here: Wikipedia:Requests_for_comment/infobox_template_coherence SebastianHellmann (talk) 11:49, 12 November 2009 (UTC) Change to proposal There seems to be some support for the general method of providing a template-based Semantic Mapping of infoboxes, which can be useful to extraction approaches. There also seems consensus that the template we created with the logo and links will not be accepted. Most of the opinions on this page disagree with the current form of the template, so we propose a new one for discussion, that tries to generalize the approach (and does not contain any mention of DBpedia or any other approach whatsoever). As an alternative approach implementation in the core of the system was mentioned. We propose a way, that does not involve any development effort for MediaWiki, but only for external applications and also does not cause extensive restructuring as in the case of e.g. Microformats, which require Template changes and propagation of modifications to possibly thousands of articles.[reply]

Here is the basic outline:

a template will be created at Template:Template_annotation
there will be three basic operations for infobox properties:
- map one to one (e.g. bornIn can be mapped to birthplace) realized by Template:Template_property
- split properties (born containing birthplace and date can be split into two), Template:Template_property can be reused.
- merge properties (geocoordinates are often scrambled accross the whole infobox, sometimes using 6 properties) at Template:Template_merge_property
there will be a vocabulary, i.e. a list of terms or words to basically tell the parsers how to extract the data in each of the 3 scenarios above. The list will be kept somewhere (any ideas?) and properly documented. Some initial "parsehints": date, links, text, geocoordinate, hierarchy, currency(euro, dollar), units(km, cm, kg, g, stone).
we made some good experience with mapping several infoboxes to a common class or category, i.e. Template:infobox_mass_town_govt and Template:infobox_israel_municipality could both be mapped to a class "City"
some requirements:
- the template should be as unobtrusive as possible, small, no logos, slim and (if possible) collapsible
- the template should contain clear guidelines and formulate the intent clearly

To make the discussion more concrete and not on an abstract level, we will create a mockup of the above mentioned pages and afterwards include them, filled with example values, at the end of the discussion on this page. The general purpose of these new templates will be to help extraction approaches extract cleaner data and also will allow Wikipedians to express how the data they entered in the articles should be interpreted and transformed by machines. Maybe, we can achieve consensus on how the template should look like and afterwards decide, where they shall be placed (if they are collapsed by default and only take up one line, the doc subpages might yet be adequate). SebastianHellmann (talk) 02:03, 10 November 2009 (UTC)[reply]

Hello Sebastian. I think it is better to create a more comprehensive and self-contained proposal first to make it easier for others to see the whole picture before people now start to comment/vote on your idea of a changed proposal. @core-Wikipedians: Would it be appropriate to create a page (e.g. "Wikipedia:Ontology") in the Wikipedia namespace belonging to category "Wikipedia_proposals"? Or is it better to develop the proposal elsewhere and then copy it here in a separate section? Jens Lehmann (talk) 06:53, 10 November 2009 (UTC)[reply]

Question - How does this relate to other consumers of Wikipedia templates who produce structured data? I know Freebase has been doing live extractions for years, but I imagine there are others as well. Is the intent for everyone to converge on a single set of annotations or each have their own? If a single set, how is consensus obtained? (directed here from DBpedia mailing list, so no account - sorry) 65.215.113.195 (talk) 05:01, 10 November 2009 (UTC)[reply]

As mentioned above, we plan a proposal update which is not DBpedia specific. The common ground should still be the W3C Semantic Web specifications (RDF and OWL). It is very likely that Freebase can and will make use of the annotations as well in this case. Consensus would be obtained by the standard processes in Wikipedia, i.e. Wikipedians decide how to annotate the data. (The DBpedia project can, however, provide an initial version, which we already developed and tested over the past year.) I would opt for a single annotation template per infobox. Apart from the overhead required for multiple annotations, it is also quite clear from the discussion above that annotations, which are specific to a commercial company like Freebase, probably won't find support. Jens Lehmann (talk) 07:22, 10 November 2009 (UTC)[reply]

break

I recommend drawing this thread to a close, it's getting a bit TLDR, and there seems to be agreement on taking a step back and talking about how to do data extraction generally, agreement on which would ultimately meet DBpedia's objectives but be designed with a wider audience in mind. I suggest starting a Request for Comment: WP:Requests for comment/data extraction. Sebastian could introduce his changed proposal there, but it might be better for a non-DBpedian to formulate the RFC. Rd232 ^talk 10:56, 10 November 2009 (UTC)[reply]

Yeah for instance, i'm not so convinced that adding this to /doc is any better than adding it as microformats to the infoboxes themselves. I understand that "disruption" to the english wikipedia was one of the factors that was taken into consideration when choosing this implementation. There is nothing wrong however, with making changes to many infoboxes if this improves Wikipedia. The templates in their current form are not sacred, and although it would be annoying to make changes to so many templates, i'm not against it per say. There is nothing wrong with a disruptive approach, if it is the best approach our money and effort can buy us at this moment in time. —TheDJ (talk • contribs) 13:57, 10 November 2009 (UTC)[reply]

It should be stable before being disruptive, there could be a lot of argument about whether Prime Minister is an occupation or an office, also classes and a hierarchy can be disputable. So this approach could be seen as a requirement engineering and also produce a stable version, which can be used to disruptively edit template definitions. I agree to your break, there will be another page soon, which will have a clear proposal to discuss SebastianHellmann (talk) 16:14, 10 November 2009 (UTC)[reply]

Following your suggestion, an RFC draft for the topic was created. Please edit and/or comment on the page. We took the discussion input into account and tried to address the issues mentioned. We also made the page mostly self-contained such that everyone can comment without needing to read the entire discussion leading up to the RFC. I hope this is in line with the standard Wikipedia processes for reaching consensus. Otherwise, moderation from an admin would be welcome. Jens Lehmann (talk) 14:42, 11 November 2009 (UTC)[reply]

Could this be delt with through DBpedia coming up with a standard, publishing an IETF style RFC and then us considering if it is something we want to adopt?©Geni 23:41, 11 November 2009 (UTC)[reply]

Category:Redirects

Yes, it exists... It's unsustainable though, so there's no real point in having it... except if the category is automatically added by the software. This seems possible, since it's done for example with Category:Noindexed pages. But it should be only for redirects in mainspace; or there should be a category of redirects for each namespace. So, do you think we should request this at bugzilla, for the mainspace at least ? Cenarium (talk) 00:02, 9 November 2009 (UTC)[reply]

I think a new special page (Special:Allredirects) or just a checkbox on Special:Allpages would be better. Mr.Z-man 03:51, 9 November 2009 (UTC)[reply]

Why do we need this at all? It seems to be categorization for categorization's sake (and a special page would be equally pointless, as far as I can see). But if people have some use for it, then the special page seems more in line with what the software normally does than an automatically generated category.--Kotniski (talk) 07:52, 9 November 2009 (UTC)[reply]

I personally don't see the point of such a category, too; though I expect some people might find it useful since it's been created. Special:Allpages should definitely have a way to exclude redirects, and also exclude non-redirects. Cenarium (talk) 18:55, 9 November 2009 (UTC)[reply]

One of the purposes is to keep track of the different kinds of redirects, including Category:Unprintworthy redirects, Category:Protected redirects and Category:Wikipedia soft redirects, all important information to have. Also, as far as I can tell, it is well-maintained. It is automatically populating the root category that would be unmanageable and of no use. OrangeDog (τ • ε) 20:16, 9 November 2009 (UTC)[reply]

The category page even states that the category contains only categories and pages about redirects, and should not contain any redirects themselves. But 953 of the 1046 pages in the category at the moment are redirects. I could easily enough run a bot over the category to remove "[[Category:Redirects]]" from all those redirects and then repeat periodically to keep it clean, if there's consensus to do that. Anomie ⚔ 22:08, 9 November 2009 (UTC)[reply]

Well, I'd be in favour.--Kotniski (talk) 09:42, 10 November 2009 (UTC)[reply]

They should be removed regardless of an an automatic categorization, manually it's untenable. Cenarium (talk) 04:28, 11 November 2009 (UTC)[reply]

I nominated for deletion the stunning Category:Uncategorized redirects. Cenarium (talk) 00:38, 15 November 2009 (UTC)[reply]

I have found some advantages in an automatic categorization of redirects though: we can see recent changes to redirects, on the category page it provides a link for new/inexperienced users who are often confused by them, and if Template:Bug is resolved, we'll be able to know if a page is a redirect in the interface (so editnotice for redirects, useful for new users). Cenarium (talk) 04:28, 11 November 2009 (UTC)[reply]

So in light of this, shouldn't we request this ? Cenarium (forever) 16:25, 13 November 2009 (UTC)[reply]

Deletion stats

What percentage of all the articles created by: a. Non-autoconfirmed registered users b. Auto-confirmed registered users get deleted via: 1. speedy deletion, 2. proposed deletion and 3. articles for deletion? Fences&Windows 00:14, 9 November 2009 (UTC)[reply]

Multimedia Paris meeting

As some of you may know, there was a meeting in Paris last week to discuss/brainstorm/develop around all things Multimedia in the Wikipedia sphere. A summary of this can be read on the usability wiki. It at least saw the deployment of the Global Usage extension, something welcomed by many I presume. Another important element was a demo of the first forays into subtitling support. —TheDJ (talk • contribs) 20:04, 9 November 2009 (UTC)[reply]

GlobalUsage has been disabled. Relevant bug: bugzilla:18059. --MZMcBride (talk) 01:59, 10 November 2009 (UTC)[reply]

Bot editing while logged out

FYI, 91.198.174.201 (talk · contribs · WHOIS) is a bot editing while logged out. Mentioning here first rather than blocking. Thanks. Wknight94 ^talk 20:26, 9 November 2009 (UTC)[reply]

Whose bot is it? You should probably discuss it with the botop. Intelligentsium 01:34, 10 November 2009 (UTC)[reply]

No idea. How do you tell? Wknight94 ^talk 01:41, 10 November 2009 (UTC)[reply]

That is the Toolserver IP, please DO NOT block it as you will take down dozens of bots. MBisanz ^talk 01:44, 10 November 2009 (UTC)[reply]

The bot is one of the HBC AIV helperbots. I have no way to know which one it is. I think it is not a terrible thing if it edits while logged out, not ideal but it is still being helpful and causing no harm. Even though I don't know which one it is(we have something like 5 copies running) they all run off the same source code. I will look through that code to see how it handles staying logged in. Chillum 01:47, 10 November 2009 (UTC)[reply]

According to the current source code it does not detect if it has logged out or not, but it does log in regardless of if it is needed every hour. So if it does get logged out somehow it will last less than 1 hour. In other words if you ignore the problem it will go away. Chillum 01:50, 10 November 2009 (UTC)[reply]

I thought we had the Toolserver IPs blocked from editing anonymously.... If not, it should probably be done. All bots running on the Toolserver are required to run logged in (cf. tswiki:Rules). --MZMcBride (talk) 01:51, 10 November 2009 (UTC)[reply]

To be frank, that is how I handle the IP of the server I run my bots from. I used the same framework of the name watcher bot, and dustabot, that I used for AIV Helperbot. Thus they all suffer from the same log-out issue(I really should fix that one of these days). I block the IP of my server(anon only) 1 year at a time . The IP in indefinitely under my control and if I ever give it up I can remove the block first. I see no reason why the toolserver would ever need to edit anonymously, however perhaps a message to the mailing list would be a good idea just to make sure it will no break anything. Chillum 01:55, 10 November 2009 (UTC)[reply]

It's almost trivial to prevent a bot from editing anonymously: just add "assert=user" to the POST that submits the edit and it will error out if the bot isn't logged in. Anomie ⚔ 03:12, 10 November 2009 (UTC)[reply]

Shouldn't it be "assert=bot" since my understanding is that all editing bots on en.wp have to be approved and get the bot bit? and why are their five versions of that bot running at the moment? Peachey88 ^{(Talk Page · Contribs)} 00:21, 11 November 2009 (UTC)[reply]

Yes, assert=bot would be preferable in general, but the question here was just about preventing a bot from editing while not logged in. Anomie ⚔ 01:48, 11 November 2009 (UTC)[reply]

Blocking anonymous edits from the Toolserver screws up some tools and disables read-only pywikipedia bots without an account. — Dispenser 13:37, 10 November 2009 (UTC)[reply]

Why would a read-only bot need to make edits? OrangeDog (τ • ε) 18:50, 10 November 2009 (UTC)[reply]

They don't, but pywikipedia quits as soon as it detects a block. — Dispenser 20:17, 10 November 2009 (UTC)[reply]

Sounds like a reason to fix pywikipedia. --MZMcBride (talk) 00:31, 11 November 2009 (UTC)[reply]

Functions

Clicking on the back button on the browser shouldn't reset the number of revisions displayed or the position of the radio buttons. Report to bugzilla.174.3.111.148 (talk) 01:46, 10 November 2009 (UTC)[reply]

This must be something your browser does. Mine doesn't. PrimeHunter (talk) 01:57, 10 November 2009 (UTC)[reply]

I think Internet Explorer 7 does that. Not sure about Internet Explorer 8. Wknight94 ^talk 03:21, 10 November 2009 (UTC)[reply]

Resetting form data when you click "back" is a hallmark feature of Internet Explorer. I'm not aware of any other modern browser that does it. --Carnildo (talk) 02:27, 11 November 2009 (UTC)[reply]

New "scientific refs" for Wikipedia

Article view when script SciRefs is running. Demo page - http://ru.great.wikia.com/wiki/Zinc

I wrote a new script for Wikipedia which replaces tags "ref". My script implements in the scientific (Harvard) style, but it is also compatible with tag "ref" and other markup.

Here are some examples of how my script is used:

[name] - is link, e.g. [Smith 2009] or [Smith 2009| p.121]

[*name] - is an anchor, e.g. [*Smith 2009]

For compatibility reasons, an editor should insert the template {{SciRefsOn}} somewhere in the page to turn the script on.

Additional details (description with screenshoots) can be found here: http://en.wikipedia.org/wiki/User:X-romix/SciRefs

Demo Wiki with working realisation - is here: http://ru.great.wikia.com/wiki/Zinc

I would like to help make Wikipedia more user-friendly. When using this script, backlinks may be accessed via the "Back" button in the browser or the backspace key on the keyboard. This backlink will be highlighted.

This reference style is simpler than the current convention, and it corresponds to the scientific standard (author-date Harvard referencing system).[14]

Jimbo Wales commented on my work the following way: I strongly support making refs easier to read and easier to use. You might want to pass this along to the usability team?--Jimbo Wales (talk) 22:32, 5 November 2009 (UTC) [15][reply]

X-romix (talk) 12:04, 10 November 2009 (UTC)[reply]

I have some smaller problems with your proposal (I find the long notes ugly; it will break many articles that contain some text in square brackets; showing the pipe character before page is also ugly) and one HUGE problem: it requires JavaScript to work – it doesn't work AT ALL without it. I also don't see what your proposal tries to solve: The Back button already works, some articles use the Harvard style (see e.g. Albert Speer) and I don't think that <ref>{{harvnb|Smith|2009}}</ref> clutters the article that much. Svick (talk) 19:59, 10 November 2009 (UTC)[reply]

JavaScript is one of possible implementations. Another possible realisation - in PHP. Please note, that problem with square brackets is not exist: there is switcher template {{SciRefsOn}} to turn script on (default state - it switched off), and there is no effect if you want to write something, e.g. [xxx] without pair tag [*xxx]. You can test this cases here. Note, that button back in current ref implementation already works, but backlink is not highlighted. It is difficult to user to return on his reading point by eyes. X-romix (talk) 21:27, 10 November 2009 (UTC)[reply]

Stop: Was using this proposed or discussed anywhere before hand? I have a real problem with this, for all of the reasons that Svick mentions. Besides, you know that something is on the wrong track when the proposer is invoking the name of Jimbo or the Foundation... I admire the clear thought in trying to improve the encyclopedia, but this is the wrong way to go about things.
— V = I * R (talk to Ω) 21:00, 10 November 2009 (UTC)[reply]

Script do not take any effect if there is not required tag pair [xxx] and [*xxx] where xxx - is equal sequences (labels). In known for me articles [*...] sequences is not exists, but I use a switcher {{SciRefsOn}} (default it is off) for precaution as shown above. Proposing is discussed in the Russian blog ru_wikipedia. Working test article you can see on the references above. You can edit the test article http://ru.great.wikia.com/wiki/Zinc if you want to test the script and the markup (I've unprotect it). X-romix (talk) 21:44, 10 November 2009 (UTC)[reply]

I think this is just a solution looking for a problem. The caret (^) by every footnote leads back to the note (this might be a problem if one note is used more than once, but then again, you proposed system is pretty much the same). Intelligentsium 21:47, 10 November 2009 (UTC)[reply]

Well, it seems his solution does solve this problem – if you have more notes that point to the same footnote, his script aparently remembers which one you clicked and returns you to it when you click to the equivalent of caret in that system. But this couldn't be done without JS (as he said that this could be done in PHP too). Svick (talk) 22:03, 10 November 2009 (UTC)[reply]

There is not problem to reproduce usual format of backlinks. Highlighting can be writed only in JavaScript, but this is an optional extra. I can mix both PHP and JavaScript to make most convenient refs. X-romix (talk) 22:21, 10 November 2009 (UTC)[reply]

Main purpose of using square bracket links - is move book descriptions to the end of the article, and make book references (with page numbers) more simple and intuitive to the author. <ref>{{harvnb|Smith|2009}}</ref> is a good idea, but why not write [Smith 2009] in body of the article and [*Smith 2009] labels in biblbograhy section? There is not incompatibles anyway as shown above. X-romix (talk) 22:45, 10 November 2009 (UTC)[reply]

Labeling refs?

I think the specific implementation being proposed above is ultimately a non-starter (requires Javascript for starters), but I'd like to ask about the general issue of labeling. Would people like / appreciate the option of replacing the ^[1] with a more informative label, e.g. ^{[Johnson, 1905]}? It wouldn't be hard to add that option to the existing ref system in a way that is backwards compatible with the current system. Dragons flight (talk) 21:11, 10 November 2009 (UTC)[reply]

JavaScript implementation I can rewrite on PHP. Backward compatible there is in my realisation. You can use "ref" tag for footnotes, and mix it freely with "Harward" references to books and articles. And make refs from other refs. Footnotes and References - is different things! For example, you can use ref to any book from the footnotes, and footnotes from the refs. X-romix (talk) 22:03, 10 November 2009 (UTC)[reply]

We can already use ref to create separate footnotes and references. They can be placed in different sections by using the group attribute of the ref tag. Dragons flight (talk) 23:05, 10 November 2009 (UTC)[reply]

Sometimes—depending the reason why I'm reading a topic—I'd like citations to be handled differently, e.g. using ^{[Smith, 2008]}, or displaying the reference as a sidenote, or even in a javascript floating box when I hover over the citation anchor. But I wouldn't want the article's authors/editors to make that decision: it should be the reader's choice for a particular session. Ideally, I'd like to see a far more radical overhaul of the reference/citation model, storing all sources in a database (common to all languages) so the article author finds/creates the source in the database, adds citation-specific details (chapter, page, quote) to the article and leaves rendering to the user preferences. I need to think this through and write it up properly, but you see what I mean. BTW, your proposal to define reference names in the ==References== section is a step in the right direction. Thanks - Pointillist (talk) 22:31, 10 November 2009 (UTC)[reply]

Pssssttt, WP:LDR has been live for a while now. Dragons flight (talk) 22:54, 10 November 2009 (UTC)[reply]

I know! That was just to thank you for having made the original proposal :-) Pointillist (talk) 23:27, 10 November 2009 (UTC)[reply]

Yeah, one can think of more radical solutions, but I'm not sure how well one could sell them to the community. For example, I work on a wiki where all references exist in a separate Reference namespace, such that adding a citation to an article (assuming the reference already exists) only requires {{Reference:Harper and Block 1994}}. The corresponding Reference space entry then has a combination of include-able citation data and noinclude additional data such as a copy of the abstract and categories on the reference for organization.

Anyway, if someone wants to come up with a more radical solution, and can sell the community on it, then I am willing to work on such things. Dragons flight (talk) 23:00, 10 November 2009 (UTC)[reply]

Heathhunnicutt suggested a "sources in a database" approach back in 2007 but it didn't take off. To sell it to the entire community in one shot is a tall order, but success in a niche area could be a sufficient starting point. Active support from a major content provider (e.g. BBC, NYT, FT, Springer, Lexis etc) might be helpful, but that would be difficult for anonymous volunteers like us to organize. It would make all the difference if we could demonstrate a decent prototype, but it would probably take months to build one, and we all have other priorities in RL. - Pointillist (talk) 23:53, 10 November 2009 (UTC)[reply]

Everything here is already available through the use proper of the existing Cite.PHP extension. If you want to have more then ^[1] show up on a reference, then just use a group= parameter for the ref tag. For example: <ref group=Johnson name=1905>Page 10</ref> will produce references exactly as is being described here. Let's not reinvent the wheel. For example, see: Moon landing conspiracy theories
— V = I * R (talk to Ω) 22:50, 10 November 2009 (UTC)[reply]

The longer labels (that I personally don't prefer) are something completely different than the group parameter. Your solution won't produce ^{[Smith 2005]}, but ^{[Smith 1]}, would require lots of {{reflist}}s and would force the references to be grouped by author. So, implementing this wouldn't be reinventing the wheel at all. Svick (talk)

Please see how your test <ref group=Johnson name=1905>Page 10</ref> is works:

My tests is works better. X-romix (talk) 17:04, 11 November 2009 (UTC)[reply]

That's not the point of the group attribute though, it creates different reference groups such that each one requires a unique <reference group="foo"> or {{reflist|group=foo}}. It's meant for separating references from notes, not for labeling individual references. Dragons flight (talk) 22:52, 10 November 2009 (UTC)[reply]

If you look at how the group paramater is actually used you'll discover that your mistaken. That's why I included the link to an example article which uses the format being discussed.
— V = I * R (talk to Ω) 23:05, 10 November 2009 (UTC)[reply]

And they need 7 different calls to reflist to do what's on that page. I don't think anyone would go for having one reflist for every unique entry, which is what would be required in other to add a unique label to every entry. It also defeats the purpose of having built-in sorting functionality. As I said, the group attribute is not designed nor intended to label every reference (and a certainly hope no one uses it that way). Dragons flight (talk) 23:11, 10 November 2009 (UTC)[reply]

I don't understand where the "need 7 different calls to reflist" comment is coming from. I'm getting the distinct impression that I have no clue what is really being discused, here. :(
— V = I * R (talk to Ω) 23:37, 10 November 2009 (UTC)[reply]

Where is group= documented, anyway? - Pointillist (talk) 23:20, 10 November 2009 (UTC)[reply]

WP:CITE.
— V = I * R (talk to Ω) 23:38, 10 November 2009 (UTC)[reply]

Not if I search (FF 3.0.15) for the word "group" on the page. Can you be more specific? Pointillist (talk) 23:51, 10 November 2009 (UTC)[reply]

Try WP:FOOT and Help:Footnotes. Neither are very detailed, but they do mention it. Dragons flight (talk) 23:54, 10 November 2009 (UTC)[reply]

I'm not really sure what more could be documented, anyway. The group parameter only does one thing: placing references into a different grouping then the 0th one. Is there a specific question that you're wondering about?
— V = I * R (talk to Ω) 00:12, 11 November 2009 (UTC)[reply]

No, just trying to decide whether it is a useful approach. The Jane Austen example mentioned in WP:FOOT actually uses the {{Cref2}} technique which looks intricate and isn't widely used anyway. Thanks for asking, though. - Pointillist (talk) 00:33, 11 November 2009 (UTC)[reply]

The Jane Austen example brings up a corollary point to what I think I'm trying to get across here. I don't understand why {{Cref2}} is needed at all. I don't see any new utility to it's use which isn't available through using the group parameter.
— V = I * R (talk to Ω) 00:49, 11 November 2009 (UTC)[reply]

Don't ask me! - Pointillist (talk) 00:58, 11 November 2009 (UTC)[reply]

I think that most uses of {{ref}}, {{cref}}, {{cref2}}, {{scref}}, {{hcref}}, {{note}} and other variants can be replaced by the cite.php group feature. I suspect most uses were added before the group feature and continue to be proliferated because of a lack of knowledge of group. The only use for any of these is where a named reference is used so many times that the backlinks become unwieldy and ugly. It might be appropriate to start a separate discussion on merging and deprecating these templates. ---— Gadget850 (Ed) ^talk 01:02, 11 November 2009 (UTC)[reply]

Incorrect block status (+ a block request)

Looking at the user contribs for 24.109.207.40 (talk · contribs · WHOIS) brings up a notice that the user is blocked. Except they aren't. They were blocked for 6 months in September 2008, so their block expired months ago and they are now able to edit, as evidenced by their recent edits. I assume this notice is automatically added, but whatever calculates the status seems to be broken. If an admin could block the IP after this is fixed, that would be great - it is the main IP of Swamilive (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log). Thanks. Delicious carbuncle (talk) 18:21, 10 November 2009 (UTC)[reply]

Peculiar. Doesn't appear to be any range or global blocks in effect as far as I can tell... –xeno^talk 19:31, 10 November 2009 (UTC)[reply]

Well, it seems to be working as expected today (i.e. no block notice). I have no idea if my posting here prompted a fix somewhere or if this is a bug that occurs intermittently. I'll take the block request to ANI. Delicious carbuncle (talk) 18:49, 11 November 2009 (UTC)[reply]

Changing username ??

Will changing my username create any tecnical difficulties? --88.90.85.204 (talk) 19:28, 10 November 2009 (UTC)[reply]

Probably not, but the page you want is this one. TNXMan 19:31, 10 November 2009 (UTC)[reply]

Bug in feedback templates

I recently created the templates {{leave feedback}} and {{feedback link}}. There is a problem in {{feedback link}} (subsequently, in {{leave feedback}}) when the page (current or through {{{page}}}) contains spaces and Template:Feedback page/preload/page or Template:Feedback page/editnotice/page exists, for example {{feedback link|page=Wikipedia:Help desk}} returns Leave feedback (it breaks at the first FULLPAGENAMEE within ifexist). It works when page is url-encoded: {{feedback link|page=Wikipedia:Help_desk}} returns the expected Leave feedback. Any idea on how to solve this ? Thanks, Cenarium (talk) 04:40, 11 November 2009 (UTC)[reply]

Add {{urlencode:string}}? Rd232 ^talk 09:13, 11 November 2009 (UTC)[reply]

"Wikipedia Forever" banner / Change in link styles?

The new banner seems to have screwed up my CSS. Links are supposed to be underlined, but now are not. Sach (talk) 05:09, 11 November 2009 (UTC)[reply]

I've just had the "Wikipedia Forever" notice—which at first glance, by the way, looks like the work of a vandal—start to crop up on pages. In the process, my link style has gone from underline to non-underline. Checking my preferences shows that "Underline links" is (still) set to "Always". This may be just a coincidence, but can someone check the notice to ensure that it is not responsible for the formatting change? — Bellhalla (talk) 05:09, 11 November 2009 (UTC)[reply]

I agree on the look of the banner. I really thought a hacker got to us. That thing needs to be toned down, and the slogan is just all wrong. Equazcion (talk) 05:11, 11 Nov 2009 (UTC)

I was just about to post here with the same thing, as I'm showing the same behavior. (AKK DAMN EDIT CONFLICTS) ♫ Melodia Chaconne ♫ (talk) 05:13, 11 November 2009 (UTC)[reply]

(EC) Yeah, its something from the banner. I've left a note with Tomasz Finc. at Meta asking them to fix it...hopefully quickly. Ugh...this tiny font hurts my eyes.[16] -- Collectonian (talk · contribs) 05:12, 11 November 2009 (UTC)[reply]

I click on the banner and rien du tout, no matter where I click! Is this an IE problem, or just mine? Otherwise my pages look fine. Bielle (talk) 05:17, 11 November 2009 (UTC)[reply]

Its an IE problem. Totally borked and untested code from the looks of it. -- Collectonian (talk · contribs) 05:24, 11 November 2009 (UTC)[reply]

The banner's a bit screwy but the rest of the page looks pretty normal to me on IE 8. Which version are you using? Dragons flight (talk) 05:30, 11 November 2009 (UTC)[reply]

I'm seeing horrible changes in styling in Firefox 3 -- Collectonian (talk · contribs) 05:42, 11 November 2009 (UTC)[reply]

In FF 3, the underlines are gone, colors are wonky, and the fonts just appear off. Found the problem CSS and reported it. It looks like it is being looked into now. -- Collectonian (talk · contribs) 06:13, 11 November 2009 (UTC)[reply]

I can also confirm the same behavior in Opera 10 and Google Chrome. Nate • (chatter) 06:27, 11 November 2009 (UTC)[reply]

IE 7 Bielle (talk) 06:07, 11 November 2009 (UTC)[reply]

Voice your aesthetic concerns at Wikipedia:Village_pump_(proposals)#Abolish_the_silly_headers. Equazcion (talk) 05:28, 11 Nov 2009 (UTC)

Or at meta:Fundraising_2009/Launch_Feedback which also notes the CSS should be fixed RSN. TRS-80 (talk) 06:55, 11 November 2009 (UTC)[reply]

The linking issue should hopefully be resolved now (cf. this and this). --MZMcBride (talk) 07:17, 11 November 2009 (UTC)[reply]

The link still doesn't work when I hit it in IE8 - Kingpin¹³ (talk) 08:47, 11 November 2009 (UTC)[reply]

Ahh, it does work, but not when you pres the text, which is what you'd expect to be the link... - Kingpin¹³ (talk) 09:07, 11 November 2009 (UTC)[reply]

Twinkle stalling

Multiple users - myself included - are reporting that Twinkle is stalling during tagging. Any issues? 7 02:03, 12 November 2009 (UTC)[reply]

Also, I'm receiving the message "Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server" when trying to "restore this version" when comparing diffs. Undo and rollback seem to be working Declan Clam (talk) 02:09, 12 November 2009 (UTC)[reply]

Seems like its everybody since no (TW)s show up in recent changes. Friendly is also not working, but HotCat and Popups seem fine. I still see (HG)s in recent changes, so I guess Huggle is fine. Any other tools broken? --Suffusion of Yellow (talk) 03:02, 12 November 2009 (UTC)[reply]

This was due to an experimental switch to an HTML5 doctype last night. It turns out this breaks magical behavior in browsers, which only support named entities in XML for a small fixed list of doctypes. The switch was turned off after about two hours, so all should be well now. If any problems persist, try purging the relevant pages. —Simetrical (talk • contribs) 16:31, 12 November 2009 (UTC)[reply]

Cite errors...

Is it possible to maybe make the cite error dialogues a bit more...less scary looking for the noobs? I was thinking stuff like this:

This article contains references, but no reference list. Please add one.
This message will disappear automatically when the problem is resolved.

This article contains a reference with too many parameters. Please fix it.
This message will disappear automatically when the problem is resolved.

Or something around these lines. ViperSnake151 Talk 02:53, 12 November 2009 (UTC)[reply]

I think that this is a good idea. Support

You should move this to the (Proposals) portion of Village Pump, though. Simply open this section for editing, open another tab for WP:VPPR and add a new section there, then select all of the text in this section and cut and paste it there. Then save both, with the edit text for this (the Village Pump (technical) section) empty.
— V = I * R (talk to Ω) 03:23, 12 November 2009 (UTC)[reply]

The problem is that the first would have to go at the end of the article, and the second wherever in the middle of the article (possibly mid-paragraph) the problem ref occurs; and were that not the case, would it be at all useful when it gives no indication of which ref is the problem? I don't think that's quite what you intend. Anomie ⚔ 03:26, 12 November 2009 (UTC)[reply]

But, the current (angry, large, red) messages already show up at the end and in the middle of the article. Regardless of what the message is or how it's formatted, it should only exist on the article for minutes.
— V = I * R (talk to Ω) 04:03, 12 November 2009 (UTC)[reply]

Wasn't the proposal here to replace the current messages with these boxes? If not, I misunderstood. But (without software modifications) the boxes would still have to be inserted where the error occurs, while boxes like this normally go at the top of the article/section. Anomie ⚔ 12:33, 12 November 2009 (UTC)[reply]

"Cite error: There are <ref> tags on this page, but the references will not show without a <references/> tag" is generated by MediaWiki:Cite error refs without references. That MediaWiki message does not support wikimarkup, nor do two other messages; see Template:Bug. BTW: The Cite error part of the current error message links to the relevant section at Help:Cite errors via an anchor. ---— Gadget850 (Ed) ^talk 19:01, 12 November 2009 (UTC)[reply]

Okay, maybe I'll start this fresh on the correct board, I got a better idea... ViperSnake151 Talk 19:15, 12 November 2009 (UTC)[reply]

Expanding template

This template gets wider when you open one of its sub-menus instead of remaining the same size. I can I eliminate this undesired behavior? SharkD Talk 03:09, 12 November 2009 (UTC)[reply]

~~Done.~~ By increasing width: to 19em, the box is wide enough to allow the list contents to be shown without it necessitating an increase in size. Since the width is based on the lists not being shown, it was sized smaller than it needed to be to properly display the contents. --tennis man 03:24, 12 November 2009 (UTC)[reply]

This is not a good solution. Please suggest a fix that doesn't involve increasing the overall size of the template. SharkD Talk 05:01, 13 November 2009 (UTC)[reply]

The problem is that {{Sidebar}} applies the "nowraplinks" class to its table, which via rules in MediaWiki:Common.css causes links to not wrap, which makes the box expand when those long links are shown. The fix seems to be to use {{normalwraplink}} for the links that are too long, or to pipe the links to shorten the displayed text. Anomie ⚔ 12:58, 13 November 2009 (UTC)[reply]

wow... you know, someone should take a stab at simplifying the various .css files for the site (and, of course, all of the derivative pages) when they get a chance to do so. This sort of thing (technically) just sucks.
— V = I * R (talk to Ω) 13:36, 13 November 2009 (UTC)[reply]

Need big auto-move in CAT:SVG

Hi, all images in Category:Other images that should be in SVG format with the {{Non-free logo}} tag should be moved to Category:Fairuse images that should be in SVG format. I guess a bot is needed. This would really help the categorization. --Beao 14:52, 12 November 2009 (UTC)[reply]

Interwiki links broken?

Is it me or are all interwiki links broken? Regards So Why 18:36, 12 November 2009 (UTC)[reply]

It's not just you - also links to Commons.Nigel Ish (talk) 18:38, 12 November 2009 (UTC)[reply]

Correct. Also the link to Terms of Use beneath the edit summary box is now a redlink. Enigma^msg 18:39, 12 November 2009 (UTC)[reply]

Also links to BugZilla and the MW support desk are now redlinks at the top of the page. Enigma^msg 18:40, 12 November 2009 (UTC)[reply]

That was fixed quickly, at least. The links are working again. Interwikis still broken, though. Enigma^msg 18:42, 12 November 2009 (UTC)[reply]

Pages may need to be purged, or the templates transcluding the interwiki links. Cenarium (forever) 18:50, 12 November 2009 (UTC)[reply]

This is a known issue and they're working on it. –xeno^talk 18:42, 12 November 2009 (UTC)[reply]

Interwikis back now as well.Nigel Ish (talk) 18:43, 12 November 2009 (UTC)[reply]

Thanks a lot that the change has been reversed, it was simply horrible! -- 84.47.59.184 (talk) 18:45, 12 November 2009 (UTC)[reply]

See the Server admin log. Cenarium (forever) 18:47, 12 November 2009 (UTC)[reply]

If anybody's still having problems, purge the page cache and bypass your browser cache.--Unionhawk ^Talk ^E-mail ^Review 18:52, 12 November 2009 (UTC)[reply]

Template size limit

Is there a limit on the size of a template?—NMajdan•talk 19:52, 12 November 2009 (UTC)[reply]

The template page itself has the same size limit as any other page: it cannot be over 2 megabytes in wikitext. However there are other limits on how much data can be dynamically included in any page via templates. These limitations are described at Wikipedia:Template limits. — Carl (CBM · talk) 19:58, 12 November 2009 (UTC)[reply]

Two megabytes. That's what I needed. Thanks.—NMajdan•talk 20:10, 12 November 2009 (UTC)[reply]

Rollback Rights

Hi everyone

I've recently had rollback rights added and I'm using Twinkle for other reverts. I understood that using the rollback rights that I got an automatic message when I reverted but it would also display TW for Twinkle at the end. However my messages aren't displaying that. Any ideas? --5 albert square (talk) 21:30, 12 November 2009 (UTC)[reply]

According to your contributions, Twinkle is summarizing normally. When you use WProllback, there is no TW suffix. Intelligentsium 23:38, 12 November 2009 (UTC)[reply]

Text under the edit window

Using IE8 on a WinXp and two Win7 systems. When editing a section that has already been created, I am seeing text between the bottom of the edit window and the edit summary. Any ideas? My main system with FireFox is down for an upate. ---— Gadget850 (Ed) ^talk 02:06, 13 November 2009 (UTC)[reply]

When I open the section for editing, the text is "(UTC)" and changes as I type. ---— Gadget850 (Ed) ^talk 02:08, 13 November 2009 (UTC)[reply]

No clue from the description given so far... could you post a screenshot?
— V = I * R (talk to Ω) 04:35, 13 November 2009 (UTC)[reply]

Not showing with fireFox 3.5. Not showing with IE8 if I log out, so it is probably some personal CSS issue. The text under the edit box that starts with "Content that violates any copyrights will be deleted" is being replaced. --— Gadget850 (Ed) ^talk 06:11, 13 November 2009 (UTC)[reply]

How to con lazy admins into deleting Wikipedia's images

Let's play with the picture at Motojirō Kajii, it's easy as 1-2-3:

1: Make any small change to the filename just to break the picture.
2: Let some dumb bot just flag it as "orphaned non-free" without any sort of check.
3: Let some lazy admin just delete it as "F5" without any sanity check (even though the picture's description links to its home article, where the infobox displays a red link picture)

Voila! Bravo! Repeat as much as you like: it's free! Have fun! 62.147.25.212 (talk) 02:33, 13 November 2009 (UTC)[reply]

If you feel the deletion was in error, go talk to the deleting admin, always the first step if you feel a deletion may have been made erroneously or there might be good cause to reverse it. You will probably find that will work better if you stop making personal attacks and are a bit more polite about it, though. Seraphimblade ^{Talk to me} 02:44, 13 November 2009 (UTC)[reply]

The IP has a point though. ♫ Melodia Chaconne ♫ (talk) 03:09, 13 November 2009 (UTC)[reply]

I'm not really sure it's a valid point, and certainly not one deserving of that level of venom. The bot tagged the article, the deleting admin found that it is indeed orphaned and has been for some time, and deleted it. At that point, there's not necessarily even any way of telling what article it was used on, and some were used on several articles before orphaning. There's a week's lag between the image going orphan and the deletion, so I think by that point, it can be easily enough presumed that silence indicates consensus. I'm not sure it'd be reasonable to check the (sometimes multiple) pages an image used to be on to find the occasional screwup that no one over a week's time noticed or cared enough to fix. (I'm also not sure why we'd need a nonfree image for that article, there's nothing in it that really indicates that the guy's looks rather than his books are the subject. That's not why it was deleted, of course, but could have something to do with the lack of objection.) Seraphimblade ^{Talk to me} 03:20, 13 November 2009 (UTC)[reply]

The use of SILENCE in relation to deletion worries me, here. That sort of justification can only lead to confrontational guardianship/ownership of articles and files.
— V = I * R (talk to Ω) 04:28, 13 November 2009 (UTC)[reply]

The point of waiting a week is to give people time to fix things like this. It is not the role of the admin doing the deletion to research every page the image has been used on. If the image is tagged as orphaned for a week and is still orphaned at the end of the week, it can be deleted. Of course, if it turns out there was a mistake, the image can be undeleted as well. And if the image was not orphaned when it was deleted, that is a problem. But in this case it appears there was simply a strange gap in the people watching the page, so that nobody noticed the broken image. — Carl (CBM · talk) 04:35, 13 November 2009 (UTC)[reply]

I'm not particularly concerned with the specifics, simply the idea that it's OK to delete the <whatever> because nobody has said not to within a set period of time. The idea there just bothers me... a lot.
— V = I * R (talk to Ω) 04:52, 13 November 2009 (UTC)[reply]

Considering no one even noticed the vandalism to the article between August and November...not sure the image being deleted is the biggest issue here... -- Collectonian (talk · contribs) 04:59, 13 November 2009 (UTC)[reply]

That's probably what's giving me the most trouble with this. You'd think that the person would look at the article/file history prior to using the deletion button. That sort of carelessness doesn't exactly inspire confidence (what little actually exists) in those who we've given access to the tools.
— V = I * R (talk to Ω) 05:04, 13 November 2009 (UTC)[reply]

PS.: I wouldn't really call the original edits which created the issue here "vandalism", since it seems to me that the person was simply unaware that the file name is important.
— V = I * R (talk to Ω) 05:06, 13 November 2009 (UTC)[reply]

You would also think someone from Wikiproject Japan would have this on their watchlist. As Collectonian says, there are bigger problems with this specific article, since the image was deleted in August and apparently nobody noticed until now. Really this incident is an argument in favor of a reviewing system to ensure edits aren't missed, but that's another issue. — Carl (CBM · talk) 05:22, 13 November 2009 (UTC)[reply]

(indent reset) Regarding silence being consensus, we have an entire deletion process based upon that very concept, and realistically, most editing is done that way (if I do something, and no one argues, it can be presumed to have consensus until and unless someone does object). Images for deletion quite often works that way as well—an image will be proposed for deletion, and if no one argues it shouldn't be deleted, it is. Only if someone raises an objection does a full debate take place, otherwise it's presumed that, again, silence is consensus. Seraphimblade ^{Talk to me} 05:45, 13 November 2009 (UTC)[reply]

I am really glad that editors are becoming more vocal in a deletion problem which has existed since at least 2004. Those interested in this topic may find Wikipedia talk:Requests for comment/new users and Wikipedia:Newbie treatment at CSD valuable. Ikip (talk) 06:33, 13 November 2009 (UTC)[reply]

Silence and consensus have nothing to do with this. Admins are supposed to make some basic verifications before deleting, especially speedily deleting, such as checking the history. It's very clear from the image description that it's supposed to be used on Motojirō Kajii. You just had to make one simple click to get to that page, and you would immediately see the redlink image and see the problem. Maybe it should be noted at MediaWiki:Filedelete-intro. Cenarium (forever) 17:16, 13 November 2009 (UTC)[reply]

Um, I guess I should add that there is a proposal at WP:BRFA to delete these files automatically. Would you like to make a suggestion as to how to improve that method (since bots can check histories and so forth, taking it out of fallible human hands)? I don't think any checking for this sort of vandalism is currently proposed. - Jarry1250 ^{[Humorous? Discuss.]} 17:27, 13 November 2009 (UTC)[reply]

FWIW, I feel that automating these sorts of things is an excellent idea, as long as its not really a quick process and that a human being could relatively easily interject at any time to prevent deletions. My gut feeling is that the existence of large backlog queues creates an unnecessary sense of urgency in these matters (and not only for deletion, by the way). We have created a monster, so to speak (both in the sense of urgency problem and the sense of overwhelming workload, actually), and so it's up to us to deal with the problems that it's causing.
— V = I * R (talk to Ω) 17:46, 13 November 2009 (UTC)[reply]

That was not vandalism, but a mistake by a new user. There is not really a feasible automatic way to check this. I've commented at the BRFA. But isn't there semi-automatic ways to make such deletions ? Cenarium (forever) 23:33, 13 November 2009 (UTC)[reply]

In the case of orphaned fair-use images (F5), where the file clearly has a fair-use rationale that includes (as required by policy) a link to the article where the file is purportedly being used, it is not at all unreasonable to expect the deleting admin to take a glance at the page to confirm that the image really is not being used there, which should identify scenarios like this. With file redirects now live on WMF wikis but not entirely bug-free, it is possible for files to actually be in use on pages, displaying entirely correctly, and still not appear in the list of file links. A few seconds of extra care is entirely appropriate. CSD, as has been said many times, is not about deleting the greatest possible number of pages in the shortest possible amount of time. Happy‑melon 23:12, 13 November 2009 (UTC)[reply]

The case of the missing revisions

Odd one here. Does anyone have any idea why the revisions from here to here (inclusive) are empty? Doesn't look like they were oversighted, and there was talk activity during that period, but so far as the revision history goes the page was apparently blanked at the start of that period, edited several times while still empty, and then restarted afresh (with a bunch of new comments) at the end. Database problem? Chris Cunningham (not at work) - talk 14:32, 13 November 2009 (UTC)[reply]

bugzilla:20757 —TheDJ (talk • contribs) 14:50, 13 November 2009 (UTC)[reply]

Great, cheers (and thanks for adding this instance to the bug report). Chris Cunningham (not at work) - talk 15:34, 13 November 2009 (UTC)[reply]

Now, if we could actually get someone interesting in addressing the bug report...
— V = I * R (talk to Ω) 16:43, 13 November 2009 (UTC)[reply]

Table / conditional parser nuances

Anyone able to look into a sticky problem with trying to use conditionals with wikitable syntax in {{talk header/sandbox}}? Have a look at the middle of the code, where I've had to hack around the problem by using HTML elements. The basic problem is that there doesn't seem to be a way to stop the parser treating a new line as a line break and adding <p><br /></p> in. The test cases page has tests for the various permutations. Chris Cunningham (not at work) - talk 16:09, 13 November 2009 (UTC)[reply]

*guffaw* Sorry, you're on your own with that damn template... *rolls eyes*
— V = I * R (talk to Ω) 16:44, 13 November 2009 (UTC)[reply]
- If you're not actually going to help, why comment? This is the technical village pump after all; technical questions are to be expected. Mr.Z-man 18:10, 13 November 2009 (UTC)[reply]

It's likely the issue could be prevented by switching completely to Html and judicious use of comments... --Izno (talk) 17:52, 13 November 2009 (UTC)[reply]

That's as much of a non-answer as the comment above. I'm looking to see whether the parser can handle what I'm asking; I'm perfectly capable of hacking around it already, as shown by the working state of the current sandbox. Chris Cunningham (not at work) - talk 22:54, 13 November 2009 (UTC)[reply]

It's a non answer because I doubt you're going to get the answer of "yes, you can do this". I was simply providing the alternative to mixing wikiml with html. Simply put, wikiml isn't made for parserfunctions. /shrug. --Izno (talk) 23:40, 13 November 2009 (UTC)[reply]

I'm not posting on VPT because I want hedged bets which tell me things I already know, but thanks for responding anyway. Chris Cunningham (not at work) - talk 23:56, 13 November 2009 (UTC)[reply]

Bugs in categorization (still)

As I mentioned before, {{FormattingError}} can add pages to Category:Pages with incorrect formatting templates use. However, I have been seeing a lot of random category assignments; I recently fixed all of them using null edits and made sure the category was empty. 5 minutes later I check again and many pages are added back to the category without any change to them in the mean time. This sounds like a bug in MediaWiki, but I have no idea what to file - I can find no reason for this behavior. Anybody know what's causing this or what I should put in a bug report? Thanks! — SkyLined (talk) 16:57, 13 November 2009 (UTC)[reply]

It's not a bug, it's just a caching issue. You can force a reload on your end (if you're using FF, for example, simply pres [ctrl-shift-R] in order to force a page reload). The server should re-cache most pages when you try to edit them, so the null edit ought to have taken care of the potential server side issues.
— V = I * R (talk to Ω) 17:09, 13 November 2009 (UTC)[reply]

Unfortunately, that cannot be true: if this is a caching issue, one would expect a page to remain in a in a category after it has been removed from it. By refreshing/null edits/purge you could fix that. However, in this case the page is actually out of the category at one point and 5 minutes later it is back in the category, without there being any reason for it to be in it... — SkyLined (talk) 00:11, 14 November 2009 (UTC)[reply]

Yes, this is looking weird. This query shows timestamps of yesterday around 16:50 for all of the pages in that category - does that mean the system did some kind of automated repopulation at around that time, and used out-of-date data for it?--Kotniski (talk) 10:50, 14 November 2009 (UTC)[reply]

(I've just done a null edit on Alpha particle, which successfully removed it both on the category page and in the results of the above query. Let's see how long it takes to reappear.)--Kotniski (talk) 10:57, 14 November 2009 (UTC)[reply]

Interesting... the theory that some sort of batch job may be changing things is probably a good one. I'm not exactly sure how to check on that, but I'm fairly sure that whatever it is would be on the toolserver. I have no clue what we'd look for, however.
— V = I * R (talk to Ω) 11:28, 14 November 2009 (UTC)[reply]

I suspect it's something to do with the job queue, but I've no idea what to look for either.--Kotniski (talk) 11:57, 14 November 2009 (UTC)[reply]

Update - someone just made some unrelated edits to Foot-pound (energy), and that caused the page to disappear from the category (as expected). But the weird thing I've noticed is that User:Kathryn NicDhàna/Admin Toolbox has popped up on the category page a couple of times, then disappeared again, despite not having been edited recently. (Unfortunately that page won't load for me, so I don't know if it ought to be in this category or not.) --Kotniski (talk) 15:50, 14 November 2009 (UTC)[reply]

Now User:Pigman/Admin toolbox is doing it. I think I'm starting to believe in ghosts...--Kotniski (talk) 15:55, 14 November 2009 (UTC)[reply]

Mysterious added <p> in multiline <div>

This code:

<div>a
b
c
d</div>

generates this HTML:

<div>a
<p>b c</p>
d</div>

Is there a reason for the added <p>, enclosing everything except the first and the last line? If the <p> wasn't there, it would solve some problems in Template:Navbox. Svick (talk) 22:38, 13 November 2009 (UTC)[reply]

The "<p>" is the equivalent of hitting "return". XHTML does not recognize manual line breaks (i.e., added by the use of the "return" button). Intelligentsium 23:54, 13 November 2009 (UTC)[reply]

The question, presumably, is why line breaks 1 and 3 cause the parser to open and close a paragraph element but line break 2 doesn't. Chris Cunningham (not at work) - talk 23:59, 13 November 2009 (UTC)[reply]

In wikicode, one line line break shouldn't create a new pargraph. Normally, you have to use two line breaks to crate a new paragraph (<p>). Svick (talk) 03:41, 15 November 2009 (UTC)[reply]

.js code problem

I am trying to add a script from another wiki (fr:) that allows easy evaluation of articles. Unfortunately, this script does not exist here, which means I have to copy and paste the rather lengthy full source code; a problem aggravated by the fact that line breaks "disappear" when I hit save. The code does not work without the breaks. How do I prevent the line breaks from disappearing? Intelligentsium 23:50, 13 November 2009 (UTC)[reply]

Javascript isn't whitespace-sensitive; if it's not working, it's for reasons other than the whitespace being swallowed. Chris Cunningham (not at work) - talk 00:02, 14 November 2009 (UTC)[reply]

That is not true: The ECMAScript specification suggests that the scripting engine should automagically insert missing semi-colons (chapter 7.9) when encountering line breaks in white-space. This suggests that the problem might be fixed by putting semi-colons at the end of lines. — SkyLined (talk) 00:15, 14 November 2009 (UTC)[reply]

Yes, but there are many, many lines at the end of which to insert colons. Intelligentsium 00:23, 14 November 2009 (UTC)[reply]

In this case the code did not work because it was hidden behind // comment. The solution is simply to copy from the edit mode, that is click "view source" tab on top first. P.S. importScript(':fr:User... will not work, to import the script from other Wikipedia you need importScriptURI('http://fr.wikipedia.org/w/index.php?title=User:xx/scriptname.js&action=raw&ctype=text/javascript'). — AlexSm 00:50, 14 November 2009 (UTC)[reply]

New Subpages

It would be very useful to have a way to see all new subpages of a given page. It could be used to see new XFDs, RFAs, Wikipedia books, spam bot reports, SPIs, portal subpages, articles for creation, etc. I don't believe we have a way to get new subpages ? If not, I'll fill a bug pointing here, for a special page Special:NewSubpages, or a way to filter Special:NewPages. Cenarium (talk) 01:24, 14 November 2009 (UTC)[reply]

Also peer review, WP:FAC, WP:FPC, WP:BRFA, etc. Cenarium (talk) 04:33, 14 November 2009 (UTC)[reply]

I don't know about some of those, but as for XfDs, PR, FAC, BRFA, RFA, and SPIs, new subpages of those are all transcluded on the main page, so there's already an easy way to see all the new subpages. rʨanaɢ ^talk/_contribs 05:53, 14 November 2009 (UTC)[reply]

When they are transcluded, some are not (created by new users, oversight, etc). Orphan XFDs, RFAs and such are regularly deleted. Besides this, it's an alternative way to find new ones. Some of those (WPbooks, AFCs) are specifically categorized (except accident), but portal subpages, bot reports are not, so we have no way to find new ones. Cenarium (talk) 16:49, 14 November 2009 (UTC)[reply]

Go to Special:PrefixIndex, then enter the article name that you are wondering about. For example, for RFAs go to: [17]
— V = I * R (talk to Ω) 07:48, 14 November 2009 (UTC)[reply]

To add a Subpages link in the toolbox, add this to your JS:

addOnloadHook( function () {
  addPortletLink("p-tb", wgServer+wgArticlePath.replace("$1", "Special:PrefixIndex/"+wgPageName+"/"), "Subpages", "t-subpages", "See all subpages of this page");
});

---— Gadget850 (Ed) ^talk 13:20, 14 November 2009 (UTC)[reply]

I know how to see subpages, I do it all the time. What I mean is new subpages of a given page, a way to filter Special:Newpages to subpages of a given page. Similarly, it would be nice to have a way to filter recent changes for subpages of a given page. Cenarium (talk) 16:49, 14 November 2009 (UTC)[reply]

How to keep nested <div> tags from messing with one another?

In things like

<div style="something"> bla bla bla

bla bla bla bla <div style="something else">stuff stuff</div>

bla bla bla</div>

the first closing </div> tag seems to close both of them. See, for example, this AfD close, where the div tags within a {{quote}} template caused the archiving (<div class="boilerplate metadata afd vfd xfd-closed" style="background-color: #F3F9FF; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px solid #AAAAAA;">) to close early—if you scroll down a ways, you can see that the nice blue box ends rather suddenly. Is there a way to stop div tags from behaving in this way?

(For a short-term fix on this particular page, I just changed the quote template to a <blockquote>. But it would be nice to be able to fix the problem instead of avoiding it.) rʨanaɢ ^talk/_contribs 04:20, 14 November 2009 (UTC)[reply]

Mayhaps your problem is the same as that which I addressed at Wikisource:Wikisource:Scriptorium/Archives/2008-12#div needs to go on a separate line. Hesperian 04:58, 14 November 2009 (UTC)[reply]

I saw something like that on bugzilla, too.... in {{quote}}, putting the div on its own line seems to correct that problem, to an extent, but it introduces a new one (it makes the <blockquote> within that template stop working), so I don't know how feasible it is.

For what it's worth, the only reason that template has divs in it is to allow multiline blockquotes (without a need to type <br/> or <p>. But that might be more of a big deal than this one div issue, so I don't know if it's worth removing them just for that. rʨanaɢ ^talk/_contribs 05:07, 14 November 2009 (UTC)[reply]

I think the problem in this case is that the opening <div> is at a different level of ":"-indentation from the </div>. That generates raw HTML tag soup something like <div><dl><dd><div>.....</dd></dl></div>; note how the </div> highlighted in blue is outside of the block that its matching <div> is inside. Tidy fixes by inserting an extra </div> (highlighted in red) as <div><dl><dd><div>.....</div></dd></dl></div>. But this leaves the </div> highlighted in blue to incorrectly close the archiving box. Anomie ⚔ 00:49, 15 November 2009 (UTC)[reply]

Change in "Save page" behavior

When editing a section on the daily TfD pages, one used to be returned to said section after clicking save. Recently, however, clicking save returns you to the top of the page. Is this an intentional change? If so, why? Or am I missing something? JPG-GR (talk) 05:34, 14 November 2009 (UTC)[reply]

Just made a change to Template:Tfd2 that should fix this for future nominations. — RockMFR 12:40, 14 November 2009 (UTC)[reply]

ads not shown without javascript?

Is there a reason why ads are not shown when javascript is disabled? --87.78.20.139 (talk) 17:04, 14 November 2009 (UTC)[reply]

Yes. If they were simply embedded in the HTML, then varying the ads would interfere with the server-side caching of pages, which would be unacceptable. So Javascript is used to insert the ads as an alternative. Dragons flight (talk) 19:32, 14 November 2009 (UTC)[reply]

What's up with upload?

Is there some sort of trial system in operation at Special:Upload? There is loose code – "<fogg-for_improved_uplods><fogg-please_install>" – on the main page, trying to upload connects you to some prototype subdomain and gives you a progress bar entitled "<mwe-upload-in-progress>", stuck at 0%. Could someone fix this absolute joke of a usability initiative, or at least explain it? Thanks, Skomorokh, barbarian 19:57, 14 November 2009 (UTC)[reply]

I don't see anything like that there right now. Maybe it was fixed? Svick (talk) 03:56, 15 November 2009 (UTC)[reply]