Wikipedia:Village pump (proposals)/Archive 81

Source: Wikipedia, the free encyclopedia.

cannot contribute to keep wiki free

because i'm in china any chance you can accept local cards

Check your credit card to see if it has the logo for
China UnionPay
on it (you can see the logo on the linked article). If it does, follow these steps:
1) Go to the bar on the left of any Wikipedia page and click on "Donate to Wikipedia"
2) Leave the drop down currency selector in "USD - $", and type in the amount the amount you wish to donate, in US dollars (remember 1 USD is about 6.3 RMB, or 6.1 RMB after the bank charges a currency conversion fee).
3) Click the button that says "Donate via PayPal"
You will be taken to a new screen.
If you already have a PayPal account, click the login link and donate as normal. If you don't:
4) On the new screen, the first field says "Country". Click the drop down menu and select China if it isn't already selected.
The page will load for a bit, and you will then see the UnionPay logo added to the list of accepted card types.
5) Type in the number of the credit card that has the UnionPay logo on it. When you're done, a button will light up that allows you to create an account. Click that, and you'll have an account.
6) If it dosen't log you in right away, you'll have to log in. Once you do so, you can pay as normal.
7) Optional 7th step: Write a letter to the WMF reminding them that China is the second largest economy in the world, and it might be a good idea to make it easier to donate from there.
From Beijing,
Wha?
17:24, 18 November 2011 (UTC)


I've also been informed of this donation form. I'm not sure why I, editing from a China Unicom IP, in China, didn't reach it (it could only be accessable from zh.wikipedia) but that's the other, easier option, however it does not allow you to pay by UnionPay.

Wha?
17:39, 18 November 2011 (UTC)

VP/T Sorry, I meant
WP:VP/M#Wikipedia Fundraising - Donation payment linmitation (Suggestion) pointed out that the IP country recognition for the form is a little buggy. --Philosopher Let us reason together.
21:51, 18 November 2011 (UTC)

Regarding Portals

There is an ongoing Request for Comment on the purpose of Portals in Wikipedia. As this RfC has implications for an entire namespace, all editors are encouraged to participate.--~TPW 22:12, 18 November 2011 (UTC)

Using Wikipedia As A Universal Portable Health Record and Electronic Medical Record

Personal opinion: Wikipedia presents the most advanced platform for a universal medical record that could dramatically impact collaboration and knowledge generation on the human condition.

I have been a independent researcher and have spent the past five months intensely studying the problems of healthcare.

The problem for myself and many of my colleagues is that health information is abstracted so poorly into current electronic medical records, so that the human story and experience becomes reduced to a series of data points in the absence of context.

Stunning and transformative realization in my research this year that humans remain by far the best sensors. Sight, hearing, smell, taste, touch, emotion. These are truly the only instruments needed to arrive at 80% of the diagnosis for most conditions.

Imagine the impact of teaching individuals how to become "lead investigators" for their personal health experiences and relegating healthcare practitioners to lab partners, rather than "directors" of their attempt at easing human suffering.

We are incredibly powerful, and with collaborative technology and policies such as Wikipedia is developing for Encyclopedic knowledge storage, inverted to help the individual journal their own experiences in a standardized, comparable fashion, we may produce the greatest body of research on the human condition and our imperfect attempts to improve it.

I would happily devote the rest of my life to contributing to such a cause. — Preceding unsigned comment added by Laith Bustani (talkcontribs) 05:56, 15 November 2011 (UTC)

  • I don't think Wikipedia is the right place for the project you have in mind (if I understand the proposal correctly it wouldn't be encyclopaedic but entirely OR) but MediaWiki is definitely great software and WikiMedia may support a new project (I don't know). fg 07:21, 15 November 2011 (UTC)
  • Oppose not part of our core mission, would cause a mind-field of legal issues. --Cameron Scott (talk) 09:49, 15 November 2011 (UTC)
  • Oppose Pretty much what Cameron Scott said directly above.
    Wha?
    11:55, 15 November 2011 (UTC)
  • Oppose For (obvious) legal reasons as well as the fact that it's not Wikipedia, but as fg said, what's stopping someone from using the MediaWiki software to do this independently? It doesn't have to be a part of Wikipedia proper to use the Wikipedia form. Writ Keeper 14:39, 15 November 2011 (UTC)
  • Response Thanks
    Patient Centered Care
    .

It is well established that N_of_1_trial are the most valid for of scientific evidence. What I have realized is that life is the ultimate laboratory and the goings on at the hospital are in fact the most ethical research institutions available. The thing is, patients need to be the lead investigators for their own health. The rest of the healthcare system must approach the patient as a "concierge" to leverage who/what is available at a given time/place to ease the patients suffering. This is the often quoted/envied philosophy of the Mayo Clinics in the US. No one comes to hospital unless they are suffering. No one seeks a "professional" unless they are suffering. What we have done, in delegating the responsibility we each hold towards each other to "abstract concepts" is pervert the simple truth that any two people interacting have the potential to exchange knowledge and stories and come away richer for the experience. Money has distracted us from this truth. The failing economy is a symptom of this forgotten lesson. Wikipedia and all of you contributing to it may just be my nominees for the Nobel Peace Prize. Thank you. You are all inspiring. You are all my teachers. User:Laith Bustani November 16th 2011 11:59 EST.

O-P-P-O-S-E. Wikipedia can not give any medical advice. PaoloNapolitano 18:19, 20 November 2011 (UTC)

Information page here on EN Wikipedia informing about the consequences for Wikipedia if IBB gets approved

See Wikimedia supports American Censorship Day. Could we perhaps create a page here on EN Wikipedia containing information about this bill and what the consequences for Wikipedia would be (something like WP:Internet Blacklist Bill)? I am not very familiar with this, thus I am not confident I could create that page myself right now. Toshio Yamaguchi (talk) 17:57, 18 November 2011 (UTC)

Perhaps I will create an essay about it. Toshio Yamaguchi (talk) 15:38, 20 November 2011 (UTC)

4 million article party

Take this as it's meant, a little light spirit in what can sometime seem a very contentious room. Wikipedia is fast approaching 4 million articles (according to the template {{NUMBEROFARTICLES}}). That's a seriously large book! I seriously propose a less than serious mass thank you and congratulations to be thrown in the general direction of The Wikimedia Foundation and the generous genius Jimmy Wales. I imagine WMF have already thought of this insofar that a banner may be worn across the encyclopaedia for a week or so but, I'm thinking of our thanks and grats to them. We may not be able to give Jimbo 4 million bumps (an English tradition of throwing people in the air as many times as they are old in years) but we could send him 4 million Barnstars! (although that might rather screw up the servers so maybe not). You get the general idea though right? When the clock reaches 4 million there should be a general "Hoorah!". Consider mine brewing. Thanks. fg 19:05, 18 November 2011 (UTC)

You'll find me at the front of a sizable list of people that have absolutely no desire to do anything for or with Jimbo Wales. Celebrate? Yes. Celebrate with our "genius" leader? Heck no.
Wha?
19:33, 18 November 2011 (UTC)
Not too many. 1 would do. So we could just have the sitenotice for a quick celebration. Keep it for 1 day. ~~Ebe123~~ → reportContribs 21:26, 18 November 2011 (UTC)
How about a count-up to 4 million from say 3900000 then 24 hours past the goal? It's quite a hefty achievement after all. Wouldn't you think that 1 day would be a bit of a damp squib? It would be a great opportunity to grab some headlines and raise some funds (if not just for pure celebration and site-wide sense of accomplishment). fg 21:42, 18 November 2011 (UTC)
I'm part of that sizable list Sven just described. I'm grateful that Jimbo founded Wikipedia but I'm also grateful to Larry Sanger, to the numerous developers who made MediaWiki what it is today, to everyone at the Foundation and perhaps most of all to the millions of editors who created 4 million articles and helped to improve or maintain them. So yes, I'm grateful to Jimbo and to you Fred and to you Sven and to you Ebe and Jimbo is no more deserving of 4 million whatever than you are. I'm not part of a Jimbo cult and never want to be associated with one. Pichpich (talk) 00:07, 19 November 2011 (UTC)
Sven says leader and Pichpich says cult. Jeeze! No wonder threads on these discussion pages get so heated and confused. fg 12:49, 19 November 2011 (UTC)
Wikipedia has outgrown the need to praise our godlike founder, in my opinion. There are so many more people who have done so much more for Wikipedia than he ever did. Ajraddatz (Talk) 19:39, 19 November 2011 (UTC)

Does Wikipedia need a “share” button?

Disable WikiLove by default

Time for rollback edits to be unambiguously identified as such (re-prop)

Rollback edit summaries should be clearly labeled with "using [[WP:Rollback#When to use rollback|RB]]", as done by AWB, Huggle, Twinkle, and others. Example edit summary:

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 using RB)

