Wikibooks:Reading room/Proposals/2011/September

User:CommonsDelinker
This is not the first time I call attention to the collateral damage this bot does to our project. I propose that the bot needs to be carefully monitored by humans on its "Removing" action. From time to time I get hits on pages I watch and I attempt to fix them if possible but I believe that this should be made more transparent to the rest of the community, remove the bot flag so the edits are visible if we can't filter only the removals. What is the status of the bot in regards to revisions of pages? I would expect that edit reviews to be done by human but I'm not fully aware of how flags interact and if the bot can get automated promotion... The bot does an indispensable work but I would even prefer to keep red links to deleted images than let it continue to work as it has. --Panic (discuss • contribs) 02:02, 4 September 2011 (UTC)


 * When a bot edits a reviewed page, I believe the page is automatically reviewed. That happens with bots on Wikinews even though we have autoreview turned off.  Wikinews runs CommonsDelinker without the bot flag.  --Pi zero (discuss • contribs) 04:31, 4 September 2011 (UTC)


 * That is then a problem with the CommonsDelinker Removing action, it shouldn't be automatically reviewed. I don't have an issue with the other functions of the bot but how it is removing images that are sometimes replaceable is extremely damaging (this should also be an issue with the people at commons, not to delete images that are in use in other Wikimedia projects without making a minimum of effort to find a replacement (even better if the bot could do the "redirect" for them). --Panic (discuss • contribs) 05:25, 4 September 2011 (UTC)
 * Note also that this silent removal of "dependencies" of sister projects downgrades the usefulness of the Commons project in itself and preventing the categorization of images by relevancy. --Panic (discuss • contribs) 05:28, 4 September 2011 (UTC)


 * Agreed, and I've raised this before (when it removed the title image used for a Featured Book). However, I didn't think it auto-reviewed pages. If it does, then we should remove the "reviewer" right so that it can't QU TalkQu 09:22, 4 September 2011 (UTC)


 * The only right it has is "IP Block Exempt". I've checked the last ten edits to reviewed pages and they were all manually approved by a human reviewer... QU TalkQu 09:28, 4 September 2011 (UTC)


 * Indeed. I removed reviewer from it in May 2010 for the reasons above.  For a few weeks the delinker wasn't even working.  That's worse, in that deletions at Commons just leave red links in books that you don't know about.  People should replace removed images with equivalents if possible. – Adrignola discuss 19:44, 4 September 2011 (UTC)


 * I have been attempting to call Commons to act also better on deletions. [Consider_adding_as_a_requirement...] by adding as a step, to their deletion process, finding alternatives and fixing images uses. We have locally shown consideration for other projects so I don't see it why they can't reciprocate (We move deleted projects to other locations and probably by using Wikipedia links also contribute to that project evolution).
 * My proposal still stands, should we remove the bot flag should be off (the review is relevant only when there are people active on the affected projects), since our projects tend to be extremely personal and often the topic is not accessible to every one we most of the time will not review outside of our sphere of action, except if the edit value is obvious.
 * I also don't share Adrignola dislike for red links (I don't love them), since they are themselves informational. It would be wonderful if the CommonsDelinker could be made to act a bit differently. --Panic (discuss • contribs) 03:46, 7 September 2011 (UTC) edited --Panic (discuss • contribs) 14:45, 7 September 2011 (UTC)

Are you proposing that CommonsDelinker be blocked indefinitely? If not, I fail to see how the proposal still stands. There are no other actions to be taken at Wikibooks. CommonsDelinker does not have the flags (bot, reviewer, autoreviewer) you propose to remove. CommonsDelinker does not auto-review any pages it edits. How CommonsDelinker deals with deleted images is something to be discussed with the bot's developers. Finding a suitable replacement instead of deleting is something to be discussed at Wikimedia Commons. --dark lama  14:19, 7 September 2011 (UTC)


 * No, as I state above "I propose that the bot needs to be carefully monitored by humans on its "Removing" action" (also to determine if it is problem and define avenues to mitigate the issue). This developed into discussion of the CommonsDelinker access flags (me and others) were not aware of how the flags stood (or any changes made to them), so this also serves to express the community view on how to keep them.
 * As for the later avenues you advanced, I already presented a proposal at Commons (addressing the deletion process or even to create a methodology to ease our problem, the lack of people performing corrective actions, that I myself associate with a lack of visibility/impact of the changes), and so I agree that from our side (Wikibooks) there is not much that can be done, but anyone able to participate in finding/creating a solution will benefit from this push to address what is now understood to be a real problem.
 * The last solution that I proposed at Commons I'm not certain if it is technologically viable. I asked that since the bot is capable of making substitutions (the mechanics of how it is processed I do not know) if it was possible to use a boilerplate image asking users to find or contribute a substitute. Another avenue would be for the Wikimedia software to report the absence of an image in another way than by a red link. --Panic (discuss • contribs) 14:45, 7 September 2011 (UTC) edited --Panic (discuss • contribs) 17:15, 7 September 2011 (UTC)
 * Or creating a local bot/script to fix the CommonsDelinker removals (by substituting them with a local boilerplate image). --Panic (discuss • contribs) 14:48, 7 September 2011 (UTC)
 * The bot is quite capable of making substitutions. I've done it before when deleting an image that was in use but violated copyright but had equivalents.  It requires the administrator to find a replacement, then order the bot to make a replacement prior to making the deletion.  Everything the bot does is a direct result of administrator action.  (You may have seen the replacements for exact or scaled-down duplicates).  It is certainly possible that the bot could be set up to swap in a default placeholder when removing a deleted image, if you were to get enough support for that. – Adrignola discuss 15:10, 7 September 2011 (UTC)
 * I haven't seen people expressing opinion on what they see is a best method to call people into action. I think a reader will be more prone to it if he notices something missing or out of place (hence the wiki adoption of the red links). This solution could also resolve the issue with the bot access flags (since visibility would be preserved). In any case this seems one of possible solutions, a change of procedures at Commons would majorly reduce the instances that the removal negatively impacts our project, but failing that this seems to be a viable alternative, even a complement. Do you see any negatives ? --Panic (discuss • contribs) 17:15, 7 September 2011 (UTC)

