Wikibooks:Reading room/Archives/2014/November

Where can I request blocks of vandals?
Such as this vandal: https://en.wikibooks.org/wiki/Special:Contributions/209.112.140.130 - I would like this vandal to be blocked for problematic edits after his/her first and final warning. Thanks! --goldenburg111 (talk) 23:56, 11 November 2014 (UTC)
 * You can request an administrator to look into blocking a vandal here or at Reading_room/Administrative_Assistance. I have further warned this IP user but I haven't blocked him/her as the vandalism appeared to be minor rather than extreme or offensive.  Additionally I have protected the High School Science page so that any future edits (indefinite) by an IP user or a new user need to be reviewed before being visible (as is the case with other kid's books like all of the Wikijunior books).  The Japanese History page has been protected for 2 weeks.  Thanks.--ЗAНИA [[Image:Flag_of_the_Isle_of_Mann.svg|15px]]talk 00:17, 12 November 2014 (UTC)
 * Alright, thanks. --goldenburg111 (talk) 13:37, 12 November 2014 (UTC)

Global AbuseFilter
Hello,

AbuseFilter is a MediaWiki extension used to detect likely abusive behavior patterns, like pattern vandalism and spam. In 2013, Global AbuseFilters were enabled on a limited set of wikis including Meta-Wiki, MediaWiki.org, Wikispecies and (in early 2014) all the "small wikis". Recently, global abuse filters were enabled on "medium sized wikis" as well. These filters are currently managed by stewards on Meta-Wiki and have shown to be very effective in preventing mass spam attacks across Wikimedia projects. However, there is currently no policy on how the global AbuseFilters will be managed although there are proposals. There is an ongoing request for comment on policy governing the use of the global AbuseFilters. In the meantime, specific wikis can opt out of using the global AbuseFilter. These wikis can simply add a request to this list on Meta-Wiki. More details can be found on this page at Meta-Wiki. If you have any questions, feel free to ask on m:Talk:Global AbuseFilter.

Thanks,

PiRSquared17, Glaisher — 17:34, 14 November 2014 (UTC)

Request comment regarding cookbook and baking recipes
Hi, this morning or last night I updated one Basic bread dough recipe with baker's percentages and the weights of the original recipe, determined via lookup at the USDA Nutrient Database. Many of the newest artisan baking books always include baker's percentages and/or weights in addition to volumetric measure. I'm at the point in my own baking that if an author doesn't have those already printed, I usually skip it for another that does, unless I have reason to believe it's an unusually good recipe. I thought I'd go through the baking-related recipes, slowly as my time allows, and try to get more of the recipes similarly notated. I was wondering if anyone could offer suggestions for improving the general look, or formatting. Thanks. I want to add that there's some redundancy which I don't care for, the ingredients are listed twice. It seemed necessary due to an inability to get the table's ingredients lined up with the bulleted list. An alternate might be a table without borders including all values including the volumetric text, but then the bulleting function doesn't work. Suggestions? I have updated the table to a different format which eliminates redundancy. MOS does not seem to say bullets are required, though they are used on every recipe I've seen. This table style looks cleaner to me. Gzuufy (discuss • contribs) 17:23, 21 October 2014 (UTC)


 * Update. This is a copy of a message I put on the talk page of cookbook_talk:Cinnamon Bun, "How is 2 cups of all purpose flour = 480 g? ... I can't make sense of this recipe. 2 cups of all purpose flour, per the USDA National Nutrient database (NND), should weigh 250 g, or 125 g per cup.  But this recipe says 480 g of all purpose flour = 2 cups.  There are other inconsistencies, but the flour is the biggest one. The shortening, USDA NND says composite vegetable shortening weighs 205 g per cup.  But this recipe says 1/2 cup weighs 120 g, which is 240 g per cup. The brown sugar is not specified as packed or unpacked, leading to three possible values, because the same error seems repeated.  Too many inconsistencies....  I've done a little more investigation, and it appears that 'metrication' was added in this diff. In a different recipe, I found the same user making a similar mistake, 1.75 x 125 g = 218.75 g, but the same user converted it to 300 g." It's kind of interesting, because if a user was following gram weights, instead of cup measure, and presumed the values were correct, they'd get a completely different result from the results someone else following the cup measure would get.  I say "interesting", because weighing ingredients is considered a more accurate method, particularly for "flour" based recipes, but these kinds of errors in the conversions appear to undermine that accuracy. I find myself wondering how many other "metrications" the same user has performed, and if the same kinds of major errors were made in them.  We all make typos, but two repetitions of the same error, particularly on the flour weight, the "core" of the "baker's percentage" method?  Gzuufy (discuss • contribs) 00:33, 20 November 2014 (UTC)