or

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 (RB))

(I proposed this at (policy). Once clarified, it received support from 3 editors, of four discussing, aside from me, but rolled off into the archives. So I'm re-upping its central point here for wider discussion and possible implementation.) Oppose? Support? --Lexein (talk) 14:40, 11 November 2011 (UTC)

(revised specific link above. --Lexein (talk) 14:13, 14 November 2011 (UTC) )
  • Comment It is possible this would encourage greater numbers of requests for the ability. I trust admin to determine who is given/denied the ability but wonder if the potential flood of requests for it might have two knock on effects. Namely 1) A backlogging 2) Admin rushing through the requests and perhaps being less inclined to consider them as carefully when doing so. Otherwise I think it's a fine idea and do not oppose it. fgtc 15:03, 11 November 2011 (UTC)
  • Seems OK to me (either). It looks like it's in MediaWiki:Revertpage  Chzz  ►  16:25, 11 November 2011 (UTC)
  • Comment I support this, but it would be even more useful if an edit identified as a rollback were flagged as such in the API. --JaGatalk 17:32, 11 November 2011 (UTC)
  • Comment - It's already linked; "Reverted edits by....". Also,
(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44) (RB)
  • looks better, in my opinion. →Στc. 22:59, 11 November 2011 (UTC)
Please point out an edit where the word "reverted" is already linked. I literally haven't seen it. All the "Reverted edits by" edit summaries I've seen have been unlinked. Did this just happen recently? Hm. Hm hm hm. I hope I haven't been mistaken this whole time. The linked "Reverted" goes to
RB) added. --Lexein (talk
) 07:06, 12 November 2011 (UTC)
Although I don't see any good reason why the tool needs to be identified; as long as the "reverted" link remains, my soft opposition to adding a link to "rollback" can be considered even softer. fg 10:14, 12 November 2011 (UTC)
I'd be reluctantly satisfied if the "reverted" link pointed to
WP:ROLLBACK for rollback edits (because it lists explicit reasons for rollback/undo), and nothing else changed. --Lexein (talk
) 14:13, 14 November 2011 (UTC)
Seems like a very long way around the horn for an editor to learn the reason for an edit, and guesswork, as opposed to an explicit statement of reason. We're trying to retain editors, and clear(er) edit summaries can help. I'd like to know the "conversion rate" of editors who were at first "bad" editors, who later became "good", and what role clear edit summaries played. --Lexein (talk) 14:13, 14 November 2011 (UTC)
  • Gently oppose. I just don't see the point. Who actually cares whether I click the red "Rollback vandal" button or the blue "Undo" button when I encounter vandalism? They have exactly the same effect on the article. WhatamIdoing (talk) 03:21, 12 November 2011 (UTC)
All other tools identify themselves. --Lexein (talk) 07:06, 12 November 2011 (UTC)
Rollback is a core feature of the mediawiki software, not a js script or external application. Per what Sven said below, in most cases a block is required to stop use of those, whereas rollback can just be removed. Ajraddatz (Talk) 15:53, 13 November 2011 (UTC)
Its status as a core feature does not seem like a good reason to provide no direct link to the actual rollback edit reasons. See Why: below. --Lexein (talk) 14:13, 14 November 2011 (UTC)

Rollback isn't a tool, in the way that TW is, and there's no real practical difference between a rollback done using rollback and one done using restore revision and one done by undo. More importantly, abusing the revert functions is handled by blocking. It's no longer possible to remove someone's TW access, so yes, you could revoke rollback, but then someone would switch to TW. That's why if talking dosen't work, you just block. I guess what I really want to know is "Why?"

Wha?
13:35, 12 November 2011 (UTC)

Why: Rollbacks offer 1. No edit reason (I get it), 2. no class of edit reasons (rollback), 3. no unambiguous identification of the tool AND 4. the "reverted" link points to the less specific
Rollback
set of explicit reasons", without having to waste time examining the diff to puzzle it out. Unambiguously identifying the tool adds trust and saves time.
Also, from a random editor's point of view, it's just a tool, and seems unique. --Lexein (talk) 14:13, 14 November 2011 (UTC)
And this differs from the undo button how, exactly? "Undo" offers "1. No edit reason (I get it), 2. no class of edit reasons (rollback), 3. no unambiguous identification of the tool AND 4." it doesn't even offer a link to Help:Reverted.
Why should one regular software feature (rollback) be held to a different standard than another regular software feature (undo)? WhatamIdoing (talk) 17:40, 18 November 2011 (UTC)

