Wikibooks:Reading room/Proposals/2012/April

Proposal for making interwiki links a different color
I am restating this proposal here in a clearer way at the suggestion of User:Panic2k4.

The proposal is to make links on Wikibooks to other Wikimedia projects (notably Wikipedia) a (slightly) different color then internal links, in much the same way as links you have already followed look different then links to pages you haven't visited. My original proposal was this:

My reasons for proposing this are explained in there. The exact color of the links would have to be decided based on readability and the effect on color blind people. I would suggest #336600     ( link ) or #808000      ( link ). Another shade of blue may be better, though.  Liam987  07:24, 3 April 2012 (UTC)
 * My comment is that wikipedia does not typically use plain links for any site outside of the project itself. They make it known that you are leaving their site by using things like "Related media on Wikimedia Commons." and so on. Wikisource has adopted the same practice, in that most links only link internally to wikisource. Maybe it might be better to leave all interwiki links in a "Further reading" section or something? - Theornamentalist (discuss • contribs) 10:18, 3 April 2012 (UTC)


 * Wikipedia is an encyclopedia it would defeat its purpose to rely on other sources to explain the subject matter on Wikisource the issue is probably resumed by most content not being wiki formated on the source material and intended to be static (not open to improvements). --Panic (discuss • contribs) 12:24, 3 April 2012 (UTC)


 * Wikibooks also has and uses templates that let the reader know they are leaving the website (wikipedia for example). I think Wikibooks best practice is already considered to only list external links in a further reading page or to make use of templates that distinctly separate an external link from the content, just as Wikipedia either uses templates or places external links in either a see also, references or external links section.
 * I think inline templates can just as easily be made and used in books where the contributors want to make a distinction in some other way like with color differences or adding an icon after the link. Other options include the use of the per-book stylesheet to effect just one book, make a Gadget so the choice is up to people, or make use of the personal stylesheet at Special:MyPage/common.css. --dark lama  13:13, 3 April 2012 (UTC)


 * I do not support nor object the proposal (because I do not see it as necessary my browser does all the differentiation I require). I only ask that the changes take in account the themes colors and mobility of content and do not become too prominent. --Panic (discuss • contribs) 12:24, 3 April 2012 (UTC)
 * I too am not too concerned about whichever route this takes, and wouldnt stand in the way of those who wish to have it stylized this way. However, I think the colors might be confusing; sister sites plus internal would mean 9 Wikimedia links, and thus, 9 different colors. Wikipedia would be the most often linked, but I could easily imagine someone linking to wiktionary, wikisource and commons almost as easily, just less frequent.
 * The purpose (I believe) is to let users simply know when they are leaving, but a green or grey link on a wikibook may not convey that until learned or explained somewhere prior. Using an icon after the word works well in that it keeps the color scheme the same and can let someone know where they are going because of it, but it also assumes that they know our icons.
 * Either way, the worst thing that happens is they have to hit back in their browser. Personally, I prefer the template boxes for any linking. - Theornamentalist (discuss • contribs) 16:16, 3 April 2012 (UTC)


 * Of course there wouldn't be a different link style for each Wikimedia project, just one style that means "interwiki link". (I think gray is a good color for that.) Also, those templates are not inline. The irritation of a different color of link really is not that annoying. And, when you are reading a book, you really don't want to go to a page with out knowing wether it is a chapter on the topic or an article on Wikipedia. Of course you can hit the back button, but you completely lose the thread of your reading.  Liam987  17:44, 3 April 2012 (UTC)
 * Is there a way to force it into a new tab if it is outside of the work or wikibooks? - Theornamentalist (discuss • contribs) 19:16, 3 April 2012 (UTC)
 * See Gadget Preferences. There is an External Links Gadget under Readers for opening any link that points outside of Wikibooks in a new tab or window. A Gadget that opens links outside the book in a new tab or window sounds like a good idea. --dark lama  23:08, 3 April 2012 (UTC)
 * Ok, I am going to be bold and say that at this junction I support a separate color (which has been specified somewhere in a wikibooks help page) for all outgoing links, with the outgoing links being opened in a new tab as default for all users. - Theornamentalist (discuss • contribs) 23:47, 3 April 2012 (UTC)

Wikipedia links
I have noticed that quite a lot of Wikibooks use links to Wikipedia regularly. At the same time however, they link to other Wikibooks and other chapters of the same book. It is, of course, impossible to tell wether the link is internal, to another book, or to Wikipedia without clicking on it or hovering over it. This can be extremely bothersome to a reader, who may want to read a Wikibook or chapter on the subject, but not a Wikipedia article. The reader can not tell until he or she has clicked on it where it is going. An example from C++ Programming:

"Bjarne Stroustrup, a Computer Scientist from Bell Labs, was the designer and original implementer of C++ (originally named "C with Classes") during the 1980s as an enhancement to the C programming language. Enhancements started with the addition object-oriented concepts like classes, followed by, among many features, virtual functions, operator overloading, multiple inheritance, templates, and exception handling. These and other features are covered in detail along this book."

The first two links link to Wikipedia pages, the second links to a Wikibooks subject page, and the rest link to other chapters of the same book. Wikipedia links are useful, of course, because they can link to related pages that the Wikibook does not deal with. For example, a Wikibook about the French language may say that French is also spoken in Monaco, but a reader might like to know where Monaco is and the book does not want to waste time explaining it, as it is not directly relevant. A link to Wikipedia becomes very useful in cases like this. But Wikibooks should try not to rely on Wikipedia too much, and so a link to it should appear different than one to a chapter within the Wikibook or another Wikibook. After all, books should be encased within themselves and not need to rely on the explanation of an encyclopedia or another book. Can you imagine how annoying it would be to have a math text book that makes you go look up what a quadratic function is?

So my proposal here is to use the project-wide CSS page to make all links to other projects look different than inter-chapter and inter-book links. This could be done with a slightly different color or font, or something similar to (but different than) the way external links appear (with the arrow thing like this - external link).

This would really facilitate the reading experience, and make this project less dependent on Wikipedia. After all, Wikibooks is not an encylopedia, and so does not have to conform to the formatting standards of Wikipedia.  Liam987  14:31, 29 March 2012 (UTC)


 * I'm certainly no css expert, but I wondered if you could actually do that. How do you distinguish between a namespace at WB, a page at WB with a : in the name, an interwiki and an interwiki that includes a non-main namespace at the other project? And do it reliably? QU TalkQu 15:49, 29 March 2012 (UTC)


 * Of some relevance, there's a gadget on Wikinews to "Open links to external sites [which includes sister projects] in a new window [in my browser at least, actually a new tab]". --Pi zero (discuss • contribs) 16:08, 29 March 2012 (UTC)


 * Wikibooks has that Gadget too. --dark lama  16:19, 29 March 2012 (UTC)


 * The body tag has a class that varies by namespace to allow styling to depend on the namespace of a page. If only the styling of a book's content is to be effected a more narrower container needs to be used in combination with the namespace class, but that one varies by skin. --dark lama  16:19, 29 March 2012 (UTC)


 * On my CSS style page on Wikipedia I added


 * which I got off of Wikipedia:WikiProject User scripts/Scripts. This CSS makes all the external links I see look greenish, and links between Wikimedia projects a different color green. So it's possible.  Liam987  16:25, 29 March 2012 (UTC)
 * So clearly  defines interwiki links (including links to other projects) and   defines one that has been previously visited.  Liam987  16:28, 29 March 2012 (UTC)


 * ".external" is present for all links of the form some text . ".extiw" is present for all links of the form some text where magic is treated as a page somewhere other than the local wiki, for example "w:" or "v:". If styling differs between those two classes, links for the same page using different forms won't have the same styling. E.g [//en.wikipedia.org/A A] vs A.
 * ":link" and ":visited" just mean to match unvisited or visited links.
 * Without .ns-0 or .ns-110, external and interwiki links will also be green even in places like the reading room where it might not matter.
 * Without a more specific container like #article (Standard and CologneBlue skins), #mw_contentholder (Modern skin), or #bodyContent (Vector and Monobook skins), external and interwiki links will also be green in areas like the copyright notice seen upon ever edit.
 * With Vector, for example, the ideal CSS is:


 * --dark lama  17:29, 29 March 2012 (UTC)


 * The view that the "The reader can not tell until he or she has clicked on it where it is going." is incorrect. For instance I can easily see where a link goes to by simply using the browser resources to show me that information. I can simply hover over a link and a popup will appear or read the same information on the status bar.
 * No opposition to the proposal, but since I'm personally aware that some people dislike the visual pollution wiki links create in general content, this will exacerbate those issues. Because the proposal is "to use the project-wide CSS page to make all links to other projects look different" a specific discussion requiring more visibility would be needed as to select the color used for the differentiation, or we should explore the possibility that the setting can be made personal and not global. --Panic (discuss • contribs) 23:29, 29 March 2012 (UTC)
 * Possibly, then, a variant of the external link arrow (like this) that appears next to the external link. Is that possible? Also, making interwikis look different would encourage editors to maybe not use the links so frequently, reducing visual clutter.  Liam987  06:59, 30 March 2012 (UTC)


 * I don't think this will help reduce at all the visual clutter, most pages here are edited by a single editor and those rarely have that issue but in project with a few editors or in works that use tranwiki culling down the replication is extremely hard another issue is that works can become extremely extensive and when fragmenting the page in smaller sections what was a duplication becomes a useful link again, this and the high volatility of any wiki content makes delimiting visual clutter from useful metadata an extremely hard task... --Panic (discuss • contribs) 09:38, 30 March 2012 (UTC)


 * As well as the browser status bar (or similar) the links already are formatted in a subtly different shade of blue (on Vector, no custom CSS) - the link to Bell Labs is colour 3366bb, while the link to multiple inheritance is 0645ad. This is done using CSS, and Vector is the default skin, isn't it?  Although the difference is subtle and IMO could be a bit greater, this seems the best approach - inserting the external link symbol or similar breaks the flow of reading.  ChrisHodgesUK (discuss • contribs) 10:06, 30 March 2012 (UTC)


 * So color definitely is a better proposal than the "External.svg" idea.  Liam987  11:04, 1 April 2012 (UTC)

