Wikibooks:Reading room/Proposals/2010/June

Per-book CSS
Would it be technically reasonable to have per-book style sheets enabled by default for everyone instead of just as an optional gadget for registered users to play with? Despite the complications arising from the added complexity that could be very useful for editors looking for prettier and more consistent layout. It could also be handy to solve more immediate problems - for instance, book communities unhappy with the recent changes to Geshi.css would be able to disable the grey boxes for their books with just a few lines of CSS instead of having to fight with the enclose="none" hack like Thenub was doing a few weeks ago. --Duplode (talk) 05:30, 10 June 2010 (UTC)
 * A few comments since I have thought about this a little. I should preface this with I have only a rudimentary understanding of CSS. One advantage (to me) would be that this would allow one to modify the :before and :after pseudo-elements, which would allow one to implement automatic counters.  But maybe it is possible to do this with div tags somehow?  I don't know.
 * On the other hand there is a small danger that this would allow very clever vandals to do moderately clever things that then vandalize every page of a book at once. This is not a reason not to do it, but just a thought.
 * Finally, is there any concern over accessibility? With my counters example above, I think if I were to actually implement it would cause problems for older IE browsers which do not support CSS2? (again I am not too sure.)  So it seems were we could end up quickly in a state where different books have different browser requirements.  To be honest there has long known to be some problems with older IE browsers and the way it displays some characters.  I know the set notation characters are particularly bad, such as &isin;, &cap; &cup; &sube;, etc.  But these symbols still get used all the time... so maybe we are already at a state where different modules need different browser requirements and shouldn't worry about it?  Or maybe we would be raising the bar on what is considered an "older IE browsers"?  I don't know for sure what different browsers do and do not support, but I thought I would mention it. Thenub314 (talk) 09:02, 10 June 2010 (UTC)


 * Several things to mention here. The per-book CSS has no documentation linked from the gadget page (or at all as far as I can tell), so it could be enabled globally and then removed from the gadget list, but in either case would not be used by those who don't already know it's there.  The definition is at MediaWiki:Gadget-Perbook.js.  The only use of it is at MediaWiki:Perbook/X86 Disassembly.css, which stems from the lack of documentation or awareness.  The main thing to not is that CSS and JS pages for a book have to begin with MediaWiki:Perbook/, so only administrators would be able to make changes, preventing vandalism. Also, there is no documentation for the personal per-book CSS/JS on the gadget page, and apparently that one doesn't work in Vector, so maybe that should be removed as well. – Adrignola talk contribs 12:22, 10 June 2010 (UTC)

IIRC this was globally enabled at first. Somethings were made gadgets IMO over zealously probably because gadgets was a new toy at the time. --dark lama  13:01, 10 June 2010 (UTC)


 * Well, those issues complicate things, indeed. Admin-only edition would be annoying both for users and admins, resulting in no one actually using Perbook. Answering to Thenub's remark on vandalism I would suggest the pages would be editable by editors only - that assuming there was a way of changing the permissions without rewriting the whole gadget... and the vector issue would have to be solved too, of course. And accessibility is a concern too - since we are an educational site we need to be tolerant with people using Horrible Browsers (such as old IE versions). Assuming that we would have a handful of editors able to review the style sheets for major issues and that not too many books started to use them at once (both reasonable assumptions) I think that problem could be managed. Additions to the Manual of Style to advise against too radical changes (say, pages with purple background) would be in order as well. --Duplode (talk) 18:47, 10 June 2010 (UTC)


 * Due to safety concerns, per-book CSS/JS remains accessible only to admins, but per-user book CSS/JS and per-book CSS/JS are now combined in MediaWiki:Common.js/Perbook.js. You can test per-book CSS/JS for yourself and then request an admin to move it to the MediaWiki namespace.  Documentation will have to be developed and linked. – Adrignola talk contribs 14:03, 23 June 2010 (UTC)


 * If anyone can simply add whatever javascript they wanted they could do something malicious like directs you to a fake website that looks like Wikibooks and claim you need to sign in, in order to gain access to people's account for example. While someone couldn't do that with CSS, they could vandalize a page and than edit the css to hide the edit button to make it more difficult for most people to undo it. Thats why editing a personal version that affects only one user and than requesting changes be made that affects everyone is important to do. That can also minimize the introduction of bugs that could immediately affect people trying to work on books, since people can continue work on the book unaffected, while other people are working on changes that affect only them and work out any kinks. --dark lama  14:37, 23 June 2010 (UTC)