Oppose. I really can't see what possible good this could do. Per Sven above, half of the point of marking tool usage is so that people can be blocked when they abuse it - rollback is different, since it leaves a very distinguishable summary and can be removed from the user. What's next, adding (undo) to the end of the undo summary? I just cannot see any possible benefit to this proposal, or any need for it in the first place.

If this does go through, though, please at least change it to

(Reverted edits by 12.34.56.78 (talk) to last version by 11.22.33.44 using rollback)

which looks more professional and doesn't include meaningless acronyms. Ajraddatz (Talk) 15:50, 13 November 2011 (UTC)

  • Oppose. I just don't see the point. Hans Adler 16:04, 13 November 2011 (UTC)
See Why: above. --Lexein (talk) 14:13, 14 November 2011 (UTC)
I still don't see the point. These reasons are so minor that they are outweighed by the potential disruption due to lots of difficult new editors trying to get rollback revoked for the editors who reverted them. Only editors with some idea of how Wikipedia works (in particular not a bureaucracy) should be able to recognise rollback edits. Hans Adler 10:01, 22 November 2011 (UTC)

Comment This is a functionality of mediawiki, so I don't see it any more useful than like if we changed all edit summaries to have (MediaWiki) in there, reason why there is TW, HG etc is to notice that edit was done by tool and not by the interface itself, so I don't think it's really needed. Petrb (talk) 09:16, 14 November 2011 (UTC)

I wouldn't add "Mediawiki" to edit summaries, nor reduce them to state only "edit occurred." This isn't just MediaWiki, it's an instance, with its own guidelines, like
WP:Edit summaries. See also Why: above. --Lexein (talk
) 14:13, 14 November 2011 (UTC)

A simple "last best version" marker

I know we're likely not to get Pending Changes any time soon, but I've got a few articles that I watch that will, at random times, be targets for anon vandalism from offsite sources, or other aspects that may introduce changes that can easily got lost and buried through attempts at manual fixing or reverting. Obviously nothing we can do about it without locking under semi-prot, but that's not ideal.

