Wikinews:Water cooler/technical/archives/2020/March

A bug on left sidebar

Greetings , When I browse some articles , I found that issue on left sidebar. There duplicates on languages. Omda4wady (talk) 11:52, 15 March 2020 (UTC)

See the thread above this as for why this happens. —Justin (koavf)❤T☮C☺M☯ 18:39, 15 March 2020 (UTC)

Modify the 'review not ready' note appearance?

Would suggest to change the 'Ask' link in the 'review not ready' template to make it look like a button, or mark it in bold. This may make it easier for the authors to discover. --Gryllida (talk) 10:09, 18 March 2020 (UTC)

Bolded. --Pi zero (talk) 11:26, 18 March 2020 (UTC)

Notification of authors

When a review is not ready, or a new question is asked at the talk page of the article, substantial authors of the article should be notified. This was brought up previously. Now I am thinking of implementing this. How could one possibly keep track of the substantial authors (not spam reverts)? This information would need to be approved by a human and stored somewhere.

There are two options.

1. This storage is per-article, for instance, this could be done by creating 'Substantial authors' section at article talk.

2. By having this information stored for many articles in one .json file on-wiki. Then this list would need to be cleaned up periodically to remove articles which are archived. Is this correct? Otherwise this file would become too full. But then sometimes people ask questions about archived articles...

--Gryllida (talk) 10:13, 18 March 2020 (UTC)

This has long been high on the list of things to do once a dialog-based replacement is created for the review gadget (the theory being that the existing gadget code is just too scary to try to touch). Obviously the dialog-based-replacement part is taking a while. The question of how to do it from a practical perspective is something I've supposed would be shaped by what the dialog-based facilities are amenable to, but even if that were true, to some extent the dialog-based facilities can also be shaped by what we want them to be able to do. So, whatever the basis of the implementation, the behavior is worth thinking about.

Information per-article should not be stored centrally.

