Wikipedia:Village pump (proposals): Difference between revisions
MiszaBot II (talk | contribs) m Archiving 3 thread(s) (older than 7d) to Wikipedia:Village pump (proposals)/Archive 81, Wikipedia:Village pump (proposals)/Archive 80. |
|||
Line 1,090: | Line 1,090: | ||
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). --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 19:19, 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). --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk: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 "[[Help:Redirect|redirected]]" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word. [[User:Fred_Gandt|'''<span style="font-family:arial;font-size:130%;color:#044;">f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i></span>''']] 19:25, 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 "[[Help:Redirect|redirected]]" at no less than 1/4 size (of page name). No extra words just up the font-size and link one word. [[User:Fred_Gandt|'''<span style="font-family:arial;font-size:130%;color:#044;">f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i></span>''']] 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. [[User:Uniplex|Uniplex]] ([[User talk:Uniplex|talk]]) 08:09, 26 November 2011 (UTC) |
|||
== A simple "last best version" marker == |
== A simple "last best version" marker == |
Revision as of 08:09, 26 November 2011
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
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.
Does Wikipedia need a “share” button?
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)
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 Help:Reverting, not WP:ROLLBACK. This doesn't explicitly state the tool used. So I'd still like (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)
- 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)
- Since Σ has pointed out what I had forgotten (I try and avoid using rollback per policy/guidelines) I must softly oppose. The link already present provides a page with exactly the sort of info editors would benefit from reading if they are the sort of editors who need any link at all (due to not understanding why their edits were reverted). So beyond "if it ain't broke don't fix it" I really think this would be a downgrade compared with what we already have. fg 23:48, 11 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 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)
- All other tools identify themselves. --Lexein (talk) 07:06, 12 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?" Sven Manguard 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 Help:Revert (which surprisingly does not list the recommended reasons for rollback, or indeed undo), not WP:Rollback; this obscures the clear reason why the edit occurred. At least identifying the tool or using an appropriate link provides a reviewing editor with a class of reasons for the edit - that is, "the editor thought the reason fell within the 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)
- See Why: above. --Lexein (talk) 14:13, 14 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)
- Weak support. Not terribly useful, but completely harmless AFAICT. ― A. di M. 12:53, 14 November 2011 (UTC)
- Slightly oppose: This doesn't immediately appear to add anything useful. Normally, when I see "Reverted edits by such-and-such," without a (TW), (HG) or (IG) attached, I assume it was a standard rollback. In addition, I'm concerned that adding a tag such as this might confuse some editors on the difference between a scripted tool such as Twinkle and a server action like rollback. In the end, though, it's two letters, so I don't particularly care either way. elektrikSHOOS (talk) 20:52, 14 November 2011 (UTC)
- Comment re. why - there's at least a couple of reasons why it can be useful; 1, it helps when checking if a user is/isn't using rollback correctly, because it makes it easier to find 'em in their contribs, and 2, it helps with tools that can count certain types of edits by any user - see http://toolserver.org/~soxred93/autoedits/ - if it's working, that tool counts how many edits a user has made with twinkle/huggle/etc, by counting (TW) etc. in edit-summaries. Adding this unique string would mean we could count rollback-usage. Chzz ► 09:29, 17 November 2011 (UTC)
- Of course, you could do that right now, using the unique "Reverted" string, and unlike changing the format, that would be useful for all edits ever, not just those made in the future. WhatamIdoing (talk) 17:43, 18 November 2011 (UTC)
"Blocked" template tweak
Hi according to previous discussions about the archiving of talk pages of ip users, based on Chzz's suggestions I created an extension for mediawiki which allows creation of template which automatically change its content when user is unblocked, so that we could have templates which don't confuse especially new users who are using shared ip address, were blocked in past but don't understand that they were already unblocked, this extension is now installed on huggle test wp. If you need any detailed technical informations about it, let me know. Please let me know what do you think about it, if you support the idea, or have some comments how to improve this. Petrb (talk) 08:59, 12 November 2011 (UTC)
Technical details extensions introduces new word {{USERBLOCKED}} which substitutes to true of false based on that if block of user is active or not, that means we could make templates like this http://hub.tm-irc.org/test/wiki/Template:Blocked-test?action=edit which automaticaly change their content when block expires, as you can see http://hub.tm-irc.org/test/wiki/User_talk:Testy_Magee there. Petrb (talk) 20:51, 16 November 2011 (UTC)
- Uh, why is CheckUser accesible to everyone?Jasper Deng (talk) 23:05, 12 November 2011 (UTC)
- It is not a wikimedia site so they can do what they please... (I don't see where you are getting that idea from anyway) --Guerillero | My Talk 23:41, 12 November 2011 (UTC)
- There is no permissions error when someone tries to access Special:CheckUser right there.Jasper Deng (talk) 04:12, 13 November 2011 (UTC)
- The fact that you are stress testing other wikis is a tad troubling --Guerillero | My Talk 07:46, 13 November 2011 (UTC)
- Isn't that irrelevant? we do more tests there, I am mediawiki dev, so there are some more extensions being checked, it's latest head from svn, so it seems that it's a bug (I started reviewing cu source for now to fix that), anyway if it's a problem I will disable cu there, so that you can try that tool I am talking about here, your ip address wouldn't be recorded if you just open the link I sent here (you would probably have to make some edits), but I will probably clean cu table after tests anyway. Petrb (talk) 10:36, 13 November 2011 (UTC)
- The fact that you are stress testing other wikis is a tad troubling --Guerillero | My Talk 07:46, 13 November 2011 (UTC)
- There is no permissions error when someone tries to access Special:CheckUser right there.Jasper Deng (talk) 04:12, 13 November 2011 (UTC)
- It is not a wikimedia site so they can do what they please... (I don't see where you are getting that idea from anyway) --Guerillero | My Talk 23:41, 12 November 2011 (UTC)
- Back on track, I like the idea --Guerillero | My Talk 16:04, 13 November 2011 (UTC)
- I was thinking of a similar idea, conditional text for Mediawiki:Blockedtext based on block reasons.Jasper Deng (talk) 17:42, 13 November 2011 (UTC)
- If you wanted help with that, I could insert some more magic to this extension you could probably use for that ;) Petrb (talk) 20:40, 16 November 2011 (UTC)
- So I support this idea.Jasper Deng (talk) 17:42, 13 November 2011 (UTC)
Comment since this is a very simple extension it's quite possible that it could get deployed soon (if there was some support), so I would like to know if you wanted to change anything with that before that happens, Chzz suggested that it could return even the time when block expires so that template can show that, what do you think? is it necessary? Petrb (talk) 03:06, 15 November 2011 (UTC)
- Support the simple change - giving true/false for user blocked; it's easy enough info for anyone to see (e.g. under 'contribs' which would show the latest block-log entry), but having it as a magic-word helps templates be smarter. It seems easy enough, so why not? I'd suggest keep-it-simple, and not worry about date/other data. Chzz ► 09:21, 17 November 2011 (UTC)
- Support - Good addition. Shadowjams (talk) 20:10, 17 November 2011 (UTC)
- Support - This seems helpful. - Hydroxonium (T•C•V) 10:13, 18 November 2011 (UTC)
- Template magic could do a lot of this, especially if people are using tools to block. Something like
{{Blocked|2011-11-18 23:22|3 hours}}
Rich Farmbrough, 02:08, 19 November 2011 (UTC).
{{Timed block}}
for your delectation and delight. Rich Farmbrough, 02:59, 19 November 2011 (UTC).
- Comment I think it would be better if the image were different when the block had expired (e.g. a pink X, or a translucent X, or something), so that it would be immediately obvious what the situation was without having to read the template. Because new users might not even be aware that the template changes at all and so might just see the obvious warning image and assume it meant "blocked", or only read it once (when the block was active, say) and not bother re-reading. It Is Me Here t / c 13:14, 23 November 2011 (UTC)
- Absolutely! I expected someone else to take care of that - and the detailed wording! Let me spend a few minutes on it though. Rich Farmbrough, 15:34, 25 November 2011 (UTC).
- Absolutely! I expected someone else to take care of that - and the detailed wording! Let me spend a few minutes on it though. Rich Farmbrough, 15:34, 25 November 2011 (UTC).
- Comment I think it would be better if the image were different when the block had expired (e.g. a pink X, or a translucent X, or something), so that it would be immediately obvious what the situation was without having to read the template. Because new users might not even be aware that the template changes at all and so might just see the obvious warning image and assume it meant "blocked", or only read it once (when the block was active, say) and not bother re-reading. It Is Me Here t / c 13:14, 23 November 2011 (UTC)
Block expired
Block running
- Rich Farmbrough, 15:39, 25 November 2011 (UTC).
- Possible issue I'm concerned that a magic word like {{USERBLOCKED}} would be difficult in quite a lot of cases:
- Users may be blocked under more than one IPs, or IP ranges for example, or under a usual and alternate account (legit or socked). :# It would need thought whether a template based on "the IP/account who !owns this user page/user talk page is blocked" would cover IP users, dynamic IP users, users who edit as a username and as an IP.
- It is meaningless in some namespaces, not a problem per se but needs considering in design.
- It also needs thought whether it exposes Checkuser data and breaches privacy. If I want to check if user X is the same user as IP Y.Y.Y.Y, would I be able to post this template on User:X or User:Y.Y.Y.Y a minute before the block on one of these expires, or when the user is blocked, and see if its status is in sync with the block on the other? What about autoblock collisions?
- Overall I prefer a templated approach as User:Rich Farmbrough suggests - more flexible, and no risk of any exploits which might allow non-public data to be verified. FT2 (Talk | email) 15:13, 19 November 2011 (UTC)
- Actually it works only in userspace or talk, otherwise it return word unknown concerning the templates which works automaticaly with timestamp, it's good idea but they also have some issues, for instance if someone unblock the user before it expired, it wouldn't work, also it can't replace existing templates, and it's harder to submit such templates for sysops. I don't see any possible security or technical problems, it detects if user is blocked directly from User class in mediawiki, so there are no colissions or such issues. Actually I also heard idea to implement this to mediawiki core (from wmf dev) Petrb (talk) 09:12, 21 November 2011 (UTC)
- Support It Is Me Here t / c 13:06, 23 November 2011 (UTC)
- Why not {{USERBLOCKED:<user>}} so that the status of an user can be worked out on another page. ~~Ebe123~~ → report on my contribs. 20:34, 24 November 2011 (UTC)
- Perfect idea, I will extend it right now. Petrb (talk) 07:52, 25 November 2011 (UTC)
- Unfortunatelly current mediawiki doesn't have capability to support such feature, so maybe in future, sorry. Petrb (talk) 08:12, 25 November 2011 (UTC)
Proposal to take the "File namespace noticeboard" live
Hi there. I'd like to get some additional consensus for this board before taking it live. Once it's taken live, I would like for it to be linked to in the "Noticeboards and related pages" template that is at the top of many of the noticeboards, (it's the big one at the top of AN, AN/I, and this proposed page, among others. Sven Manguard Wha? 11:31, 12 November 2011 (UTC)
The following comments were from Village pump (idea lab). This was moved after interest was expressed for it going ahead.
I'd like some people to help me flush out User:Sven_Manguard/File_namespace_noticeboard before I formally propose that it's created. Sven Manguard Wha? 07:34, 11 November 2011 (UTC)
- Wouldn't the function of this be covered by a number of existing noticeboards ( with respect to the licensing issues) at least?
- I don't have a problem with collation of function in a single noticeboard though, the concern is duplication of effort.Sfan00 IMG (talk) 12:03, 11 November 2011 (UTC)
- No. In theory these things would move over, gradually until the FNN becomes known. This would reduce effort for the file workers, because we'd have one primary center for all the threads that concern file issues, instead of having them spread out over AN, VP:P, VP:M, CENT, etc.. Sven Manguard Wha? 12:16, 11 November 2011 (UTC)
- I have made a new subpage for the header at User:Sven_Manguard/File_namespace_noticeboard/Header. I also made it more complicated and added the New section link. ~~Ebe123~~ → report ← Contribs 13:01, 11 November 2011 (UTC)
- This would make file work so much easier --Guerillero | My Talk 13:08, 11 November 2011 (UTC)
- How does this relate to Wikipedia:WikiProject Images and Media ? MilborneOne (talk) 13:56, 11 November 2011 (UTC)
- Maybe add an extra tab at the top of Wikipedia:WikiProject Images and Media to show the new noticeboard? Ronhjones (Talk) 20:04, 11 November 2011 (UTC)
- It's a great project that suffers, unfortunately, from poor publicity. I spent a year working in files before finding out that the project existed. Also, it's great for planning projects and has an excellent cache of resources, but it really isn't the place to hold major RfCs, for that a noticeboard that's linked to the directory, and isn't attached to any specific body (such as a WikiProject). Sven Manguard Wha? 09:23, 12 November 2011 (UTC)
- Maybe add an extra tab at the top of Wikipedia:WikiProject Images and Media to show the new noticeboard? Ronhjones (Talk) 20:04, 11 November 2011 (UTC)
- I think this could go on WP:VPR now. ~~Ebe123~~ → report ← Contribs 15:43, 11 November 2011 (UTC)
- I think the general idea makes sense (viz. centralizing general file issues that are not about a specific file), and the exact header can be tweaked and refined later / through discussion. Chzz ► 00:00, 12 November 2011 (UTC)
- Per our brief discussion the other day on your talk, I think this is a great idea. Alpha_Quadrant (talk) 03:30, 12 November 2011 (UTC)
- I also think this is a good idea as it will centralize debates and permit longer, less structured discussions then at IFD. MBisanz talk 03:49, 12 November 2011 (UTC)
Above comments from Village pump (idea lab)
Thoughts? Sven Manguard Wha? 11:31, 12 November 2011 (UTC)
- Question: do you have some example problems that were not handled either at all, or not well, by current venues? I have a certain scepticism about new boards, any examples would be helpful. Grandiose (me, talk, contribs) 09:56, 13 November 2011 (UTC)
- A lot of the 'getting the word out' type messages (for backlog drives, etc.) are not effective because file workers aren't all watching the same pages. This would fix that. There were a few proposals that I, for one, tried to get out, which never really got seen, such as a proposal that, in hindsight, might have saved featured sounds. Sven Manguard Wha? 03:48, 14 November 2011 (UTC)
- Support, absolutely. ~~Ebe123~~ → report ← Contribs 14:09, 13 November 2011 (UTC)
- Support Seems a useful idea to try and coordinate filefolk better. —Tom Morris (talk) 00:49, 19 November 2011 (UTC)
- I've never been called "filefolk" before. The part of me that plays D&D with pencil and paper very much likes the moniker though. Sven Manguard Wha? 04:44, 19 November 2011 (UTC)
- I think that he means the group of users dedicated to files. Not you. ~~Ebe123~~ → report ← Contribs 14:05, 19 November 2011 (UTC)
- I'd say Sven is fairly active in the file namespace. Alpha_Quadrant (talk) 02:33, 20 November 2011 (UTC)
- Ebe123 I know he was referring to the group that works in files, but I consider myself part of the group, and very much like the name. Beats "file workers", which is what I usually refer to us as. Sven Manguard Wha? 07:20, 20 November 2011 (UTC)
- There's a much ruder version I can use if you prefer.
—Tom Morris (talk) 12:20, 25 November 2011 (UTC)
- There's a much ruder version I can use if you prefer.
- Ebe123 I know he was referring to the group that works in files, but I consider myself part of the group, and very much like the name. Beats "file workers", which is what I usually refer to us as. Sven Manguard Wha? 07:20, 20 November 2011 (UTC)
- I'd say Sven is fairly active in the file namespace. Alpha_Quadrant (talk) 02:33, 20 November 2011 (UTC)
- I think that he means the group of users dedicated to files. Not you. ~~Ebe123~~ → report ← Contribs 14:05, 19 November 2011 (UTC)
- I've never been called "filefolk" before. The part of me that plays D&D with pencil and paper very much likes the moniker though. Sven Manguard Wha? 04:44, 19 November 2011 (UTC)
- Support; seems like a reasonable and practical approach. (I'm not one of the filefolk, alas) bobrayner (talk) 16:33, 20 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 (talk • contribs) 05:56, 15 November 2011 (UTC)
- Weak oppose - Unfortunately Wikipedia cannot always be trusted, as much as I'd like this to be done.Jasper Deng (talk) 05:58, 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 This is not for Wikipedia. doktorb wordsdeeds 07:40, 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. Sven Manguard 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)
- Head over to meta:Proposals and suggest it there. This would not be appropriate for "the free encyclopedia," but you can always propose a new WMF project. --Philosopher Let us reason together. 02:18, 16 November 2011 (UTC)
- Response Thanks Philosopher. I will consider posting at meta:Proposals. One key factor in the success/failure of such a scheme is the "community" behind the site. I've seen many WikiMedia projects come and go, tried a few myself. The most powerful feature about Wikipedia is that it is an organically evolving democracy of ideas powered by passionate volunteers, and this would be incredibly powerful as a concept in Medicine. As soon as you obscure the author of ideas and begin allowing corporate agendas to distort truth, the confusion propagates. There are no doubt several privacy concerns, issues, etc. But, it is my firm belief that patients and medical professionals can be trained (just as they are trained to contribute to WikiMedia) to understand what should and should not be posted. What is it about "society" that we so easily underestimate each other's potential to "do the right thing?". The most important factor in reversing the spiralling cost of health care is to stop delegating the responsibility for our health to other people and take personal charge of seeking out the best advice possible recognizing the powerful potential of the reduced friction/energy requirements for any two people to communicate. The framework of our current healthcare system is too rigid to adapt to advances, but the industrial complex, tempered by competition, finds more and more ways to siphon resources away from individuals interacting, which is the historical root and fundamental power of the healing arts. I had a patient who was very interested in trying this and consented (along with his family) to try. We put an abstracted progress note, devoid of any personal identifiers, accessible only through a random string that the patient could then look up my documented impression, edit/append/copy it in real time, and contribute additional ideas/insights to fulfilling their full health potential. There were problems with it, and I decided to remove the note, but the problems were easily solvable with enough smart people focused on a "moon shot" for humanity. I stopped looking at the computer/chart before speaking with the patient, because the patient was always able to tell me what they needed "right now". I go back to the chart/computer once I know how to use it to most effectively (and most efficiently) help the patient. Here is an example of such an interaction. My team (nurses, PT/PT/SW/CCAC/colleagues) are all first rate and they will alert me if I trust them to prioritized medical issues (as do I to them), but fundamentally, the single most important improvement in the quality of care I was providing was to surrender control of my time and agenda to the patient. This can only work when we all see it as our individual responsibility to help out. The rigid roles/responsibilities tend to bread the reflexive response "not my problem" or "can't help you", which is a symptom of time pressures exerted on us. If we were able to count on our colleagues easing our burden, then our energy would flow most naturally to where it provides the most benefit. We all need checks/balances/skills, but the only way to get these things is to learn them from people who have the time to teach. I would contend that patients who are in need of assistance and at the mercy of the healthcare system are in an excellent position to teach the system providers how to most effectively achieve their goals. This is a well established concept in medical education referred to as 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)
A heretical idea: "closing articles"
I have always been primarily a reader of wikipedia, though I do help out when I see something I feel I can do.
Over the years, I have noticed that a number of articles have gotten really, really good and then have begun to decay. A committed group works on an article, brings it to a decent status, and then moves on. Meanwhile, less experienced or knowledgeable editors wander across the page and slow start filling it with unverified information or even start changing previously excellent sections. Then maybe someone else recognizes that the section has become full of inconsistencies and decides to just remove the entire paragraph. Thus, what was once an accurate well-written piece entirely disappears, not all at once but slowly through multiple edits. While this can technically be dealt with using present policy, it requires a large amount of dedication and there is nothing like fixing the same problems over and over again to incite fatigue.
What if there was a list of criteria by which certain articles could be considered "finished" or "closed?" What I am basically talking about is long-term protection, but for the sake of maintaining quality. I don't mean they could never be re-opened, but that there would have to be a consensus that it was time to re-open. This seems like more work, to go around judging articles and getting consensus, but I think for certain articles it would actually be less work than continually re-improving once good articles. Exactly what level of protection would have to be worked out, but I know I am basically at the point where I am very reluctant to do any improvements at all because I know that no matter how much I work on an article, that work could be gone in 6 months. Wikipedia is good at reverting obvious vandals, but less good about maintaining quality on less-watched articles where hard work is not washed away in a single prank but rather through a slow process of less than careful edits when no one is looking. Wickedjacob (talk) 13:06, 15 November 2011 (UTC)
- Don't think much of that but it might be possible to make the 'article milestones' on talk pages more prominent and do more with them like list the last one on the article page. Dmcq (talk) 13:15, 15 November 2011 (UTC)
- I'm very much in favour of a mechanism whereby articles could be closed to public editing once they reach a certain point in their evolution. I know it's a bit heretical, but you're not the first person to tell me that they're reluctant to contribute to Wikipedia for this reason. Selecting articles for this type of protection would be a far more useful activity than (or could be combined with) the selection of "good" or even "featured" articles.--Kotniski (talk) 14:34, 15 November 2011 (UTC)
- Well, while you have a point, one of the main functions of WP is that articles are considered NEVER complete. While it's true that for some articles it's rare that anything substantially new to the world content could be added, even FAs almost always have little things here and there that can easily be tidied, sources that no one happened to use with good unique info, and so forth. Closing editing to our best articles would be just as bad as closing articles to the really bad ones. Not everyone knows how to easily make an edit request, and for little things are unlikely to bother. What needs to be done, I think, is a much more push toward "if you think you're helping please do it" so the reluctance will be gone. Yes it's possible some will degenerate, but I'm sure the net value of articles as a whole only goes up, and would ever more if less people were "reluctant". Plus, if those who brought the article up to quality "move on" from it....well then they didn't care about their work so much to see it maintained. ♫ Melodia Chaconne ♫ (talk) 14:46, 15 November 2011 (UTC)
- I don't quite understand what message you want to send to "reluctant" editors to make them more willing. (The message we send at the moment is "Your contributions are valuable, but not so valuable that we're prepared to do anything to protect them, so if you want them to be of continued value, we'll need you to log on to Wikipedia twice a day for the rest of your life to fight with vandals and idiots." Something like that, anyway.) --Kotniski (talk) 15:01, 15 November 2011 (UTC)
- (edit conflict)In response to the moving on point you make; I don't think it's so much that they don't care about their work, as much as there's just so much to look after. For anyone who has created hundreds of articles (I say this as a guess - I've only created two or three), looking after those articles could easily become their only on-wiki activity. For editors who help out by copyediting articles on request, or collaborating on a certain subject, there really isn't any way to maintain those articles all the time, without using all their time. Nolelover Talk·Contribs 15:08, 15 November 2011 (UTC)
- (edit conflict)Yes this is arguably a good idea. It's probably a perennial proposal and isn't likely to gain main traction at this time. I recall back in 2005 seeing a chart showing the lifespan of an article: a rapid rise in quality at first, after which the article kind of just bumped up and down a little as people added stuff, took stuff out, futzed with wording, people adding unref'd or trivial or POV material and other people deleting it, etc.
- There are, basically, two paradigms for moving forward. One is to continue steady as she goes. The other is consider changing the nature of the Wikipedia to take into account various changes in the nature of the Wikipedia, such as all the really important stuff having already been written about, declining numbers of contributors, and so forth.
- The Foundation is committed to steady as she goes. Their thrust is entirely oriented toward maximizing the number of active editors and reversing any decline, using various outreach and editor-retention strategies. I'm skeptical whether this is possible or even necessarily desirable, although I could be dead wrong about that. But as long as this is the operative strategy, then locking down articles is not likely to fly. Herostratus (talk) 15:09, 15 November 2011 (UTC)
- I don't see why not - I see it very much as an editor-retention strategy ("if your work goes towards making something really good, we'll protect it for you" - makes editing Wikipedia seem just that little bit more worthwhile). --Kotniski (talk) 15:53, 15 November 2011 (UTC)
- You make a good point. I would consider supporting this, although it's probably quixotic at this time. Herostratus (talk) 17:41, 15 November 2011 (UTC)
- I don't see why not - I see it very much as an editor-retention strategy ("if your work goes towards making something really good, we'll protect it for you" - makes editing Wikipedia seem just that little bit more worthwhile). --Kotniski (talk) 15:53, 15 November 2011 (UTC)
- The Foundation is committed to steady as she goes. Their thrust is entirely oriented toward maximizing the number of active editors and reversing any decline, using various outreach and editor-retention strategies. I'm skeptical whether this is possible or even necessarily desirable, although I could be dead wrong about that. But as long as this is the operative strategy, then locking down articles is not likely to fly. Herostratus (talk) 15:09, 15 November 2011 (UTC)
- Take a look at a 1911 encyclopedia article. Those were "locked" onto paper and were good at the time. But even if the facts haven't changed, styles and tone do. Quick sample: "After the death of Shelley, for whom she had a deep and even enthusiastic affection, marred at times by defects of temper; Mrs Shelley in the autumn of 1823 returned to London. At first the earnings of her pen were her only sustenance; but after a while Sir Timothy Shelley made her an allowance, which would have been withdrawn if she had persisted in a project of writing a full biography of her husband. In 1838 she edited Shelley's works, supplying the notes that throw such invaluable light on the subject. She succeeded, by strenuous exertions, in maintaining her son Percy at Harrow and Cambridge; and she shared in the improvement of his fortune when in 1840 his grandfather acknowledged his responsibilities and in 1844 he succeeded to the baronetcy." Rmhermen (talk) 16:05, 15 November 2011 (UTC)
- WP just celebrated its tenth birthday. In that span, have grammatical styles really changed that much? Yes, in 100 years, a lot can happen, but this is a solution for a short term (in the sense that WP may very well not even be around in 2111) problem. Plus, Jaga's idea below would help to solve your objection. Nolelover Talk·Contribs 17:32, 15 November 2011 (UTC)
- The FA process in March 2002: But if you come across a particularly impressive page, why not add it to the list as your way of saying "Thanks, good job"? Things have indeed changed... --Stephan Schulz (talk) 17:54, 15 November 2011 (UTC)
- Right, "locked for 100 years" would be an OK compromise, I think... Herostratus (talk) 17:41, 15 November 2011 (UTC)
- WP just celebrated its tenth birthday. In that span, have grammatical styles really changed that much? Yes, in 100 years, a lot can happen, but this is a solution for a short term (in the sense that WP may very well not even be around in 2111) problem. Plus, Jaga's idea below would help to solve your objection. Nolelover Talk·Contribs 17:32, 15 November 2011 (UTC)
Instead of closing an article altogether, we could create a new level of page protection between semi and full. To edit, you would have to have a user right ("experienced user"? whatever) that is automatically conferred upon your 1000th edit but can also be granted or taken away. Then, when an article becomes featured, or just plain complete, it can be protected at this new level. It would slow decay, but not keep dedicated editors out. --JaGatalk 16:48, 15 November 2011 (UTC)
- Yes, that's how I imagine this working. Something a bit similar to these flagged revisions we seemed to be trying out some time ago, but packaged in a more positive and less confusing way.--Kotniski (talk) 17:47, 15 November 2011 (UTC)
- Or we could just have pending changes... (This user cowers in fear as the brickbats start being thrown.) —Tom Morris (talk) 14:19, 25 November 2011 (UTC)
- Fully Support There is nothing more disheartening than watching a good article turn bad. All articles are open honey jars, attracting flies. There are some articles which are as complete as they'll ever be, so why not say "Well done everyone, this is complete". Heck, create a new project to nominate complete articles if needs be. Let's not pretend that Wiki is perfect - there's enough work to be done. BUT for those articles where no work can possibly build on what's gone before, why not bring up the drawbridge? doktorb wordsdeeds 17:08, 15 November 2011 (UTC)
- No. If an article is good, and you want to keep it that way, no one is stopping you. But even featured articles can be improved, and we should never imply that even on our "best" articles that the work is done. It is never done, new information becomes availible, better pictures can be added, language can be made even better, etc. etc. No, this is a phenomenally bad idea. If you don't want to see decent articles degrade, stop it. But don't let "good enough" get in the way of "better". There is no good enough at Wikipedia. --Jayron32 18:34, 15 November 2011 (UTC)
- Yeah, in theory. In practice, I'm not so sure. I think that nobody is saying completed articles can't be changed by anyone ever. The question is, should the same editing paradigm -- "anyone can edit it in any way" -- apply to stubs, mediocre articles that need work, and really good featured-article-quality articles? It does now. Should it? Why? It seems kind of like a one-size-fits-all approach that may no longer be optimal. Herostratus (talk) 18:43, 15 November 2011 (UTC)
- This looks like a proposal that has come at the right time. All longtime contributors have had to deal with attempts that slowly downgrade the quality of a finished article. There is already a method available to stop most of these attempts: permanent semi-protection. This can be done by changing the policy of Wikipedia:Protection policy Each WikiProject can then designate which articles deserve this semi-protection and an admin can perform this task. This wouldn't exclude all vandalism or botched attempts at “improving” an article, but would certainly be a great help. JoJan (talk) 20:01, 15 November 2011 (UTC)
- Support restricting (not closing). Is there be a way of spotting articles were the main contributing author is no longer active? (As these pages would be prime victims of non-patrolled vandalisms and good faith erroneous edits) --Squidonius (talk) 20:26, 15 November 2011 (UTC)
- No. That's what the watchlist is for - you can throw an article on it and forget it, yet be alerted when it is changed so you can take a look at whether the changes were good and/or whether they can be improved. --Philosopher Let us reason together. 02:16, 16 November 2011 (UTC)
- Personally, I don't know if this really works with massive amounts of articles on a watchlist (perhaps someone with, say, more then 1k can comment on how easy it is to follow every change), but even if I'm totally wrong, what's to say the watchlist is the "only" way we fix these articles. I mean, the "watchlist everything" method obviously isn't working now'... Nolelover Talk·Contribs 13:33, 16 November 2011 (UTC)
- I have 3,982 pages on my watchlist, excluding talk pages, primarily split between deleted articles that I watch for re-creation, and active articles that I'm not really involved in but still want to keep an eye on. It works. --Philosopher Let us reason together. 08:42, 17 November 2011 (UTC)
- And I had less then 300 at its max. Call me incompetent if you wish (no, I won't take offense :), but it was too much. Nolelover Talk·Contribs 13:10, 17 November 2011 (UTC)
- I am the 5000th and something most active editor ever in en:WP (w/ ~9k edits), and I also can not keep up with 300 watchlisted pages. u:Philosopher, you are either lying (to us or to yourself) or you are super-human, and as such not a reasonable reference for the rest of us. - Nabla (talk) 20:15, 20 November 2011 (UTC)
- Of course it depends on what one watches. I have 527 on mine, including all the village pumps and 35 have been changed in the past day. I can easily imagine watching 5000 pages that get almost no edits, especially if one considers archives and other pages that aren't supposed to be edited. Considering Philosopher said many of them are "to watch for re-creation" (i.e. they don't even exist) that right there is a large number of pages that won't get edited. ♫ Melodia Chaconne ♫ (talk) 20:54, 20 November 2011 (UTC)
- However, if you have a bunch of redlinks on your watchlist that you're just watching for recreation, then that doesn't help this problem at all. The "watchlist method" only works if actual articles (not WP: pages, not userspace) are on people's watchlist and are actively being checked. I just cleaned my WL of a bunch of articles that, even when they would pop up, I didn't really check. All this to say that there are a lot of problems with believing that people watching articles alone will solve this problem. Nolelover Talk·Contribs 21:18, 20 November 2011 (UTC)
- Of course it depends on what one watches. I have 527 on mine, including all the village pumps and 35 have been changed in the past day. I can easily imagine watching 5000 pages that get almost no edits, especially if one considers archives and other pages that aren't supposed to be edited. Considering Philosopher said many of them are "to watch for re-creation" (i.e. they don't even exist) that right there is a large number of pages that won't get edited. ♫ Melodia Chaconne ♫ (talk) 20:54, 20 November 2011 (UTC)
- I am the 5000th and something most active editor ever in en:WP (w/ ~9k edits), and I also can not keep up with 300 watchlisted pages. u:Philosopher, you are either lying (to us or to yourself) or you are super-human, and as such not a reasonable reference for the rest of us. - Nabla (talk) 20:15, 20 November 2011 (UTC)
- And I had less then 300 at its max. Call me incompetent if you wish (no, I won't take offense :), but it was too much. Nolelover Talk·Contribs 13:10, 17 November 2011 (UTC)
- I have 3,982 pages on my watchlist, excluding talk pages, primarily split between deleted articles that I watch for re-creation, and active articles that I'm not really involved in but still want to keep an eye on. It works. --Philosopher Let us reason together. 08:42, 17 November 2011 (UTC)
- Personally, I don't know if this really works with massive amounts of articles on a watchlist (perhaps someone with, say, more then 1k can comment on how easy it is to follow every change), but even if I'm totally wrong, what's to say the watchlist is the "only" way we fix these articles. I mean, the "watchlist everything" method obviously isn't working now'... Nolelover Talk·Contribs 13:33, 16 November 2011 (UTC)
- Comment: At one time, a similar idea did exist on Wikipedia. It was Wikipedia:Stable versions, but it's been inactive for some time. It might be a better idea to invest your time in reviving this project, or one like it. elektrikSHOOS (talk) 17:45, 16 November 2011 (UTC)
- Comment. Regarding the Watchlist, I'd like to say my tuppence's worth, I find it quite flawed:
- as mentioned by Nolelover if you have too many it become unwieldy,
- when expert editors become non-active their pet in-depth esoteric pages loose their watchmen (I have gone on "wikipedia vacation" for a while due to work stress only to "come back" to derelicted pages)
- successive edits are not visible in the watchlist, only the last (I have seen vandalisms becoming fixed due to reverts of the last edit not all edits)
- The watchlist does help, but does not solve the problem in my opinion. --Squidonius (talk) 20:35, 16 November 2011 (UTC)
- Comment. Regarding the Watchlist, I'd like to say my tuppence's worth, I find it quite flawed:
- Support restricting . Going by other multi-volume encyclopedias (like the old print editions of E. Britannica) I should think about 100,000 articles cover most of the essential areas of science, philosophy, deceased historical biographies of high notability etc. Most of these articles, should be ready for semi-protection right now as they are likely to be closely watched. This would be a start -and from the experience gained in completing this effort, a firm policy can be hammered out. That leaves a huge number of many times that figure that beginners can still wreak. There are good psychological reason too. It will not only help to stem the loss of good editors with knowledgeable and in-depth expertise but should encourage new editors to work on expanding stubs and learn wiki-code and WP policies without having edits immediately reverted. It seems that new editors are drawn to the well written and nearly complete article for the very reason they are good and are commonly read. This leaves an inexperienced editor very little room to make meaning full contributions. If they start on stubs, it will lead them to explore for templates and all the other bells and whistles we have – using the good articles as example of what can be achieved. By now, I don't think there is a schoolchild that hasn't heard from numerous friends and other sources, that to become a new editor it is an up-hill struggle in battle against the entrench Mafia of experienced editors already here. What we say on these discussion pages and within WP about welcoming and helping new editors just doesn’t reach them any more. It bonkers to carry on as we are. This is a historical practice that may once had a point -rather than a useful one. --Aspro (talk) 15:32, 17 November 2011 (UTC)
- It is proposed herein to restrict editing of "mature" articles to stop them "rotting". We all agree that article get a burst of improvements get to an excellent level, but go down hill afterwards. However, several question remain open, in my mind at least:
- When is an article mature? E.g. Is it when it gets to FA status or according to other criteria?
- Who can edit the "restricted" articles? Protection stops IP users. Or are talking about something more stringent, although defining who is an expert is quite problematic, are they self-appointed (i.e. mavens) or are they nominated?
- Who gets to "restrict" articles (admins?) and what process do other editors undertake to request it?
- It is proposed herein to restrict editing of "mature" articles to stop them "rotting". We all agree that article get a burst of improvements get to an excellent level, but go down hill afterwards. However, several question remain open, in my mind at least:
.--Squidonius (talk) 22:57, 17 November 2011 (UTC)
- Comment: Good question; Who can edit the "restricted" articles? . A sub page showing the 'new edition' can be edited 'freely' and viewed openly and all can vote for the original to be replaced. The history of the original article will show all competent editors -they can ask for privileged voting rights. --Aspro (talk) 23:13, 17 November 2011 (UTC)
- This recent discussion about preemptively protecting pages against vandalism has some content related to this thread. I suggested then that an automated guard could be employed to close articles that (measured by edit frequency) were under possible attack. For this proposal, similar methods could be applied. I also suggested that safe versions could be cached and presented to the public during times of page closure (just in case the closed page was in a damaged state) and that the safe version could be established by admins (just a suggestion that could be expanded to include community review etc). An extension of that idea could be to have drafts: a primary, agreed and established draft with edits to it stored for review rather than immediately applied. Another wiki I worked on uses (or used (can't find an example page)) a draft system on some more official pages (that contain legal statements or policies etc) that presents an agreed correct page. While the page can be freely edited, only the reviewed and accepted changes are applied to the final draft. I agree that levels of protection could be employed across the board here in any number of ways and believe the benefits out-way the costs. I almost waffled. fg 23:41, 17 November 2011 (UTC)
Amendment to the proposal
No article is ever "finished" of "perfect". I can see the value of some form of protection against quality rot by casual editors, vandals etc, but there must always be some way of allowing access by those of us who can and wish to improve an article. Perhaps a good quality article can be stored as a closed page for general access, so that people looking for information see a good quality product, but an alternative version will be open for improvement, with an icon in the header giving the option to the new edition under consrtruction? This way, if the page gets better, it can be subsituted after a review and the process started again. If it rots, it can be periodically reverted, and all the time the reading public sees the protected version first. This procedure may even discourage vandalism and edit warring if it is applied to cases where these are a problem. Since all versions are saved anyway, this shouldnt increase overheads. Decision to apply the process could just be a couple of requests to an admin, as the development version is still universally editable.
This form of protection could be automatically applied to all featured articles, and possibly to all good articles. Further down the line it is an option for problem and contentious articles, which could be given this protection after reaching a consensus, to tide them over while the squabbling continues on the development page.
The tool bar would be missing the "edit" button on the protected page. Instead a button would lead to "development version", where the edit button would be in its normal place. Some form of tab or icon indicating the status of the protected page would be clearly shown at the top of the page. I dont know what this should be called. Something like "Stabilised version N: This page can not be directly edited. Make changes to the development version". where N is the version number of the stabilised article. This way an interested reader can compare stabilised versions easily by referring to the edit summaries where they would be recorded. Peter (Southwood) (talk): 07:07, 18 November 2011 (UTC)
- You realize that what you have proposed is also called pending changes? Nolelover Talk·Contribs 13:54, 18 November 2011 (UTC)
- I did not, thank you for the information. Peter (Southwood) (talk): 06:22, 22 November 2011 (UTC)
It seems that two questions are which articles get protected and who can edit these protected articles. For the which, an easy start could be "all Featured and Good articles, automatically, and no others" for now. (This could possibly be broadened later, not sure how though). Who is a harder question. Right now we have (not counting Developers) four classes of editors:
- Anon IPs
- Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
- Everyone else (except admins)
- Admins
Anon IPs cannot do many things (such as create pages I think) and non-autoconfirmed editors have a few restrictions (can't upload files or move articles). But after autoconfirmation one has the same rights at the most veteran editor, so the "everyone else" category includes editors from four-days-and-ten-edits to ten-years-and-100,000-edits (and on up). This is quite a broad range. Too broad? Maybe.
Suppose this was refined with a new category, I'll call it "established" but the name doesn't matter. So then we have:
- Anon IPs
- Non-autoconfirmed editors. Editors are autoconfirmed after four days and ten edits.
- Non-established editors. Editors are established after X months and Y edits.
- Everyone else (except admins)
- Admins
Only established editors can edit Featured and Good articles (they can also request permission on the talk page for a specific edit such is down now for fully protected articles, or just informally suggest a change.) I don't know what the values for X and Y should be, this is a detail. (1 month and 100 edits, 3 months and 300 edits, 6 months and 600 edits, whatever.) Obviously this would require a software change and also would not entirely solve the problem.
The problem is, this would be a huge change culturally. It would require a software change and that's a big deal to get pushed through. With the reluctant exception of restrictions on anon IPs and non-autoconfirmed editors, which is mostly to restrict drive-by vandalism, we've always treated all editors as equal (admins have no special standing as regards content.) This makes little sense to me and most organizations don't do that I don't think, but it is what it is.
Any proposal to be simple and automatic, so you have objections like: non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article, established editor who is nonetheless a complete idiot can. The refutation of that is while specific individual-case objections can be raised against most anything, from a system-dynamics standpoint it'd be an improvement, but a lot of people won't buy that.
So I'm not seeing a way forward on this, beyond just continuing to talk it up and hope for a sea change. Herostratus (talk) 15:52, 18 November 2011 (UTC)
- Unfortunately, I have to agree. While there is definitely a problem, there's no way in Hades that any sort of Pending changes-esque solution will be accepted in the near future, and the prospects of another "class" of editors probably aren't much better. Big, sweeping "cultural changes" aren't generally the easiest things to pass on WP. Nolelover Talk·Contribs 16:38, 18 November 2011 (UTC)
non-established editor who is Professor Emeritus of Asian History at Columbia can't edit the article,
- Some of the above suggestions 'will' allow new editors to edit. However, this time they will be improving the 'new' edition of the article (on a sub-page) which will replace the old one. To make sense of the above suggestions, what we need is a table showing how this proposal is structured. A commonly agreed glossary of terms I think is needed as well- as this is geting like the tower of babel. For instance: Stable page or current edition or current impression, Sub-page or pending changes or second edition proof or something etc.
- As I see it we can:
- Freeze the current page of a featured article.
- The normal edit tab is replaced with a 'edit next edition' tab.
- The 'next edition' tab takes any editor to a sub page where the original 'copy' of the article can be improved.
- Any editor on the talk page can then ask at any time for a vote on whether the new edition can/ is ready/should replace the old version.
- An admin says yea or neigh.
- What is the problem wit that?!!
- New editors may even get better advice and guidance from experienced editors this way, since they are no longer messing up the 'live' articles and frustrating those competent editors have taken much time and effort to get right.--Aspro (talk) 17:56, 18 November 2011 (UTC)
- I think this is the Mediawiki extension that would provide the ability to have stable (protected) and editable (unprotected) versions of each article, for different levels of user. I gather from the page's hat that Wikimedia are almost certainly not going to be implementing anything like it here within our lifetimes. I'm afraid we may just have to stick with page watching and vigilante-ism! If the Tool apprenticeship goes through we'll be swamped with eager young gun slingers too. Yee-haw! fg 18:10, 18 November 2011 (UTC)
- I've decided that I flat out oppose this idea (sry). I have to side with Jimbo on this. There are currently 6,878,249 articles and they were created by all and sundry. Viewed in detail the content is in perpetual flux but, viewed from a perspective most readers have, this is an incredibly stable and full encyclopaedia. The ethos has proven itself. The proof in this pudding has been tasted. We are looking after it now.
- I'm a programmer. I like and believe in code. I would have a T-shirt of ClueBot if I were a T-shirt person. If an automated way could be found to more rapidly guard pages, I'm all in favour. Machines are totally unbiased and ruthless. No sweet talking will sway them and they cannot have bad days (unless badly written). People are fallible and make mistakes and act in bad faith or in good faith but poorly. However, en-mass humans do manage to display The Wisdom of Crowds. That's how this remarkable project started and how it should continue. We each do our little part and natural equilibrium will continue. The OP (original proposal) was to find a way to save rotting articles. If those articles are worth anything to anyone, they will be turned around in time and rise again to good or better status. The idea to find, save and protect the gold-that-was is so very tempting, I was almost suckered in. But no; we must trust in the incredible system that got Wikipedia this far. Free editing for all, all the time (unless common sense dictates otherwise). Knowledge is constantly shifting and one can only assume it always will. We (Wikipedia) must adapt. If adaptation results in article occasionally falling by the wayside (think genetics) then so be it. Nearly 4million! We should have a party!! fg 18:41, 18 November 2011 (UTC)
- Your missing the point! All articles can still be edited. Its just that the frozen page is frozen. A tab is still there to edit the page which will replace it. It is just a temporal displacement. WP will still be an encyclopedia that anyone can edit.--Aspro (talk) 18:24, 18 November 2011 (UTC)
- Fred Gandt rightfully points out that this whole discussion is against rotting articles — a problem acknowledged by all in this discussion.
- There are legions of editors, some are waxing and some are waning. Under the assumption that all editors have the same knowledge, wikipedia pages will continually get better eventually with some occasional periods of "article rot" as the decreasingly-active experts are substituted by increasingly-active experts. The problem is many editors are the sole experts of a set esoteric topics: editors have "pet articles" and often they and they alone are the only users that knows about the topic well enough to edit it. Consequently some (but not all) articles that rot tend to go down hill until they are noticed again, but without the expertise are deleted, merged or severely reduced. I am however not sure of what proportion of articles go down hill and never come back. --Squidonius (talk) 21:44, 18 November 2011 (UTC)
- PS. Trying to find examples, I keep thinking of several cases where a interesting piece of information disappeared due to vandalisms being removed but not reverted and due to the last edits of a series of deleterious edits being reverted. These two are issues with the watchlist. So I am not too sure about my own stated theory above... --Squidonius (talk) 21:49, 18 November 2011 (UTC)
- Correct me if I'm wrong (really) but articles would only disappear (by deletion) if they had gotten too small to be considered worth keeping, right? Assuming this is correct: A possible software solution could be to watch pages for significant shrinkage. If an article reaches an alarming stubbyness it is immediately added to a category for adoption. Volunteers could then pick them up, find out why they have shrunk from perfectly reasonable to not even a stub, and take it from there. This way would at least prevent forgotten articles fading away through lack of active guardianship. fg 21:59, 18 November 2011 (UTC)
- Evolution by open editing is a noble goal, but we risk losing our dinosaurs. Not in this case with a bang, but with a whimper. Peter (Southwood) (talk): 06:22, 22 November 2011 (UTC)
{{Stable version}}
is a way of marking milestones, see Talk:Risk_aversion for how it works. It might need to more slick to be really useful. Rich Farmbrough, 17:32, 25 November 2011 (UTC).
To be able to own Wikipedia.
I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.
I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.
A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.
We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.
In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.
- See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)
- Do you know about page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [6], and gradually expanded [7] [8]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth.
- There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write Don't Panic in large, friendly letters. Chzz ► 09:09, 17 November 2011 (UTC)
Wikipedia has never been for sale - Wikipedia always has been, and probably always will be, a free internet site, which is able to be accessed by any one who has access to the world wide web. ACEOREVIVED (talk) 20:53, 23 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. Sven Manguard 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~~ → report ← Contribs 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)
- Not too many. 1 would do. So we could just have the sitenotice for a quick celebration. Keep it for 1 day. ~~Ebe123~~ → report ← Contribs 21:26, 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)
Tracking misuse of the cquote template
I made a proposal yesterday evening at Template talk:Cquote#Proposal to track improper usage. My proposal was the first edit in over 2 weeks, however, so I'm bringing it here instead. The basic reasoning is as follows:
- {{cquote}} is reserved for pull quotes. This is stated at MOS:QUOTE and on the template's documentation.
- But it's widely used for generic block quotations, which contradicts the MOS.
- There was consensus at TfD to correct the usage of the template, or change the MOS, rather than deleting it.
- I've made a cursory search of the WT:MOS archives, but found no recent evidence of consensus to scrap that rule.
- The template supports attribution parameters, like
author
. Since it's supposed to be used for pull quotes, which shouldn't need attribution, the template itself encourages misuse. - However, removing the parameters now, while the template is widely misused, would break a lot of articles' attribution, which is even worse.
- Therefore, I propose that this template categorize any uses of those parameters into a new tracking category: Category:Articles with attributed pull quotes.
Once we've emptied that tracking category, we may want to scrap the attribution parameters. We should probably also tie this into WP:MAINT at some point. --NYKevin @746, i.e. 16:54, 19 November 2011 (UTC)
- I guess. In my opinion, {{cquote}} is pretty, and the general block quote templates are ugly, and something like cquote should be used for quotes generally. So I personally can't get too exercised about editors voting with their feet in this way. A better solution might be to change the MOS and the cquote documentation to encourage more general use of the template. Herostratus (talk) 20:32, 19 November 2011 (UTC)
- It's been almost two months since the TfD in question and so far as I can tell, no one cares enough to build a consensus to change MOS. If you want to preserve this usage, I'd recommend starting an RFC over there soonish. Obviously I would put this proposal on hold if such discussion materialized. --NYKevin @961, i.e. 22:04, 19 November 2011 (UTC)
- Support Cquote is being used as a decorative quote and is not appropriate for the encyclopedia. I have yet to find any article where it is actually being used as a pull quote. ---— Gadget850 (Ed) talk 01:03, 20 November 2011 (UTC)
- See Kamie Ethridge. My goal isn't to undermine your point, but support it. I like the looks, but accept the community consensus that they should be reserved for pull quotes. I've seen it used improperly many times, and proper use is very rare.--SPhilbrickT 16:48, 21 November 2011 (UTC)
- Although I agree its intrusiveness is undesirable in articles, it sees much legitimate use outside the article namespace (here for instance), where such decoration is entirely benign. I'm not sure removing the parameters altogether is a constructive development. Happy‑melon 00:02, 21 November 2011 (UTC)
- OK, perhaps we could disable them in article space only. Of course, they will continue to work until we've emptied this tracking category -- I don't want to break large numbers of articles. --NYKevin @705, i.e. 15:54, 21 November 2011 (UTC)
- I will discuss namespace detection on the template talk. ---— Gadget850 (Ed) talk 16:27, 21 November 2011 (UTC)
- OK, perhaps we could disable them in article space only. Of course, they will continue to work until we've emptied this tracking category -- I don't want to break large numbers of articles. --NYKevin @705, i.e. 15:54, 21 November 2011 (UTC)
- Diff: [9]. Note that this is between two different pages. The main template has not been edited. Moreover, it appears that I'm proposing the removal of the {{doc}} and noincludes, but I'm not. --NYKevin @751, i.e. 17:00, 21 November 2011 (UTC)
Multilingual search results for registered Wikipedians.
![]() |
|
RfC tag added on 23:59, 23 November 2011 (UTC).
Proposal: Enable users who have registered Wikipedia accounts to receive search results from multiple Wikipedias automatically.
Synopsis: Single language search is the wisest decision for the majority of users, but multilingual search results are incredibly useful for multilingual users, allowing them easier and more reliable access to information.
Cons against multi-language searches: Currently, there is a fairly fast and effective way to search for items in a language other than the wiki a user is visiting. By typing in the country prefix at the beginning of a search, we can navigate to a page that is not on the originating project. This is a smart balance between usability and technical performance when considering the average usage of the Wikipedias. For most users, the side language options in an article and the ability to specify a country prefix are more than enough options for effective information gathering. On top of that, it would be horribly inefficient to force the server to crawl every language whenever an anonymous user searched for something. It would also be hard on the servers to attempt to detect a language for each search call. Searching every database for a single item would be a Herculean task to perform even once, and the time it would take to do such a comprehensive search would severely detract from a usability standpoint. Although I am currently unfamiliar with Lucene, I am under the impression that a single call is made to a language's index when a search is made. The functionality of the searching and the availability of individual wikipedia language stats suggest that the articles reside on separate indexes. If this is the case, to find articles in multiple languages would require multiple searches to be made for a single request. This would also be a very large no-no from a performance standpoint if there were a large amount of languages being searched by a significant amount of active users.
Pros for multi-language searches: For articles that exist in both the language of the original search term and in the originating wikipedia's language, the user will most likely be redirected to the originating language version of the article. This is certainly a simplified explanation, as one might end up on a disambiguation page for that word. For example, if one searches for 愛 in the English Wikipedia, that user will be served with Love. Searching for Amore(Italian for love), however will redirect you to a disambiguation page for Amore. That page provides a link to the English article for love. It should be noted, however, that neither search will allow you to immediately reach the existing articles for love in the languages in which they were searched. It would be necessary to reach the article in the language of the wiki first before clicking on the language sidebar. This is acceptable, but not as user-friendly as it could be.
The above only relates to searches that involve articles that represent the concept in the searching wiki's native language. If a user creates a basic search for an article that does not exist in the language of the wiki being searched from, then the results page will display nothing. If one searches for the Japanese celebrity 温水洋一 (Yōichi Nukumizu) in the English wikipedia, it displays nothing. If you search for the romanization of his name, there is still no link to the Japanese article, but there are suggested articles that contain his name. As there is no article in English at the moment which talks about this person, there are much more limited search results on the English Wikipedia. This makes sense if the person doing the search doesn't understand Japanese, which would be understandably assumed about most users on the English Wikipedia. This isn't a valid assumption for users that explicitly specify that they would like to be unified with both the Japanese and English Wikipedias.
There will be much fewer users who unify their accounts with multiple languages. Therefore, the load would be significantly less taxing on the server to search those unified languages for a single search term.
Possible Solution: A registered Wikipedia User can specify whether or not they wish to receive search results from multiple languages. This option would be disabled by default. If this is still not a large enough limit, we could require the user account to be unified with the languages they selected.
For performance issues, I would recommend that by default when a user opts in to this functionality, all searches would be performed as they currently work. Therefore, if multiple languages have articles for the same concept, the user would be served with the page on the Wikipedia that was originally queried. Only when no result was found on that Wikipedia would there be a search for the other languages that had been opted for. If the user wishes, however, they could specify that they wish to given a choice of articles in the languages for which they opted. This would require some new functionality. The new manner of search could be done in multiple ways. If an Article exists on the language of the Wikipedia being searched, it could check for a corresponding interlanguage link and display all relevant choices from that information. This would save resources as there would be no need to search for a second time. Another option would be to run a separate search on the wikipedias opted, so that if an article exists in language, but has yet to receive an interlanguage link, the information won't be lost. Either way, I'll leave that up to people who are in charge of the technical matters and who have much more experience than myself. I'd think that it would be best to combine the two. If an interlanguage link exists, give those choices, if it doesn't exist for one of the languages opted for, make sure to search that language explicitely. This would also be a good way to find and report articles which should related via interlanguage links!
Example process flow for the various ways a search could be handled depending on the type of user:
anonymous Wikipedia user or registered user who has not opted for multilingual support:
(no change from current method)
registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support without specifically wishing for a choice of articles in both languages:
searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in the current manner -> redirects user to Love. (no change from current method)
searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in the current manner -> redirects user to 愛. (no change from current method)
searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the current manner -> no results found -> runs a search for “ja: 温水洋一” -> redirects user to 温水洋一
registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support and specifically wishes for a choice of articles in both languages:
searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love
searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love
searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the new manner -> no results found. runs a search for “ja: 温水洋一” -> redirects user to 温水洋一
Thanks for reading! I hope you think this is a worthwhile idea and look forward to your ideas. Also, I apologize for the informal nature of this proposal. It's my first wikipedia page and I'm just a dumb art student. Subcogitate
- Oppose: We've considered it before, but most people don't know all the 20+ languages Wikipedia uses. One word in one language can mean something else in another, so users could get misinformed. I don't think it's worth the increased server latency. By the way, this is not a unique page - see Wikipedia:Your first article.Jasper Deng (talk) 23:42, 19 November 2011 (UTC)
- ---Thanks for the feedback! If you notice, however... My proposal doesn't say anything about searching all the languages. Just ones that the users select. You might want to reread the entire article and gain a better understanding of what I am suggesting. Also, you are right about this not being a unique page, so thanks! :) Subcogitate
- I like the idea, but there are a few things that need to be sorted out (logistics).Jasper Deng (talk) 04:04, 21 November 2011 (UTC)
- Nice idea. Well considered and presented. I'll think about it a bit before deciding one way or another though. First impression is that it could be a boon for those who speak multiple language to more quickly find matches across all Wikipedias. fg 01:43, 20 November 2011 (UTC)
- Previously proposed umpteen times, it is languishing at Bugzilla unloved and uncared for at https://bugzilla.wikimedia.org/show_bug.cgi?id=1837. Fences&Windows 00:59, 22 November 2011 (UTC)
- -- It's nice to see people hoping for the same thing. The title of that bug is "search all languages" which is a bit different from what I'm suggesting... If that's not what the bugfix is supposed to do, then maybe it needs to be re-written to be more specific :) Thanks for the tip! I'll look into bugzilla from this point forward! Subcogitate
Personally, I think this could be quite a good idea. ACEOREVIVED (talk) 20:55, 23 November 2011 (UTC)
- You might want to use http://www.qwika.com/, but I am not sure how relevant or how useful it is.
- —Wavelength (talk) 21:29, 23 November 2011 (UTC)
- Support Can't think of any down sides. I don't speak or read any other languages but English (except programming and scripting languages but that's different) so would not get the benefit but, I can see how useful it would be to a user who is multilingual. I can well imagine it being a boon for Wikipedia too since it would encourage cross language Wikiknomery etc. I also imagine it would be quite simple to implement. A quick extension to some php and a couple of tweaks to related UI and Bob's your uncle (as we say in blighty). fredgandt 23:53, 23 November 2011 (UTC)
- Comment: I have listed this proposal at Template:Centralized discussion to canvass wider input. Cunard (talk) 00:01, 24 November 2011 (UTC)
- I'd love to be able to search the French and German Wikipedias at the same time as I search the English one. We'd need to think about how the results were displayed, because with many things -- biographies, geographical locations, the sort of thing you'd actually want to use a foreign-language Wikipedia for -- the articles will have the same titles. I suggest using the standard Wikipedian prefixes, if this is technically possible, so if I used the search term "Goethe" the results would be listed as en:Goethe, de:Goethe and fr:Goethe.—S Marshall T/C 12:18, 24 November 2011 (UTC)
- Support. As I'm regularly using the English, the French, the German and the Slovene Wikipedia, I find it a great idea to have the results for all of them listed in one place. This makes finding the relevant information easier, simplifies the comparison between the different versions and cross-checking and also allows for easier building of articles using information and references from different language versions. I'm really looking forward to have this enabled. --Eleassar my talk 12:50, 24 November 2011 (UTC)
- I'm doing some translation right now, and this would certainly be helpful, especially as a little option on the search page. What would be cool would be having the interwiki result(s) pop up next to each search result so people can also see which languages have an equivalent article to what they're looking for. /ƒETCHCOMMS/ 19:01, 24 November 2011 (UTC)
- Comment Don't forget Google "goethe site:wikipedia.org" - not great but better than nothing. Rich Farmbrough, 17:38, 25 November 2011 (UTC).
- Support Sounds like a good idea. Dusty777 (talk) 23:56, 25 November 2011 (UTC)
Online Status
![]() |
|
Please note that this extension doesn't introduce new feature, it is supposed to replace {{Statustop}} and the similar templates in order to do the same thing more effectively, without having to create thousands of new revisions to the database, what update of the template does - it is also an opt-in feature that mean it is disabled for all people who don't want to use it by default. This is not a discussion whether users should display their online status on their user pages, but about that how is it being done.
Hi, I would like to ask you what do you think about installation of http://www.mediawiki.org/wiki/Extension:OnlineStatusBar to enwp, as replacement for existing {{Statustop}}, which creates a lot of pointless revisions, I already asked on VPT but only about 4 people answered there, the extension is almost finished, it's example is available on huggle-testwp, the purpose of this extension is to allow people show their online status, instead of having to update their user pages everytime when they logout etc. current proposal is to have this extension disabled for all registered and unregistered people unless they choose otherwise. What is your opinion about installation of this extension to english wp? Thanks Petrb (talk) 10:06, 29 October 2011 (UTC)
- Example of status: http://hub.tm-irc.org/test/wiki/User_talk:Petrb Petrb (talk) 10:14, 29 October 2011 (UTC)
How does it work: it writes all data to special table which is stored in operating memory, and periodicaly cleaned, everytime when user who does want to be tracked open any page on wikipedia it update the timestamp there, when user logout or their timestamp is too old, their record is removed from table., if you open their user page, and if they have feature enabled, it looks up the timestamp from that table, if user is there it consider them as online and render the status in their userpage, unless they wish to display it otherwise.
- I agree that the present practice of updating User:Me/status repeatedly is ludicrous. Any automatic method would be better. I also agree that it should be opt-in not opt-out. Whether it is actually needed or not is debatable. Personally I like the idea and support it. I think it should be kept simple and free of friends lists etc. (if anyone felt the need to track fellow Wikipedians I'm sure a JavaScript could be created to read the status' and produce a sidebar display of your listed friends. I don't think it's Wikimedias job to support that functionality). Not only is that likely to create cliques but it would require a fair whack of extra server and page scripting. Nice and simple indicator seen only on each account users talk and main page. Nothing fancy. -- fgTC 11:08, 29 October 2011 (UTC)
- You can see how does it look, it doesn't do more than showing the user status as current template does, only difference is that it doesn't make revisions to wikipedia as current template does. Petrb (talk) 11:37, 29 October 2011 (UTC)
- Against We already have Special:Contributions. WP is not Facebook - Nabla (talk) 11:28, 29 October 2011 (UTC)
- Please note I am not implementing new feature, I am replacing the existing feature which consinst of thousands of pointless revisions. This feature of "I am online" is already there over existing template, I agree with you that it's wrong and that's why I created this extension, so I don't understand why you rather would like to have it as it is now. Petrb (talk) 11:36, 29 October 2011 (UTC)
- I mean, the question wasn't "do you want to have this feature on enwp?", but "do you want this feature to be implemented over that template which does a lot of revisions seen in recent changes etc. or do you want this to be implemented over extension which doesn't touch wikipedia content tables and doesn't mess at recent changes"? :), just to clarify that.... Petrb (talk) 11:56, 29 October 2011 (UTC)
- I do not want it implemented. Period. Also, there is no current feature. Editors can write whatever they want, within policy, and some write that. That is not a feature (templates are not features, as I see it). Once in a while warning that you are off-line may make sense - I've done it once - but continuous warning is not needed for any purpose - and come to think of it, my warning was not needed either, WP carries on, with or without me :-). If you think such edits are wrong then do not make them easier. Instead why not suggest that they are not allowed? Change policy, delete the template... I might even support the idea, though I don't mind these edits. - Nabla (talk) 12:07, 29 October 2011 (UTC)
- I took a quick - and small, I know - sample of uses of the aforementioned template. Out of 6 users having it 5 got it wrong: either they are on-line but not editing for many months, or they are off-line since months ago but edited hundreds of pages today. The one 'correct' status wasw... "Unknown" :-) Useless. (actually, slightly counter-productive, as is misleading) - Nabla (talk) 12:23, 29 October 2011 (UTC)
- That looks to me just as another reason to have it done using extension, nothing else... Petrb (talk) 12:29, 29 October 2011 (UTC)
- No, that is an indication that this is not used. - Nabla (talk) 13:19, 29 October 2011 (UTC)
- Thousands of people use this, which indicates something else, imho Petrb (talk) 13:24, 29 October 2011 (UTC)
- Transclusion count: 1074, one thousand, not thousands. Used once, not use. Quite different. You do have some point for your suggestion (I don't agree, but you do) inflating fugures does not help you at all - Nabla (talk) 23:35, 29 October 2011 (UTC)
- I am not inflating any figures, you counted transclusions of only one template used for this, and I counted revisions made by changes to all userpages transcluding all of those, which are thousands, even the transclusion count is much higher than 1074, I have direct access to sql as anyone else, so it's not a problem to count it... Petrb (talk) 12:25, 30 October 2011 (UTC)
- Transclusion count: 1074, one thousand, not thousands. Used once, not use. Quite different. You do have some point for your suggestion (I don't agree, but you do) inflating fugures does not help you at all - Nabla (talk) 23:35, 29 October 2011 (UTC)
- Thousands of people use this, which indicates something else, imho Petrb (talk) 13:24, 29 October 2011 (UTC)
- No, that is an indication that this is not used. - Nabla (talk) 13:19, 29 October 2011 (UTC)
- That looks to me just as another reason to have it done using extension, nothing else... Petrb (talk) 12:29, 29 October 2011 (UTC)
- I took a quick - and small, I know - sample of uses of the aforementioned template. Out of 6 users having it 5 got it wrong: either they are on-line but not editing for many months, or they are off-line since months ago but edited hundreds of pages today. The one 'correct' status wasw... "Unknown" :-) Useless. (actually, slightly counter-productive, as is misleading) - Nabla (talk) 12:23, 29 October 2011 (UTC)
- I do not want it implemented. Period. Also, there is no current feature. Editors can write whatever they want, within policy, and some write that. That is not a feature (templates are not features, as I see it). Once in a while warning that you are off-line may make sense - I've done it once - but continuous warning is not needed for any purpose - and come to think of it, my warning was not needed either, WP carries on, with or without me :-). If you think such edits are wrong then do not make them easier. Instead why not suggest that they are not allowed? Change policy, delete the template... I might even support the idea, though I don't mind these edits. - Nabla (talk) 12:07, 29 October 2011 (UTC)
- I mean, the question wasn't "do you want to have this feature on enwp?", but "do you want this feature to be implemented over that template which does a lot of revisions seen in recent changes etc. or do you want this to be implemented over extension which doesn't touch wikipedia content tables and doesn't mess at recent changes"? :), just to clarify that.... Petrb (talk) 11:56, 29 October 2011 (UTC)
- I don't really oppose the whole thing of online status, but I don't find it useful either (though others might). I guess I don't really care if it becomes an opt-in automatic feature. I'd like to see some benefits listed though and someone who has genuinely found this useful beyond "Ah, I'll message them later since they are offline anyway". Does this really improve the encyclopedia? — HELLKNOWZ ▎TALK 12:16, 29 October 2011 (UTC)
- Thanks for reply, and once more: this proposal is not about allowing or disallowing people doing it, it's only about the way how it's being done (there used to be even ticket it mediawiki bugzilla regarding those pointless revisions), but if you want to know opinion on that, I myself do not like the current way because it spam recent changes and disallowing people from doing anything is always stupid, so my opinion is, let them do that in proper way. And concerning if it's of any use: yes it is, certain people would like to let others know whether they are available atm or not, in the end it can improve the communication between people, let's say 10 people are from one project (like AFC), you need urgent response from someone who's is participant of that project, but you don't know who is available at the moment to help you, this feature could help you find them (one example) Petrb (talk) 12:28, 29 October 2011 (UTC)
- I never said anything about disallowing this; I said I don't care if it becomes an automated feature (implying online statuses are already being used). I also didn't say it's not useful to anyone, I said it might be useful to some. — HELLKNOWZ ▎TALK 13:30, 29 October 2011 (UTC)
- Ok, reply to your question is: it doesn't improve the content, but it could improve the communication between contributors. Or at least it would make easier for other contributors ignore changes to userpages of other people who use that template. Petrb (talk) 13:34, 29 October 2011 (UTC)
- I never said anything about disallowing this; I said I don't care if it becomes an automated feature (implying online statuses are already being used). I also didn't say it's not useful to anyone, I said it might be useful to some. — HELLKNOWZ ▎TALK 13:30, 29 October 2011 (UTC)
- Thanks for reply, and once more: this proposal is not about allowing or disallowing people doing it, it's only about the way how it's being done (there used to be even ticket it mediawiki bugzilla regarding those pointless revisions), but if you want to know opinion on that, I myself do not like the current way because it spam recent changes and disallowing people from doing anything is always stupid, so my opinion is, let them do that in proper way. And concerning if it's of any use: yes it is, certain people would like to let others know whether they are available atm or not, in the end it can improve the communication between people, let's say 10 people are from one project (like AFC), you need urgent response from someone who's is participant of that project, but you don't know who is available at the moment to help you, this feature could help you find them (one example) Petrb (talk) 12:28, 29 October 2011 (UTC)
- (ec x2) For normal users it is not so useful, but it would be helpful if you are trying to contact administrators/oversighters/checkusers and for whatever reason don't want to email RFO. Yoenit (talk) 12:29, 29 October 2011 (UTC)
- bugzilla link to show that in past this used to be an issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=13520 Petrb (talk) 12:39, 29 October 2011 (UTC)
- Petrb, so te extension exists for 3.5 years! Why have it not been used so far?
- Because it wasn't finished Petrb (talk) 13:25, 29 October 2011 (UTC)
- mediawiki.org - Extension:OnlineStatus says: «Last Version 2009-08-22». Maybe the page is outdated? - Nabla (talk) 23:38, 29 October 2011 (UTC)
- Because it wasn't finished Petrb (talk) 13:25, 29 October 2011 (UTC)
- Yoenit, to contact an admin ask at the noticeboard. to contact a specific admin, as at the talk page, if you don't get a reply soon, s/he's off-line (or ignoring you) - Nabla (talk) 13:19, 29 October 2011 (UTC)
- I am well aware of that, but some things are best discussed with a specific oversighter/checkuser who was previously involved. If I know they are online I can mail them directly for a fast response rather than having to use wp:RFO. Yoenit (talk) 14:14, 29 October 2011 (UTC)
- Petrb, so te extension exists for 3.5 years! Why have it not been used so far?
- bugzilla link to show that in past this used to be an issue: https://bugzilla.wikimedia.org/show_bug.cgi?id=13520 Petrb (talk) 12:39, 29 October 2011 (UTC)
- Support. I think this upgrade of the status template is a good idea. Being automatic it would avoid all the pointless edits (on the current version). And editors who don't like the idea don't have to opt in which seems fair enough to me (they might even come up with a script to block themselves from seeing such templates). Maybe ask some more people who actually do use <code>{{Statustop}}</code>? - Benzband (talk) 12:46, 29 October 2011 (UTC)
- Actually it's possible to implement option to hide status of other users in the extension if there were more people who'd like it. Petrb (talk) 12:49, 29 October 2011 (UTC)
- Oppose Unless it's strictly opt-in. If people specifically want it, it's fine. If they don't, it could cause all manner of headaches of people seeing "oh X is online...ok why aren't they responding on their talk page!? Better spam them more!". ♫ Melodia Chaconne ♫ (talk) 13:52, 29 October 2011 (UTC)
- Yes proposal is to have it strictly opt-in as I said. It is also default configuration of extension. Petrb (talk) 13:54, 29 October 2011 (UTC)
- Query how does it know? Rich Farmbrough, 15:41, 29 October 2011 (UTC).
- How who know what? Petrb (talk) 16:35, 29 October 2011 (UTC)
- Source code of extension is at http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/OnlineStatusBar/ if you had question related to that Petrb (talk) 16:37, 29 October 2011 (UTC)
- Could you briefly explain it to the general public, please? "Read the source, Luke" comes across as one of those replies from snotty IT staff. ASCIIn2Bme (talk) 22:15, 29 October 2011 (UTC)
- Sorry, I didn't see this: I moved explanation to the head of this thread Petrb (talk) 11:18, 30 October 2011 (UTC)
- Could you briefly explain it to the general public, please? "Read the source, Luke" comes across as one of those replies from snotty IT staff. ASCIIn2Bme (talk) 22:15, 29 October 2011 (UTC)
- Source code of extension is at http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/OnlineStatusBar/ if you had question related to that Petrb (talk) 16:37, 29 October 2011 (UTC)
- How who know what? Petrb (talk) 16:35, 29 October 2011 (UTC)
- What's the point of this? Wikipedia isn't Facebook. We have IRC if someone needs to find an admin/steward in case of "emergency". /ƒETCHCOMMS/ 19:30, 29 October 2011 (UTC)
- Again, it's not about the "I am online" thing, that is already being used, it's about how is it done, this extension was developed to save the database (currently every update of template make a new revision) this affect the db dumps and also other users, because it's being recorded in recent changes. that's the point Petrb (talk) 19:53, 29 October 2011 (UTC)
- For some reason people still think this is a discussion about that if users should display their online status on their pages, which it isn't, I updated the description of proposal and I hope it's more clear now. It only improve the way how it's being done now. Petrb (talk) 20:01, 29 October 2011 (UTC)
- Actually, it is about the status thing. By making status displays more accessible, do you not admit that it will almost certainly result in more people choosing to display their status? And thus you must first consider whether that benefits Wikipedia or whether it is detrimental. What I consider good with this current system is that its annoying need for manual updating discourages its widespread adoption. So I will continue to oppose this proposal unless you claim that it will not have the effect of more users displaying their status, which would move Wikipedia in a direction with which I disagree. /ƒETCHCOMMS/ 00:56, 30 October 2011 (UTC)
- I think it would certainly lead to more users displaying their on-line status. I can't imagine a good argument to counter that glaring fact. I'm personally still in favour of using an automated system rather than the one(s) we have now but, wonder if you may very well be right ƒETCHCOMMS. Maybe this sort of improvement would lead toward us being more sociable. I really didn't mean that to be quite as sarcastic as it reads. Most social networking sites bore and worry me so I am not in favour of Wikipedia becoming like those at all. I think the benefit past the obvious reduction in edit histories to pages with nothing but one word on them would be simply allowing users to interact in a more human way. Some frustrations could be calmed on disputed pages since "Why is this person not responding??" (but in capitals) would be answered in a flash. Maybe I'm just a soppy hippy but I think it's nice to get along and easier to get along with people if they are a little more interactive than a page full of text. fgtc 01:38, 30 October 2011 (UTC)
- Indeed it's possible that it would lead more people to use it just like it is possible that it wouldn't, no one did such a research so far, I don't want to argue about that, but another fact is that it would probably be rather benefit, more users who display their online status would not harm encyclopedia even a bit, while pointless revisions do harm it seriously, we all know that every year people donate just enough to buy more storage in order to keep all the mess which is in database, but to me it looks like waste of money, while I see no problem in online status of people who want inform others about it, it isn't anyting more social, than having username instead of number. Petrb (talk) 12:19, 30 October 2011 (UTC)
- Actually, it is about the status thing. By making status displays more accessible, do you not admit that it will almost certainly result in more people choosing to display their status? And thus you must first consider whether that benefits Wikipedia or whether it is detrimental. What I consider good with this current system is that its annoying need for manual updating discourages its widespread adoption. So I will continue to oppose this proposal unless you claim that it will not have the effect of more users displaying their status, which would move Wikipedia in a direction with which I disagree. /ƒETCHCOMMS/ 00:56, 30 October 2011 (UTC)
- For some reason people still think this is a discussion about that if users should display their online status on their pages, which it isn't, I updated the description of proposal and I hope it's more clear now. It only improve the way how it's being done now. Petrb (talk) 20:01, 29 October 2011 (UTC)
- And this is where I disagree. Thousands of pointless revisions don't hurt Wikipedia (actually, does anyone have numbers for how many extra revisions the status changer causes right now versus how many almost pointless minor edits are done by bots each day?), but creating a more social-networking-like environment is not conducive to Wikipedia's mission. I don't want people hitting up other users for a nice talkpage chat just because they're bored and see the "online" message. That would be pointless revisions. People donate millions every year, and the WMF has more than enough to buy extra servers and whatnot. If you think the WMF is wasting money, there are many other frivolous things to complain about (e.g., Wikilove) than a few extra edits each day. And yes, statuses are more social than usernames—"social" is not the same as "personal"; usernames are personal indicators, not social ones. A username does not invite people to chat with you. /ƒETCHCOMMS/ 17:52, 30 October 2011 (UTC)
- I am a wikimedia developer, rather than searching things I can complain about, I try to improve them so that they don't suck that much so that no one needs to complain about them, as this one, indeed I disagree with wikilove as default, also you might be right that all the pointless revisions done by this template are not enough to be really harmful, but all pointless revisions done by templates like this (there is more that just online status, even talk pages are some sort of mess since there are liquid threads available for mediawiki) that all together makes mess in db which could be handled much better than donating more money so that we can purchase servers fast enough to handle all that crap, that's where I'd like to help. There are also many other better ways how we can invest all the millions donated by people than keeping alive system which is obsolete and doesn't work properly. It's also possible to update it so that it isn't so expensive, it's fascinating that it's easier to ask people for more money, than ask community to approve utility which could eventually make less resource-expensive something what is here and will be here, no matter of what result of this proposal would be (if people want to show their status on user pages, they will do show that and there is hardly a way to prevent them from doing that). Now I understand why many tools are enforced by wmf without asking community whether they want them (including moodbar and wikilove, as I just found in their documentation). I always respected the community and that's why I asked for your opinion here, of course when you disagree with that, I understand that and I wouldn't enforce anyone to have it here unless others would approve it, I just wanted to improve one of few things which could be improved, but it seems to me that many of people responding here, didn't even understand what is this proposal about. Petrb (talk) 20:34, 30 October 2011 (UTC)
- You know, if we just banned the entire status update system, we'd probably end up saving the database a lot more trouble. And given that the WMF has the power to enact any sort of rules it wants, then why not solve the issue that way? Otherwise, we're targeting side effects rather than the underlying issue. But regardless, I think most people understand what your proposal is for, but like me, they don't like its consequences—which are increasing the social-networking side of Wikipedia. There must be a way to solve both the "extra edits" problem while balancing it with the "not Facebook" argument. /ƒETCHCOMMS/ 21:20, 31 October 2011 (UTC)
- IMHO blocking people from being able to do something they like is not friendly, eventually could cause some leave wikipedia (or edit less often at least), which doesn't really help the project, goal of wmf is to make editing of wikipedia more entertaining and to bring more people to the project, not to discourage them, by adding extra rules. So far there aren't really rules on wikipedia, (for instance I follow only one rule: Ignore all rules) any unnecessary rule is counter productive to encyclopedia. It doesn't even make it look liberal, which it maybe isn't, but many people at least like to think that it is. Petrb (talk) 22:06, 31 October 2011 (UTC)
- Making Wikipedia more Facebook like is similarly detrimental. That, too, has caused many users to leave. I find it unfortunate that the WMF's goal is to make editing more entertaining, because entertainment is in the eye of the editor. We should not be making Wikipedia more social-network-like or more of a game. I'm not sure what you're trying to achieve by going back-and-forth with me; I've stated my reasons plenty of times and if you disagree, then disengage as well. Regards, /ƒETCHCOMMS/ 14:34, 1 November 2011 (UTC)
- IMHO blocking people from being able to do something they like is not friendly, eventually could cause some leave wikipedia (or edit less often at least), which doesn't really help the project, goal of wmf is to make editing of wikipedia more entertaining and to bring more people to the project, not to discourage them, by adding extra rules. So far there aren't really rules on wikipedia, (for instance I follow only one rule: Ignore all rules) any unnecessary rule is counter productive to encyclopedia. It doesn't even make it look liberal, which it maybe isn't, but many people at least like to think that it is. Petrb (talk) 22:06, 31 October 2011 (UTC)
- You know, if we just banned the entire status update system, we'd probably end up saving the database a lot more trouble. And given that the WMF has the power to enact any sort of rules it wants, then why not solve the issue that way? Otherwise, we're targeting side effects rather than the underlying issue. But regardless, I think most people understand what your proposal is for, but like me, they don't like its consequences—which are increasing the social-networking side of Wikipedia. There must be a way to solve both the "extra edits" problem while balancing it with the "not Facebook" argument. /ƒETCHCOMMS/ 21:20, 31 October 2011 (UTC)
- I am a wikimedia developer, rather than searching things I can complain about, I try to improve them so that they don't suck that much so that no one needs to complain about them, as this one, indeed I disagree with wikilove as default, also you might be right that all the pointless revisions done by this template are not enough to be really harmful, but all pointless revisions done by templates like this (there is more that just online status, even talk pages are some sort of mess since there are liquid threads available for mediawiki) that all together makes mess in db which could be handled much better than donating more money so that we can purchase servers fast enough to handle all that crap, that's where I'd like to help. There are also many other better ways how we can invest all the millions donated by people than keeping alive system which is obsolete and doesn't work properly. It's also possible to update it so that it isn't so expensive, it's fascinating that it's easier to ask people for more money, than ask community to approve utility which could eventually make less resource-expensive something what is here and will be here, no matter of what result of this proposal would be (if people want to show their status on user pages, they will do show that and there is hardly a way to prevent them from doing that). Now I understand why many tools are enforced by wmf without asking community whether they want them (including moodbar and wikilove, as I just found in their documentation). I always respected the community and that's why I asked for your opinion here, of course when you disagree with that, I understand that and I wouldn't enforce anyone to have it here unless others would approve it, I just wanted to improve one of few things which could be improved, but it seems to me that many of people responding here, didn't even understand what is this proposal about. Petrb (talk) 20:34, 30 October 2011 (UTC)
- Again, it's not about the "I am online" thing, that is already being used, it's about how is it done, this extension was developed to save the database (currently every update of template make a new revision) this affect the db dumps and also other users, because it's being recorded in recent changes. that's the point Petrb (talk) 19:53, 29 October 2011 (UTC)
- Already done - Use
importScript('User:Ale_jrb/Scripts/statusCheck.js');
to accomplish the same thing. Unfortunately, nobody uses it. →Στc. 19:44, 29 October 2011 (UTC)
- Hardly, it's not possible to do this using java script. Petrb (talk) 19:53, 29 October 2011 (UTC)
- Actually, some users do use the script. It isn't without it's drawbacks though. Currently, the script only tells an editor whether or not someone has edited in a given amount of time. Alpha_Quadrant (talk) 02:10, 31 October 2011 (UTC)
- Hardly, it's not possible to do this using java script. Petrb (talk) 19:53, 29 October 2011 (UTC)
- I'm not a fan of this. We're not a social networking site and we don't need social networking features. This will "legitimize" a practice that's outside our scope, and it will encourage people who aren't currently doing it to do it. You're mischaracterizing it by saying "People are already doi1ng it". If you make it official then more people will do it. And that'll just create more pressure to move the site in a bad (user-centric) direction. I don't want articles being "liked" even if people want to "like" articles on their own userpage. —Designate (talk) 20:19, 29 October 2011 (UTC)
- Thanks for your reply, I am unsure what you mean by "like" this is not implementation of "like" button, also this is definitely not anything illegal atm so if someone would like to have that on userpage, they would add it no matter of implementation (which is the reason for this), I don't even see what does it have common with social networks, it's like if you said that whole "register an account" feature was making it social network. It's about removing pointless revisions from content database. That's all. While I agree with you that online status may look silly to some users on wikipedia (especially using template which is updated everytime when you log in - out, and I personally never used it), not allowing its improvement wouldn't stop people from doing that. And this extension would rather help to people like you who don't like that feature, because it would allow you to ignore it even better. Petrb (talk) 20:29, 29 October 2011 (UTC)
- It's interesting that "wikilove" which definitely have character of social network has been smoothly approved, while this feature with merely technical context, which main purpose is to separate content from nonsense (those status-updating revisions are non-sense compared to other stuff in db including articles, which unfortunatelly are stored together), is really having troubles. Petrb (talk) 20:45, 29 October 2011 (UTC)
- It's a slippery slope. Petrb points out that we have Wikilove, which is a social networking feature (the only reason it "was smoothly approved" is because I had no idea it was happening, and I would've been completely against it for the same reason). Once we have two official features, it'll be easier to promote a third, more objectionable feature, by pointing out that we already have several social networking features. Once we have three, it'll be easier to add a fourth. I don't care about people saying they're online. That's irrelevant to me. What I care about is the perception of the site changing. Officially adding social-networking features (this is one) will encourage people to formulate other, more obnoxious features (ones that can't be done manually). I don't want to encourage that kind of culture here. That's why I'm against this. —Designate (talk) 22:25, 29 October 2011 (UTC)
- Thanks for your reply, I am unsure what you mean by "like" this is not implementation of "like" button, also this is definitely not anything illegal atm so if someone would like to have that on userpage, they would add it no matter of implementation (which is the reason for this), I don't even see what does it have common with social networks, it's like if you said that whole "register an account" feature was making it social network. It's about removing pointless revisions from content database. That's all. While I agree with you that online status may look silly to some users on wikipedia (especially using template which is updated everytime when you log in - out, and I personally never used it), not allowing its improvement wouldn't stop people from doing that. And this extension would rather help to people like you who don't like that feature, because it would allow you to ignore it even better. Petrb (talk) 20:29, 29 October 2011 (UTC)
- Question But what about people, like me, who use a different template for their status info, like {{Useronline}}? This has a completely different design, which I like better then the design of {{Statustop}}. Will this feature have more designs? I wouldn't use it if would only designed after {{Statustop}}, but would make the necessary edits further. Sir Armbrust Talk to me Contribs 21:22, 29 October 2011 (UTC)
- This feature was designed for this aswel, it creates magic word which can be used in templates so that you can create custom template aswell. Petrb (talk) 08:04, 30 October 2011 (UTC)
- In that case I support the implementation in order to avoid redundant edit (which I often forget to make, for example now I edit offline). Sir Armbrust Talk to me Contribs 12:09, 30 October 2011 (UTC)
- This feature was designed for this aswel, it creates magic word which can be used in templates so that you can create custom template aswell. Petrb (talk) 08:04, 30 October 2011 (UTC)
- Support I am one of those people who is always listed as offline because I always forget it update my status --Guerillero | My Talk 21:29, 29 October 2011 (UTC)
- Need more information. Will this be automatic?Jasper Deng (talk) 22:28, 29 October 2011 (UTC)
- Yes it will be automatic and it would not touch content db. Petrb (talk) 08:04, 30 October 2011 (UTC)
- Will I be able to change the status myself?Jasper Deng (talk) 22:01, 31 October 2011 (UTC)
- Yes. But you can't create own status unless you create own template for that. Petrb (talk) 09:16, 1 November 2011 (UTC)
- Will I be able to change the status myself?Jasper Deng (talk) 22:01, 31 October 2011 (UTC)
- Yes it will be automatic and it would not touch content db. Petrb (talk) 08:04, 30 October 2011 (UTC)
- Support but I'd like to see the information exposed in a parser function or some such thing so that we can use arbitrary status templates with it. I'd also like to see documentation of precisely how it behaves (and don't tell me to read the source, that's insufficient). --NYKevin @027, i.e. 23:39, 29 October 2011 (UTC)
- There is documentation on mediawiki, explaining how does it work, if it got installed on wp I will update meta aswell, atm updating it with stuff which isn't available is not of any use Petrb (talk) 08:04, 30 October 2011 (UTC)
- Oppose, but with great respect to the coder of this extension. You mean well, but Wikipedia is not a social media site and we should not be codifying a bad idea just because the current implementation is poor. The better response is to deprecate {{Statustop}} and its clones. Resolute 01:37, 30 October 2011 (UTC)
- Support I am probably one of the most vehemently anti-social networking people you've ever met, and I'm damn proud of that fact, but this is a feature that has legitimate uses on Wikipedia. During my GAN I was sending messages to people who I thought were receiving them, only to find out that they had gone offline just five minutes earlier. I was stuck in a holding pattern, not working on the article in question, because I thought a response to my question was just around the corner. Yes, this can be abused by social networking addicts, but so can other things we already have. Unlike the share button proposal, this proposal has merit for improving the encyclopedia. Plus, he already said it would be opt-in only. Sven Manguard Wha? 05:14, 30 October 2011 (UTC)
- I don't how this feature would have helped you with that ("just five minutes earlier"). See how it works below; it keeps track of when someone last read a page. There's not way to tell from that if they went to the bathroom or if they went to bed. ASCIIn2Bme (talk) 16:38, 31 October 2011 (UTC)
- That is not correct, even a bit. Petrb (talk) 19:17, 31 October 2011 (UTC)
- Support as optional - As an improved feature for those who find it useful; however it should remain entirely optional. — CharlieEchoTango — 05:26, 30 October 2011 (UTC)
- Support. Eliminating all the useless revisions and time-wasting edits to status pages is a good reason to support. The ability to customize the design is also appealing. -- Ϫ 08:48, 30 October 2011 (UTC)
- Oppose because it encourages inappropriate use of the Encyclopaedia as a social networking tool. Chzz ► 08:51, 30 October 2011 (UTC)
- Oppose Apart from my suspicion of ever-more social networking gadgets, the extensive commenting above without actually saying anything about what actually happens is an indication that the gadget is unlikely to have much encyclopedic benefit (see response to "how does it know?" above). Johnuniq (talk) 09:41, 30 October 2011 (UTC)
- I hope that explanation on top is what you meant by "what happens". It's not that it's secret, I just didn't notice the question. Petrb (talk) 11:24, 30 October 2011 (UTC)
- Concerning benefit, there were many answers in thread, some of them were like: it improves the communication between people, it help prevent creation of pointless revisions to encyclopedia, it wouldn't spam recent changes and others... Petrb (talk) 11:25, 30 October 2011 (UTC)
- I hope that explanation on top is what you meant by "what happens". It's not that it's secret, I just didn't notice the question. Petrb (talk) 11:24, 30 October 2011 (UTC)
- Support as opt-in feature. For those complaining that this would add unwanted social networking functionality, people who like it are already using it, but in a way that adds pointless revisions, messing up the edit history. I certainly won't use it, but I'm absolutely fine with others doing so. Nageh (talk) 14:03, 30 October 2011 (UTC)
- Support; Sven Manguard above sums up my thoughts quite well. 28bytes (talk) 15:25, 30 October 2011 (UTC)
- Support Per Sven Manguard. There have been so many times I have wondered whether or not a user is online. Adding an opt-in auto-updating status gadget would be quite useful. This feature will not turn Wikipedia into a social networking site. All it will do, is improve communication between users. Alpha_Quadrant (talk) 02:10, 31 October 2011 (UTC)
- Support, in my personal capacity. Okeyes (WMF) (talk) 03:18, 31 October 2011 (UTC)
- Support useful feature - I already use the statuscheck tool, but it is quite slow & tends to be a bit resource heavy. Knowing with a glance whether someone is accessible/online is extremely useful for collaboration. --Errant (chat!) 10:12, 31 October 2011 (UTC)
- Support - WP:NOT is a conversation starter not a debate ender. Wikipedia is a far cry from being a social network anyway. Marcus Qwertyus 10:25, 31 October 2011 (UTC)
- Support but only if it's optional. I do agree that creating subpages that are updated manually every time one logs in or out is a waste. I don't like the concept either, but I think this automated tool is a good compromise. — Train2104 (talk • contribs • count) 13:44, 31 October 2011 (UTC)
- Support if optional Lugnuts (talk) 15:02, 31 October 2011 (UTC)
Opposeper "the timestamp shows when the user last read a page ". It think this contravenes the foundation:privacy policy: "No more information on users and other visitors reading pages is collected than is typically collected in server logs by web sites. Aside from the above raw log data collected for general purposes, page visits do not expose a visitor's identity publicly" (emphasis mine). ASCIIn2Bme (talk) 16:31, 31 October 2011 (UTC)- If that is problem I can customize it so that data are collected only for people who use this. Also I don't understand why you don't have troubles with other things like checkuser which already violates the foundation policies... Petrb (talk) 17:16, 31 October 2011 (UTC)
- I don't think that's the case. Does checkuser track when people read pages? I though it was tracking only when they edit pages. ASCIIn2Bme (talk) 17:42, 31 October 2011 (UTC)
- If that is problem I can customize it so that data are collected only for people who use this. Also I don't understand why you don't have troubles with other things like checkuser which already violates the foundation policies... Petrb (talk) 17:16, 31 October 2011 (UTC)
- It doesn't track people any more unless they use this feature, therefore your reason lost its point. Thanks for the opinion. Petrb (talk) 19:20, 31 October 2011 (UTC)
- Please note that wikimedia servers already track ip addresses and other data when browsing pages for statistics, also this extension doesn't track your ip, just last time when you opened last page and only for the time you are online, so your reason was loosing its point from begining, but it's possible you just didn't know that or you oppose for some other reason, which I respect anyway, or you just don't like it, for no reason, I don't really care... Petrb (talk) 19:27, 31 October 2011 (UTC)
- It doesn't track people any more unless they use this feature, therefore your reason lost its point. Thanks for the opinion. Petrb (talk) 19:20, 31 October 2011 (UTC)
- Also, I see no attempt to take into account editors' clicks on the "log out" button. So, to continue an example given by Sven Manguard above, this extension doesn't make any distinction between someone going to the bathroom for 5 minutes and someone who clicks "log out" and goes to bed. ASCIIn2Bme (talk) 16:53, 31 October 2011 (UTC)
- It of course set you offline in that case, so this isn't true. I updated the description, I apologize if that confused you Petrb (talk) 19:13, 31 October 2011 (UTC)
- Okay, others may find it useful now and the privacy issue seems addressed in the promise that "I can customize it so that data are collected only for people who use this". I see no reason to oppose it anymore, but I have no real reason to support it myself. ASCIIn2Bme (talk) 13:16, 1 November 2011 (UTC)
- It of course set you offline in that case, so this isn't true. I updated the description, I apologize if that confused you Petrb (talk) 19:13, 31 October 2011 (UTC)
- Support - improves existing functionality by making it more reliable and reducing meaningless diffs. (I'd make this a specifically opt-in support, but I see above that's already the case.)--SarekOfVulcan (talk) 17:14, 31 October 2011 (UTC)
- Support. This is just an enhancement to an existing feature, so I can't see a good reason to oppose it. Thryduulf (talk) 17:35, 31 October 2011 (UTC)
- Support, provided it's opt-in and that it doesn't reveal any additional private information. I don't think I would use it myself (as I used to use the scripted one in the past but became too lazy to update that one), but I also don't see the harm in including it if it helps the encyclopedia along. –MuZemike 21:32, 31 October 2011 (UTC)
- Support Common sense change. Noformation Talk 08:39, 1 November 2011 (UTC)
- Support A better version of an already-existing feature. --Philosopher Let us reason together. 02:34, 3 November 2011 (UTC)
- Support As with Sven_Manguard, I'm not a big fan of social networking features. But people are already doing this, so we may as well do it in a sensible, sane way. And the problem isn't "social networking" per se: it's that sometimes you need to contact specific people in order to get things done on-wiki. If you are dealing with vandalism or serious user behaviour issues, sometimes you do need to contact specific admins by e-mail or talk page, and it's quite useful to be able to see if they are online. I already have a user script installed that shows me how long since their last edit (userinfo.js). This is utterly common sense: user page policy limits what is acceptable on user pages to that which helps build the encyclopedia. Like it or loathe it, real-time updating is the norm, and real-time collaboration is vital to the functioning of Wikipedia. Yes, yes, people can use IRC. But not everyone wants to. This is an utterly sensible thing to have, and opposition to it seems to stem from that utterly bizarre Wikipedian attitude of "well, it's okay if we have X, but so long as it isn't easy to do X" (e.g. barnstars good, Wikilove bad; templates good, visual editor bad; status updating on user pages okay, implementing it in a sensible way bad). —Tom Morris (talk) 12:39, 4 November 2011 (UTC)
- Support. Like many of the above editors, I loathe adding social networking features to Wikipedia, but this does make sense. People have and will continue to do the online/offline thing (And I'm not sure if I will opt in if this proposal succeeds). Better to have a system which is automatic rather than one which 99% of the users fail to update regularly. VictorianMutant(Talk) 23:20, 5 November 2011 (UTC)
- Support as opt-in. I've no intention of using it, but Wikipedia is a collaborative environment and this seems something that might facilitate collaboration for some editors. older ≠ wiser 23:39, 5 November 2011 (UTC)
- Support as opt in. I don't see much down side to replacing the current template with this. I also don't see how this makes Wikipedia a social networking site. Even gmail has status indicators. Kaldari (talk) 05:58, 6 November 2011 (UTC)
- Support - Wikipedians already do this anyway; an extension would just make easier what already happens. It would have to be opt-in so that those who do not want it are not troubled by it. Those who do not like the idea don't need to use it if they don't want to - that's fine by me. Unless one proposes that any form of online status should be banned form userpages, I see no real rationale for rejecting this. ItsZippy (talk • contributions) 21:45, 7 November 2011 (UTC)
- Support This is a "social networking" instrument only in that it gives new editors access to the same information that we aged users do. It might save a few new editors blowing a gasket when I don't respond immediately because I'm sleeping, an unpleasant experience for both of us. Danger High voltage! 01:38, 8 November 2011 (UTC)
- Support I use the Qui script system - it works well and I change the status with a click of the mouse, but it does add an edit every time to my status sub page. An automatic system would be better - but I think opt-in is required. Ronhjones (Talk) 22:47, 12 November 2011 (UTC)
- Support as a parser so people can use it as they want. I see absolutely nothing wrong with giving people a choice. Ajraddatz (Talk) 15:47, 20 November 2011 (UTC)
- Opposetracking. you're creating a tracking-system for all users, whether they choose to have it shown on their page or not. Choyoołʼįįhí:Seb az86556 > haneʼ 08:13, 21 November 2011 (UTC)
- No, it doesn't track anyone unless they activate it, and even if they do, it doesn't save anything else than a timestamp. Petrb (talk) 08:47, 21 November 2011 (UTC)
- Said facebook. I read your defense below, doesn't convince me. Choyoołʼįįhí:Seb az86556 > haneʼ 10:37, 21 November 2011 (UTC)
- Support as a voluntary option of editors. Particularly for articles that might be contentious or whose subjects might be undergoing rapid change, it might be useful to be able to bring together all the "sides" involved, or people with access to all the relevant sources. And making it voluntary would not oblige anyone who doesn't want to take part to do so. John Carter (talk) 23:39, 21 November 2011 (UTC)
- Support as a voluntary option. I don't really see any harm in adding this, and I'm sure that some people would find this useful. Regardless of what some people may claim, Wikipedia will not become Facebook or a social networking site. If people wanted to use it like that, they'd simply use a social networking site already made for that purpose.--Slon02 (talk) 01:56, 22 November 2011 (UTC)
- Strong support.(with opted-out as the default) As a participant on other large collaborative open source projects that draw their core teams from across many time zones and from people with different levels of availability, it is often important to provide, and be given some indication of how long a response may be forthcoming. Arguments that there are plenty noticeboards, help desks, admins, and other people around are not convincing, as many items for discussion and/or action can only be addressed by one individual. One may argue that nothing here is urgent, but some are, and unless one has a friendly talk page stalker, articles may get deleted, users blocked, and users denied the opportunity to respond to other accusations of malpractice. I abhor social media sites and such a feature would not turn Wikipedia into any more of a social gathering than the collaboration on phpBB and it's help forum. I use StausChanger and wouldn't want to be without it, but it concerns me that it adds up to 3,000 edits a year my editcount. it will need more variable for user customisation that are being offered, and I for one would be happy to test it. If this proposal were to be implemented, its introduction would be discrete, and there is no reason to believe there would be a stampede to use it. If 1,000 of the busiest editors end up using it, that's a 1,000 reasons to adopt it. --Kudpung กุดผึ้ง (talk) 12:52, 22 November 2011 (UTC)
Online Status: How does it work?
The heading to this section has been updated with some information about what the proposed extension does. Could that please be clarified: This extension would maintain a table of [user_id, timestamp] records for all users? The timestamp shows when the user last read a page? The table is periodically purged to remove entries with an old timestamp? The time elapsed before a timestamp is regarded as old is a wiki-wide setting? What would be a proposed value? If some magic wikitext is present on a user page, that magic is expanded each time the user page is viewed? Does it work on user talk pages? On any other page? If user X puts the wikitext on user Y's user page, would everyone be able to see if Y is offline? Johnuniq (talk) 00:54, 31 October 2011 (UTC)
- This extension would maintain a table of [user_id, timestamp] records for all users?
For most of registered users who visit wikipedia, just like the checkuser table or cache tables, data will not be accessible and would be only used when user allows that- For users who did enable this feature in their settings. Petrb (talk) 19:09, 31 October 2011 (UTC)
- The timestamp shows when the user last read a page??
- Timestamp shows when user who use this feature last opened any page (but doesn't store name of the page, it doesn't store anything else than timestamp as reference and username) on wikipedia when logged in. (if $wgOnlineStatusBarTrackIpUsers isn't true), otherwise even when not logged in
- The table is periodically purged to remove entries with an old timestamp? The time elapsed before a timestamp is regarded as old is a wiki-wide setting?
- default setting is 1 hour, it can be changed wiki-wide, it's not customizable by user.
- What would be a proposed value?
- That's up to you, otherwise it would be default value.
- If some magic wikitext is present on a user page, that magic is expanded each time the user page is viewed? Does it work on user talk pages? On any other page? If user X puts the wikitext on user Y's user page, would everyone be able to see if Y is offline?
- Text is expanded everytime page is purged, it does work in user and user talk space, if user X put that text on user Y page who doesn't have it allowed it expand to unknown, otherwise it shows their status.
- Some informations on statuses:
- This extension was not designed in the style of social network feature therefore the implementation of statuses may appear little bit too simple, but I believe that it's enough for purpose of extension:
- The extension contains following statuses: Online as a general online status, Away for people who (as already noted) may become temporarily unavailable but not left for longer time, Busy for people who for instance work on some article and can't respond quickly - and that's all, also there is a status hidden which appears same as offline. It isn't possible to create own "fancy" statuses. It also isn't possible to change the appearence of icon of status and text, it's integrated to the mediawiki skin you choose so that it follows its preferences. For that you would need to create a custom template.
Thanks for question. Petrb (talk) 06:17, 31 October 2011 (UTC)
- question Did I get it right that you wrote, or maintain, this extension and thus you - and you alone - control what it logs? And it may quickly changed from logging all user to logging opt-in users, as your above striken explanation suggests? In short, who controls the code? - Nabla (talk) 22:06, 1 November 2011 (UTC)
- No you didn't it's is stored in mediawiki svn, so that any wikimedia developer with access to svn can change the code, also before deloyment it would need many reviews done by others. Having say that, everyone can see if it does what I say it does, and anyone could improve it or change. (Althougt I am maintaner now) Petrb (talk) 14:50, 2 November 2011 (UTC)
- But you were true that I change it based on the feedback here. Any constructive ideas are welcome. Petrb (talk) 14:52, 2 November 2011 (UTC)
- Thank you. Understood, no problem about it then. I understand we disagree, which is fine, I hope you also understand that when I ask not to implement this, I am not being "destructive" (as opposed to constructive). In my opinion, right or wrong I can't be sure, turning WP into a facebooky thing is very bad. To me personally it would be a very very good thing. You implement this and I am out the very next minute :-) It will gain me a few hours per week for other interesting things.... And I am only one, sure. But will this help WP? How many editors out there will avoid a WP site that turn (more) 'social'? And how many editors will WP gain? Is it worthy in the long run? - Nabla (talk) 01:57, 3 November 2011 (UTC)
- I can't answer this, I just try to improve existing stuff which can be improved - I have seen a thing which I didn't like (that template) and instead of proposing to force people to stop using it I tried to improve it, I don't like idea of making more restrictions anywhere, I like freedom and having say that it already exist, I don't assume it change anything else than its technical implementation / functionality. Or I can eventualy implement stuff requested by community, wheter it harm it or not, that's something what community needs to answer (and that's why I asked here). Petrb (talk) 10:16, 3 November 2011 (UTC)
- Thank you. Understood, no problem about it then. I understand we disagree, which is fine, I hope you also understand that when I ask not to implement this, I am not being "destructive" (as opposed to constructive). In my opinion, right or wrong I can't be sure, turning WP into a facebooky thing is very bad. To me personally it would be a very very good thing. You implement this and I am out the very next minute :-) It will gain me a few hours per week for other interesting things.... And I am only one, sure. But will this help WP? How many editors out there will avoid a WP site that turn (more) 'social'? And how many editors will WP gain? Is it worthy in the long run? - Nabla (talk) 01:57, 3 November 2011 (UTC)
- But you were true that I change it based on the feedback here. Any constructive ideas are welcome. Petrb (talk) 14:52, 2 November 2011 (UTC)
- No you didn't it's is stored in mediawiki svn, so that any wikimedia developer with access to svn can change the code, also before deloyment it would need many reviews done by others. Having say that, everyone can see if it does what I say it does, and anyone could improve it or change. (Althougt I am maintaner now) Petrb (talk) 14:50, 2 November 2011 (UTC)
up?
So, is this up or not? When? - Nabla (talk) 14:14, 8 November 2011 (UTC)
- Discussion is still open, I am just wondering why you dislike this so much while it's so minor update of system that you can't even see if it has been already installed or not... I can assure you that even if this discussion was closed in favor of installation, it would take at least week for it to happen. Petrb (talk) 20:17, 8 November 2011 (UTC)
- You could be in the process of installing, as you say it. You do place an interesting question, though. If this is a minor update - and I may admit it is technically - why do I dislike it so much? Really... I do not know! I quite like the 'social' possibilities offered by the 'net. I enjoyed a lot playing chess by e-mail and being able to talk with the opponents was a major enjoyment factor. I've play some MMOG longer than I've been here, and enjoyed chatting in there. Yet one of the factors that drove me off of it was... these "social" thingies that help little, except in 'facebooking' the site. I enjoy meeting people in here (see this message :-) I am not able to tell exactly why, but I very much dislike the (specifically) social features. Probably the problem is about being "pushed" into a "social" site. I'm not here to meet people (if I do I go out and have a beer with some friends or I'll join the real facebook :-), I want to write, correct, organize, etc. And there is not a single urgent matter requiring prompt assistance from anyone specific. None whatsoever. There is nothing that can not wait until tomorrow OR be executed by any available editor/admin/... I wish the best of luck, in this in whatever else you code and do. But, to me, this is very bad. Fine, WP can live without any single editor, as I have just said:-) I am not leaving but this is bad, turning the whole net into facebook is silly. - Nabla (talk) 22:30, 12 November 2011 (UTC)
1 user likes this. I couldn't agree more with Nabla. This hits the nail on the head. Toshio Yamaguchi (talk) 16:04, 20 November 2011 (UTC)
- At the same time, Nabla, the entire internet is "upgrading" to be more like Facebook. Whatever stance you have on the issue, that is a fact. I think that it could be rather easy for Wikipedia to fall behind if it doesn't continue to improve methods of user interaction - while one person leaving won't make a difference, over time we could be looking at significantly more than that. Now, I'm not trying to scare everyone into enabling this minor change, but I do see the potential for some bad effects resulting from Wikipedia's unwillingness to improve (improvement being, of course, a very subjective term). Ajraddatz (Talk) 02:17, 21 November 2011 (UTC)
- You could be in the process of installing, as you say it. You do place an interesting question, though. If this is a minor update - and I may admit it is technically - why do I dislike it so much? Really... I do not know! I quite like the 'social' possibilities offered by the 'net. I enjoyed a lot playing chess by e-mail and being able to talk with the opponents was a major enjoyment factor. I've play some MMOG longer than I've been here, and enjoyed chatting in there. Yet one of the factors that drove me off of it was... these "social" thingies that help little, except in 'facebooking' the site. I enjoy meeting people in here (see this message :-) I am not able to tell exactly why, but I very much dislike the (specifically) social features. Probably the problem is about being "pushed" into a "social" site. I'm not here to meet people (if I do I go out and have a beer with some friends or I'll join the real facebook :-), I want to write, correct, organize, etc. And there is not a single urgent matter requiring prompt assistance from anyone specific. None whatsoever. There is nothing that can not wait until tomorrow OR be executed by any available editor/admin/... I wish the best of luck, in this in whatever else you code and do. But, to me, this is very bad. Fine, WP can live without any single editor, as I have just said:-) I am not leaving but this is bad, turning the whole net into facebook is silly. - Nabla (talk) 22:30, 12 November 2011 (UTC)
- Well the sysadmins won't even think about installing it until it's had two rounds of code review, one for general code quality and then one for security and performance from Tim. Given that that process hasn't even started yet (Template:Bug), you're looking at much more than a week. Happy‑melon 00:07, 21 November 2011 (UTC)
- actually it has been already reviewed by Ian (wmf), it had one more performance fix and it will be reviewed again once it's clear if community wants it. Petrb (talk) 07:29, 21 November 2011 (UTC)
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: Herpes zoster and Shingles 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)
- 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)
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:
- 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)
- 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)
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) |
---|
- 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) |
---|
- 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) |
---|
- 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) |
---|
- 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) |
---|
- 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 Vilnius "also known as 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 ([10]). 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 Vilnius "also known as 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 ABCDEFGHIJKLMNOPQRSTUVWXYZ. that is obviously not a pseudonymous for "alphabet", but the former does redirect to the latter (as does its lower case twin). With nearly 4millon articles it is fair to assume there are many cases where redirects are not for the purpose of "AKA"'s. Another example: 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)
- 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)
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)
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 Wikipedia:Flagged revisions/Quality versions, Wikipedia:Stable versions, meta:Reviewed article version, Wikipedia:Flagged revisions/reliable revisions. Fences&Windows 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. Shimgray | talk | 13:52, 22 November 2011 (UTC)
Non-controversial admins
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. Sven Manguard 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)
Celebration for 5 millionth edit
How about a small celebration for the 5 millionth edit? We are currently at 1,239,236,067, so we only need −739,236,067 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)
- No, it's 19.55 by average edits per page. ~~Ebe123~~ → report on my contribs. 20:25, 24 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 739236067 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)
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:
- If set to
no
, add media with the license tag to Category:All free media not requiring a link to the description page (feel free to suggest a better name). - If set to
yes
, do nothing. - If set to anything else or omitted, add the media and/or the template itself to some sort of maintenance category.
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. Sven Manguard 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)
- 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)
- 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)
- (edit conflict) Re: MGA73: The fact of the matter is that, whether or not you approve of the practice, we do have many free images uploaded locally and we do have {{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)
- 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 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)
- 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)
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.
- Output
- 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).
- 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).