I am wondering if we can device some makeshift system whereby an editor of concern can tag specific revisions of an article as a "good version", marking that on the talk page, ideally alongside the other "Article Milestones" header, since actions like GAN or FAC do a similar action. The act of marking such should really only be done by a registered editor (so there's traceability in case the editor purposely or accidentally marks a bad version as "good"), with the possibility of IPs dropping a talk page tag request to have a third-party editor bless articles otherwise.

Technically, all this can be done with what we have now in wikicode and MediaWiki; a few templates here and there, a modification of the Article Milestone template, some process and rationale approach to when to do it, etc. The only thing that I'd would like to add is to have this marking record be in a separate space (like Page Notices) which is blocked from anon IP editing, simply to avoid attempts to vandalize the record. (named editors can still vandalize it, but this is at least traceable).

All this is to bless certainly versions, so that when an article "wrecked" beyond a certain degree due to fighting vandalism, a quick check of the past marked versions can give us the last best revision and a copy-paste to fix things can be done, followed by diff checking to re-add good new info. It's not required at all, it's to be used as editors see fit (not day-to-day, but month-to-month or more often for high-visibility articles), and certainly has none of the "the encyclopedia anyone can edit"-stigma that Pending Changes would have had. Plus its lightweight and requires no Mediawiki code modification.

I know technically I can do this right now by dropping such notes on a talk page, but I'm suggesting that we can formalize this with a few templates and the like. --MASEM (t) 15:07, 21 November 2011 (UTC)

Not far above us there is a similar conversation going on. fredgandt 00:48, 22 November 2011 (UTC)
Probably a good idea, but probably also worth digging through 00:49, 22 November 2011 (UTC)
The flagged-revisions feature proposal explicitly included something quite similar - a lightweight method of marking a revision as "patrolled", which was only a log entry and did not affect what was shown to readers. It was to be a second phase of the trial, but seems to have been poisoned by association with the trainwreck that was FR, and never appeared. It seens it would do the job admirably, albeit without the registration on the talkpage. Perhaps it would be easier to get that small section turned back on than developing a new method?
Alternatively, if you're looking for a stopgap, you can try null edits - make a trivial change, leave an edit summary with something like "clean stable version, 22/11/11". When you return to the page it's relatively easy to find that one edit in the history, do a diff from there to now, and see what's happened.
talk
| 13:52, 22 November 2011 (UTC)

Wikipedia mobile page loading

In Wikipedia mobile you shouldn't have to wait till the opening page loads before beginning a search. You should be able to interrupt a page loading with a new search. You shouldn't have to wait for all the images to load before being able to scroll down the page (Mozilla worked this out c 1995 with Netscape navigator)

All these are infuriating when using Wikipedia mobile with slow download times. — Preceding unsigned comment added by 58.163.175.179 (talk)

Please see Wikipedia:Bug reports and feature requests. Wikipedians can't do anythign to help with this issue. עוד מישהו Od Mishehu 12:24, 23 November 2011 (UTC)

Non-controversial admins

Render title as alternative name (with Template:R from alternative name)

There are many articles in Wikipedia whose subjects have more than one commonly used name, for example:

refer to the same article. Which alternative should be used when the subject is referenced in other articles, will depend on the context. With current practice, one of the alternative names is often chosen (perhaps arbitrarily, as the first that was used) as the 'title' name, and the other alternative names are implemented as 'redirects' to the title name. Thus, when following a wikilink to (or searching for an article for) 'alternative name', the following may be rendered:

Title name
From Wikipedia, the free encyclopedia
       (redirected from Alternative name)

This can be disconcerting to the reader, whose eye is drawn to the large text title and, especially if not familiar with the term 'title name', may be left thinking: "That's not the page I selected—has something gone wrong?" This could be easily solved by changing the rendering as follows:

Alternative name
From Wikipedia, the free encyclopedia
       (alternative name for Title name)

This would apply only in conjunction with the use of the existing "R from alternative name" template; redirects from mis-spellings, for example, would not be affected. Uniplex (talk) 08:14, 21 November 2011 (UTC)

I don't think there is an easy way to make the title show something completely different. Choyoołʼįįhí:Seb az86556 > haneʼ 08:20, 21 November 2011 (UTC)
The rendering of articles reached via redirect is already specialized; this would just specialize it a little more, so it seems hard to imagine that the implementation would be difficult. However, I think that the discussion here should focus initially on whether or not the proposal would enhance the user experience—if not, the question of implementation is moot. Uniplex (talk) 08:50, 21 November 2011 (UTC)
It could be worthwhile that if the redirect provides the right information to have a parenthetical reason after the redirect line, eg: "(Redirected from Alternate Name (common misspelling))" Given that not all redirects are done for alternative naming, this would be a better solution to explain to the reader why they're now at this page. --MASEM (t) 15:09, 21 November 2011 (UTC)
Templates "R from misspelling" and "R from alternative spelling" could of course be included in the proposal, though IMO, the effect of seeing a change in spelling from wikilink to article title, is less disconcerting than seeing a completely different term (e.g. per Shingles above), and one would hope that mis-spelled wikilinks would be corrected. Uniplex (talk) 15:31, 21 November 2011 (UTC)

I fear that this would result in more confusion than clarity. The title of an article implies a number of other properties, and those relationships would become unclear to the casual editor. For just one example, what value would magic words like {{BASEPAGENAME}} return? Powers T 15:38, 21 November 2011 (UTC)

A possible compromise would be to simply make the redirection notice "(redirected from Alternative name)" slightly larger/more prominent. fredgandt 00:44, 22 November 2011 (UTC)
In response to Powers, I would say nothing else should change: we're not trying to hide the fact that the article has another title, perhaps "break it to the reader more gently" (the alternatives will likely be discussed in the lead sentence). As Fred_Gandt surmises, the essence of the proposal is to change the relative size and position of two pieces of text; if there is a downside to doing both, a partial approach could give some of the benefit. Uniplex (talk) 06:06, 22 November 2011 (UTC)
My concern, then would be confusion caused by it not being clear what the actual (technical) title of the article is. Taking the Shingles example, we would have the article titled "Herpes zoster", but people who arrive by the "Shingles" redirect would see "Shingles" at the top, followed by a hatnote that says "'Shingles' redirects here". 'Shingles' redirects to 'Shingles'? It makes sense, but only after one stops and thinks about it for a bit, which is not good user interface practice. Also, consider the infobox; in this case, it's fine because the "real" title is the "technical" term, but in other cases it could look weird to have a different title for the infobox versus than at the top of the page. Powers T 04:04, 23 November 2011 (UTC)
I had considered the infobox, but for me at least, the eye is always drawn to the (much larger) title text first. Whatever we do, there's bound to be some weirdness that remains for the user. One other problem with the existing solution is that after being presented with a large, surprising title, the "Redirected from ... " is not much comfort: it gives no clue as to why the user has been redirected. "Alternative name for ..." is much clearer in this respect. Let's try it with the real example and look at a few more options:

Current (direct):

Herpes zoster
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Current (from redirect):

Herpes zoster
From Wikipedia, the free encyclopedia
       (redirected from Shingles)

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Ideas (from redirect):

Shingles
From Wikipedia, the free encyclopedia
       (alternative name for Herpes zoster)

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Herpes zoster
       (also known as Shingles)
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...


Herpes zoster
also known as Shingles
From Wikipedia, the free encyclopedia

          "Zoster" redirects here. For the ancient Greek article of dress, see Zoster (costume).

          "Shingles" redirects here. For other uses, see Shingle (disambiguation).

Village pump (proposals)/Archive 81
Herpes zoster (or simply zoster), commonly known as shingles and also known as zona, is a ...

Uniplex (talk) 13:46, 23 November 2011 (UTC)

I think the last one looks best, removes the astonishment, and is broadly per fredgandt's compromise suggestion. So if there are no further comments, I'll raise the ticket. Uniplex (talk) 13:00, 24 November 2011 (UTC)
Er, sorry, but what exactly is gained from that? After all, the alternative name is supposed to be listed in the first sentence of the article in bold... Not to mention that in the example the "main" and "alternative" names get listed three times (yes, in other cases there will be less mentions). Also, change as such is undesirable: what about the users who expect redirects by now? Wouldn't they be astonished instead? Also, if the user interface shows "also known as [...]" after hitting a redirect, wouldn't the user be astonished after getting to the article some other way and learning that its subject isn't "also known as [...]" any more..?
And one more problem... At the moment hardly anyone cares about categorisation of redirects. But if they will be made more prominent, they will become more important too. And the interface will make some names look more "legitimate" than others. When exactly will we confer such "legitimacy"? For example, is
Wilno"? Is Burbiškis "also known as Burbiszki"? And yes, there was a discussion (and an edit war) if that Polish name should be listed in the article ([6]). Would we have to repeat it for a redirect (yes, thankfully, there is no real redirect in this case, but what about other cases?)? I guess we would do well to sacrifice some usability of our user interface (in this case that amount is extremely small and maybe even negative - I'd say the current system is just better (yes, a little)) to avoid those problems... --Martynas Patasius (talk
) 19:47, 24 November 2011 (UTC)
"what exactly is gained from that?"— "Also known as" explains to the user why, when they clicked on a Wikilink, they ended up on what at first appears to be a wrong page. "change as such is undesirable"— transitory astonishment is preferable to permanent astonishment (and Jimbo urges that we should be BOLD in looking to the future). "learning that its subject isn't "also known as [...]" any more..?"— good point, this suggests the parenthesized version is better. “is
Wilno"?” the proposal is 100% agnostic on this. If consensus is that the "alternative name" is an alternative name (i.e. mentioned as such in the lead sentence) then being tagged as an alternative name is a consequence of this. Were someone to then suggest that no-one really cares about the tagging, that would likely be seen as an attempt to subvert consensus. (With the parenthesis back in place,) all the proposal is doing is making a pertinent piece of information prominent enough so that it is not missed, and changing the developer-centric phrase "redirected from" to the user-centric phrase "also known as" (with prior consensus that this is indeed the case). Uniplex (talk
) 06:42, 25 November 2011 (UTC)
"(With the parenthesis back in place,) all the proposal is doing is making a pertinent piece of information prominent enough so that it is not missed, and changing the developer-centric phrase "redirected from" to the user-centric phrase "also known as" (with prior consensus that this is indeed the case)." - sorry, but what "prior consensus" do you have in mind here..? I don't think I understand that part... And it seems to be crucial to your point...
""change as such is undesirable"— transitory astonishment is preferable to permanent astonishment" - well, is there a proof that there is such "permanent astonishment"? So far I can only see that you assert that this is the case. Well, I can assert that it is not - do you have any data to show that real users are actually astonished? For otherwise, while it might be that "transitory astonishment is preferable to permanent astonishment" (though I would still hope that "intensity" of astonishment should be taken into account too), it is also true that we should care about real and known astonishment more than about imaginary or hypothesised.
"“is Vilnius "also known as Wilno"?” the proposal is 100% agnostic on this." - yes, I know. That is exactly why I am objecting. First of all we would need some guideline, only then we can consider such user interface change. Otherwise we will get a "rematch" of old edit wars. --Martynas Patasius (talk) 18:54, 25 November 2011 (UTC)

