Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

suppressredirect

Quite a simple proposal really, here it goes. Basically, all user groups (except IPBE) which can be granted by an administrator would also have the suppressredirect bit on them. Simple. Regards, ⇒TAP 18:52, 22 June 2012 (UTC)

• Could you please specify whether this includes 'autoconfirmed' or 'Confirmed'?--Jasper Deng (talk) 18:56, 22 June 2012 (UTC)

• Clarified. This does not include them two. ⇒TAP 18:59, 22 June 2012 (UTC)

• (Talking about user groups here).--Jasper Deng (talk) 19:03, 22 June 2012 (UTC)

• I'd have it be its own userright, reviewer has nothing to do with it, account creator has nothing to do with it, there's no reason to bundle those. I think there should be a page for suppressredirect, just like there is for rollbacker. Ryan Vesey Review me! 19:08, 22 June 2012 (UTC)
• I don't hugely care how suppressredirect is given out, only that it becomes a userright of some sort. It really streamlines some of the common tasks of a NPPer (moving articles into userspace to be worked on, the occasional hilariously bad title such as BANURI VILLAGE (HIMACHAL PRADESH)) and creates less cleanup for admins as a result. The Blade of the Northern Lights (話して下さい) 14:33, 27 June 2012 (UTC)
• Suppressing a redirect is pretty close to deletion. If not carefully assigned, handing the right out could create a lot of problems. First, userfication of a page created by a new editor, without leaving a redirect behind, can result in confusion, as the article is no longer 'live'. Second, while userfication of content that will actually be developed into an article that meets article space guidelines is great, userfication of bad content that never will be and/or that should be promptly deleted for policy reasons is actively bad, and skipping the step where an admin reviews the userfication prior to deleting the redirect reduces accountability. Finally, abuse of the supressredirect ability seems like it would be more harmful then abuse of many of the other rights that it is proposed to be bundled to. I'm in support of unbundling it from the admin package, but it should be a stand alone user right, not tacked on to existing rights where it will be assigned to people who never requested it, and don't understand the potential pitfalls of its use. Monty₈₄₅ 14:53, 27 June 2012 (UTC)

  Monty's right. Suppress redirect is actually a rather dangerous tool in the wrong hands - and in combination with move vandalism can do quite a bit of damage. I'm fine with it being unbundled, but not just tacked on to other rights. Worm^TT(talk) 14:59, 27 June 2012 (UTC)

  As noted, this is awfully close to a deletion tool. I would oppose such a user-right group being given out like the other tools granted by admins. this should be granted by bureaucrats, and only following community discussion, if anything. - jc37 21:41, 28 June 2012 (UTC)

  I would say that may be a bit too strict. With a right like this one it does need to be clear to the person handing the right out the potential for misuse, and clear to the receiver how to properly use the tool. While I did point out the potential for inappropriate uses, I think the biggest risk of abuse is from editors who misunderstand the proper use of the tool, and that can be dealt with using a much lighter process then full community discussion for each person its granted to. Monty₈₄₅ 21:58, 28 June 2012 (UTC)

  (waffles) I dunno. To support that, I'd really need to be convinced. The concept of redirects has become a rather big deal. Especially now that I've been seeing pages being redirected to list pages or overview pages. So redirects now can (and often do) have substantive contribution histories. So redirects don't seem to me to be as unimportant as we may have once considered them. - jc37 22:26, 28 June 2012 (UTC)

Suppress redirect would, as I understand it as a non-admin, not allow you to delete redirects once they are created, regardless of how they were created, but would allow you to stop the initial creation. So there would be no direct loss of histories. The WP:BEANS issue is that a malicious editor could move a page, suppressing redirect creation, into userspace or anywhere else, and then create a new page in its place. Unless someone looked at the page log, they wouldn't realize that the moved page had ever existed, whereas without the additional right, there would atleast have been the redirect in the history pointing to the new location. It would basically allow much better hidden page move vandalism. Monty₈₄₅ 02:00, 29 June 2012 (UTC)

My point was that it's getting hard enough to find these things, this would make it worse (as you note). - jc37 17:16, 29 June 2012 (UTC)