VisualEditor coming to this wiki as a Beta Feature (errata)
''Please notice the correct direct link to access is this one. Thanks for your understanding! Elitre (WMF) 18:35, 21 November 2014 (UTC)''

VisualEditor coming to this wiki as a Beta Feature


''Hello. Please excuse the English. I would be grateful if you translated this message!''

VisualEditor, a rich-text editor for MediaWiki, will soon be available on this wiki as a Beta Feature. The estimated date of activation is Wednesday, 26 November.

To access it, you will need to visit the page after the deployment and tick the box next to "". (If you have enabled the "" option, VisualEditor will be automatically available for you.) There will also be a "" that you can enable if you need it.

Then, you just have to click on "" to start VisualEditor, or on "" to edit using wikitext markup. You can even begin to edit pages with VisualEditor and then switch to the wikitext editor simply by clicking on its tab at any point, and you can keep your changes when doing so.

A guide was just published at mediawiki.org so that you can learn how to support your community with this transition: please read and translate it if you can! You will find all the information about the next steps there. Please report any suggestions or issues at the main feedback page. You will also receive the next issues of the multilingual monthly newsletter here on this page: if you want it delivered elsewhere, for example at your personal talk page, please add the relevant page here. Thanks for your attention and happy editing, Elitre (WMF) 18:12, 21 November 2014 (UTC)


 * I'm sorry to hear it's coming here in any form at all. The Foundation has made clear they don't care what users think, though.  --Pi zero (discuss • contribs) 18:17, 21 November 2014 (UTC)
 * I'm interested to hear what your reasons for opposing it are. I don't know that much about this but I reckon that anything which encourages more non-technical people to contribute to Wikimedia projects is a good thing.  Wikipedia and sister projects are so fiddly to edit and very little has changed in 10 years.  It's stilll just as much of a pain in the arse to find pages, to add templates and to remember what code does what as it was at the very beginning.--ЗAНИA [[Image:Flag_of_the_Isle_of_Mann.svg|15px]]talk 19:47, 21 November 2014 (UTC)


 * Having taken a few days to mentally prepare, I'll take a shot at articulating this. Though, there could well be deep considerations that contribute to my intuition without my having explicitly identified them. (I've said for many years now, I take my ituition very seriously because I've found from experience that my intuition is way smarter than I am.)


 * I've got two ways of describing this, very different from each other though seemingly somehow intertwined &mdash; one in terms of the way markup languages evolve, and one in terms of the way wiki users learn.


 * Having watched as data formats rise and fall, I've observed that the ones that enjoy real long-term success are text; not some binary format, just plain text. This is closely related, of course, to the open-source concept, since text is by nature broadly readable and maniuplable with no need for specialized software to access it.  UNIX is founded on text as a common data form.  Programming languages (successful ones) are too.  TeX, and its highly successful library extension LaTeX.  Text is the medium of the web, and of (for all its flaws) javascript.  Html.  And wikis.  This is why something like Flow (yes, I know we're not primarily talking about Flow here) is just a stupifyingly bad idea; if you deliberately set out to bring about the destruction of the wikimedian movement, you couldn't do much better than Flow.


 * However, there is a qualitative difference between text that can be manipulated by hand, and text that can only be handled by machine. In the early days of html, we wrote our web pages in html.  And it was tolerably easy to do.  The markup language was, however, oriented in its design more toward software than toward human authors, and continued to evolve in that direction &mdash; and wiki markup came along, the dominant characteristic of which was that it is incredibly easy for a human being to write and edit.  There's been a lot of revisionism about this, but despite efforts to portray wiki markup as difficult, the whole reason it was ever successful in the first place is that it's a miracle of convenience.  And the one thing guaranteed to turn any text-based language, no matter how easy to use, into a humanly intractable mire &mdash; as demonstrated consistently by history&mdash; is to have a program "help" to write it.  The computer will "help" you right into being unable to deal with the text directly, losing a great chunk out of the marvelous benefits of text.  Programing language source code written by software is unreadable, even if (as rarely happens) the software is made to enforce some ostensibly human-friendly style discipline.  Html, that reasonably tractable markup I remember hand-coding in the first few years of the web, can still be written to be sort-of legible if it's written entirely by hand, but the moment any of it is generated by software you've lost it, and since it's been ceded to the software a lot of what you'd want to do is beyond reasonable reach of hand-composition anyway.  If you want to hang on to the lion's share of the benefits of text &mdash;and, as I say, those benefits are requisite to large-scale, long-term success&mdash; you have to avoid ceding its composition to software.


 * My other view of this thing is based on personal experience with learning wiki markup, and watching others do so. If you want to write something on a wiki, how do you do it?  You want to correct a spelling error, perhaps; my first several wiki edits were correcting spelling errors.  You click where it says "edit", and you're presented with an edit buffer full of stuff.  Most of it is just plain text; there's a little markup, much of it very light-weight, which you don't have to bother with right now &mdash; but you see it there, and at least with the lightest-weight parts of it, you can see immediately how it's done.  Later on, when you have occasion to want to do some of that yourself, you've already seen it done &mdash; and if you have any doubts, you just go and find where somebody else has done something similar, and there's your example to follow.  Pretty much all of wiki markup &mdash;and there really isn't much to it&mdash; is like that, you don't need much very often, and by the time you do need something you've probably already seen it done, and you can find examples of how it's done.


 * The whole thrust of VE is to try to prevent you from ever seeing the raw wiki markup &mdash; in other words, its whole purpose is to prevent you from learning how to do anything, to deprive you of the very benefits that have made wikis a huge success. My first eperience with VE went like this:  I was looking at a section of a Wikipedia article, and there was something missing from a bulleted list.  Oh, I thought, I'll just add that.  And it occurred to me to try to use VE for it, since VE had been much touted, and this was a very simple edit.  I tried.  And tried.  I couldn't figure out how.  I finally gave up and just edited the wiki markup directly.  And in doing so, I reflected that a complete novice could trivially easily have made that edit, because the moment they edited the wiki markup for that section, it would have been immediately obvious how to add another bullet item to the list, because you're looking right at nothing but a block of examples of how to do it.  Even if you figure out how to do something with VE, it doesn't help you do something else with VE; even if you see an example where somebody else has done something on a wiki page, with VE you can't imitate it because you don't know how they did it; and you also don't get to incidentally see examples of how things are done that you haven't needed to do yet but may in the future.  So you've taken a markup language that's incredibly easy to learn, and actively interceded to prevent users from learning it.  As with Flow, this is a profoundly bad idea.


 * --Pi zero (discuss • contribs) 17:40, 24 November 2014 (UTC)
 * I understand your reasons and I see how useful it is for editors to learn the markup. But Wikimedia needs to look at how many people start editing and then never edit again.  So many editors are tech-savy which might suggest that ordinary people find it too cumbersome to edit pages.  I believe that anything which makes this process easier is a good thing.--ЗAНИA [[Image:Flag_of_the_Isle_of_Mann.svg|15px]]talk 07:58, 26 November 2014 (UTC)
 * Some thoughts.
 * I actually don't think the Foundation, as a whole, is competent to do studies, and then extract correct conclusions, of things like "how many people start editing and then never edit again". Almost all such studies get misdesigned, misimplemented, and then misinterpreted, and the misinterpretation usually favors whatever conclusion was already favored by those providing the initiative for the study.  The line about "three kinds of lies:  lies, damn lies, and statistics" is saying something profound.
 * In this case, right off the bat, in the unlikely event one could actually determine reliably how many people start editing and then never edit again, one probably couldn't reliably determine why (self-impressions certainly wouldn't do it, and asking people for self-impressions might actually increase the likelihood that they wouldn't come back).
 * I've heard anecdontally of non-tech people who try wiki markup and VE, find wiki markup easier, and are surprised by this because they had heard that wiki markup is difficult. There are a bunch of tech people who basically want wiki markup to be difficult for non-tech people.  Why do they want this?  Proobably because changing replacing the interface is a simple-minded way of throwing tech labor at the problem.  Irony, that.
 * I maintain that
 * all you have to be able to do in order to start using wiki markup is edit a plain text file.
 * If somebody wants to make an easier-to-use interface for editing plain text, they're welcome to try. Not sarcasm.  When you're in the standard wikimedia interface, and you go to edit a section, you get an edit box with the cursor at line 1 column 1 of the edit box, and you then have to hunt for the part of the edit buffer where the thing you actually wanted to change (such as a spelling error) is.  Might it be more useful, for mobile devices, if you could enter the edit interface from any point in the text, and that would put you in edit mode with the cursor at the point where you entered?
 * once you're in, the fact that you are working directly with the wiki markup is what helps you learn more wiki markup.
 * So as soon as you're dealing with something that actually is technical, you're better off having started out working with wiki markup.
 * the actual causes of the slow decline of wikimedia are to be found elsewhere. I see two major causes, one social and one technical.
 * (a) The Wikipedian social atmosphere is toxic. Untangling why, and moreover what can be done to change it, is a really difficult social problem.  The Wikipedian social order is based on, broadly, bureaucracy and AGF-and-civility.  These seem to me like technical approaches to social structure: bureaucracy is like programming, and AGF-and-civility is a gross oversimplification, naive in the extreme.  And instead of tangling with anything deeper on the social side, folks want (as I mentioned before) a simple way of throwing tech labor at the problem.
 * (b) The higher-level things wikimedians do, on every sister project including Wikipedia, actually do require expertise; not expertise with writing wiki markup, but expertise with what high-level decisions are needed, when, and what one needs to know to make them well.
 * I was under the misapprehension, when I'd been on Wikinews for just a little while, that Writing a news article is an especially technical task; but really, the pressure at Wikinews is merely because the technical task has to be done in such a short period of time. I've since concluded that writing a Wikipedia article is, on the whole, actually a good deal more complicated; and organizing a book &mdash;from overall outline to arrangment of parts at scales all the way down to the paragraph/table/figure&mdash;  so that it comes out well is, I think, even more complicated.  And the technical means avaiable to capture expertise on wikis is, of course, to do the one thing wikis have been made to be good at:  writing documents.  Manuals and guides and help pages and such.  Which (I think I've said this before) is a really lousy way to try to pass on the expertise.  Hands-on is what you want. I'm working on a technical approach to making it possible to actually address the expertise problem, in a way that can eventually be crowdsourced to the sister-project communities (once I've devised appropriate idioms for practical use of the low-level tools I'm implementing); and I'm hoping even the social problems can be partly alleviated by capturing expertise for social interaction.  (The low-level tools would make wiki pages interactive; make that one change, the theory goes, and all else can follow.)
 * --Pi zero (discuss • contribs) 12:03, 26 November 2014 (UTC)

Give rate limited move-subpages (and supressredirect-new-self) to autoconfirmed users
I suggested this at wikipedia, and it was pointed out that this would be particularly useful for wikibooks. This would allow autoconfirmed users to move books with up to seven subpages in one action, instead of having to move each subpage one by one. The subpage moves would be counted in the rate limit of eight moves per minute, removing the potential for abuse that the was the reason this feature got restricted to admins in the first place. As a bonus, you could increase the rate limit for reviewers to, for example, 30 moves per minute, so that they can move in one go books with more subpages. I also suggest to allow recently created pages with a single contributor to be moved by said user without leaving a redirect. If you were to show your support for this, it would be prioritized by developers. I'll file the bugs then. Cenarium (discuss • contribs) 10:10, 28 November 2014 (UTC)