Herpes zoster
(Shingles automatically redirects here)


From Wikipedia, the free encyclopedia

Whatever whatever whatever... fredgandt 07:57, 25 November 2011 (UTC)
Well, I'd settle for it, but "automatically redirects here" is not quite as as informative. It tells the reader that the two terms are probably related in some way and that the article should contain some information on Shingles (in this case), but "Also known as" tells the reader that pretty much everything in the article is about Shingles. Also, for someone not familiar with the implementation of WP (and there's no requirement that any reader should be), "automatically redirected" is something of a technical term: it relates to the mechanism, not the reason ("also known as" is an everyday term). Uniplex (talk) 11:33, 25 November 2011 (UTC)
The problem being (as stated above) that "AKA" is going to cause endless arguments and confusion. If (e.g.) "Shingles" and "Herpes zoster" have found themselves linked by traditional means (Wikiwise), the mechanism(s) are in place to create hints to that link in (what is clearly arguably) the right places. I agree that more obvious and clear indication as to why the visitor (unfamiliar with redirects) has landed on some other page is needed, but do not think suggestions of alternative names should be applied. An example could be
Furries redirects to Furry fandom
and neither can be considered an alternative for the other in any reasonable respect. Furries are members of Furry fandom (or a rock band). Too many differentials exist to whitewash the lot with "AKA".
A clearer statement showing that the search term is definitely something to do with this article is all that's needed and all that can (in all cases) be relatively guaranteed (since the redirect already exists). fredgandt 18:53, 25 November 2011 (UTC)

Actually, maybe we should just add a link to Help:Redirect? Then whoever is astonished to find a "wrong" name will have a chance to find out what happened (and how to fix it if it is really wrong - after all, everyone is a potential editor - we should never look at the readers as if they were just readers). --Martynas Patasius (talk) 19:19, 25 November 2011 (UTC)

Agreed if combined with an increased scale. So we have the Page name in big, the original search term at maybe 1/2 size and "redirected" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word. fredgandt 19:25, 25 November 2011 (UTC)
You're misrepresenting the proposal: the "also known as" indication was suggested only for names (unlike ABCDEFGHIJKLMNOPQRSTUVWXYZ) that are listed as such in the lead sentence, and naturally wikilinked elsewhere (not just searched for). Anyway, you seem sure of what you want, so I'll leave it to you. Uniplex (talk) 08:09, 26 November 2011 (UTC)

Celebration for 5 millionth edit

How about a small celebration for the 5 millionth edit? We are currently at 1,216,201,688, so we only need −716,201,688 more edits. If you think about it, it's not alot. A small sitenotice maybe? ~~Ebe123~~ → report on my contribs. 12:07, 24 November 2011 (UTC)

You mean 500 millionth edit? :) (with near on 4 million articles we'd be looking at barely 1.2 edits per page :) for a total of 5 million) --Errant (chat!) 12:22, 24 November 2011 (UTC)
No, it's 19.55 by average edits per page. ~~Ebe123~~ → report on my contribs. 20:25, 24 November 2011 (UTC)
Indeed it is; which equates to either 74 Million edits to article space, or 500 Million (half a billion) overall edits. We passed 5 million many moons ago :) --Errant (chat!) 12:55, 25 November 2011 (UTC)

If we are now on the number which is quoted, that means we have aleady passed the five millionth edit- was this figure quoted in error? ACEOREVIVED (talk) 15:54, 24 November 2011 (UTC) More specifically, it means that we are 716201688 edits past the five millionth edit. ACEOREVIVED (talk) 15:55, 24 November 2011 (UTC)

The number quoted is the magic-word {{NUMBEROFEDITS}}, and thus constantly updating. When the message was posted, it was under 500M. When you read it, I suppose it was over that. Chzz  ►  18:58, 24 November 2011 (UTC)
I suggest this thread is closed as it is clearly now redundant and seems to be nothing more than a bone of contention. fredgandt 18:37, 25 November 2011 (UTC)

Toolbar Chat on wikipedia

Hi,

I have a proposal for wikipedia

could you put a toolbar chat so that when you visit a wiki people can interact each other? --Tegra3 (talk) 10:34, 26 November 2011 (UTC)

Actually some folks already work on such feature (I don't know details), however you can visit irc channel on freenode to be able to talk to others :) Petrb (talk) 11:26, 26 November 2011 (UTC)
People interact with each other by adding and editing pages in the encyclopedia. We also have
Talk pages for direct discussions. Further, there are pages like the Village Pump where you can discuss ideas, as we're doing here. Did you want something more than that? What, specifically, do you want to achieve, that the present functionality doesn't provide? — JohnFromPinckney (talk
) 11:35, 26 November 2011 (UTC)
There is a difference between talk page and live chat, if you don't believe it, try it yourself, that's probably what he meant ;) Petrb (talk) 11:45, 26 November 2011 (UTC)
Yes i meant that :) people in the same wiki can chat for improve the content --Tegra3 (talk) 11:49, 26 November 2011 (UTC)
#wikipedia-en connect - for chat with english wp users Petrb (talk) 11:52, 26 November 2011 (UTC)
Petrb, it isn't that I didn't believe there's a difference; I just didn't see what Tegra3 wanted to achieve with something called "toolbar chat". Frankly, I get nervous at the prospect of see more stuff like
especially this and don't want to encourage things that come close. If Tegra needs to IRC with others and I can easily ignore every word, then that's fine with me. I just don't need to see discussions about Tegra's cat or digestion problems (or the cat's digestion problems). — JohnFromPinckney (talk
) 12:16, 26 November 2011 (UTC)

My Books