We should avoid introducing additional data formats to on-wiki pages (json). In storing structured data (if we go that way), I've tried very hard to use only wiki markup for things expected to be edited by general users (such as the infobox tables). Usually I've tried to avoid storing structured data that mostly isn't meant to be edited by general users, but when I do store it, or more commonly when I'm passing it around as template parameters or dialog parameters (rather than storing it on any page), I've used wikilisp S-expressions; preferably, simple S-expressions, i.e., not nested. I think there may be one old, stop-gap piece of code buried in the dialog tools that stores an emergency information-dump in json, but my planned upgrades to the dialog code would eventually eliminate that in favor of S-expressions, too. This question of storage formats sometimes gets awkward. On one occasion over on en.wb, I did resort to storing a wikilisp S-expression (embedded within wiki markup; for the ancestry of a shelf in the Wikibooks Stacks). I'm also still puzzling, over on en.wb, on how best to store the master table-of-contents for a book, since that is meant to be edited by general users (for which I tried to set up a facility years ago, but it's data format was a bit awkward for my tastes, because it was trying to do the job without dialog or wikilisp, neither of which had been imagined yet).

It's worth noting that, in the above example of using wiki markup for stored data (infobox tables), I use wikilisp to extract the data, which works out neatly because the data is being extracted by a template (thus, on the wiki markup side of things), and the dialog tools are made to mesh smoothly with templates. It's not as convenient, yet, to extract data from an S-expression to a javascript tool (even though wikilisp itself is written in javascript); I am planning to write some stripped-down code to add to the dialog tools that reads a simplified form of S-expression, because I've realized the dialog tools need to interact more smoothly with wikilisp, but of course I haven't gotten to that yet.

It honestly hadn't occurred to me, for this problem, to store the information on a page; I'd supposed the review gadget would put together the information when it's needed. When first suggested, years ago, iirc who-to-notify was envisioned as derived in some straightforward way from the article's revision history (but I don't remember quite what was suggested, who suggested it, or where). --Pi zero (talk) 12:58, 18 March 2020 (UTC)

I advise against this. Do not install any kind of notification system at this time.

Having Wikinews send emails or other messages to drafters and co-drafters would only be worth the programmers' time if not knowing about a failed review causes a delay in revision and resubmission.

1. As far as I can tell, our drafters already know to check articles once every few hours.
2. If someone gets a message, say, on their cell phone during a break at work, that will not make their work day end so they can get back to their computer and Wikinews any sooner.
3. It will, and I know from personal experience, annoy the heck out of reviewersdrafters who have simply decided to spend their time and energy elsewhere. It would feel like nagging for another $10 after I've already donated $40.

I recommend polling or informally asking a bunch of active Wikinews drafters whether a notification system such as the one you've planned would be a bug or a feature. If the other drafters say "Yes I would spend more time doing revisions if Wikinews sent me messages saying they were necessary," then by all means go with what would help most people. But we're all volunteers here, and sometimes "If they like it, they'll publish it, and if they don't, I'll move on and write another one" is the best way to go. Reading a negative review takes a lot of patience on the part of the drafter, and everyone has other demands on that patience, even when we're not dealing with quarantines and sick friends and relatives.

My take: Spend your valuable time improving other parts of Wikinews. Darkfrog24 (talk) 14:02, 18 March 2020 (UTC)

It's common practice to leave a note on the reporter's talk page when submitting a review of their article; we don't want boilerplate messages, but custom messages are something reviewers have known for many years are useful and effective with newcomers. The reason we don't do more of it is that there's a lot of tedious overhead associated with doing it, a problem amplified by the fact that it happens just when the reviewer is already most exhausted from doing the review and writing the review comments. A little bit of well-designed semi-automation to make it easier to leave such notes would be most welcome to aid reviewers; an important part of designing it well is that it aid personalized notes rather than fostering boilerplate.

Part of the confusion here may be because the purpose of such a feature is to help typical newcomers along. Newcomers do not know to watch their articles, and frankly that's more complication than ought to be dumped on them when they've just arrived and are struggling with our initial learning curve. Most users do, in fact, learn early and continue to learn; and they learn from, and by, revising and resubmitting articles that don't pass on the first review in cases where the problem is reparable. --Pi zero (talk) 15:32, 18 March 2020 (UTC)

┌─────────────────────────────────┘
@Darkfrog24: Go to the bottom of User Preference in Special:Preferences and set the email options to check which emails you want to receive and which ones you don't.
•–• 18:52, 18 March 2020 (UTC)

How nice, Acagastya. If the programmers here on Wikinews do decide to implement this, I may do just that. Darkfrog24 (talk) 19:16, 18 March 2020 (UTC)

Yes, the script can suggest a list of substantial contributors from the article history. A human would need to approve it, and the script would store it somewhere.

Do you have an example of the lisp storage thing? I looked at wikibooks:Category:Book:Wikibooks Stacks/Shelves/Ancestry, but didn't see what that does.

As an example of storage in wiki markup, I use bullet lists at n:User:Gryllida/wab/dev/wiki. Gryllida (talk) 19:58, 18 March 2020 (UTC)

Certainly a bulleted list could work, in some situations. It should be pretty easy to write wikilisp code to parse that. (I suspect it may not be sophisticated enough for that master-table-of-contents thing, though, which is what makes that problem challenging.)

Regarding b:Category:Book:Wikibooks Stacks/Shelves/Ancestry. If you look at any one of those ancestry pages, for example b:Shelf:Civil law/ancestry (which is a subpage of the shelf page itself, b:Shelf:Civil law), it appears as a blue information box, and down at the bottom of the content is a Lisp-style list of strings, in the example

( "Humanities" "Law" "Social sciences" )

If you edit the ancestry page, you'll find that in wiki markup it's a template call, to b:Template:Shelf:Ancestry, with two parameters: an unnamed parameter, and a named parameter ancestors. The value passed to the ancestors parameter is the Lisp-style list of strings. The value passed to the unnamed parameter is {{{1|}}}. If you just view the page, the logic in b:Template:Shelf:Ancestry sees that you're viewing it from an ancestry page and the unnamed parameter is blank, so it displays that blue information box that you see. If you transclude the ancestry page with unnamed parameter value ping, the logic causes it to return string Shelf:Ancestry. If you translcude the ancestry page from a page that isn't an ancestry page (as judged by the page name), or if you transclude it with an unnamed parameter value that's non-blank but not ping, the logic cause it to return just the Lisp-style list of strings. --Pi zero (talk) 21:42, 18 March 2020 (UTC)

Is there an advantage in the lisp thing compared with a bullet list? I already have a parsing code for that. Gryllida (talk) 23:32, 18 March 2020 (UTC)

Well, since I'm coding everything in wiki markup and using wikilisp for parsing, the basic advantage is that while wikilisp can parse a bulleted list, S-expressions are its native format and therefore much easier to handle. --Pi zero (talk) 00:58, 19 March 2020 (UTC)

Local interwikis versus Wikidata

I have just noticed that on pages where both local interwikis and Wikidata interwikis are available, we have multiple links for the same language. (This is a somewhat expected behavior.) If we want to keep local interwikis (and, as I understand, the consensus is to keep them), we should somehow suppress them in cases when a local and a Wikidata interwiki points to the same article. Two examples: Wikinews:Story preparation, Luxembourg's free public transport comes into effect. - Xbspiro (talk) 23:40, 12 March 2020 (UTC)

On the contrary, correct behavior for the wiki software would be that local interwikis override Wikidata. I've noticed the platform has recently been broken by an "update" so that it is not behaving the way it should. (Any remarks on this, Bawolff?) --Pi zero (talk) 23:51, 12 March 2020 (UTC)

Thank you (I learn something new every day). - Xbspiro (talk) 00:41, 13 March 2020 (UTC)

Code comments in wikibase [1] seem to indicate what Pi Zero said is indeed the intended behaviour. File a bug in phabricator to request the wikidata people fix it. Bawolff ☺☻ 05:24, 13 March 2020 (UTC)

Thank you. Here is the ticket: phab:T248048. - Xbspiro (talk) 03:28, 19 March 2020 (UTC)

Email???

What the heck is up in our Wikinewsie email?? Mine is glitching!! I know I'm using the correct password............... --Bddpaux (talk) 19:49, 20 March 2020 (UTC)

Nevermind....I found it over at the top of wikinewsie.org (not very prominently displayed......and hadn't logged in in a bit). --Bddpaux (talk) 19:55, 20 March 2020 (UTC)

Stalk toy?

At the bottom of my contribution page I see a wikilink titled Stalk toy. When I click on it I go into a wiki-snooze that I have to get of manually (Sorry, no patience). This is the first time I have noticedthis wikilink and was wondering about the choice of words.

I guess this concludes my short visit to wikinews. Ottawahitech (talk) 13:04, 31 March 2020 (UTC)

We didn't choose the name of the device; that's what it's called (see the url). Yes, it does take a very long time for the data display to come up. --Pi zero (talk) 13:42, 31 March 2020 (UTC)

If you have a problem with the naming, please file a Phabricator request to rename it, after all it is Wikimedia's tool. It is hosted on WMFLabs, and isn't a tool created by or for Wikinews. The source code is available on GitHub, and the name "Stalk Toy" has existed for many years now. See.
•–• 13:52, 31 March 2020 (UTC)