Module talk:SDcat

Testing

Check whether local short description matches that on Wikidata
Article	Wikidata description	Short description	Category
Douglas Adams (Q42)	English science fiction writer and humorist (1952–2001)	English author and humorist (1952–2001)	Category:Short description is different from Wikidata
Christian art (Q645717)	art genre	Art genre	Category:Short description matches Wikidata
Resultado do tratamento das fístulas enterovesicais para doença de Crohn (Q58861153)			Category:Short description with empty Wikidata description

Wikidata is unavailable

@IceWelder: What is the point of this edit? Why would this module be used on a wiki where Wikidata is unavailable, and why would it be a good idea to populate the "different" tracking category with every single use if that were the case? * Pppery * _{it has begun...} 16:37, 16 August 2020 (UTC)[reply]

Pppery, there is no guarantee that Wikidata is always available, and when it is not, this template produces an error displayed in red and bold on every single article using shortdescs. I use a local MediaWiki instance for preparing some of the articles I write and export/import the pages I intend to rewrite, which is how I noticed the issue. There are no trade-offs to this change. I assumed that the "different" category was the default, based on how the template was previously set up. If this is incorrect, I would be fine with changing it to another (I'm yet to test whether it works with none at all). IceWelder [✉] 16:44, 16 August 2020 (UTC)[reply]

You shouldn't mass-import templates from other wikis without making sure they make sense on the wiki they end up on. Neither {{short description}} nor Module:SDcat make any sense on any wiki that does not support Wikidata, therefore code to support such wikis is code bloat and does not belong. * Pppery * _{it has begun...} 16:51, 16 August 2020 (UTC)[reply]

In my case specifically, they are not supposed to "make sense", just work for the purpose of displaying the article approximately like how it would appear here, which it does just fine. Adding this failsafe eases the process of quickly setting up such an instance. It also avoids errors here when Wikidata is offline for whatever reason. I checked on the template again locally and returning an empty string works just fine in this case. Implementing it that way would also avoid mass category-stuffing in the case of a Wikidata outage. IceWelder [✉] 17:02, 16 August 2020 (UTC)[reply]

I reverted the change for now but documented the new approach at Module:SDcat/sandbox. IceWelder [✉] 17:14, 16 August 2020 (UTC)[reply]

Wikidata was once offline, and the result was that viewing every single non-talk page produced an error, rendering any tracking category pollution irrelevant. * Pppery * _{it has begun...} 17:23, 16 August 2020 (UTC)[reply]

If there's no connection to Wikidata, then the template should do nothing because it cannot determine the status of the short description in those circumstances. I've just made an edit to implement that. --RexxS (talk) 17:24, 16 August 2020 (UTC)[reply]

Looks similar to my proposed second solution, though even more concise. Thanks. IceWelder [✉] 17:25, 16 August 2020 (UTC)[reply]

Sorry, I didn't check the sandbox, but the line I added is my standard "catch error" for a missing wikibase connection. I agree with your assessment. --RexxS (talk) 17:29, 16 August 2020 (UTC)[reply]

No worries, your solution is better anyhow. I synced the sandbox to the main module's state, but if you won't need it, I can have it deleted again. IceWelder [✉] 07:05, 18 August 2020 (UTC)[reply]

Thanks, I can delete if needed, but I wouldn't normally bother. The next time someone wants to do tests, they have a sandbox already synced to work in. Cheers --RexxS (talk) 22:25, 18 August 2020 (UTC)[reply]

The following seemed too off-topic for the CFD discussion

So I found my way here from there. Forgetting about wikidata for a second, would it somehow be possible to detect pages with multiple local short descriptions? That would be an issue infinitely more worthy of maintenance categorization, especially when these do not match. I believe the most common scenario will be one description manually entered in the article's wikitext, and the other automatically generated from infobox parameters (which may or may not be positioned in that order, which may or may not matter—please advise). ―cobaltcigs 14:36, 28 September 2020 (UTC)[reply]

@Cobaltcigs: Infobox templates that generate short descriptions should be in the Category:Templates that generate short descriptions and they should all add the noreplace parameter. Having the noreplace parameter prevents the short description from replacing any earlier defined short description, so the order won't matter: any explicit use of {{short description}} will override a generated one.

If you think there's a maintenance value in looking at articles that have a generated and an explicit short description, then you can search for hastemplate:"Infobox settlement" hastemplate:"short description", for example (and repeat for each of the other 36 templates in Category:Templates that generate short descriptions). There are currently 527,822 articles with both {{Infobox settlement}} and {{short description}}. --RexxS (talk) 17:18, 28 September 2020 (UTC)[reply]

Negatory on the category, then? ―cobaltcigs 16:01, 30 September 2020 (UTC)[reply]

Nah, go ahead. Don't let my minor misgivings stop you. --RexxS (talk) 20:59, 30 September 2020 (UTC)[reply]

I was only asking about technical feasibility. I think it would probably require the same technique used by Module:Citation, which makes date-formating decisions by looking for "use mdy/dmy dates" templates in the surrounding wikitext of articles where it is used. So we would instead have to look for a direct use of {{short description}} plus one of the 36 templates which also use it, minus those using a parameter to suppress the extra description? That might be straightforward enough, but how would the module determine that these have the same or different content? It seems that would require viewing the rendered page html.

Speaking of rendered page html, it appears that (by default at least) a manually entered {{short description}} and one generated from {{infobox settlement}} are styled with identical html <div class="shortdescription nomobile noexcerpt noprint searchaux" style="display:none">. This makes it difficult to confirm which description (if any) has taken precedence. ―cobaltcigs 03:33, 4 October 2020 (UTC)[reply]

Modules indeed can't read the rendered html as they run on the server before the displayed text is generated. Modules can use the mw.title.getCurrentTitle():getContent() method to read the current page's unparsed content, and finding the templates is trivial, but you won't be able to compare the contents unless you use mw.getCurrentFrame():expandTemplate{} to explicitly expand the generated template or require Module:Settlement short description and call it. Frankly, I wouldn't bother.

The manually entered {{short description}} and the one generated from {{infobox settlement}} are styled in identical spans because they are functionally identical (and because the generated one actually calls Template:short description). You don't need to confirm which one takes precedence because you already know that the one which is manually entered has precedence because of noreplace being added in the generator – see Module:Settlement short description line 30. --RexxS (talk) 18:06, 4 October 2020 (UTC)[reply]

Okay so some amount of research later, I've come to realize this "noreplace" parameter is actually passed along as the second parameter to a certain {{SHORTDESC:...|...}} "magic word"—and that this mechanism is totally separate from the hidden(-by-default) span tag, which only uses the first parameter. Fair enough. I suppose I was preoccupied with the span tag because I use client-side css like this to make the description (or potentially multiple descriptions) clearly visible:

.shortdescription { display: block !important; color: red; white-space: pre-wrap; font-family: monospace; font-size: larger; width: auto; border-bottom: 1px dashed black; }
.shortdescription::before { content: "{{short description|"; color: black; }
.shortdescription::after { content: "}}"; color: black; }

As designed I don't see any robust way to identify and unhide only the description that, based on whatever internal noreplace-logic, is ultimately used. Perhaps the name noreplace could be appended to the span's list of classes, when applicable. Then one could at least use javascript to examine the spans' classes and decide by elimination which one to unhide. ―cobaltcigs 19:50, 4 October 2020 (UTC)[reply]

If you're going to use JavaScript then you can access the API and read the value of "Local description" from the "Page information" for each article (there's a link to it in the left margin box called 'tools'). That's where the backend database stores the overriding value supplied by the {{short description}} via the {{SHORTDESC:}} magic word. If you want to understand better about how the 'noreplace' parameter works, you should check out phab:T193857 where we thrashed out the logic of it. --RexxS (talk) 02:02, 5 October 2020 (UTC)[reply]