For those of us who are utilizing Wikipedia as a Search Engine to drive a research project, the set up to enter My Books is an arcane nonsensical process. MY suggestion: 1. Log IN should be on the face page, not the second page 2. MY books Link should be where My Talk link is.

You guys have this all configured for those contributing, and not for those who are referencing. Make it a bit more user friendly.

Secondly My Books seems to be VERY fragile. I have now LOST two extensive books, and have absolutely no idea how I did it. Deleting the entire book should be about a tripple are you very sure apparatus.

Wikipedia is a fabulous tool. I continuously use it in my research. The second I have two extra nickels, I will send the first to Doctors without Borders, and the second to you guys. Thank you, thank you, thank you for your work. — Preceding unsigned comment added by Fredwage (talkcontribs) 11:17, 26 November 2011 (UTC)

You do not seem to have made any books with this logon, perhaps your work was not saved? Or did you use a different logon to do this? (This means I do not know what to undelete to assist you). If remembering a page is very important, I would suggest book marking it on your browser, as well as adding it to your watch list. If you do log on the suggest place to put your books is User:Fredwage/Books/something. But there is nothing there. Graeme Bartlett (talk) 01:53, 27 November 2011 (UTC)

different language versions of particular article in mobile view

Hi. I use Wikipedia in Bulgarian and very often switch to English version, when there is no enough information about what i read in Bulgarian. Sometimes I don`t know the English word for something and I use Bulgarian version for starting point for my search in English Wikipedia. But I can`t do that on my Kindle because in mobile version of Wikipedia there is no side menu for different Languages. And every time I have to select the link "View this page on regular Wikipedia".

I wanted to propose this language menu to be included somehow in mobile version of Wikipedia.

When I use Wikipedia on my desktop computer and click on "Mobile view" in the end of article page, I see a drop-down list with different languages between search field and the title of article (and two buttons - HOME and RANDOM). But when I search the very same article trough my Kindle, this drop-down list and 2 buttons are missing. I thought the problem is in my Kindle, but on my brother`s smartphone the drop-down language list is missing too. I`m sorry if this is not the right place to tell this all :) — Preceding unsigned comment added by 78.90.19.22 (talk)

The short answer is, someone's working on it :-) The upgraded version of the mobile site (
talk
| 18:25, 26 November 2011 (UTC)

Warning about {{DEFAULTSORT:}} when moving a page?

