Wikibooks:Reading room/Archives/2019/January

CentralAuth referring to reviewers as editors
As said on the title, CentralAuth calls reviewers on Wikibooks as editor. While a small thing, I wonder whether it can be fixed to show the correct designation of the user? Leaderboard (discuss • contribs) 14:22, 27 December 2018 (UTC)
 * Isn't it the same with enwp New Page Reviewers called as +patroller?--Cohaf (discuss • contribs) 15:47, 27 December 2018 (UTC)
 * I had to look this up. Yes, you're right. Leaderboard (discuss • contribs) 15:55, 27 December 2018 (UTC)
 * and Pending Change Reviewers called +reviewer to mess things up further. I think it's the flag name that is the issue. A short local discussion and a phab ticket should solve the problem.--Cohaf (discuss • contribs) 16:03, 27 December 2018 (UTC)
 * .Do you intend to start a community discussion on this issue?--Cohaf (discuss • contribs) 02:47, 8 January 2019 (UTC)
 * I don't see why this discussion itself cannot be that 'community discussion'. Leaderboard (discuss • contribs) 10:39, 8 January 2019 (UTC)
 * I see. Now we simply have to get more people aware about this and a consensus need to be obtain. Afterwards, a phabricator task can be started. Regards,--Cohaf (discuss • contribs) 11:28, 8 January 2019 (UTC)
 * I'd really like to first understand the technical reality underlying this a bit more. Then, if it's something subject to a community consensus, we should start a new thread for it at the proposals reading room, as that's where community-interested users would be looking for such a discussion, and also the consensus discussion can then be clear of preliminary clutter. My impression, from years ago, is that deep inside the wiki platform the name for the basic flaggedrevs permission group is "editor"; and each project can put in place (with community consensus) a local name for it, so we did that.  That is, both en.wn en.wb did that, with, I believe, community consensus (however much thereof was required); though it's been so long I no longer recall which of the two projects did it first.  The local name is what shows up when one looks at a user's user rights log on a given project; for example, in the user rights log of a user with the permission on Wikibooks or Wikinews, that permission is called "reviewer".  On Wikipedia I think it's called "pending changes reviewer".  If I look at someone's Special:UserRights on this project, or on Wikinews, the box to check for that permission is labeled as "reviewer"; I can't look at it on any other projects, because those two are the only projects where I'm an admin.  But on Special:CentralAuth, for both en.wb and en.wn, it shows as "editor".  And yet, as best I can tell, Special:CentralAuth shows the right for Wikipedia as "reviewer" &mdash; unless perhaps I've misidentified it, and that's really a different right?  But both Wikibooks and Wikinews have long since gone through the rigamarole to get the local name changed, so it doesn't make sense to me that the internal name, "editor", would show for them at CentralAuth unless there was simply no way to change it there; and if there were no way to change it there, how could it be different for Wikipedia? QU, do you know anything about this? --Pi zero (discuss • contribs) 13:49, 8 January 2019 (UTC)
 * A simple way if there's consensus is to depreciate the current group. Start a new group named reviewers with all the permissions that current reviewers have. In addition, change the autopromote bot accordingly. After which move all current reviewers over. That a local consensus and quick phab deployment should be all that is needed. IMHO that will be faster if the community wish to proceed this way.--Cohaf (discuss • contribs) 13:56, 8 January 2019 (UTC)
 * That doesn't sound at all simple to me; it seems (tbh) like a complicated operation with lots of opportunities for something to go apocalyptically wrong. --Pi zero (discuss • contribs) 14:20, 8 January 2019 (UTC)
 * That's my view as well. First off, the autopromote is not really a bot; it does not even have a username (unlike Fuzzybot, for instance). Secondly, I'm not aware of potential complications that could arise to the historical logs, for instance. Leaderboard (discuss • contribs) 14:25, 8 January 2019 (UTC)
 * (ec) However, IMHO changing the group name by itself maybe even more problematic. Hopefully more can chime in into this issue. I think we have to weigh the cost of whether to continue the discussion or leave as status quo. In one of my home projects, I proposed to set up an uploader group but the setting up of NFCC policy makes me think twice already.--Cohaf (discuss • contribs) 14:28, 8 January 2019 (UTC)
 * Question: why does anyone care that CentralAuth has a different name? It is likely that CA uses the standard MW definition rather than the override for each project as its real purpose is to enable people like Stewards to see cross project rights - which for them is easier if every single project describes a right the same way. E.g., Custodians on Wikiversity are described as sysops in CentralAuth. It is not a bot that performs the promote, it is part of the MediaWiki software. The history of the configuration changes is documented on this project FlaggedRevs Extension. QuiteUnusual (discuss • contribs) 15:04, 8 January 2019 (UTC)
 * Apparently Leaderboard cares, that's the reason for this thread anyway.--Cohaf (discuss • contribs) 15:35, 8 January 2019 (UTC)
 * I'm mostly intereted in the consistency; after all every other right (even the uncommon autoreview) is represented by CentralAuth correctly. That being said, QU's reply makes sense, but stewards do not manipulate reviewer/editor. From my understanding, editor started as something like patroller on Meta, and then dropped as the reviewer permission had all that with the ability to flag revision. All in all, it's a small thing as I said at the beginning and I was wondering whether it could be changed. Leaderboard (discuss • contribs) 15:52, 8 January 2019 (UTC)
 * Not really. Patrol was a way of marking an edit as "okay", reviewer / editor was introduced with the FlaggedRevisions extension which has extensive functionality and can be configured in different ways for different projects. Potentially Stewards do manipulate it as they do for any right on projects where there are no users with the rights to add or remove flags - which is the majority of Wikimedia projects (albeit none of which have FlaggedRevs). My point was more that coding CentralAuth to apply local descriptions doesn't make sense because it is a central function. If you want to know what the local name is, you look on the local project. QuiteUnusual (discuss • contribs) 17:54, 8 January 2019 (UTC)
 * Thank you very much for the explanation. I guess then this request is invalid and can be closed. Leaderboard (discuss • contribs) 18:53, 8 January 2019 (UTC)