Transwiki importer
Is there any interest in getting the Transwiki importer flag enabled for this wiki? —Internoob (Disc·Cont·Wikt) 03:40, 22 June 2010 (UTC)
 * I doubt if that is necessary, since everything here is controlled and I don't think there is a need to get the transwiki importer flag. Kayau ( talk &#124; email &#124; contribs ) 07:42, 22 June 2010 (UTC)


 * I am not sure…, take a look at WB:RFI where there is currently a request for over 200 pages. Large requests like this are not unheard of, and they represent a fair amount of work when they occur.  On the other hand, I am not sure it makes sense to fill our transwiki namespace with pages that have no book they correspond to, so I would expect a transwiki importer to be very familiar with the project. Over all I am personally neither hear nor there (says someone who hasn't put his fair share of work importing.) I reserve my judgment until after I read what a few more people have to say. Thenub314 (talk) 07:54, 22 June 2010 (UTC)


 * I think having this flag could be helpful. Like the uploader flag, should be given only to people that have a need for it, and it should be able to be given and taken back by anyone with the sysop flag. --dark lama  11:41, 22 June 2010 (UTC)


 * I support it for trusted users only and would not give it out like the editor flag (but the uploader flag is a good comparison). A bad import merges the history at the destination page and reconciling that is near impossible. – Adrignola talk contribs 12:22, 22 June 2010 (UTC)


 * Since Adrignola is supporting, I see know reason why I should oppose, particularly since he does most of the importing work. Support. Kayau ( talk &#124; email &#124; contribs ) 14:25, 22 June 2010 (UTC)

There's an important difference from uploader. Were we to do this, we should be sure that granting anyone the importer bit would always be accompanied by an admonishment that WB:WIW. Note that if someone were setting out to do something that would violate WB:NOTWP, a likely symptom would be that they would want to import hundreds of pages at a time. --Pi zero (talk) 14:04, 23 June 2010 (UTC)


 * I don't think it's difficult at all to see if an editor knows about our project scope... Kayau ( talk &#124; email &#124; contribs ) 14:11, 23 June 2010 (UTC)


 * Our project scope is sometimes so subtle that it takes an RFD discussion to sort it out. If a simple measure can help to keep down the number of cases that ever get that hard to sort out, we should take it.  To be clear, I was using the term "admonishment" in a sense at the opposite end of the spectrum from the harsh sense listed at admonishment, and close to definitions 2 and 3 at admonish.  --Pi zero (talk) 15:49, 23 June 2010 (UTC)


 * Is your comment (Pi zero) a subtle commentary on the current state of WB:RFI? – Adrignola talk contribs 15:14, 23 June 2010 (UTC)


 * The situation there feeds into my general concern on the subject. I'm sure I have a general concern here, so that's what I commented on.  --Pi zero (talk) 15:49, 23 June 2010 (UTC)


 * Would anyone object if a feature request were filed at Bugzilla? —Internoob (Disc·Cont·Wikt) 17:49, 24 June 2010 (UTC)


 * I personally don't feel there's consensus for this yet. We have a couple people who have concerns.  Another supports it simply because I do (I'm flattered, but that's not a weighty argument).  I'd like to see more opinions on this, though participation is down. – Adrignola talk 18:07, 24 June 2010 (UTC)

FWIW, large imports can easily be automated. Perlwikipedia supports transwiki importing, it would be easy to write a script to do imports en masse. &mdash; mike@enwikibooks:&#126;$ 18:12, 24 June 2010 (UTC)


 * Might work if imports didn't time out half the time. – Adrignola talk 18:19, 24 June 2010 (UTC)

Next step in deprecating bookshelves?
Being one of the most steadfast holdouts against the deprecation of bookshelves I would like to undermine myself and suggest our next step. After looking at some of the links point here from wikipedia I think it would be in our best interests to make sure there are redirects pointing to the subject pages for any "major" subject. For example, I moved the Mathematics redirect away from the bookshelf and pointed it at the subject page and just created a Science redirect.

My thinking is that this will provide a minuscule improvement on visibility for the project (just barely an ε). In particular because wikipedia's template simply searches for the article name here, it would be nice if for "major subjects" people ended up seeing us with our best face on.

So this is what I intend to do, and I would like to encourage others to do the same. Anytime we think of something that is a "major subject" that we are interested in, we add a redirect to the corresponding subject, assuming of course such a subject exists here and there is not already a book with that title, and it is a phrase that is reasonable to believe will be search for. I am not going to pursue this as a very active task, but thought it might be a nice idea to have in the back of our minds. Thenub314 (talk) 11:54, 23 June 2010 (UTC)
 * I've redirected the first two tiers of subjects to their non Subject: names. – Adrignola talk contribs 13:38, 23 June 2010 (UTC)
 * I think sister links isn't used much to refer to works on Wikibooks if at all. I think is most often used and it supports linking to pages in any namespace. I think we should get rid of main space redirects to bookshelves/subject pages. --dark  lama  13:50, 23 June 2010 (UTC)


 * I am not so sure one is used more then the other. A quick checking the "what links here" pages for both templates you can click "next 500" about 6 times.  Granted this is not a very accurate count since for both of them one should really exclude user space pages, etc.  But to an order of magnitude they seem to be used about equally.  I only came up with the idea as I went to include a few links back to wikibooks from some articles (such as Science and Mathematics) and found they already linked here using the this template. Unfortunately when I followed the links I was often not lead back to anything sensible.


 * For the record one thing I find personally disappointing is that choice of placement of links to wikibooks vs links to wikipedia books. The general consensus seems to be links to wikibooks belong in the external links section, while links to wikipedia books belong in the "see also" section.  Since the see also section typically comes before the external link section, the links back to wikibooks are not as visible. It makes sense in one way since we are a separate site, and their collections are internal to their site.  Unfortunately I think it overall erodes the usefulness of links to wikibooks and (probably) sows confusion about what wikibooks is.  Now if I try to get colleagues interest in the project over lunch, I run the risk of having them go back to their office and google'ing books wikipedia.  But we are only the third link on that search, it could be worse I guess.   Thenub314 (talk) 14:19, 23 June 2010 (UTC)
 * I must be a bit confused about your comment.
 * Thenub, it is possible to exclude all links, redirects, and non-mainspace transclusions by clicking a few buttons or adding a few suffixes, so the urls are http://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere&hideredirs=1&hidelinks=1&target=Template:Wikibooks&namespace=0 and http://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere&hideredirs=1&hidelinks=1&target=Template:Sister+project+links&namespace=0 FYI. Also, I think it is Darklama's right about this. For sister project links, the first page is already to C, while for wikibooks the last one still starts with a B. In addition, the sister project links is semi-protected while the wikibooks template is fully protected. Kayau ( talk &#124; email &#124; contribs ) 14:33, 23 June 2010 (UTC)
 * BTW, if a change (adding additional parameters, most probably) in the Wikipedia templates make sense, I could represent Wikibooks to propose the change... :P Kayau ( talk &#124; email &#124; contribs ) 14:36, 23 June 2010 (UTC)


 * Um... I must be very confused by something. When I follow the links you give above it is the Wikibooks template which gets all the way down to C, and the "Sister project links" that gets to B.  With the links above you can click "Next 500" for the Wikbooks template 4 times while you can click it 6 times on the "Sister project links" (still to an order of magnitude they are about the same).  Even if I do have it backwards we are still talking about a few thousand links. It is interesting they have different protection statuses, but I imagine this is an oversight on someones part, or that one was actually getting vandalized and not the other. Thenub314 (talk) 14:50, 23 June 2010 (UTC)


 * Whoops, switched the two around (must be confused by all those tabs - I currently have 20 on Chrome. :P) Sorry, this is embarassing. Kayau ( talk &#124; email &#124; contribs ) 15:37, 23 June 2010 (UTC)


 * I don't think it matters which has more. I made an assumption without actually checking WhatLinksHere at all. I've only ever seen the Wikibooks template used. Since they are both clearly used, both have to be dealt with. --dark lama  15:41, 23 June 2010 (UTC)


 * Why not just enable the Subject namespace on search by default? --hagindaz (talk) 16:04, 23 June 2010 (UTC)


 * It is enabled by default. – Adrignola talk contribs 16:22, 23 June 2010 (UTC)

Kayau ( talk &#124; email &#124; contribs ) 11:51, 24 June 2010 (UTC)
 * I've created a template on Wikipedia, w:Template:Wikibookssub.
 * I think everyone's missed w:Template:Wikibookspar.
 * For the latter calls have been made for it to be deprecated/deleted/unprotected. It does allow namespace specification. The former needs to have a category and documentation or it will be neglected. – Adrignola talk contribs 11:57, 24 June 2010 (UTC)