Should I start a vote/poll for this?  Liam987  08:25, 2 April 2012 (UTC)


 * I have difficulty in defining what option was final agreed as a way to proceed or if all objections stated above have been resolved (or accepted). It seems that no one opposes making the information more visible, but not on the method to implement it. For instance I would object for the use of an image.
 * I would ask you to restate the (changed?) proposal and simply request that anyone opposing to come forward. State an end date to reach a conclusion of 7 days after the last post on the discussion.
 * If a site wide alteration is on the table then a announcement is required, ask for it to the administration. --Panic (discuss • contribs) 08:44, 2 April 2012 (UTC)


 * Who should I ask to put up an announcement?  Liam987  07:43, 3 April 2012 (UTC)


 * Any administrator can do it, after you restate the proposal ask at Reading room/Administrative Assistance (the admin will probably use part of your proposal text in the announcement). --Panic (discuss • contribs) 12:01, 3 April 2012 (UTC)


 * I suggest you create a proposal sub page here with a description of the proposal and a support / oppose section. Transclude the proposal onto this page. That way we can more easily keep track of the discussion and archive it later. QU TalkQu 10:14, 4 April 2012 (UTC)


 * It seems it was already restarted below. I also find that simply discuss things in general in this single talk is conducive of poor records or even inconclusive ends (since some discussions may be archived without a proper conclusion, something I already called attention previously).
 * I must state that show of support is not necessary, the objective is only to resolve oppositions, in that demonstrations of support may help (or not, if no arguments is made or addressed contested) but are not expressly necessary and a proposal without objections would classify as consensual (considering that the rest of the rules of process decision have been followed). --Panic (discuss • contribs) 15:23, 4 April 2012 (UTC)


 * So should it be moved to a subpage?  Liam987  17:47, 4 April 2012 (UTC)


 * At this time it would be counter productive (I already think that separating it in a distinct thread had a negative impact on the discussion, since this thread already covered much regarding it). Since the administration is now aware and knows the requirements of announcing high impact decision processes as soon as it becomes obvious that the proposal will indeed affect the general project they will perform it (something that seems that it is not clear at this time). --Panic (discuss • contribs) 19:38, 4 April 2012 (UTC)

Autoreviewed user right
(For readability and ease of continuation, previous posts have been framed, this does not remove their relevance, please consider their content, especially if you only now joining the discussion  --Panic (discuss • contribs) 04:40, 18 April 2012 (UTC) )

As to resume the discussion, now extremely long of the primary proposal that has suffered several changes, themselves independent proposals that retroactively would affect the principal. In accordance to what was previous discussed (read above), the first item that needs consensus is if the new "Autoreviewed users" access group (see Special:ListGroupRights for the permissions ), should be adopted on Wikibooks (answering the issue raised by Adrignola above). Because this would alter the rest of the proposals and so this item is given primacy. Maintaining "Autoreviewed users" access group would permit a distinct access group whose edits will not change the review status of a page and no access to the rollback function of the reviewer groups. As to address the issues discussed and close or continue addressing the dependent proposals, the community is therefore called to express opposition to keeping the "Autoreviewed users" access group. This discussion will last for 7 days after the last post on this thread. No opposition (or their restatement) will mean keeping the "Autoreviewed users" access group. The group will then have the community's support and we will proceed in giving it a function (as previously discussed) and the necessary requirements for attribution (the primary primary proposal by QuiteUnusual). Please attempt to focus only on the specific topic and/or the viability of alternative approaches that would resolve most of the problems the community feels that having pages showing a pending reviewed status seems to cause. It would not only be welcomed but necessary to understand the real possibility of such solutions and how they may impact the use of the group. Any issues not related with the discussion of this item, I (and I believe others) will gladly address on our own talk pages (but please read the previous posts above first). --Panic (discuss • contribs) 04:40, 18 April 2012 (UTC)