How about making suppressredirect a new userright for users involved in page moving, given out by admins at WP:RFR? David1217 ^{What I've done} 04:31, 3 July 2012 (UTC)

I'd support that, although some rough criteria would be helpful. We need to make it easier harder to get than rollback, but we also don't want to make it ridiculously hard like autopatrolled used to be. I'd say the guidelines for AWB plus a certain number of good page moves (~50 or so, which is pretty easy to rack up on NPP in 3-4 months or so) might work, although I also know I tend to be much more relaxed about permissions than most; other comments would be good. The Blade of the Northern Lights (話して下さい) 01:27, 4 July 2012 (UTC)

Do you mean harder to get than rollback? I assume that's what you mean from the context, but I just wanted to be sure. Ryan Vesey Review me! 01:31, 4 July 2012 (UTC)

Thanks, fixed; that's what happens when I'm simultaneously typing and cursing out Russell Martin for his second big error of the game (I still can't believe he fucking blew either one of them, much less both...) The Blade of the Northern Lights (話して下さい) 01:41, 4 July 2012 (UTC)

I've added an RfC. David1217 ^{What I've done} 01:57, 4 July 2012 (UTC)

RfC

This RfC is intended to answer two questions:

1. Should suppressredirect (the ability to prevent creation of a redirect from the former page title when performing a move) be a separate userright?
2. If yes, what should be the criteria for receiving suppressredirect? The Blade of the Northern Lights has suggested that it should be "the guidelines for AWB plus a certain number of good page moves (~50 or so)".

David1217 ^{What I've done} 01:57, 4 July 2012 (UTC)

Should suppressredirect be a seperate userright?

• Yes It is a reasonable userright to split out, and could be helpful to gnomish editors if used carefully. Prior to assigning the userright, WP:Suppressredirect should be created to give guidance on when it is appropriate to use the right, and times when it should be avoided. Specifics should be developed there. Monty₈₄₅ 03:52, 4 July 2012 (UTC)
• Just a question: what do people think about either merging suppressredirect with move-subpages (the ability to move pages with their subpages) or the file mover right? David1217 ^{What I've done} 16:26, 4 July 2012 (UTC)

I don't see a problem with bundling it to move-subpages. Filemover on the other hand is a bit more problematic, as it currently lets editors do to files what they already can do to articles, while suppress redirect is I think more fraught with potential for misuse. We don't want to make it harder for those who need it to get the filemover right by including a right they will require additional scrutiny. Monty₈₄₅ 17:25, 4 July 2012 (UTC)

Okay, sounds good. I frankly don't care what happens to this proposal, I just set up the RfC so that other editors could say what they thought. David1217 ^{What I've done} 17:57, 4 July 2012 (UTC)

• Oppose - this is a type of deletion (it actually logs in the deletion log). - jc37 22:41, 4 July 2012 (UTC)
• Oppose — outright deletion, which this is, should require the user to pass RFA; the answer to problems like this is implementing more passable standards at RFA. I apologise if I've weighed in here before; I remember joining in a similar discussion recently but can't find my signature here. Nyttend (talk) 06:05, 5 July 2012 (UTC)
• Oppose, just like two months ago when this was last proposed. "Suppressredirect" is misused enough by admins as it is. Jenks24 (talk) 06:39, 5 July 2012 (UTC)
• In case it is not completely clear, I explicitly declare my support for it. It's not really materially different from moving a page and leaving a redirect, except it makes it somewhat easier to move it back if necessary. If you can read a page history and/or a move log, it's really not that hard to figure out what former titles a page might have had unless you're interminably lazy. The Blade of the Northern Lights (話して下さい) 21:56, 5 July 2012 (UTC)

  I should also add that this is extremely helpful if you're userfying something or working at AfC, for what would seem to be fairly obvious reasons. The Blade of the Northern Lights (話して下さい) 15:26, 9 July 2012 (UTC)

• Support it is not an outright deletion, as all it does is fail to make a redirect. This is about the only one of the administrator privileges that is not dangerous or controversial. Other non controversial features may be move subpages or create edit notice (If this can be separated from create blacklisted pages). If rights could be narrowed more then we could have trusted editors editing selected protected pages, eg spam black list or bad iamges, but not the mediawiki: pages for example. Graeme Bartlett (talk) 11:32, 6 July 2012 (UTC)
• Oppose I agree it is overused and should be discouraged, not encouraged. I can recall using this feature only once in the last year or so. DGG ( talk ) 23:30, 8 July 2012 (UTC)
• Oppose It allows the user to break a bazillion links to an existing page - and leave the owners of the pages containing those links no easy way to discover where the page went to...it would (on the face of it) appear as if the page had been deleted. In the hands of a disgruntled editor, this can potentially be amazingly disruptive. I might agree to a different right - the right to delete redirect pages. That (IMHO) would be slightly less disruptive because it leaves a paper-trail...first the document was renamed...then the redirect was removed. An even better solution might be:
  1. Move the page (creating a redirect).
  2. Deliberately blank the redirect.
  3. Have a process that finds empty pages and dumps them into a list where a bot can remove them after some suitable amount of time - IF there are no links to them. SteveBaker (talk) 14:47, 15 July 2012 (UTC)
• Support - it'd allow more users to help with the massive requested moves backlog. I'd do more closes of requested moves if I didn't have to poke an admin every time to do a G6 for me. It can be given out cautiously, not by default. Steven Zhang ^{Get involved in DR!} 15:50, 15 July 2012 (UTC)
• Support - A way too common scenario right now is that a new user starts off thinking they're creating their user page when they're actually creating a page in mainspace → article gets deleted due to being about an unremarkable person → new user goes away pissed off. Instead, I could use this to move the page to their user space (which is what they're expecting, after all) and then leave a note on their talk page and not have to bug an admin to do cleanup. Better new user experience and less dog work for admins? It's all good. Yes, bad things could happen, but that's true of everything done on a wiki. Dori ☾Talk ⁘ Contribs☽ 02:16, 18 July 2012 (UTC)
• Naw - while suppressing redirects is certainly useful at times, unfortunately the potential for abuse is there for making things conveniently disappear (as well as the more general misuse due to lack of familiarity with consequences and procedures and the like), and meantime it's not that hard to just move the page without suppressing the redirect and then tag the redirect for deletion. -— Isarra ༆ 18:44, 23 July 2012 (UTC)

How should the right be assigned?

• Admins should be more careful with the supressredirect right then with many of the other rights assigned at WP:PERM. I would suggest a guideline of 1000 edits, similar to AWB but not requiring they all be mainspace, with a 3-7 day waiting period to give anyone who has reason to a chance to object. Unlike RFA, the burden should be on the editor(s) objecting to show why the requesting editor should not be trusted, rather then a burden on the requester to meet a specific threshold of support. However I don't think tying it to a specific number of past moves makes much sense, depending on the type of moves an editor runs into, they could frequently encounter good moves to suppress redirect on, or never encounter them. The question should be less about the editors particular experience, and more whether we can trust them to read the directions and use the tool in good faith. Monty₈₄₅ 03:52, 4 July 2012 (UTC)

• Strong oppose - this should not be given out by admins. It is a type of deletion. It also makes things more difficult to track. And so on. If someone groups this with a package of deletion tools, which requires going through a community process like RfA, closed by a bureaucrat, then maybe. - jc37 22:41, 4 July 2012 (UTC)

• Comment A suppressredirectifnolinks would be a good right if it existed but would need some development work first. -- WOSlinker (talk) 22:14, 5 July 2012 (UTC)
  • suppressredirect-ifnew makes more sense to me (suppressredirect option only available on new pages for such users). Rd232 ^talk 00:52, 20 July 2012 (UTC)

Informing new creators of article guidelines

There are currently 55,070 articles tagged for unclear notability.

One of the main concerns at Wikipedia is that new users are not adequately informed of what new articles should be. Proposals that creation could be limited to autoconfirmed users were rejected. Various substituted proposals for a new landing page are under discussion and/or development but this takes time. Many new articles have borderline notability and other important issues that require tagging but not necessarily CSD or PROD for deletion. More content and/or more research could probably turn them into decent articles. Many editors and those patrolling new pages may feel that it is not the remit of regular users to complete such articles on behalf of their creators.

While (when using Twinkle) CSD and WP:PROD leave messages on the creators' talk ages drawing their attention to issues, maintenance tags do not. Many new pages may be the creations of WP:SPA who might not return to the project and be aware of any tags, but this does not mean that their articles are necessarily any less worthy of inclusion. It is possible that if new users were quickly notified while still on line that their article needs attention, we may be seeing a step towards increased user retention, and over time, a reduction in clean-up backlogs, and other areas such as AfC that are snowed under.

I propose that:

Certain important tags such as (to cite a few examples) COI, Unreferenced, More references required, Close paraphrasing, Essay like, Tone, Written like an ad, etc. should automatically place a welcome and a friendly notice on the new user's talk page, making them aware of work that still needs to be done, and perhaps with links to the appropriate specific guidelines.

This may have been previously proposed, but as I don't immediately see anything listed at WP:PEREN this is just a suggestion that has occurred to me during my recent intensive use of the prototype Special:NewPagesFeed, and if it gains sufficient support it could be moved to RfC and further discussed and perhaps developed as an additional combined feature of NewPagesFeed.

Kudpung กุดผึ้ง (talk) 03:52, 5 July 2012 (UTC)

• Yes, it is certainly a good idea.--Ymblanter (talk) 07:33, 5 July 2012 (UTC)

There's a related discussion (and related suggestions) here (down the bottom, just above "Can we do both")   LittleBen (talk) 08:59, 5 July 2012 (UTC)

Thanks, but such discussions often get convoluted and bogged down. This is a straightforward, unambiguous single proposal, and perhaps it can be handled quite quickly without any side issues. Hence the reason for seeing what support there is for a discussion before moving to RfC for a discussion on the pros & contras of the proposal itself. Kudpung กุดผึ้ง (talk) 09:29, 5 July 2012 (UTC).

Isn't the problem that such users don't know about talk pages and so would not look at them or for them?   My suggestion (3) is

(3) When a user who is not logged in (or who is logged in with an IP address) attempts to create an article,

it might be a good idea to display a link like "you might like to know the advantages of creating a logon alias, and talk page".

And my suggestion (2) is

(2) (When a user searches for a non-existent page "ABCDEF")

Instead of saying just "You may create the page "ABCDEF"...", also say something like "You might like to read Wikipedia Article naming guidelines". (It would be useful if this article were more clearly linked to the search engine tutorial which explains how to use search engines for research to satisfy Wikipedia requirements like verifiability and recognizability). LittleBen (talk) 15:26, 5 July 2012 (UTC)

I like LittleBen's suggestions, except that I would have the user directed to the Article Wizard rather than the naming guidelines pages. (Maybe something like "if you have not previously created an article or not familiar with Wikipedia's guidelines and policies concerning articles, please consult the Article Wizard before proceeding further").--JayJasper (talk) 15:37, 5 July 2012 (UTC)

Thanks, for te suggestions but such discussions often get convoluted and bogged down. This is a straightforward, unambiguous single proposal, and perhaps it can be handled quite quickly without any side issues. Hence the reason for seeing what support there is for a discussion before moving to RfC for a discussion on the pros & contras of the proposal itself. --Kudpung กุดผึ้ง (talk) 18:54, 5 July 2012 (UTC)

I'm not sure that I'd be happy with this. I don't want to receive any such messages. How does Twinkle know whether I'm a new editor, so it knows who needs a welcome-refimprove note and who doesn't? Given the way some editors tag-bomb new pages with every conceivable problem, how would you handle multiple tags? WhatamIdoing (talk) 19:29, 5 July 2012 (UTC)

I'm not talking about you or your contributions. That said, you might not be aware that Twinkle is already able to discriminate between regular and new users. Editors who tag bomb articles are the totally inexperienced and/or young page patrollers whom some editors consider not to be a cause for concern although they make up 80% of the patrollers. This proposal is part of a move to improve NPP and new user retention, where other suggestions for improvement to NPP, and the introduction of a new, new-user landing page appear to have failed. --Kudpung กุดผึ้ง (talk) 22:24, 8 July 2012 (UTC)

Kudpung, could you please explain how "inexperienced and/or young" patrollers can make up 80 percent of the patrollers? The existing data says much different (on the young point, at least). And it's not really helpful to look at number of patrollers; the useful data is number of patrols. If 80 percent are 14, and those 80 percent each tag 1 article a year while the rest of the work is done by everyone else (hyperbole, but you get the point) then the situation is rather different from what your number would suggest. Ironholds (talk) 12:05, 9 July 2012 (UTC)

On the existing data front; the survey data (which you have seen, as you helped gather it :)) suggested that "Between 79 and 82 percent of new page patrollers are over the age of 18, in line with the editorial community overall, and this rises to between 83 and 85 percent with the high-workload patrollers". Ironholds (talk) 12:08, 9 July 2012 (UTC)

I have no interest in that survey and its data whatsoever. It was my initiative, following a couple of years intensive research by some concerned, mature, experienced users into the enormous problems concerning the quality of NPP. I helped launch it, and immdiately afterwards the survey project was adopted by the Foundation who months later suddenly published a report that had little in common with the actual empirical findings of those established users and admins who have hands-on experience of new page patrol. Hence, some mature, experienced users are still looking for new, alternative ways to address the continuing problem of poor patriolling (and possible mis-judged deletions by some admins who may occasionally take the tags on face value in good faith), and user/new page creator retention. Wikipedia is losing content creators due to the way they are treated by drive-by deletionists.--Kudpung กุดผึ้ง (talk) 14:35, 9 July 2012 (UTC)

Can you point me to these empirical findings, please? And also to an example of how the report does not line up with them? And, ideally, either show how the report doesn't line up with the raw data from the survey or how the raw data was flawed? Ironholds (talk) 14:58, 9 July 2012 (UTC)

I ask the latter questions because, well, either the report was wrong about the raw data, the raw data was wrong, or the empirical data gathered "by some concerned, mature, experienced users" is wrong. Ironholds (talk) 14:59, 9 July 2012 (UTC)

As that survey project is dead as far as the community who initiated it is concerned, the volunteers are no longer interested in discussing it or digging for their empirical findings at this stage. The fact that some people prefer data driven explanations, while some prefer the reality of hands-on experience is one of the classsic breakdowns in communications where the WMF and the community are nevertheless working towards the same goal. --Kudpung กุดผึ้ง (talk) 16:47, 14 July 2012 (UTC)

Well, as the top patroller in '10 and someone who still keeps their hand in I don't think anyone could accuse me of not having hands-on experience :). If you don't want to discuss the survey or talk about it, that's fine - I'm not going to force anyone to rely on data they don't like - but I really wish you'd stop pulling out numbers, here and elsewhere, that isn't supported by actual data, like " Editors who tag bomb articles are the totally inexperienced and/or young page patrollers whom some editors consider not to be a cause for concern although they make up 80% of the patrollers.". If it was "I see a lot of young patrollers", that's fine, but once you start talking about hard numbers, you're talking about quantitative data that can't be accurately gathered simply by watching and looking unless you're watching, looking and actively counting ages. And quite frankly, I think the community deserves better than numbers that aren't supported by hard evidence, because, well...they're numbers. Hard evidence is where they come from. Subjective experiences are great, but only if you're giving subjective outputs. Okeyes (WMF) (talk) 19:37, 16 July 2012 (UTC)

WADR, your experience is, IMHO, possibly out of date, and nothing has been done yet to implement a concrete solution to the problem of what is generally very poor patrolling as witnessed by those experienced editors who do it seriously in an attempt to get to the root of the issues. Plain numbers can can all to frequently be interpreted by those who cite or extrapolate them to disprove the blatantly obvious, or to avoid the opportunities to discuss them face-to-face. If control over patrollers is to be ruled out, then other solutions must be examined. --Kudpung กุดผึ้ง (talk) 01:34, 20 July 2012 (UTC)

What do you mean by "discuss them face-to-face" exactly? Okeyes (WMF) (talk) 01:39, 23 July 2012 (UTC)

• Seems like a good idea in general. One concern is that if the note is too long, new users are likely to skim through it and miss something. I would suggest a very short note with a link to the article's talk page that contained more detailed instructions. Perhaps the detailed instructions could be formatted in a checklist fashion in short bite-sized segments that would be quick to read and could be checked off as they were completed. 64.40.54.4 (talk) 07:36, 6 July 2012 (UTC)
  • I agree with Kudpung that this is a simple and obvious change that, while it certainly will not solve all the problems, will probably lead to the improvement of at least some of them. it is something that any careful NPPatroller would want to do themselves manually, but even many experienced patrollers do not always have time to do. Better that it be done with a notice than not at all. DGG ( talk ) 23:16, 8 July 2012 (UTC)
• Support The proposal is direct and to the point. --j⚛e decker^talk 14:43, 9 July 2012 (UTC)
• Support New editors need more guidance when creating articles. David1217 ^{What I've done} 16:56, 12 July 2012 (UTC)
• Support - Guidance is crucial. Theopolisme _{TALK 17:01, 12 July 2012 (UTC)}
• Support Absolutely. When tagging a new page, I always fear that the page creator--sometimes blatantly inexperienced--won't return to his or her article either because he or she doesn't quite know how, or because of disinterest post-creation. Deletion notices posted to a user talk page usually inspire a kneejerk reaction (unfortunate, but better than nothing) to return and improve his or her article accordingly, so I fail to see why we shouldn't do this for tags as well. One of the major issues among good faith new editors is indeed not only a lack of understanding for relevant guidelines/policies, but also basic expectations for the subjects of new articles and the corresponding content. Beyond welcome messages--usually ignored--I can't think of a way to immediately rectify this issue pre-article-creation, so I feel this proposal would be the next best thing. --IShadowed 14:27, 16 July 2012 (UTC)
• Support - if it can be done in a way that doesn't piss people off too much. Some way to limit initial rollout to see how it goes would be good; a "big bang" approach might just fail spectacularly and kill what's basically a good idea. Opt-out option of course is essential. BTW email notification, enabled by default, will push messages out to new users via email, so they won't need to log in to be aware of the message. Rd232 ^talk 00:44, 20 July 2012 (UTC)

Personally, I believe in keeping everything on-Wiki as much as possible. That said, the current proposal only concerns three or four templates of the most crucial kind - just one level down from threats of impending deletion. There is no reason why they cannot be worded in a very friendly manner (something we're not always very good at) - after all, the effort here is to retain articles that may benefit from more interaction from the creator rather than slumber unimproved for years with ugly tags, and to retain the editopr as a potential Wikipedian. I have found that my custom messages to users work very well, hence this suggestion for a proposal. A limited trial might well prove to be unnecessary. Kudpung กุดผึ้ง (talk) 01:34, 20 July 2012 (UTC)

Guys, I still see no practical method for limiting this to "new editors". There's also no proposal to limit it to tags added shortly after creation, tags that are actually warranted, tags that remained on the article for more than a day, etc.

So let's try this a different way: How many of you have created new articles? And how many of you are volunteering to get a {{welcome-refimprove}} or similar message posted every single time someone spams one of the hundreds of clean up templates onto that article for the rest of your Wikipedia career? WhatamIdoing (talk) 17:34, 23 July 2012 (UTC)

Machine translation

I am concerned about this all-too-frequent message at the top of many articles which need expansion:

"Don't speak German? Click here to read a machine-translated version of the German article."

My experience is that this is an invitation to chaos. Machine translations are just not good enough, and this very positive statement encourages people who don't know any better, but are interested in the topic, to simply insert the machine translation and then try to smooth out the English text a bit without knowing what the source text means, and making everything from serious to hilarious mistakes in the process, sentence after sentence. What is the use of that?

I have tried to repair one or two of these messes, but the errors are so blatant and extensive that it was much more efficient to freshly translate the source text. I would hate to think that there are more of these incomprehensible entries being generated in this encyclopedia, creating much more trouble than they are worth, and damaging Wikipedia's reputation.

Can this message, which I am sure is mean as a helpful suggestion, be somewhat elaborated? Something like:

"Don't speak German? Click here to read a machine-translated version of the German article to give you some ideas about what might be included, but do not simply insert the machine translation since both its accuracy and its readability will not be acceptable."

Of course, the issue does not just relate to German texts, but that's the area I am especially involved in. Thanks in advance for any ideas on this subject you are able to give in due course to this concern.

--Remotelysensed (talk) 10:47, 5 July 2012 (UTC)

Would you point us at one or two of the said articles? A quick search for "Don't speak German" finds nothing. --Tagishsimon (talk) 10:57, 5 July 2012 (UTC)

Special:WhatLinksHere/Template:Expand German may help. Anomie⚔ 11:01, 5 July 2012 (UTC)

Exactly what I sought, thanks. Remotelysensed, did you spot that the ExpandGerman template box expands to include advice such as "Google's machine translation is a useful starting point for translations, but translators must revise errors as necessary and confirm that the translation is accurate, rather than simply copy-pasting machine-translated text into English Wikipedia." Two possibilities: you're not satisfied with that wording; you're not satisfied that the wording is normally hidden? --Tagishsimon (talk) 11:11, 5 July 2012 (UTC)

Suggestions can be made at Template talk:Expand language. PrimeHunter (talk) 11:22, 5 July 2012 (UTC)

IMHO machine translations should never be posted to the article page. Like any other content that is not ready for publication, it can be placed on the talk page where it can either be discussed or cleaned up by those who can, or take its fate at AfT and risk being procedurally deleted. Kudpung กุดผึ้ง (talk) 22:32, 8 July 2012 (UTC)

I'm generally quite ruthless in removing machine translated content, but sadly there are even experienced users who think it's acceptable--Jac16888 ^Talk 22:36, 8 July 2012 (UTC)

why are your ruthless in removing it, rather than energetic in improving it? Or are you removing translations from languages which you do not yourself understand? Many articles in all of the Wikipedias are quite routine,; in particular, some geographical articles, or those on athletes & politicians, that I've done have been so utterly routine that I could perfectly well have done them from a machine translation without the least understanding of the knowledge -- if I know how to write in the subject area in English. (Some articles , of course, rely on a good understanding of the language --articles on historical or literary or many scientific topics.) But more to the point, the machine translations are much more likely to be uninformative or perhaps incomprehensible than actually misleading. The worst examples I have seen are either where a word is translated that clearly does not apply to the subject domain in question & without knowledge of the vocabulary of the source language one would not be able to tell what was intended, or where the machine's confusion of tenses leaves the actual sequence of events unclear to the extent it cannot be made unambiguous without knowing the grammar of the source language. DGG ( talk ) 23:13, 8 July 2012 (UTC)

If those are the worst examples you've seen then apparently you're not looking in the right places. Category:Wikipedia articles needing cleanup after translation is a list of about 400 machine translated articles, many of which are virtually incomprehensible, the only reason it's not much much larger is because I tidy the ones I can and stub the ones I can't. A few examples, Honda E07A engine, the history section of [1] before I removed it, [2], [3], Leonardo Bruno dos Santos Silva, [4], [5], [6], Loser Man and [7] is probably enough for now. The point is that in almost all of these cases the articles are better off as stubs that can be expanded (and in many cases quickly are) than tidied, since tidying the majority of these means re-translating, which often requires a tremendous amount of work, such as with this which didn't happen til over a year after you attempted it--Jac16888 ^Talk 12:15, 9 July 2012 (UTC)

I can only echo the point that in general the machine translations are useless. For example, see Wikipedia:Village pump (miscellaneous)/Archive 35#Was he a real person? - a misunderstanding that started from someone trying to make sense of such translation... Yes, it might not be that laughable with other languages, but such translations cannot be trusted. And they are also hard to correct, unless someone is able to make a good translation from scratch - in which case the machine translation is still useless. And I suspect that you also notice that, if you can tell that something hasn't been translated by a human...

It also seems wrong to encourage translations by someone who does not have a sufficiently good understanding of language being translated from, language being translated to and the subject matter.

In short, we should keep the text (the image, the article etc.) if it is better than nothing. But machine translation is worse than nothing. --Martynas Patasius (talk) 18:46, 9 July 2012 (UTC)

As cleaning up a machine "translation" is hard work, requires a competent translator, and is far less fun than actually translating the page from scratch, it is my experience that posting a machine "translation" is a very efficient way to prevent Wikipedia from obtaining a decent article soon. In short, machine "translations" should be reverted on sight or speedily deleted, and if there is no consensus to do that, at the very least they need to be discouraged as much as possible. —Kusma (t·c) 19:12, 9 July 2012 (UTC)

I found the feature very helpful. There was an article on an Italian opera that was a stub on the English Wikipedia, but there was tag leading to substantial article the Italian Wikipedia. I don't speak Italian at all but the machine translation was sufficient for me to glean several important facts that I rewrote in better English and added. Without the tag I would never have thought to look on the Italian version. My $0.02. Woz2 (talk) 16:01, 13 July 2012 (UTC)

This discussion has gone off-topic a bit, no? Template_talk:Expand_language#Google.27s_machine_translation_is_a_useful_starting_point_for_translations... is back on course, perhaps. Rd232 ^talk 01:02, 20 July 2012 (UTC)

Log of sources of poor paid advocacy editing

That a log will be kept in WP space of serious administrative action taken against paid editors, noting (where demonstrable) the employer, contractor, advocacy body or any other such body associated with hiring the paid editor who performed poorly.

In relation to this AN/I thread of 8 July 2012 it was noted that systematic poor behaviour can on occasion be associated with paid editors originating from a common source. Wikipedia reacts poorly to collusion off site, and to off site collusion with the intention or actuality of damaging the encyclopaedic project. In the case of paid editors who behave poorly to the point of serious administrative action being taken against them, it would be useful to track if these paid editors come from a common source. It would be useful to log this activity to determine if community action may be required against specific sources of poorly behaving editors in the area of paid editing.

I commend this proposal to establish such a log to you, chiefly in terms of providing coherent information regarding administrative actions taken against poorly behaving paid editors, allowing the community to better and more coherently consider the problem of poorly behaving paid editors.

Support as proposer. Fifelfoo (talk) 01:15, 10 July 2012 (UTC)

• Support as it seems a quite reasonable way to reduce un-helpful paid editing. AutomaticStrikeout (talk) 17:08, 10 July 2012 (UTC)
• Support As per Fifelfoo.Pharaoh of the Wizards (talk) 20:21, 10 July 2012 (UTC)
• Comment: if the purpose of this is to gather info about how and from where poor paid-editor editing happens, there ought to be a counterpart page to record how and from where good paid-editor editing happens, because that's also useful information for researching how and whether paid editing has value - though in either case, keeping it in WP space seems really weird to me. If, on the other hand, the purpose is to name-and-shame bad paid editors or their employers, or gather evidence favoring one side of the paid-editing divide...while I understand the impulse, that's not what we do here and it shouldn't be happening. A fluffernutter is a sandwich! (talk) 22:19, 10 July 2012 (UTC)

  "serious administrative action" is the line for recording, so that's pretty much blocks and bans. As noted, the purpose is to identify off-site collusion. The purpose isn't related to whether paid editing has value (a job for the sociologists, or more particularly political economists), but to determine whether site "X" colludes to degrade the encyclopaedia. Fifelfoo (talk) 22:26, 10 July 2012 (UTC)

• Comment Seems less than half baked, to me. First, do we do the imperative on wikipedia? Who exactly is being commanded to maintain such a list? What will you do with the information? How will you draw conclusions. Suppose you find a number of poor instances arising out of eLance ... you have a numerator. What exactly is your denominator? How do you know the ratio of good to bad articles from such a locus? And given the nature of eLance, what predictive quality would your stats yield? To what extent is the next eLance commission independent of the last? Does not the problem lie with the editor, and not the marketplace? By all means collect data, let us know if it yields meaningful results. Then we might be in a position to reconvene to discuss your suggestion. --Tagishsimon (talk) 22:43, 10 July 2012 (UTC)

  Proposals ought to be put in the imperative, otherwise they're not actually a suggestion for action. Many editors believe that the problem specifically exists with the marketplace—but that is a side issue from the immediate point. We log some administrator actions, such as community sanction results, yet don't keep a log of praise for editors editing (for example) in Indian sub-group topics. Fifelfoo (talk) 23:02, 10 July 2012 (UTC)

That's a more than inadequate answer to my criticisms. --Tagishsimon (talk) 23:05, 10 July 2012 (UTC)

• Comment Fluffernutter's comment seems reasonable to me. What is our goal here? If our goal is to track the impact that certain communities have on WP, then we would need to be tracking good and bad edits from those sites. For example, there may be more crimes committed in Asia than in Australia, but that's because Asia is a lot bigger, and more of everything probably happens there. We won't have any meaningful stats unless we can examine the whole issue, and generate percentages, even if they are rough. Obviously, I have no objection to anyone keeping an off-site log of these events, but if we're going to make an "official" log, and extrapolate from that data, then we should be logging something which is actually meaningful to extrapolate from. If our goal isn't to track the impact that various communities have on our site, then please explain what it is.   — Jess· Δ♥ 22:45, 10 July 2012 (UTC)

  Your contribution phrases this as if we weigh the contributions of a site against a feather. We don't: off-site collusion is a serious disruption of consensus. Off-site collusion which has the impact of degrading the quality of the encyclopaedia is a bad and harm regardless of "good works done." I'd suggest the EEML case at ARBCOM as an example—not all work done by EEML editors was negative, most EEML editors are now highly productive contributors to the very topic that was colluded upon. But the collusion itself was problematic due to its impact on consensus. And EEML editors did it from love of the encyclopaedia, not for external interests. Fifelfoo (talk) 23:02, 10 July 2012 (UTC)

I'm going to have to second Tagishsimon's comment above. You don't appear to have understood the problem. Trying to draw any conclusions from the data you're proposing we collect would be inappropriate because we would only have one raw number, and no context for that number. It would be similar to realizing that more than a million crimes occur every day in the rest of the country, but only 1 crime a day occurs in your small town, and so deciding the rest of the country must be a million times more corrupt. In reality, one crime a day in a small town is probably quite a bit, and your town is probably more corrupt than the rest of the country. We'd never realize that without the proper data to put what we know in the proper context. You're (presumably) proposing we draw conclusions from insufficient data. That's a bad idea. You can log stats all you'd like, but you should log the right stats.   — Jess· Δ♥ 17:00, 11 July 2012 (UTC)

And BTW, I haven't yet seen anyone suggest we're talking about off-site collusion. For elance, at least, we're talking about one editor, not any cooperative group.   — Jess· Δ♥ 17:03, 11 July 2012 (UTC)

• Oppose. Less than a half-baked proposal. Should Fifelfoo wish to compile this data, that's of course fine. But until he/she is able to articulate - in particular - the way in which denominators would be supplied to enable use to be made of numerator data, then the initiative it fatuous and likely to be misleading. --Tagishsimon (talk) 12:40, 11 July 2012 (UTC)
• Oppose per Tagishsimon, Fluffernutter, and Mann_jess. This is a noble concept laced with good intention, but we already have courses of action by which to deal with negative paid editing. This proposal would yield inconclusive data from which it is suggested we... draw conclusions? Impossible to execute upon in good faith. --IShadowed 14:38, 16 July 2012 (UTC)

Comment: At the root of this proposal is really a question: How can Wikipedia protect itself from clearly disruptive paid editing that undermines Wikipedia and gives everyone a headache?

I agree the proposal has some practical boundaries. We can't realistically collect the data and if we do the benefits of the data will only tell us things we already know without equipping anyone to prevent it.

However, there is a need to discuss how to proactively prevent overtly bad behavior before it occurs instead of playing a game of whack-a-mole afterwards. In the past, humiliation has always been the venue for this, but it has never been a perfect system or one the Wikipedia community has taken a role in.

It would be good to start with a brainstorm of different approaches to the problem or even just establish key facts and objectives everyone can get behind. I'm not sure this specific item is it, but there is a need for a pro-active community effort to stem the tide of disruptive editing. User:King4057 (EthicalWiki) 20:53, 18 July 2012 (UTC)

Objective: Make a substantial and meaningful reduction in unethical COI edits that are overtly disruptive to Wikipedia's goals

Qualifier: Without proclaiming all paid edits are bad and while directing companies to ways they can be helpful/ethical

Rational: We have to put an end to this game of whack-a-mole.

Possible tools: Public humiliation, higher content standards, PAIDWATCH investigations, stronger administrative actions, banning paid editors by source, other ideas

Docent proposal

We are not just an encyclopedia. We need to be more proactive, but in a way that is in keeping with the core principles of Wikimedia Foundation and Wikipedia. We have a help desk that many people use, but you have to be willing to use it. You have administrators that are there for many reasons, but mainly function when needed in specific areas for the most part and are authority. So I propose a new type of volunteer. A Wikipedia Docent. This person may have some priviledges (if needed and as determined) but would mainly function as a assistance to editors. They could be specific to area or subjects (pulled from these editors) to act as specialists on the encyclopedia to assist with usability, functionality, direction to specific policy, or just a real person to ask questions and be asked questions when needed. A docent can help with tasks on Wikipedia as well as round up task forces and organize. Good way to help retain editors.--Amadscientist (talk) 20:38, 11 July 2012 (UTC)

I can already see a new wiki-phrase coming out of this new breed of editor: "What's up, doc...?" :D --Coin945 (talk)

Well if we need a title for that task, then that's as good as any. Regards, RJH (talk) 04:27, 12 July 2012 (UTC)

It has been in use on Wikitravel for some time. Could be useful.

• Are you proposing this as a purely voluntary function, or one which must be approved by some part of the community?
• Would there be some prerequisite for the function in terms of edits, background, qualification etc. or could any user appoint themself as a docent?

• I would suggest that a docent should be a member of a relevant Wikiproject and supported by consensus of the project members, but quite open to other suggestions. We would need some way of preventing POV pushers appointing themselves. Peter (Southwood) ^(talk): 06:29, 16 July 2012 (UTC)

• I was thinking this could be something that editors nominate like admin, and could well be something done within projects (sounds like a good way to establish admin as well frankly, through projects that is). Or could be an entire new form or level of editor assistance, even with it's own notice board. I would see these Docents as having rollback and other tools (perhaps review status if that ever resurfaces) but not block or ban ability, but more like DRN where editors go with problems or questions or guidance needs. A docent could help with new editors find the right tools and be allowed to step into a dipute if needed or take some proactive measures on articles where needed with whatever tools can be provided. A docent would be something perjaps to be listed on a talkpage, so having this as a project task seems reasonable. The Docent could be listed on the Project Banner/banner shell. Somewhere visible on the talk page, project page and perhaps on the article itself as a catagory (articles with Docents..or something like that).--Amadscientist (talk) 19:38, 19 July 2012 (UTC)

I'm not sure that additional user groups/user rights are exactly what the community wants right now. For some reason, such user groups appear to have a tendency to attract the very opposite of what is required: mature, experienced editors. We've seen this even with Ambassadors. IMHO, more emphasis should be placed on rationalising the number of noticeboards and help desks, improving their performance, and helping new users to find them more easily. The topic was presented and discussed at Wikimania. -Kudpung กุดผึ้ง (talk) 00:59, 20 July 2012 (UTC)

Activate section 0 edit link for everyone

Per discussion at Wikipedia:Templates_for_discussion/Log/2012_July_5#Template:Introedit; it would be useful and convenient to activate the section 0 edit link by default, so that entire pages are not conflict-prone when editing the non-headered section at the top of pages. This is especially the case for high traffic and current events pages that receive many edits and would result in many edit conflicts, as every edit would conflict with editing section 0. -- 76.65.131.160 (talk) 06:37, 12 July 2012 (UTC)

You should start a request for comment using {{Rfc}}. It would also be a good idea to leave a note at WP:VPT. – Allen4names (IPv6 contributions) 07:07, 12 July 2012 (UTC)

Done; and, done. -- 76.65.131.160 (talk) 11:20, 12 July 2012 (UTC)

See bugzilla:156: "Add section edit link for 0th section".

In 2005 Brion Vibber wrote: "Please note that using the section-edit links does *nothing* special to avoid edit conflicts. Conflicts are merged (or not) from the full text, precisely the same way whether using section edit mode or not."

Does this still apply? PrimeHunter (talk) 12:00, 12 July 2012 (UTC)

I would also like to know if turing MediaWiki:Gadget-edittop into an opt-out feature would have an effect on reverting edits. It certainly would reduce the chance for errors provided there are no software problems. – Allen4names (IPv6 contributions) 05:16, 13 July 2012 (UTC)

Yes it still applies. There is no difference (from MediaWiki's prespective) of editing section 0, and editing the entire page but only modifying stuff in section 0. In both cases we just feed the entire page to diff3. Bawolff (talk) 17:38, 18 July 2012 (UTC)

Though, it would still make editing an easier process, if you need to edit section 0, you don't have to deal with the entire page being loaded into the editor. -- 76.65.131.160 (talk) 05:24, 15 July 2012 (UTC)

Support regardless of the edit conflict issue. Primarily I believe the user-interface is conceptually cleaner that way. But to some extent my own support is selfish, I'd rather that my own configuration match the default, I actually *like* this feature, but currently have it turned off because the Wikipedia's caches work enormously better when one stays with default rendering preferences, and this can have quite surprising differences on page-loading times. Of course, if it does affect the edit conflict issue raised the nom, that would only strengthen my support. --j⚛e decker^talk 22:03, 14 July 2012 (UTC)

Support as per nominator, Joe Decker, and my own use of it, which, in addition to lessening conflicting edits, also makes the user interface more self-consistent. St John Chrysostom ^Δόξα_{τω ^Θεώ} 09:48, 15 July 2012 (UTC)

Support This turns up regularly at the help desk - new users often fail to spot the "Edit" at the top of the page and have to ask how to edit the lead section. -- John of Reading (talk) 10:45, 15 July 2012 (UTC)

Support per 76.65.131.160 and John of Reading. -- Toshio Yamaguchi (tlk−ctb) 15:40, 16 July 2012 (UTC)

Support - I use this gadget myself, and I have no idea why it isn't the default for everyone. It occasionally speeds up editing by just loading the first section of an article, and I can't see any downside to it. Robofish (talk) 15:41, 16 July 2012 (UTC)

Support as opt-out feature. I use it, and I find it useful. Having this on by default seems sane to me. — Dmitrij D. Czarkoff (talk) 17:29, 21 July 2012 (UTC)

Support Use this myself; have extensive experience editing as an IP; would have been useful. Furthermore, no reason at all that I can think of to disable it (at least from an editor's POV)

I use it, nd I like it, but I'm concerned that it might confuse newbies, who may expect it to work like the full-page edit button because it's at the top. WhatamIdoing (talk) 17:38, 23 July 2012 (UTC)

Support, this is very convenient for editing infoboxes and lead sections without opening the entire article in the editor. So why shouldn't we have it as a default feature. De728631 (talk) 17:42, 23 July 2012 (UTC)

UK/Commonwealth monarchy update templates

I haven't found this proposal, please point me to it if already discussed.

Wikipedia has a great many articles to do with the UK and Commonwealth which make references to the monarch by name or pronoun, all of which will go out of date when the monarch changes, requiring thousands of articles to be updated. In particular, even articles without personal names have things like "On Her Majesty's Service".

It might be a good idea to have some general mechanism to update all articles automatically; I don't know the best way to do this; the following is discussion of the concept, I doubt the implementation I suggest is the best. There would be a master template which, when changed, would change the results returned by all the following templates (or each individual template could be changed, not much to do). I'm not usre of the exact wording of the templates, "UK monarchy" will stir the passions of those who point out that other countries are involved, maybe a mention of Commonwealth realms is better, but long.

There could be a set of templates, updated when necessary, maybe like:

• {{UK monarchy|His}} and {{UK monarchy|Her}} are identical, both return either "His" or "Her"
• {{UK monarchy|his}} and {{UK monarchy|her}} are identical, both return either "his" or "her"
• {{UK monarchy|KingOrQueenCaps}} returns either "King" or "Queen"
• {{UK monarchy|Name}} returns "Elizabeth II" or "Charles III"
• {{UK monarchy|TitleAndName}} returns "Her Majesty Queen Elizabeth II" or "His Majesty King Charles III"
• {{UK monarchy|ArticleName}} returns "Elizabeth II" or "Charles III"

Note that {{UK monarchy|His}} and {{UK monarchy|Her}} are exactly the same, perhaps better, perhaps not, than a single {{UK monarchy|HisOrHer}}.

Exactly what is needed needs thought and discussion.

Then in British Army#Oath of allegiance

I, [soldier's name], swear by Almighty God that I will be faithful and bear true allegiance to {{UK monarchy|TitleAndName}} {{UK monarchy|his}} heirs and successors and that I will as in duty bound honestly and faithfully defend {{UK monarchy|His}} Majesty, {{UK monarchy|his}} heirs and successors in person, crown and dignity against all enemies and will observe and obey all orders of {{UK monarchy|His}} Majesty, {{UK monarchy|his}} heirs and successors and of the generals and officers set over me.

This text would render as at present, but would be updated as soon as the templates were updated.

I, [soldier's name], swear by Almighty God that I will be faithful and bear true allegiance to Her Majesty Queen Elizabeth II, her heirs and successors and that I will as in duty bound honestly and faithfully defend Her Majesty, her heirs and successors in person, crown and dignity against all enemies and will observe and obey all orders of Her Majesty, her heirs and successors and of the generals and officers set over me.

This is particularly for UK/Commonwealth realms as a huge number of institutions refer to Her or His Majesty, but might be useful for other countries, where the name and sex, or personal pronouns, could be updated:

The US President (currently {{POTUS|Name}}) has the nucleear code. {{POTUS|He}}) must give the order...

Pol098 (talk) 10:17, 13 July 2012 (UTC)

• I am not a big fan of having templates that display some text in the article body. They make it more difficult to edit especially for newbies. It is normal that lots of articles need to be updated when a head of state changes; it is rare enough that we don't need templates to do it automatically. —Kusma (t·c) 10:22, 13 July 2012 (UTC)
  • Good point. I'll leave the suggestion in place, but I don't suppose it'll be favoured.
    
    While I'm at it, would it be useful to have categories like "Articles needing update when head of state of Xyz changes" (maybe they already exist?)? I suppose this could lead to category overload: "Articles to be changed when head of maths of Abc High School changes". Pol098 (talk) 10:34, 13 July 2012 (UTC)
    • That kind of (hidden) categories could be quite useful (and much less intrusive). Your idea reminds me a bit of things like Wikipedia:As of and the related Category:Wikipedia articles in need of updating. —Kusma (t·c) 12:06, 13 July 2012 (UTC)
      • I like the idea of a hidden cat, but not the template. Yes, there are a lot of articles that would need updating, but being that said updates will, in all probability, be decades apart, it doesn't seem like that big a deal. Heck, a bot could probably do a lot of it.--Fyre2387 ^{(talk • contribs)} 19:10, 16 July 2012 (UTC)

Automatic signing as a part of clicking the "Save page" button on talk pages?

Can you make it so that the sign wave four tildes are appended to any posting to a talk page as part of clicking the "Save page" button? I know there is a Sine bot that tries to do this after the fact, but my suggestion is to add it at the moment "Save page" is clicked. And yes, this signature was added manually: Woz2 (talk) 15:53, 13 July 2012 (UTC) :-)

I'm not sure that'd be the best idea because it's not a hard and fast rule that edits to a talk page have to end in a signature. Plus if you are listing something, oyu dont want a signature after each one. Or maybe you do... or... I can just see many problems with it.

I propose a variant of your proposal.. it is to move the signature button from being at the very top of the editing bar to being right next to the "save page" button.. I think this would make our lives that little bit easier.--Coin945 (talk) 15:57, 13 July 2012 (UTC)

This proposal would make a lot of sense if the only type of edit performed on a talk page was insertion of new comments. This is not the case however as talk page archiving, removal of grossly inappropriate material, untangling edit conflicts, and users correcting/updating their own comments are all commonly performed edits. While I sympathize with the desire to force signatures at the end of edits where they should be, this should not be at the cost of signatures being forced onto edits where the signature does not belong. --Allen3 ^talk 16:06, 13 July 2012 (UTC)

Thanks for your thoughts. Yes, putting the Sign button to the left of the Save Page button would help (to the left because I think in a left to right sequence). Or maybe have two buttons "Sign & save page" and "Save page" side-by-side Woz2 (talk) 16:09, 13 July 2012 (UTC)

I'm not sure that automatic adding of things, such as signatures, is always helpful. Some of the warning templates, like {{nn-warn}}, automatically add a {{welcome}} if they're added to a blank page. Others don't automatically welcome. It means an extra preview for me, to make sure I don't have no welcome or two welcomes if I guess wrong about which templates auto-welcome.

As noted above, trying to automatically add a signature would be a bigger can of worms. There are too many times where an edit to a talk page is not adding text to the bottom of the page, so we'd wind up with stray signatures that the editor might not even realize got tacked on. That said, adding a new button and moving the existing one might be good ideas. —C.Fred (talk) 16:11, 13 July 2012 (UTC)

I'm not convinced this cannot be easily resolved. I agree for example, that correctly a typo should not include a signature. Easily solved, correcting a typo should be a minor edit, and generally speaking, a minor edit doesn't need a signature. Are there any exceptions? Signbot doesn't add signatures to minor edits, or pure removal of material, so the rules exist.

And if someone forgets to mark an edit as minor? ♫ Melodia Chaconne ♫ (talk) 18:21, 18 July 2012 (UTC)

I don't think signing should be tied to saving an edit. As noted above, there are situations where an edit to a talk page shouldn't be signed at all. Perhaps someone can make a script that any user could install at his/her own discretion, but making it the default behavior would in my opinion cause more problems than it would solve. -- Toshio Yamaguchi (tlk−ctb) 16:32, 13 July 2012 (UTC)

{od}Signing should be automatic. Almost every discussion forum on the face of the earth automatically signs for you, so new editors are surprised to hear that it is manual. It doesn't need to be. Yes, there are exceptions, which fall into two classes: • People who don’t want to sign – this one astounds me, but it appears that some people don't want to sign. If the community accepts that, I can be handled by a user preference • Places where signatures are not desired – certain pages, obviously article pages, but also RfA, and some other places like some Arbcom pages shouldn't be signed. they can be defined and exempted. This doesn't sound hard. It is astounding that we ask new editors, who have enough to memorize without this, to learn a rule that could be handled better by a computer, and serves no useful function.

The real problem here is that we don't have a discussion system. Talkpages are nothing but wiki pages. And hence everything like signatures and replies have to be done completely manually. We don't even have a indent syntax, much less a reply syntax. These :'s we use are actually creating a mess of definition description elements leading to an absolutely screwed up markup with meaning that is in no way related to what we're using it for. What we need is more support behind the LiquidThreads Project so that it can be developed to a point where Wikipedia will accept it's use as a discussion system. Dantman (talk) 21:18, 18 July 2012 (UTC)

I agree that we should make it a user preference whether to autosign or not, and that all newbies should be defaulted to autosign. It is ridiculous that the most common feature of welcome pages has to be a sentence explaining about the need to type 4 tildas. But I'd add that we also need a sign/unsign box in the edit screen especially so that editors who have autosign on can tweak their comments without leaving another signature. We need to make this place more newbie friendly and this would be as easy and as big a win as shifting the default skin back to monobook. I'm not too keen about resurrecting liquid threads though, we had it on the Strategy wiki and it was a complete nightmare. The final straw for me was when I returned there from a few weeks of wikibreak and there were so many "new postings in threads I'd participated in" that my system kept crashing. ϢereSpielChequers 10:47, 23 July 2012 (UTC)

Automatic block for an hour after being logged in for an hour

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

---

Sitting for too long is unhealthy. To protect the health of Wikipedians, there should be an automatic time out after an hour, after which you need to wait for an hour before you can edit again. Count Iblis (talk) 18:19, 14 July 2012 (UTC)

I am currently lying in bed with a viral infection. May I please get two hours?--Ymblanter (talk) 18:25, 14 July 2012 (UTC)

But but but... Theopolisme TALK 21:51, 14 July 2012 (UTC)

That doesn't make us get up and exercise, that only means we cannot contribute new material, correct old errors, or fight vandalism for an hour. Many of us will just go on to do something else instead, meaning we probably won't get back here the instant the hour is up. Dedicated editor activity will only decrease while POV violations, vandalism, and unsourced claims will continue at their usual rate. The intention may be good (about as good as requiring breathalyzer tests to edit, even though I do some of my better writing after a couple), but that's about it. Ian.thomson (talk) 21:59, 14 July 2012 (UTC)

I propose that after an hour, Wikipedia activates a Rube Goldberg machine that eventually sprays you in the face with water. elektrikSHOOS (talk) 22:04, 14 July 2012 (UTC)

Agree with Elektrik Shoos's suggestion, provided I can connect the spray pump to a hydroelectrically powered machine that makes women like me. Ian.thomson (talk) 22:09, 14 July 2012 (UTC)

We should also remotely monitor all unmarried female editors for their growing bellies because extramarital sex is immoral. Furthermore, the webcams should report anyone having more than one piece of chocolate per day. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 01:07, 15 July 2012 (UTC)

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

Not to re-open the pointless discussion, but this was pointy-ness, not a mistimed April Fool's joke. See Meta for the context. WhatamIdoing (talk) 17:50, 23 July 2012 (UTC)

Black Tobacco

Need an article on Black Tobacco.

Request at WP:RA or create it yourself at WP:AfC. ~~Ebe123~~ → report 02:49, 19 July 2012 (UTC)

Blonde Tobacco

Need an article on Blonde Tobacco.

Request at WP:RA or create it yourself at WP:AfC. ~~Ebe123~~ → report 02:49, 19 July 2012 (UTC)

Urine Reading in Chile

Need an article on Urine Reading in Chile.

Request at WP:RA or create it yourself at WP:AfC. ~~Ebe123~~ → report 02:49, 19 July 2012 (UTC)

Discussion at WT:BABEL#Revising Babel templates according to IELTS scale

You are invited to join the discussion at WT:BABEL#Revising Babel templates according to IELTS scale. —Yutsi ^Talk/ Contributions ( 偉特 ) 19:34, 18 July 2012 (UTC)Template:Z48

Gamified Wikipedia

I had an idea that I feel would be well suited for a Wikimedia project. The idea is basically to create a immersive game-like experience of data on wikipedia. Or, in other words, to provide a spatial and temporal map of wikipedia content.

Here is a short overview:

Imagine that you can go through time and locations on Earth. For every time period and location, ordinary people or famous historical figures can be "met" (e.g. Joan of Arc). "Talking" with them produces quotes from original sources.

Also, at any given time or place, there are historical events - each event is significant for a given number of people (event's "magnitude"). Examples include wars, rebellions, weddings, scientific discoveries, political upheavals and similar. People could talk about events: "Did you hear about the Second Punic war? Hannibal attacked Saguntum in Hispania!". And all events and characters could be links to wikipedia content.

Wikipedia already hosts all the necessary data in semi-structured form, and the available time period could expand back in time as the project develops.— Preceding unsigned comment added by Ilija_Pavlic (talk • contribs)

We're already an MMORPG. As Wikipedia is constantly changing and not stable, I'm not sure it would be an appropriate basis for another game. Ian.thomson (talk) 20:15, 18 July 2012 (UTC)

Bojemoi, NO! How many billions of dollars are you willing to donate, Ilija, in order to set up such a game and keep it going? This is not how an encyclopedia works. (There is nothing in our licensing, however, to prevent some deep-pockets third party from doing something like this, if they wanted to spend the money.) --Orange Mike | Talk 20:31, 18 July 2012 (UTC)

Deleting pages

Why don't allow registered users the right to delete pages in their own user space ? Xentram (talk) 01:35, 19 July 2012 (UTC)

You can request the deletion of any page in your own userspace using the tag {{db-self}}. Full information on speedy deletion can be found at Wikipedia:Criteria for speedy deletion. Deletions within one's own user space are considered valid under criteria G7. Once you tag a page in that way, an administrator will be by shortly (usually anywhere from a few minutes to a few hours) to delete the page. --Jayron32 01:41, 19 July 2012 (UTC)

It would be too easy for editors to abuse the ability to delete in their own user space to delete content they are not supposed to be able to delete. Going through CSD allows an admin to check for that sort of thing. Monty₈₄₅ 01:45, 19 July 2012 (UTC)

• Say for example how it can be abused? It's quite clear that all contents on user space must have been created by user.So, he/she has right to decide whether keep it or delete it.Xentram (talk) 01:47, 19 July 2012 (UTC)

I can see both sides of the argument to this suggestion. A user has the right to delete content from their own talk page/main user page if they wish. So really that aspect should follow through to deleting pages within their own user space. However, I can see the flip side of it too. A user could also get over zealous and just go on a user space deleting-rampage, which in all honesty isn't productive for the main encyclopaedia project. We could end up with people just creating/deleting pages out of boredom instead of concentrating on article collaborations. The only way around it that I can think of, would be to just give the option to delete pages in their own userspace and nothing else. But that tool could also come with sanctions for misuse too, similar to that for Twinkle users. Wesley Mouse 01:54, 19 July 2012 (UTC)

It would be trivial to abuse: move some page to one's userspace; delete page. — Coren ^(talk) 01:57, 19 July 2012 (UTC)

Surely the system can identify pages that were created by the editor, as distinct from moved by the editor? (I see that this is true but rejected as "hacky". I also see and support the more limited extension - allow deletion if you are the only contributor.)--SPhilbrick(Talk) 13:39, 20 July 2012 (UTC)

• This idea is listed in perennial proposals plus you can find a number of previous discussions. — AlexSm 02:00, 19 July 2012 (UTC)

Paid editing good/bad examples publicizing

A wall of shame/fame for COI editing to publicize good/bad COI examples that will encourage better behavior and educate folks one example at a time.

Wall of Shame & Fame

The Wall of Shame and Fame is intended to demonstrate and publicize clear examples of poor and good editing with a conflict of interest. Humiliation in the media has deterred many companies from unethical participation on Wikipedia, but the Wikipedia community doesn't feel like this tells the whole story. Editing with a conflict of interest in ways that are positive and helps Wikipedia improve its coverage deserves equal representation The media is overly focused on large corporations, but schools, non-profits and small businesses are often disruptive as well. Editors with a conflict of interest are sometimes publicly shamed in the media, even though they don't necessarily deserve it by our standards. This page is intended to humiliate organizations that deserve it for overtly corrupt censorship on Wikipedia, while giving equal weight to praising organizations that help Wikipedia improve its coverage. In this way, we hope to encourage participation we like, while doing an even better job discouraging unethical participation on Wikipedia. Wall of Shame Criteria Organizations can only be included in the Wall of Shame if: Someone has made every reasonable effort to contact the organization Substantial disruptive and deceitful behavior has taken place, to the extent that we cannot reasonably assume good faith We believe that their actions constitute an overt, intentional effort to undermine Wikipedia List Company XYZ: An IP address from company XYZ tried to censor controversial information about ABC. Checkuser verified six different sockpuppet accounts from this company. They engaged in deceitful behavior by using these sockpuppets to vote in favor of deleting negative content. Nomination for wall of shame approved with a vote of 10:1. Moved to wall of shame by admin XYZ Wall of Fame Criteria This is not a method for promoting paid editors, but for showing examples of specific organizations that have done work Wikipedians approve of The Wikipedia skills of the organization may be a factor, but are not the primary premise of nomination Organizations that demonstrate a long-term respect for the Wikipedia community and participate in a way that improves our coverage may be nominated Organizations are only included if they actually want to be An organization is not allowed to nominate themselves or solicit for nomination List Company XYZ: Engaged in a corporate social responsibility program to improve Wikipedia's coverage of subjects in their space. They repeatedly demonstrated exceptional neutrality by covering negative aspects and not whitewashing articles on subjects for which they are involved. Company was transparent and collaborated with dozens of editors. They donated 120 images to Creative Commons. Nominated for wall of fame with a vote of 10:0. Moved to wall of fame by admin xyz

Speedy deletion of machine translations

Machine translations from foreign language wikipedia articles are hard to clean up.

Consensus from the people trying to tidy them so far at WP:PNT: They should be deleted.

{{No-rough}} already says Please do not add machine translations of foreign language articles to Wikipedia..

No information is lost: Everyone can repeat Google translate as assistance when doing proper translation.

Requests for translation still prossible: Everyone can request a proper translation of a foreign language article using {{Expand German}} (template exists for all languages).

Suggestion: Create Speedy Deletion A11 Machine translation of article from other wikimedia project.

Lumialover (talk) 15:34, 21 July 2012 (UTC)

As a member of WP:PNT I support this proposal. Machine translations are far from perfect and are prone to give ambiguous and confusing results. While they may be helpful in a process of proper translation from one language to another before posting an article to the live namespace, original output from translation software should not be used as the only means to create new articles. Simply because they are utterly unreliable. De728631 (talk) 15:47, 21 July 2012 (UTC)

• Comment I see a problem with identifying machine translations. While we may all be pretty sure we know what one is, and while there are highly suggestive features, some editors produce poor translations while swearing up and down that they actually translated the material. At a minimum, they will usually have omitted some bits, added wikilinks. Some of these may be good faith translation attempts where they just had no idea how much they needed to re-work. It's going to be a continuum, and speedy deletion is a big hammer; only an admin will be able to see the page to reconsider the determination that it was a machine translation and not just a very inept machine-aided translation. Can we fairly determine where to draw the line? Also, and related, very often an editor will expand an article with machine-translated material, or material not far from machine translation. If we make machine translation subject to speedy deletion, we create a precedent for harsh treatment of those who expand using this methodology, which is often applicable to only one section of an article, or a temporary stage (the original editor may in fact intend to return and improve the translated segment). Again, I'm seeing problems with implementation. Yngvadottir (talk) 16:57, 21 July 2012 (UTC)
  • We have the same problem with sockpuppets and have a solution: someone who is indistinguishable from a sockpuppet can be blocked as such. Thus, if someone did such a bad translation that it could be considered a "machine translation" and thus "failed a Turing test", we can delete it anyway. "Good faith" doesn't matter: the ones who add machine translations are no vandals too - they also mistakenly think that they are helping. And they should be forced to go away or choose a work that they can do well - although, of course, that must be done politely. Speedy deletion seems to be just that - harsh, but polite method to say that such work is not welcome here. Much of that is also applicable to expansions. --Martynas Patasius (talk) 19:24, 21 July 2012 (UTC)
• Comment It occurs to me that "cut and paste into Google Translate" results are going to end up having unambiguous copyright issues. If they're from copyrighted material in the first place, that's a direct issue, if it's automated translation of other Wikipedia work it's *also* removing the contribution history of the original article unless that's indicated. I haven't run across many "just an automated translation" articles, is my guess here on-target? --j⚛e decker^talk 17:12, 21 July 2012 (UTC)

• Translations of non-free copyrighted texts can be disposed of by the usual means (CSD G12). For Wikipedia articles there's a talk page template {{translated page}} that points to the original version and that should always be applied. As to the automated translation process, the WMF has just taken a look into it at meta:Wikilegal/Copyright for Google Translations and found that Google can't possibly claim any rights in the output, so that shouldn't be a problem. :De728631 (talk) 18:02, 21 July 2012 (UTC)
  • De728631: Thanks for the clarification, that makes sense. --j⚛e decker^talk 19:49, 21 July 2012 (UTC)

• Support, no information is lost, and translating from scratch is faster, easier and more fun than attempting to clean up the products of Google's "translation" service. —Kusma (t·c) 19:20, 21 July 2012 (UTC)
• Support. Such translations are deleted in Lithuanian Wikipedia and the process seems to work well. After all, translation must be done by humans who know both languages sufficiently well, understand the subject matter and are willing to do some work, not by computers. Bad translations are worse than nothing. And if someone wants to disagree, there was one discussion - Wikipedia:Village pump (miscellaneous)/Archive 35#Was he a real person? - where a machine translation resulted in quite a misunderstanding. That was about someone who has died rather recently, but one should also remember that "BLP" problems are possible too... --Martynas Patasius (talk) 19:36, 21 July 2012 (UTC)
• Support, so long as the translation is unambiguously "unimproved" (noting Yngvadottir's concerns). I'd also like to see a usage note suggesting that in general the tag not be applied in the first (hour/few hours/24 hours) or so after the text is applied, so as not to bite editors who want to autotranslate and then work in-place from the automated translation. --j⚛e decker^talk 20:03, 21 July 2012 (UTC)

• Proper translation requires speaking both languages fluently. Can you trust references in a translated article from an editor not speaking both languages? An editor speaking both languages will translate the original text line by line, not dump a machine translation and later try to improve that. When editors are doing in-place translations they sometimes dump the foreign language wikipedia text, not machine translations. Practical experience also proves that editors dumping machine translations are not able to improve the machine translation later. Lumialover (talk) 11:21, 22 July 2012 (UTC)

• Oppose. The articles can still be cleaned up, but machine translations shouldn't be used. ~~Ebe123~~ → report 13:28, 22 July 2012 (UTC)

• The problem is that even the cleanup process might not improve such articles when the translation output was wrong from the beginning. And in many cases, cleaning up the garbled results of machine translations takes much more time and effort than writing a new translation from scratch. Therefore machine-translated articles shouldn't be used at all and be deleted on sight so we may start from scratch with a man-made translation by knowledgable editors. De728631 (talk) 13:36, 22 July 2012 (UTC)

• Support. Any useful "cleanup" equals re-translating manually from scratch. There is no reason to give any credit to users for creating pages through automatic translation, while burdening other users with all the work to make it into readable prose. As for recognizing a machine translation for what it is, this is usually no problem if you know the source language. Things like very literal translations of proper nouns tend to give the game away. --Hegvald (talk) 16:09, 22 July 2012 (UTC)
• Strong Oppose; not all translations can be classed as "rough" which are done by machines. I've seen a good few village stubs which use {{Expand Turkish}} or such, which are translated perfectly. ⇒TAP 16:20, 22 July 2012 (UTC)

• So how do you know that those were machine translations? Surely the {{Expand Turkish}} tag alone is not an indicator. De728631 (talk) 17:10, 22 July 2012 (UTC)

• Strong oppose Does anybody who is voting "support" here know just how productive google translate has been for me and how many articles I've produced which have been quite rough initially but after being proof read develop into valuable articles? We have a severe lack of people trying to transfer content from other wikis as it is. People need to be encouraged to do the groundwork and invite our resident foreign language speakers to assist them. Altes Stadthaus, Berlin was a machine translation and with the assistance of fluent speakers checking it is now a GA in a short period of time. If it had been deleted because the translation wasn't initially word perfect we wouldn't have an article let alone a GA. We have Template:Rough translation for a reason. If the translation though is essentially gibberish because it so bad, then deleting it would be more appropriate I think, depends on the case. But from my perspective any missing articles attempted to be put into english is a positive step.♦ Dr. Blofeld 16:30, 22 July 2012 (UTC)

• Anyone is welcome to support the folks at WP:Translation. But rough translations should never be dumped into the article namespace without prior proofreading. That's why there are offline text editors and that's why we have a user namespace where people may have their own sandbox for experimenting with translated articles and having them proofread before posting them to the article space. This proposal is not meant to ban the general use of Google translate or other such services, this is about preventing the useless products of careless editors who copy and paste their automated translation and then leave it to others to fix it. If it serves your needs you're of course welcome to use machine translations for a first draft but please don't do that initial work in the article namespace. That's why we have {{no-rough}} too. De728631 (talk) 17:10, 22 July 2012 (UTC)

• It is absolutely fine to use Google Translate as a tool in your article work. This proposal is about deleting pages that are nothing but machine translations dumped into Wikipedia. I am happy to help with translating content from languages I am speaking, but I will not lift a finger to improve autogenerated nonsense. Altes Stadthaus, Berlin was carefully edited and obviously does not fall under this proposal. An example of the problem is Sulm (Germany), where somebody dumped a machine generated text five years ago, and it still has not been fixed, or Battle of Sinsheim from 2011. Nobody seems to like doing the cleanup, while a collaborative "let us write something together" or "let us translate together" project is fun and creates much better articles. We need to encourage translation and cooperation (most human translations need human copyedits) and discourage dumping of machine produced seminonsense. —Kusma (t·c) 08:50, 23 July 2012 (UTC)

• Strong oppose You don't need any special tools to deal with it, it would be like having three different coloured shovels which are otherwise identical, when they all clean up the same way. There are already rules which cover removal of crap. "Machine translation" is just another stick to hit other editors with resulting in more silly arguments, this time across language barriers. Machine translations are brilliant for too many reasons, pick any major article and click another language, the pictures alone will get you mono-linguists started with the idea that there are plenty of simple things you can gain without a complete understanding. I contribute to more than 2 dozen language wikipedias in many languages I don't speak at all without any problems. All my problems are here on Eng.wikipedia believe it or not. Rough translations fit into the same cleanup categories which exist already. Penyulap ☏ 16:55, 22 Jul 2012 (UTC)

• Would you then agree that {{db-nonsense}} is applicable for extreme cases? De728631 (talk) 17:10, 22 July 2012 (UTC)

• In short, if you can understand it, G1 does not apply. So if you cannot understand it, it does apply, if that is unclear then yes, we can add it. Basically I think what the question here is, is a machine translation itself of any use in general, not so much if it is useful on wikipedia. If you answer that question by itself first of all, then you can answer the next question, is it useful on wikipedia to the readers. I would say, following years of experience with machine translations of the languages I cannot manage to master, that yes, it is useful. That is honest and must be stated, it IS useful. That said, what is the problem, yes, it's a surprise when you run into it in an article, so we should examine if the situation needs better explaining to the reader or not, if the reader understands the limitations and possible problems, I think, like me, they would find it useful. There are a few cases where the machine translation, just like any other edit, is an unhelpful edit. I'd say if you can't understand it well enough to verify it or consider it non controversial, then sure, like any bad edit delete it. But saying delete it just because it is machine translation alone is like saying delete the article because Daniel Citizen wrote it, that's patently unfair. There is a human behind the machine, as well, so there is another level to address it, to say, is this person editing very well, adding useful things, and if not, can I talk to them about it and so on. There are lots of shovels to clean things up now, so maybe it is best to examine if the documentation shows all the places the shovels are, to make them easy to find in case of emergency. What to do, where and when to do it and how. Let's not use a blunt instrument and throw away such a valuable tool. Google translate IS popular and we have interwikilinks for a reason. You should go and find your favourite article and click on a language that does have a star next to it. You will be surprised at how useful that alone is, even when you cannot understand the language, Images are the icing on the cake, and you can sneak a taste of the icing right now. Penyulap ☏ 14:59, 23 Jul 2012 (UTC)

• This is neither a monolinguist issue nor do we seek a total ban of automated translations. As long as people keep such semi-ready articles to their userspaces or to "Articles for creation" I'm totally fine with using Google translator and other tools for a first draft. The problem is rather that many people tend to dump some auto-translated text into a new article and then forget about it. And even when a lot of such articles may be intelligible to the common reader without much improvement, I consider it bad encyclopedical practice because a) the machine translation may have changed or omitted important information and context because b) they are unreliable, c) the article will quickly be mirrored on the numerous Wikipedia clones and will then spread its factoids to the web and d) even if there is good faith behind such article creations, it is simply impolite to leave the major work of cleaning and correcting the article to others instead of creating either a readable stub or asking for a professional translation at WP:Translation. I have translated a good lot of articles from other Wikipedias in four or five languages and I do value interwiki links for that purpose. But machine translations are far from being usable for a standalone article without major improvement – and most machine translations I have come across at WP:PNT have not receiced this imrovement and copyediting from their original creators. One properly created translation has a much higher educational purpose for the reader than a dozen garbled or even halfways intelligible automated articles. De728631 (talk) 15:31, 23 July 2012 (UTC)

I agree with almost all of what you are saying, although possibly I do think that a big machine translation is better than a small stub, the rest I do understand and agree with. My concern is the manner in which the solution is rolled out. It's too easy for it to be abused. Like the other day someone was tagging and complaining about COI for a newbie they just gather up a bunch of templates and throw them all at the newbie with nothing to support their arguments. I'm not saying that is the mainstream, I'm just saying don't call it "Use this label if you spot any machine translation whatsoever, it's a great way to BITE without meaning to" or {machine translation} for short. If we can make the what to do if you see a machine translation docs better, so that there is just the slightest reading involved, it would be a small speedbump to balance against the language barrier and the shock to the senses of the rough translation. People have to engage their brains on this one, or you'd get a world of hurt in discussion. Let's look at cutting down the workload of dealing with the machine translations a different way, or improve the presentation of this proposal to illustrate just how hard to cope with the problem actually is. Penyulap ☏ 17:11, 23 Jul 2012 (UTC)

No offence Penyulap, but if you put in a bit of time at PNT you would realise just how utterly wrong you are when you say "a big machine translation is better than a small stub". this is a big machine translation, so is this and this. Can you honestly say that you think Wikipedia would be better off for having these?--Jac16888 ^Talk 17:28, 23 July 2012 (UTC)

I'm looking at three that I would keep, and label the first one with a newbie invite 'this is a machine translation, you can help improve it' the second one is harder, because the software and bots could help there. Find out how the other two editors did their articles, and look to make guidelines there. A template that says {does not meet minimum requirements for machine translation} would be better by far, and address that problem. You could get a slap-on template or a speedy for that kind of thing, but not the blunt instrument of {any machine translation} one I would look to deleting under copyright if it hasn't been attributed, and the third has problems so small they are nothing to get upset over. Overall however, you may be asking the wrong person in a way, because I am designed to read anything at all, not just text but everything beyond the text, vandalism, as well as body language, images, tones in conversations, dynamics, everything. But on the other hand, I can emulate a group of readers, so go with minimum guidelines for a speedy delete and you'll have it there, as a slippery slope no doubt, a foot in the door where people won't take notice as to what you are deleting or notice the stiffening up of the guidelines leaning too heavily towards deletion. But that is a price to pay for helping the people doing it to use better methods just to pass the test which you create. It's one compromise that is productive in the correct manner, rather than just producing BITE. Go with {this article does not meet minimum requirements for machine translation} as well as {this is a machine translation which means it is blah blah and you can help improve it} Penyulap ☏ 18:32, 23 Jul 2012 (UTC)

• Question How is this anything at all except just another excuse to cause fights and arguments. Wikipedia isn't finished yet, it's a work in progress. (back to work you lot!) Penyulap ☏ 16:55, 22 Jul 2012 (UTC)
• I think that the key issue between the opposes and the supports is the usage of a machine translation. What Thine and Blofield are referring to are cases where machine translations are done properly, and only as part of the article creation, with proper formatting and follow up clean up. Obviously such articles are helping the project, not hurting it. However what does not help are the cases, which happen fairly often, where somebody just copies a foreign language article, runs it through google translate, pastes it here, sticks a rough translation tag on and leaves it for someone else to tidy. A case in point being one such article I IAR deleted today, 3асс, Григорий Христофорович - for those who can't see it was a direct machine translation of the front end text, meaning it included all the "[Edit] - Wikipedia, the free encyclopedia" sort of things and had been left for someone else to deal with. These are often useless, and cleanup doesn't happen, instead when we (people at PNT) get round to them we generally either stub them, or retranslate them using google as guide, just try tidying an article listed at WP:PNT without using the original and a fresh translation and you'll see why. Therefore instead of a new criteria I would support the inclusion that A2 can cover unedited and unformatted machine translations where no effort has been made to improve or inclination from the creator that they would do so--Jac16888 ^Talk 17:21, 22 July 2012 (UTC)

Dumps without any formatting or attribution yes are problematic. but even then I think it would be better to incubate them and alert a relative wiki project as the article might be important.♦ Dr. Blofeld 18:19, 22 July 2012 (UTC)

Dumps like this? It was over a year before this article was made readable, and it wasn't tidied it was retranslated from the german article from scratch. And I've made attempts to reach out relevant Wikiprojects before, I've never received any help from one, even the ones that have any active users are pretty much useless. The simple fact is that a machine translated dump helps no one, if someone wants to look at the article so badly they would be better of using google translation to view the foreign language article on it's home wikipedia, if someone is interested in having the article here they should make the effort to do it properly, and having a the machine translation already here is more likely to hinder them than help--Jac16888 ^Talk 18:25, 22 July 2012 (UTC)

• One example of a machine translation is Altes Stadthaus, Berlin, which I created a short while ago from de:Altes Stadthaus (Berlin) (FA on de-wiki), which is now a GA here. My most recent translation (under construction right now) is User:Thine Antique Pen/Köllnischer Park, which is entirely from de:Köllnischer Park, but has had many bits of it chopped, removed, but is being entirely rewritten. ⇒TAP 17:27, 22 July 2012 (UTC)

  I do not see any problem with this article, as soon as it is in your userspace. I agree with the others though that putting machine translations to the article space should lead to speedy deletion as they most likely never get tidied. Whoever is willing to work on them is welcome to move them to their userspace.--Ymblanter (talk) 17:30, 22 July 2012 (UTC)

• That's what I mean Thine (TAP? Pen?), that's how google translate should be used, I'm assuming you didn't just dump the machine translated german text into an article. As far as I can tell you and other editors instead created the article bit by bit, with proper formatting and presumably fixing grammatical errors and rewriting the parts that didn't make sense, am I right? In this way you've improved the project. However imagine you're faced with this to cleanup, it would be virtually impossible to fix (and took over a year and several noticeboard postings before a very talented multi-lingual person retranslated it, note that they did not "fix" the article problems, they retranslated the article section by section)--Jac16888 ^Talk 17:38, 22 July 2012 (UTC)

• Of course not. :) If I did, which I've tried before, there are messed up references with capital 'H''s in 'http(s)'. Also, the article becomes a load of gibberish if that is tried, and always has to be rewritten, unless a miracle occurs. ⇒TAP 17:50, 22 July 2012 (UTC)

• "unformatted" shouldn't be part of the criteria - when pasting the source from a foreign language wikipedia article to Google translate the formatting stays intact. Except for a small ref issue User:Lumialover/Fritz Kortner is a verbatim output from google translate of todays featured article in the de wikipedia. It takes an 5 minutes and no understanding of the article contents to fix the obvious formatting errors and dump the result into Fritz Kortner. Lumialover (talk) 17:54, 22 July 2012 (UTC)

• Oppose - Having pure machine translations is undesirable. I think this is not a situation suited to speedy deletion though; prod would be more appropriate and allow time for improvement of the initially bad draft. If prod is contested without improvement, AfD should follow. LadyofShalott 19:51, 22 July 2012 (UTC)

• If there is no consensus for speedy deletion at the end of this discussion, we might in fact take up that thought. Articles that have been listed at WP:PNT for a full translation, i.e. new articles with non-English content and no corresponding Wikipedia articles elsewhere, are now usually prodded after two weeks without progress, or the non-English content is removed. As a weak solution (imho) we could then expand the prodding policy to machine translations. De728631 (talk) 22:04, 22 July 2012 (UTC)

Assume I dump the machine translation User:Lumialover/Fritz Kortner into Fritz Kortner today, would you also oppose reverting that edit?

If you would support reverting that edit, you should consider supporting this proposal.

There is already a proper way to request a translation (that is also already used in Fritz Kortner): Short article (might be stub) with {{Expand German}}. This also gives all readers a link to the Google translation without the machine translation being dumped into wikipedia.

Assume other editors would improve User:Lumialover/Fritz Kortner, would they improve only the obvious formatting problems, or also verify that all of the contents is correct, especially the contents with refs?

Lumialover (talk) 10:30, 23 July 2012 (UTC)

• Oppose Speedy deletion is already a problematic area with a lot of newbies getting bitten. If we allow people to speedy delete something because they think it has been machine translated then we will inevitably get a load of editors whose English is imperfect having their articles labelled as machine translations and deleted incorrectly. There's also the issue that machine translation itself is an improving technology, but our policies have considerable inertia, and if you introduce a policy against current machine translation it will be difficult to reverse until long after the policy has become obsolete. ϢereSpielChequers 11:03, 23 July 2012 (UTC)

  The most common case, a Google "translation" of a foreign language Wikipedia page, is easily checked before deletion. I do not believe machine translation will be possible before the advent of artificial intelligence, which is probably so many years away that we shouldn't hold our breath and freeze our policies until then. —Kusma (t·c) 11:58, 23 July 2012 (UTC)

• Oppose PROD is good enough. Most of the supports are based on an unsubstantiated claim that nobody ever cleans up poor translations, which just isn't true—but they could make it true with this proposal, because it is true that people don't clean up material that they can't read because it was speedy-deleted while they were working on it. WhatamIdoing (talk) 17:56, 23 July 2012 (UTC)

Example of machine translation

da:Fodsvamp	Machine translation
Fodsvamp (tinea pedis) er en infektion med hudsvampe (dermatofytter) som lever i det yderste hudlag hvor cellerne er døde, det såkaldte hornlag.	Athlete's foot (tinea pedis) is an infection with fungi that cause ringworm (dermatophytes) live in the outer layer of skin where the cells are dead, called the stratum corneum.

I picked a random medicine-related stub and did a machine translation. This is Danish, which I can't read at all. Now I think we can agree that the machine translation has some problems (I assume, but don't actually know, that the Danish grammar is correct), but is this really the sort of thing that's so impossible to clean up that we need to delete it instantly, even if we hadn't all already agreed that deletion is not a valid form of cleanup? WhatamIdoing (talk) 18:06, 23 July 2012 (UTC)

Cleanup is impossible. If you can cleanup User:Lumialover/Fritz Kortner without removing any contents or refs I pay you $100.

{{Expand German}} does everything that makes sense (see Fritz Kortner for example) including one-click access to Google translation of the foreign article and notifying translators that an editor wishes a translation - without dumping a machine translation into wikepdia.

Lumialover (talk) 18:42, 23 July 2012 (UTC)

• Shall do so. ⇒TAP 18:50, 23 July 2012 (UTC)

Sure, it is possible to try clean it up. Let's look at the possible results:

• Athlete's foot (tinea pedis) is an infection of fungi that is caused by ringworm (dermatophytes) living in the outer layer of skin where the cells are dead (called the stratum corneum).
• Athlete's foot (tinea pedis) is an infection caused by fungi that cause ringworm (dermatophytes) to live in the outer layer of skin where the cells are dead (called the stratum corneum).
• Athlete's foot (tinea pedis) is an infection of ringworm (dermatophytes, living in the outer layer of skin where the cells are dead, called the stratum corneum) caused by fungi.
• Athlete's foot (tinea pedis) is an infection caused by fungi that cause ringworm (dermatophytes) that live in the outer layer of skin where the cells are dead, called the stratum corneum.

Well? Which of them is closest to the truth? Let's look at the article Athlete's foot: "Athlete's foot (also known as ringworm of the foot[1] and Tinea pedis[1]) is a fungal infection of the skin that causes scaling, flaking, and itch of affected areas. It is caused by fungi in the genus Trichophyton and is typically transmitted in moist areas where people walk barefoot, such as showers or bathhouses.". So, the fourth one is close, the three other are not. But, at the first sight, they do look "clean" - and that only makes disinformation worse and harder to detect.

And let's note that it was an example of translation from one Germanic language to another (and, presumably, an example of a relatively good translation). If we end up translating between languages that are more different than that, the results will be worse. --Martynas Patasius (talk) 19:44, 23 July 2012 (UTC)

User warnings

In some cases, {{blp1}} is useful for warning those who engage in blatant violations of BLP policies. For those who continue, you then use {{blp2}}, and the blocking admin would use {{blp3}}. That warning series is not recognized by Huggle. Other templates, such as {{blank}} are useful in some scenarios. These are all in Category:TestTemplates, which would be useful to “import” for standard use. Is there any possibility that this can be considered? 69.155.143.96 (talk) 21:45, 22 July 2012 (UTC)

What do these templates do that the {{uw-defamatory1}} and {{uw-delete1}} sequence of warnings don't do? —C.Fred (talk) 22:07, 22 July 2012 (UTC)

The TestTemplates have a purpose. The one for defamation is a “3im” template, if you will, for blatant defamation, which only allows two warnings. These templates are useful, and at least I use them. The {{blank}} template is much more informative, and has at least some purpose and use. If you don't agree, then, perhaps, these templates should be nominated for deletion? 69.155.143.96 (talk) 01:21, 23 July 2012 (UTC)

Categorization and parent entity merger

We have a category merge discussion going on at Wikipedia:Categories for discussion/Log/2012 July 21#Category:Boston State College alumni concerning a college which was eventually merged into another school. I am being told that there is an existing consensus to merge all alumni into the most recent successor school. This, I think, is ill-advised. The problem, in the end, is that the people to be recategorized are not alumni of the successor institution, which was already in existence at the time they graduated from a different school. In other similar situations, we may or may not follow this convention. For example, the subcategories of Category:Locomotives by railway are organized by the name of railroad at time of operation, not by ultimate successor.

I can see some logic to piling everything together when an entity simply changes its name. When entities merge, however, I would hold that, as a rule, they need to be treated as separate, and categories divided by entity should respect that separation (though I might be argued into making the subsumed entity a subcategory). Mangoe (talk) 02:01, 23 July 2012 (UTC)