(I raised this at Wikipedia:Village_pump_(idea_lab)#Warning_about_.7B.7BDEFAULTSORT:.7D.7D_when_moving_a_page.3F 10 days ago, and it got two messages of support, no opposition, and an offering of code from which DEFAULTSORT could be obtained from the database.)

I suggest that when a page containing a {{DEFAULTSORT}} is Moved, the editor moving the page should be alerted to remind them to update the DEFAULTSORT if necessary.

This could be either:

  • A warning at the time of the page move if the DEFAULTSORT is not updated, by a red text message similar to those when a file is saved with references but no {{reflist}} (although there could be cases where the DEFAULTSORT was originally wrong and was correct after the move), or
  • A warning posted on the editor's talk page, on the lines of "You have just moved [Thispage] to [Thatpage]. It has a DEFAULTSORT of [Old-default-sort]. Is this still correct? To edit it, click [here]." Ideally the edit link would go right to the {{DEFAULTSORT}} line of the moved file.

How about it? PamD 14:25, 26 November 2011 (UTC)

  • Forgot to include: there should be an opt-out so that editors who move a lot of pages and are confident that they never forget to update the sort key can choose not to get the alerts! PamD 23:17, 27 November 2011 (UTC)
I think a bot could clean up afterwards. An edit filter may also be possible. Graeme Bartlett (talk) 01:34, 27 November 2011 (UTC)

partnership between google book search, wikipedia and a website of sharing image

here in italian wiki the proposal, unlucky i am unable to translate it in english. Bye.--Seics (talk) 22:27, 26 November 2011 (UTC)

Looks like you were answered there. Rmhermen (talk) 00:44, 27 November 2011 (UTC)
Yes, i think the proposal can be intreresting for all languages of wiki.--Seics (talk) 09:00, 27 November 2011 (UTC)

The last proposal on enabling this extension received near unanimous support. It sounds like a very useful tool. Perhaps it's time to revive this discussion for another round. -- œ 10:41, 27 November 2011 (UTC)

  • Oppose: People might not want the pages. Users find the pages, and adds them. We do not need a body to push useless pages on our watchlists. ~~Ebe123~~ → report on my contribs. 16:58, 27 November 2011 (UTC)
    • It's not clear from the extension page, but you have to "subscribe" to having random articles pushed onto your watchlist. Don't subscribe and you won't have your watchlist messed with. Personally, I wouldn't use it. But judging by the linked discussion, many people would. Anomie 17:25, 27 November 2011 (UTC)
      • My point still stands as if we wanted pages on our watchlists, we put them ourselves. How about just a page where users could suggest pages, and then the user can put them at will. ~~Ebe123~~ → report on my contribs. 19:45, 27 November 2011 (UTC)
  • It looks like a very handy tool, and while I would not use it myself, I think that it should be enabled since it gives users the choice. I really don't understand where problems arise from giving users the option to do something. Ajraddatz (Talk) 18:31, 27 November 2011 (UTC)
  • bug 20523 is the bug that was opened last time. See comment 6:
From #wikimedia-tech in September 2009:
<Annemarie> TimStarling: Why did you disable PovWatch on
test.wikipedia?</message>
<TimStarling> because I was surprised it was still enabled, it was meant to be
a trial
<TimStarling> I'm not sure if it works anymore
<TimStarling> nobody has used it since it was written, 2 years ago
And it's been another two years since then. Is it even usable? Reach Out to the Truth 18:55, 27 November 2011 (UTC)
  • This would need a lot of thought as to how this is going to work - ie who is allowed to put pages onto peoples watchlists and for what reasons - this needs to be very carefully thought out as it could be easily used to push POV or effectively canvass - i.e. send pages out to editors with the same POV as yourself.Nigel Ish (talk) 21:52, 27 November 2011 (UTC)

Wikipedia:Tool apprenticeship is a proposed process in which experienced users with a need for an administrator tool may be given the tool on a trial basis, and get to keep it later if they use it responsibly. I've opened an RfC about whether to conduct a six-month trial of this process at Wikipedia_talk:Tool_apprenticeship#RfC:_Should_we_begin_a_trial.3F. Please comment there. Dcoetzee 05:35, 28 November 2011 (UTC)

Online Status

Proposal for a new free image category

Some free image licenses (e.g. any CC-BY license) require attribution, which we usually provide here by linking the image to its description page and including the necessary information there. And some free image licenses (e.g. GPL (section 3), GFDL (sections 2 & 6)) require a notice appear in connection with any "distribution" of the image, which we again provide by linking the image to its description page and including the necessary information there. And some free image licenses (e.g. CC0, public domain) have no such requirements.

It would be helpful if we had a category along the lines of Category:All free media to indicate this information. So I propose modifying {{free media}} to take a "link needed" parameter which does the following:

One possible use for this would be to make it easier both to identify images to which

WP:ALT may be applied (setting "|alt=|link=" for accessibility) and to which "|link=" has been incorrectly applied to an image requiring attribution. In both cases it would be helpful if someone could convince Commons to implement this proposal as well (any volunteers?). Anomie
15:51, 24 November 2011 (UTC)

We should just do it by license transclusions. Every file tagged with one of the licenses that has special requirements should be in a category with all the files with that special requirement, based on having the license on its file description page. I'm pretty sure that'll save a lot of time and achieve the same result.
Wha?
16:30, 24 November 2011 (UTC)
All free license templates themselves transclude {{free media}}. I have no objection to also creating a category for "All free media requiring a link to the description page", although we may have issues then if someone decides to dual-license an image under CC-BY-SA and Kopimi or something like that. The category for images not requiring a link would IMO generally be more useful, as it's safer to assume an image requires the link unless specifically marked otherwise than vice versa. Anomie 00:50, 25 November 2011 (UTC)
  • All free files should be moved to Commons. Commons only have free files (except for the copyvios not yet found) so Commons does not need a category for "All free files". So if anything needs to be done on Commons it should probably be by editing the license templates. --MGA73 (talk) 16:52, 24 November 2011 (UTC)
    How about those images that are free in the US but not in the country of origin? Move them to Commons and they'll be deleted. Or how about images that are created to illustrate a discussion here and are absolutely useless for any other purpose? They might be deleted from Commons for that reason, if some ... "user" at Commons decides to get a bug up their butt.
    Anyway, what would need to be done at Commons to implement this would be for the various license templates to apply the "does not require link" category, just as is being proposed here. It's just that here we already have a bit of infrastructure in the form of {{free media}} since we do need to make the free/non-free distinction. Anomie 00:50, 25 November 2011 (UTC)
    The PD US-files does not require require attribution so they are not a problem. On Commons we have the rule that a file that is in use is in scope. So if someone gets something up their butt on Commons then admins will close the DR as keep. If the admin deletes anyway we can undelete and spank the admin. --MGA73 (talk) 20:35, 25 November 2011 (UTC)
    My point is that there is currently no way to automatically determine (i.e. from a script) whether or not a file with a PD-US tag or any of the many other free license tags needs a backlink for license compliance. At present, for a locally uploaded image you would have to check for any of over 200 categories to reliably guess at this, and hope that you didn't miss any. And on Commons the situation is even worse, I gave up trying to enumerate the full subcategory tree of commons:Category:Public domain. Anomie 22:16, 25 November 2011 (UTC)
  • Given the number of free files we have on en.wikipedia right now, this may be a good idea. However, ultimately we should have only a very few free files, if any, here (Cue shameless advertisement) there is a drive to move them coming up in January, FYI. --Philosopher Let us reason together. 18:10, 24 November 2011 (UTC)
    See above. And then there are some editors who are just sick of the problems at Commons and want no part of it. Anomie 00:50, 25 November 2011 (UTC)
    I think that it is better to solve the problems than to create systems for a few users. For example if I think that interwiki bots are annoying because they sometimes add stupid links. Can I then select 20 articles and move the interwiki links into a template? And add a "Don't touch the interwiki templates"? --MGA73 (talk) 20:35, 25 November 2011 (UTC)
    Re:Anomie, I did say "good idea." It's unnecessary to bring up at Commons, though, as it already has commons:Category:Attribution, which is added by adding commons:Template:Attribution to a page. --Philosopher Let us reason together. 21:54, 25 November 2011 (UTC)
    I think you misunderstood. commons:Category:Attribution appears to contain only images that are licensed using commons:Template:Attribution. It doesn't contain commons:File:Cone-response.svg, even though the CC-BY-SA-3.0 license used requires attribution. And a backlink for uses of that file is also needed because both the CC-BY-SA-3.0 and GFDL licenses require a notice that the file is under those licenses. Anomie 22:16, 25 November 2011 (UTC)
    You're right, I misunderstood the template. I'll think on this a little and propose some changes over at Commons later. --Philosopher Let us reason together. 19:15, 28 November 2011 (UTC)
    (
    KeepLocal}} here. Can we discuss the proposal instead of being sidetracked into a "every free image should be uploaded to Commons, and damn the opposition!" argument? Anomie
    22:16, 25 November 2011 (UTC)

Suggestion for User-en templates

As user's level of English, doesn't only mean its abillity of well contributing, should we include one, major additional thing, and that is communicating?

So, except an user contributes to Wikipedia, other important thing is its level of communication with other users. Current text on User en-3 template is:

  • “This user is able to contribute with an advanced level of English.”, and my suggestion includes:
  • “This user is able to contribute and communicate with an advanced level of English.”

Thank you. Alex discussion 19:54, 24 November 2011 (UTC)

First off I would divide communication into two categories.
  1. Output
  2. Understanding
If output is understood as contribution in the sense that everything submitted to Wikipedia is a contribution (including contributions to discussions), we can leave contribute as it is and the templates meaning can be considered accurate regarding a user's ability to output a language at whatever level.
Understanding of a language and the ability to output that language are not directly tied. One may be able to read a language far better than one can write or speak it, and vice versa.
So, if any change were to be made to the wording of the template it should be to clarify point 2 insofar that the user can understand the language as well as they can contribute with/in it.
With this in mind I'd suggest a wording more along the lines of "This user is able to understand, and contribute with an advanced level of English." if any change were to made at all.
However, if the user is not able to understand as well as they can write or speak a language, the template in that form would not be at all accurate. Therefore a template redesigned to offer this clarification would require an argument/variable which when used, could alter the template to state the original (that is that the user can contribute to whatever level etc. etc.) text. fredgandt 00:58, 25 November 2011 (UTC)
This is the funniest thing ever. It is certainly clear that there are scores of Wikipedians with major communication difficulties - many of them native English speakers. However I don't see most of them (however modest they may be in other areas - or not) labelling themselves as having low communication skills. Rich Farmbrough, 17:43, 25 November 2011 (UTC).
The User-en templates are part of a family of templates, located on all the Wikipedias, and should be kept in line with the rest of the family. The {{User he-3}} text says "משתמש זה מסוגל לתרום ברמה מתקדמת של עברית", which means "This user is able to contribute with an advanced level of Hebrew". And the German Wikipedia {{User en-3}} has the current wording of our {{User en-3}}. עוד מישהו Od Mishehu 08:21, 28 November 2011 (UTC)