Since no opposition was expressed we shall consider the existing Special:ListGroupRights validated by the community, a concern raised by Adrignola (the creation of the user group in itself is not specifically a high-impact decision but the next points regarding function and attribution will need to be properly announced). We will now move on to the next point on the table regarding what use shall be given to the new usergroups. As advanced in the previous discussion some voiced opinions in defense of giving use to the "Autoreviewed users" usergroups as a stepping stone to reviewers and to better characterize the community confidence in those that do contribute content but do not wish to be auto-confirmed. That is we recognize a confidence that the content contributed is safe and within our project definitions and changes made by those users do not require a third person verification. This of course permits to auto-promote to "Autoreviewed users" probably using a relaxed criteria based on what is now used for Reviewers but this is not in discussion for now as there may be other proposal regarding the group function to be expressed. This discussion will last for 7 days after the last post on this thread. No opposition (or their restatement) will mean using the "Autoreviewed users" access group as an intermediary access group in relation to the Reviewers (as proposed by myself). This is a discussion regarding appropriate function not the criteria granting "Autoreviewed users", if you have a better/different function for the usergroup put it forward. --Panic (discuss • contribs) 01:22, 30 April 2012 (UTC)


 * Panic, historically I have worked very hard at being polite in discussions, but, operating in that mode, it seems some messages here haven't been getting through to you.


 * Your strategy here seems to be to flood the thread with words until everyone is sick of the thread and boycotts it, and then claim that what you want has "consensus". Seems like you may even have twice presented a biased "summary" of what had come before and then claimed consensus (I haven't got the stomach to go back to check exactly how it went down before).  This is &mdash;sorry&mdash; bullshit.  I see no consensus here, except perhaps consensus that this thread is no longer useful, that consensus being expressed by people staying away from the thread.  I hadn't even noticed the "unless there is opposition within seven days" clause you'd unilaterally imposed, until just now.  (Wait, didn't I say something earlier about assuming my position was unchanged until-and-unless I retracted it?  Wouldn't that mean that the opposition you wanted within seven days already existed at the start of the seven days?  I'm not even going to go wading back through this to find out exactly what who said when.  You can likely produce these claims far, far more easily than anyone could possibly work out exactly which of your words are specifically false.  Like I said: this thread is no longer useful.)  --Pi zero (discuss • contribs) 03:32, 30 April 2012 (UTC)


 * I agree that I shouldn't have been the one calling the consensus on the previous stage but, things need to be resolved toward a conclusion (initiated in 24 February). I'm not imposing that we should consider it closed but I feel we couldn't have excluded what was previously discussed (biased or not) and discard it to initiate a new process for the several proposals that have been made.
 * I will apply delegate in you the run of the proceeding as to respond to all concerns that have been expressed. I expressly requested a restatement because I would not want to assume again your position. The 7 days stated count after the post that indicates a proposal and a discussion limit (not that I'm enforcing the closing, because I was the initiator and I agree that ethically I shouldn't have called its closing, but more that the stipulated time had gone by and no one acted.
 * My last attempt to work toward a conclusion, (not to conclude or call a consensus like you indicated) was in 5 April 2012, it is now 30 April and the issue has not evolved. If you feel that you can bring this issue to an end please do so. I still do not understand your position fully, and several questions have not gotten an answer, not only mine, but even when you asked for other groups that should be removed, and other issues, ultimately proposals tend to derail into issues not directly involved with the initial proposal, this one is no exception.
 * Again feel free to bring yourself the proposals to an end if you think I'm being intentionally biased or attempting to steamroll the process...  --Panic (discuss • contribs) 03:54, 30 April 2012 (UTC)

Request feature: Author namespace
(For readability and ease of continuation, previous posts have been framed, this does not remove their relevance, please consider their content, especially if you only now joining the discussion  --Panic (discuss • contribs) 01:50, 30 April 2012 (UTC)

As to resume and conclude the discussion, now extremely long of the primary proposal regarding the creation of an Author namespace to protect copyright claims and attributions made by an unsigned or unregistered user and taking in consideration the opinions expressed on the subject. I move that the proposal as initially state should be negated as not gathering the consensus. A subsequent alternative proposal, taking in consideration what has been said, will occur afterwards as to provide communal validation for requests of page protection regarding copyright and legal sensitive notices, that will address partially the concerns of the initial proponent. This request will be open for participation until 7 days after the last post on this thread. No opposition (or their restatement) will mean that the community does not support the creation of a new Author namespace (as initial proposed). --Panic (discuss • contribs) 01:50, 30 April 2012 (UTC)