Linking to a Greek Wikibook
I am trying to link the wikibook Sensory Systems to the corresponding greek version. In doing so on Wikidata produces the error-message: A page "https://el.wikibooks.org/wiki/Αισθητήρια_Συστήματα" could not be found on "elwikibooks". The external client site "elwikibooks" did not provide page information for page "https://el.wikibooks.org/wiki/Αισθητήρια_Συστήματα".

I think that "elwikibooks" may have problems correctly recognizing wiki-book entries, such as https://el.wikibooks.org/wiki/%CE%91%CE%B9%CF%83%CE%B8%CE%B7%CF%84%CE%AE%CF%81%CE%B9%CE%B1_%CE%A3%CF%85%CF%83%CF%84%CE%AE%CE%BC%CE%B1%CF%84%CE%B1

Is there another way I can link the Greek wiki-book? --Thomas.haslwanter (discuss • contribs) 19:28, 12 January 2019 (UTC)


 * Wikidata accepted the name when copy-and-pasted from the title on the el.wb page; the trouble was that it needed the actual characters, rather than the URL escape sequence for them. The other way to handle interwikis is through wiki markup; and en.wb doesn't remove on-page interwikis just because wikidata also has the information; so I added those to the book page here, as well. --Pi zero (discuss • contribs) 00:49, 13 January 2019 (UTC)

FileExporter beta feature
A new beta feature will soon be released on all wikis: The FileExporter. It allows exports of files from a local wiki to Wikimedia Commons, including their file history and page history. Which files can be exported is defined by each wiki's community: Please check your wiki's configuration file if you want to use this feature.

The FileExporter has already been a beta feature on mediawiki.org, meta.wikimedia, deWP, faWP, arWP, koWP and on wikisource.org. After some functionality was added, it's now becoming a beta feature on all wikis. Deployment is planned for January 16. More information can be found on the project page.

As always, feedback is highly appreciated. If you want to test the FileExporter, please activate it in your user preferences. The best place for feedback is the central talk page. Thank you from Wikimedia Deutschland's Technical Wishes project. Johanna Strodt (WMDE) 09:41, 14 January 2019 (UTC)

No editing for 30 minutes on 17 January
You will not be able to edit the wikis for up to 30 minutes on 17 January 07:00 UTC. This is because of a database problem that has to be fixed immediately. You can still read the wikis. Some wikis are not affected. They don't get this message. You can see which wikis are not affected on this page. Most wikis are affected. The time you can not edit might be shorter than 30 minutes. /Johan (WMF) 18:38, 16 January 2019 (UTC)

Cookbook recipe: vandalism sprinkled with record
, 75.8.196.193 proposed to bake oil and flour at 400 ° (C or F ?) for one hour. This IP forgot to tell us that he/she was making his recipes in his fireproof kitchen. Fortunately, this is only intervention on WB. Now that I have just become a reviewers, I would like to thank all patrollers for their wonderful work in keeping WM healthy. --Eihel (discuss • contribs) 08:47, 21 January 2019 (UTC)