Set $wgRestrictDisplayTitle to false
The script MediaWiki:Common.js/Displaytitle.js and the template Template:Displaytitle use javascript to replace the content of the top heading of a page. Rather than using javascript to change the title, I think it would be better to just set $wgRestrictDisplayTitle to false and use DISPLAYTITLE: to have the content there from the start. --Yair rand (discuss • contribs) 21:35, 8 August 2011 (UTC)
 * Although wgAllowDisplayTitle could be set to false, this is not recommend by the developers, as it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it..
 * For changes in titles such as French/Lessons/Introductory/Review (done through [ this template]), I think it is better to create (per book?) gadgets for people who want to have non-linkable, but nice, titles. Another option is to add the original title somewhere in the page as is done by pt:MediaWiki:Gadget-Títulos simples.js (see example), so that we still have access to the original title for copy+paste. Helder 13:07, 9 August 2011 (UTC)
 * PS: The part of the script which process the tab parameter doesn't seems to be working in all skins, e.g. at [ Cookbook:Carrot?useskin=vector] and [ Cookbook:Carrot?useskin=nostalgia], so I think it should be either fixed or moved to the JS pages corresponding to the skins where it works (MediaWiki:monobook.js, MediaWiki:modern.js and maybe some other skin). Helder 13:25, 9 August 2011 (UTC)
 * I've updated it to reflect a change that must of been made to id attribute, so the namespace tab/link should be working again in all skins that have one. --dark lama  14:43, 9 August 2011 (UTC)
 * In some skins (at least vector and chick) the first letter of the tabs is in Uppercase while on monobook (and some other?) it is in lowercase. Could you make the tab link to be consistent with the other tabs depending on the skin?
 * PS: It is good practice to prefix with "$" the name of a variable whose value is an instance of jQuery (such as $dt and $what). Helder 15:27, 9 August 2011 (UTC)
 * Template:Displaytitle is already in use. How is allowing DISPLAYTITLE: to modify the title worse than using displaytitle to modify it through js? --Yair rand (discuss • contribs) 03:07, 10 August 2011 (UTC)
 * Will editing of a page still show the real page path if $wgRestrictDisplayTitle is set to false ? Will it break any of our extensions ? (a change would require us to inform devs that they shouldn't continue to assume the flag as true) Has any other project altered the flag (Wikisource) ?
 * I think that the notion that "it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it." is important but to a lesser degree in Wikibooks. We often link to books, not to specific book pages, this mostly occurs inside the same book. Since displaytitle is available to modify the displayed title (and people are using it actively, I was not the first to see some benefits for Wikibooks specific needs). If the final result is the same I don't see why we shouldn't simplify the process.  --Panic (discuss • contribs) 04:06, 10 August 2011 (UTC)
 * Even when displaytitle is restricted, the edit page still shows the real page path regardless of displaytitle (see for example ), so it probably also does when $wgRestrictDisplayTitle is set to false. --Yair rand (discuss • contribs) 07:32, 10 August 2011 (UTC)
 * Click that link again; the title is still set to the DISPLAYTITLE version when using built-in code updated in Template:Displaytitle. – Adrignola discuss 15:44, 15 September 2011 (UTC)


 * Symbol support vote.svg Support. So we can set $wgRestrictDisplayTitle is set to false, then to handle existing uses, have displaytitle use DISPLAYTITLE with a parameter. Though this would lose the tab name changing functionality, I wouldn't bemoan that and changing the basic interface is probably more objectionable than changing the title.  Changing displayed titles is consistent with pages on the Web that have titles chosen by the page's creator.  displaytitle does not show the page's real title when editing; see .  So if this setting does show the real title, it could be a superior option.  I do like situations like Muggles' Guide to Harry Potter/Books/Half-Blood Prince showing "Harry Potter and the Half-Blood Prince" and having the tab changed to "Book 6".  Few books change the tab, but the Cookbook changes it for all ingredients.  But special JavaScript could be used for the Cookbook, with everything else using the built-in function or the transition template.  At minimum it would open up an option for having titles altered without being dependent on JavaScript. – Adrignola discuss 14:06, 10 August 2011 (UTC)
 * I support not needing JavaScript for features whenever sensible. I think this is one such case. I know can be made backwards compatible by using the DISPLAYTITLE magic word to change the title while still using JavaScript to change the tab. --dark  lama  15:50, 10 August 2011 (UTC)


 * Bug filed. --Yair rand (discuss • contribs) 20:28, 7 September 2011 (UTC)
 * Done. Can someone make the change to displaytitle? --Yair rand (discuss • contribs) 00:14, 15 September 2011 (UTC)
 * I'm not seeing that it's working.  yes?  Changing just the first letter to lowercase works. – Adrignola discuss 04:02, 15 September 2011 (UTC)
 * Rumor has, it got set to true instead of false. --Pi zero (discuss • contribs) 14:57, 15 September 2011 (UTC)
 * Indeed. But now they have fixed that. – Adrignola discuss 15:41, 15 September 2011 (UTC)

New Deletion Policy for the Transwiki Namespace
I have been considering working up a draft of a change to the deletion policy as it relates to the Transwiki namespace. There are a number of long ago imported items in the TW namespace that have not been adopted. Some have since been significantly changed (I would argue improved) in their donor projects while not being modified here at all by the original requester. Examples include Transwiki:History of homosexual people in Nazi Germany and the Holocaust, imported from WP in 2006, and Transwiki:Guglielmo Marconi imported in 2008. I propose that after a period of time with no attempt to adopt transwiki'd content then it should be deleted. This wouldn't apply if the content had been deleted from its donor project of course. The idea is not simply good housekeeping but to avoid editors helping out by completing a TW clean-up of what is actually five year old content that nobody wants. It would be better surely to start again with the latest content should someone want it. I'd welcome your views on the principle before I start investing too much time in policy drafting - thanks <font color="#E66C2C">QU <font color="#306754">TalkQu 18:39, 22 September 2011 (UTC)


 * That sounds reasonable to me. I would support it. --Jomegat (discuss • contribs) 18:42, 22 September 2011 (UTC)


 * I think they should qualify for speedy deletion. "Any transwikied work not adopted after 30 days may be speedy deleted". --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  19:11, 22 September 2011 (UTC)


 * Yes, that's what I should have said ;-) At its simplest I would propose this as a new criterion for speedy deletion... <font color="#E66C2C">QU <font color="#306754">TalkQu 20:12, 22 September 2011 (UTC)


 * I also agree. Darklama's rule sounds good to me.  I also have a book in mind that consists entirely of 300 pages of transwikied content that was never edited by the person requesting it, but that may be a different issue. – Adrignola discuss 22:33, 22 September 2011 (UTC)


 * OK I understand that it's not good having stuff that was imported several years ago but which has remained untouched every since but why delete it? (waiting for people to attack me with claims that "what harm is it doing" and "are we running out of serve space?" is not allowed) But seriously, if a page/book/whatever is not completely unsuitable for Wikibooks, isn't offensive, isn't nonsense, isn't a copyright violation and isn't a duplication of something else - why delete it?--ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 23:03, 22 September 2011 (UTC)
 * OK, having re-read some of what Quitusual said it makes a little more sense especially if this would only apply to work that hasn't been deleted on the project from whence it came.--ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 23:05, 22 September 2011 (UTC)
 * Surely I always makes sense ;-) <font color="#E66C2C">QU <font color="#306754">TalkQu 10:55, 23 September 2011 (UTC)


 * Some time back I suggested redirects from transwiki space, left from moving imports out of it, should be subject to speedy deletion. Are we interested to do that too?  (Is there some drawback to it I'm not seeing?)


 * I do favor the 30-days-unless-deleted-from-donor proposal (if I'm understanding it rightly). --Pi zero (discuss • contribs) 14:13, 23 September 2011 (UTC)


 * I speedy those redirects as orphaned redirects but it could be made explicit in the policy. It seems there's a general view supporting bits of my original idea, so I'll work on the unstable branch to draft something - thanks <font color="#E66C2C">QU <font color="#306754">TalkQu 17:08, 23 September 2011 (UTC)