Hey guys, I'm trying to advertise this straw poll to get consensus not only from those heavily involved in

WP:CANVASS. Hope this is ok! Thoughts and additional suggestions very, very welcome. PanydThe muffin is not subtle
17:46, 28 November 2011 (UTC)

Possible long term codification of the ArbCom elections

As proposed at Wikipedia:Arbitration Committee Elections December 2011/Feedback#Codification, I have written a first draft for a new long-term policy for ArbCom elections. The first draft is at User:Od Mishehu/Arbitration Committee Elections, and users are welcome to comment about it at User talk:Od Mishehu/Arbitration Committee Elections. עוד מישהו Od Mishehu 05:55, 29 November 2011 (UTC)

link to Facebook for fundraising

I propose an easy way for someone to make their facebook comunity/friends aware of Wikipedia's need for money.... a button to attach a personal appeal from Wikipedia founders or programmers onto a person's facebook page. If there is a fear of social network sites, then someway to easily spread the news.

You could mention it yourself on your own personal facebook page, but there is very, very little chance that the community will approve having the facebook logo on the fundraising banner, that's too much.
Wha?
11:34, 24 November 2011 (UTC)
Yes, it would be good to spread knowledge of the campaign, but the problem with these little "share" buttons is that they also serve as ads for that site. I wouldn't see a problem with adding those buttons to, say, the last page you reach after clicking "donate". The odds of that reaching consensus, though, are comparable to a proposal to donate the project to Burger King. Thanks for the idea though, and keep 'em coming, we may figure something out. PhnomPencil (talk) 17:35, 24 November 2011 (UTC)
You mean like we already have on https://wikimediafoundation.org/wiki/Thank_You/en ? Pcoombe (WMF) (talk) 13:39, 30 November 2011 (UTC)
Facepalm Facepalm At least WMF hasn't tried to shove this down the throats of wp:en. Yet.
talk
) 13:50, 30 November 2011 (UTC)

Automatically add user JavaScript and CSS pages to watchlist when imported (cascading) (retrospective)

All JavaScript and CSS pages should be added automatically to a users watchlist if imported to any of their own script pages. This action should be retrospective (once active all watchlists update to show all imports, not just from now on) and should act to add all cascading imports as well. fredgandt 03:56, 27 November 2011 (UTC)

Suggestions

  • Suggest that all imported scripts (and their imports ad infinitum) when changed are blocked from being loaded until the user has accepted the new draft. A popup alert could have three buttons: 1) Accept 2) Diff 3) Later. If Later is clicked the script's block continues. Diff takes the user to the script's diff (between when they first imported it and the latest draft). Accept simply unblocks the imported script and allows the new version (whatever it does) to run. All this could also apply to CSS too (although clearly less importantly). fredgandt 04:38, 27 November 2011 (UTC)
  • Most users who import JS scripts probably don't know JS, and so would have little to base their decision on. Your suggestion would probably be difficult to implement, since MediaWiki would need to parse the JavaScript in a user's .js pages to determine what pages are being imported. Ucucha (talk) 05:08, 27 November 2011 (UTC)
  • Assuming you're right (that most users don't know JS), some therefore must. So some would get the benefit from seeing the difference. Assuming that most users have some common sense, most would be able to tell if the script had changed significantly and could act however they felt was appropriate on being informed of the change. As it stands, few of the most you refer to would therefore be technically minded enough to think of how the functionality of the script might change over time, or be aware of how that warning message might actually mean something. Denying users a choice on the grounds that they might not know what to do with it is quite frankly disgusting.
  • Difficult to implement? The Mediawiki software is some of the most advanced on the web. Do you really think such a small change would be beyond Wikimedia? I seriously doubt it. The text added during the addition of an import is already being parsed. Grabbing the script address, its revision id, and slapping a watched tag on it would be next to child's play compared with the vast majority of the complex processes going on here 1000's of times a day. Even if it was difficult, so what? Has the proposal any value? I believe so. Informing users that a script they are using has been changed is something I think most would insist on knowing if they knew how much it could matter under certain circumstances. fredgandt 09:17, 27 November 2011 (UTC)

Questions

  • I fear this would add unnecessary server load, and deliver an imperfect result no matter how it is implemented. (Pretty much per Ucucha above.) — This, that, and the other (talk) 07:14, 27 November 2011 (UTC)
  • We are encouraged to be bold. This includes our use of the servers and bandwidth (within decent reason). Lets not kill the idea because Wikimedia may not like it. Lets explore the idea considering its possible value, then if put on Wikimedia's desk, deal with the technical drudgery.
  • Imperfection is a universal constant. Is there such a thing as a perfect article? I think not. Should we delete them all then? No. Why not? because they can be improved. That an idea is not perfect is an opportunity to improve it not a reason to smother it. fredgandt 09:17, 27 November 2011 (UTC)

On pl.wikipedia there is

Helder
12:37, 27 November 2011 (UTC)

  • I think most if not all of what I have proposed can be accomplished by user script. But since that user script would be one of the scripts that needs watching it all gets kind of catch-22-ish. Further to that, if the user script wasn't imported the protection it offered wouldn't be in place. As a Mediawiki extension, the protection would be in lace for all. I know we have warnings now but they (even if heeded) only warn about the current version. fredgandt 22:54, 27 November 2011 (UTC)

Support

Oppose

  • Oppose This wouldn't be helpful for most user, as js and css pages can only edited by the user, in who's userspace this pages are, and administrators (and maybe others, not sure). The fact is, that most editors can't edit an other editors js or css pages and many of us (like me) wouldn't even understand, what effect a change on the function of the user-script has. Armbrust Talk to me about my editsreview 05:17, 28 November 2011 (UTC)
  • Oppose: most user a) don't understand JS and how should they informed about the changes? What happens if a script is broken? The user has to be forced to use the correct script then! And everybody who is not willing to use a updates script can easily copy and paste the old cope into it's own userspace and include/import that! mabdul 12:56, 30 November 2011 (UTC)