Wikidata:Report a technical problem/Archive/2022/09

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

The Wikipedia “Lips” page needs improvement on Procheilon statement.

Dear Wikipedia,

I don’t know how to add this, but I think the Wikipedia “Lip” page needs improvement on the Procheilon statement from reference 7 of the structure section of the Wikipedia page.

I think the word Procheilon should be highlighted in blue.

I think a diagram that shows the word Prochelon should be added. One diagram that shows the word Procheilon is shown on the following webpage : (https://cnx.org/contents/Mw1rkOh8@32.1:6HVhPsL9@1/Lips ).

Thank you A.L. – The preceding unsigned comment was added by 23.246.88.242 (talk • contribs).

I believe this is a reference to en:Lip and the fact that "procheilon", while defined, is neither linked to its own article nor marked in any diagram. There used to be a stub article at en:Tubercle of the upper lip, but it was redirected in 2018. If you wish to pursue this further, you should raise it at en:Talk:Lip. Bovlb (talk) 21:19, 1 September 2022 (UTC)

Very basic question about linking and unlinking Wikidata elements

Moved to Wikidata:Project_chat § Very_basic_question_about_linking_and_unlinking_Wikidata_elements: Bovlb (talk) 15:22, 3 September 2022 (UTC)

Automatic TOCs are not being generated

Tracked in Phabricator
Task T317857
Resolved

Examples:

Bamyers99 (talk) 14:29, 15 September 2022 (UTC)

The MediaWiki update two days ago contained changesets pertaining to the TOC generation. I'm assuming those were not quite production quality. Infrastruktur (talk) 18:49, 15 September 2022 (UTC)

The TOCs are being generated now. --Bamyers99 (talk) 19:16, 15 September 2022 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Lucas Werkmeister (WMDE) (talk) 08:45, 16 September 2022 (UTC)

Clickable buttons kaput?

Clickable buttons - Template:Clickable button - don't seem to work (e.g. at Talk:Q108046513, or User:Entbert). A couple of recent @MSGJ: edits on that template don't look like the cause, but.

Can anyone help?

Notable also that at Talk:Q108046513 the edit section link for the "Minister of State for Pacific and the Environment (Q108046513) officeholders" section points to https://www.wikidata.org/w/index.php?title=Template:PositionHolderHistory/text/en&action=edit&section=T-1 rather than enabling the section to be edited ... previously in my recollection this link worked fine. Not sure if this is or is not related. --Tagishsimon (talk) 09:08, 16 September 2022 (UTC)

It was an incorrect import by MSGJ (the imported edits appear under the original authors’ names and with original dates, so it’s not easy to catch them) I’ve reverted yesterday, should be okay now. The edit link has been completely broken ever since I migrated the template to use Autotranslate, and even before that, it would edit the template instead of the talk page. Since it’s impossible to make it edit the talk page (but I wouldn’t expect it either to do so), I just made it not appear at all. —Tacsipacsi (talk) 00:42, 18 September 2022 (UTC)

Thank you Tacsipacsi; I was confused by that blank diff. 'not appear at all' = good plan, under the circs. --Tagishsimon (talk) 00:59, 18 September 2022 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Tagishsimon (talk) 00:59, 18 September 2022 (UTC)

Property P18 (image) being displayed wrong

The property image (P18) is currently being rendered as "Hieronim Kieniewicz (1867-1925) - Tygodnik Ilustrowany-1918 AD.jpg". I assume this is a caching issue of some sort, but just in case it's not, someone should check it out. Thanks. Howcheng (talk) 18:32, 16 September 2022 (UTC)

@Howcheng: Where, exactly, is this happening? --Tagishsimon (talk) 19:52, 16 September 2022 (UTC)

@Tagishsimon: It appears to have resolved itself. It was visible (for a short while, at least for me) on the examples for P18, but it's all good now. Howcheng (talk) 19:58, 16 September 2022 (UTC)

@Howcheng: Okay, I see it now; some temporary vandalism to the property's EN label. Intriguingly, the title of the revision history of P18 is still "Revision history of "Hieronim Kieniewicz (1867-1925) - Tygodnik Ilustrowany-1918 AD.jpg" (P18)" a good couple of hours after the vandalism was corrected. [1]. Presume that, too, will pass in time. --Tagishsimon (talk) 20:09, 16 September 2022 (UTC)

@Tagishsimon: Ah, I didn't think to check the revision history. By the time I got there, it had already been reverted so I couldn't figure out where the problem was. Howcheng (talk) 20:53, 16 September 2022 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Tagishsimon (talk) 01:00, 18 September 2022 (UTC)

Edit right in pywikibot

I'm not sure if this is the right place to ask, but I've been bashing my head against this pywikibot==7.6.0 problem. The following code:

site = pwb.Site()
repo = site.data_repository()
item = pywikibot.ItemPage(repo, 'Q91726980')
claims = item.claims['P31']
item.removeClaims(claims)

produces the error message: UserRightsError: User "Bovlb" does not have required user right "edit". What am I doing wrong?

site.userinfo['rights'] = 
['skipcaptcha',
'deletedhistory',
'deletedtext',
'autopatrol',
'unwatchedpages',
'autoconfirmed',
'editsemiprotected',
'ipblock-exempt',
'browsearchive',
'titleblacklistlog',
'abusefilter-log-detail',
'abusefilter-view-private',
'abusefilter-log-private',
'read',
'writeapi',
'abusefilter-view',
'abusefilter-log',
'purge',
'spamblacklistlog']

Bovlb (talk) 03:10, 7 September 2022 (UTC)

@Bovlb Are you perhaps logging in using a bot password that doesn’t have an “edit” grant? Lucas Werkmeister (WMDE) (talk) 08:29, 7 September 2022 (UTC)

Doh! I guess I skipped that box when I configured the OAuth consumer. Thanks!

While I have your attention, I'm having trouble getting the OAuth tutorial to work. Where would be the best place to get help on that? Bovlb (talk) 14:44, 7 September 2022 (UTC)

My usual place for that would be the places linked under the general support section of wikitech:Help:Cloud Services communication, i.e. the #wikimedia-cloud IRC channel or linked Telegram channel. Lucas Werkmeister (WMDE) (talk) 10:23, 8 September 2022 (UTC)

Thanks. I was hoping for somewhere on-Wiki. Bovlb (talk) 16:43, 8 September 2022 (UTC)

Tree view not styled in header

See MediaWiki_talk:Talkpageheader#Fixing_TemplateStyles. The superclass hierarchy isn't being styled in the talk page header, which is frustrating. I'd love a more skilled person to look into this. JesseW (talk) 14:08, 7 September 2022 (UTC)

Customized search description

There has been a lot of discussion recently about whether we should place year-of-birth or death into the descriptions of human (Q5). It would be helpful if that information appeared in the user-interface when selecting amongst a bunch of people with the same name. But some people think redundantly putting the information in both the description and the statements could lead to de-synchronization. Optimally we would be able to control/customize the description text. One could imagine this feature being very useful if it could auto-generate descriptions for description-less items based on e.g. instance of (P31) or occupation (P106).

Is this something that could be done? What if I volunteered to code it. This possibly seems related to/enabled by wikifunctions/abstract wikipedia (though I don't know enough about that project). BrokenSegue (talk) 03:31, 12 September 2022 (UTC)

oh I just realized this page is for problems not feature requests... sorry. BrokenSegue (talk) 03:31, 12 September 2022 (UTC)

Hi @BrokenSegue. You can also make a feature request here. Do you mind using this template to describe the request? -Mohammed Sadat (WMDE) (talk) 10:25, 12 September 2022 (UTC)

Namespace in RDF

Would it be possible to add the namespace to sitelinks? For example, we have:

 <https://commons.wikimedia.org/wiki/Category:Beta_Eikon> schema:about wd:Q113801823 .

which in namespace 14 (Category), but it is impossible to write a SPARQL filter for that in any reasonable language-independent way. Bovlb (talk) 18:01, 12 September 2022 (UTC)

@Bovlb I doubt it, at least not without a significant amount of development effort. MediaWiki doesn’t really have a way to parse or work with titles of other wikis, so the simplest way to implement this, by looking up and adding the namespace during the RDF export, would require making an API call for each connected site to ask the other wiki for the namespace, which would make the RDF dumps prohibitively slow. (We make such an API call each time the sitelinks are edited, to normalize the title – e.g. en:test gets normalized to en:Test but wikt:test stays lowercase.) To avoid this slowdown, we’d have to change the way the sitelinks are stored, to add the namespace information whenever sitelinks are edited (and somehow update it when a wiki’s namespace configuration changes)… Lucas Werkmeister (WMDE) (talk) 08:56, 13 September 2022 (UTC)

Well, that makes sense, but I'm in an even worse place to make sense of it in SPARQL. I have a tool that attempts to assess the notability of items (insofar as this is mechanically possible), but I can't cover all the way draft, user, and category pages are referred to. I suppose that I could download the prefix tables of all client projects and make an enormous regular expression, but I baulk at the prospect. Bovlb (talk) 02:05, 15 September 2022 (UTC)

Misleading red error message

I've started seeing a big red error message "IP information for this address cannot be retrieved since no edits have been made from it." at the top of IP contributions when all of their contributions have been deleted. This is unhelpful and misleading. Bovlb (talk) 15:30, 11 September 2022 (UTC)

@Bovlb Thanks for bringing this to our attention. I could not find an example IP address whose contributions have all been deleted to look at. However, following the related conversations at mw:Talk:IP_Editing: Privacy Enhancement and Abuse Mitigation/IP Info feature changes, this message can be changed at mw:MediaWiki:Ipinfo-widget-error-ip-no-edits. In case there is something deeper to this IP info feature, the community can ask WMF to change it for all their wikis. Mohammed Sadat (WMDE) (talk) 08:08, 19 September 2022 (UTC)

Here are three examples for you: Special:Contributions/5.122.178.192, Special:Contributions/83.123.219.217, Special:Contributions/77.181.30.153

So, do you plan to make it possible to investigate IPs in this scenario? Bovlb (talk) 15:36, 19 September 2022 (UTC)

Adding a new language code, ISO 639-3: ldn (followup)

Tracked in Phabricator
Task T302705

Previous discussion: Old revision of wikidata:report a technical problem (archive)

Requesting a status report of where in the process ldn is currently. — Arlo Barnes (talk) 07:49, 17 September 2022 (UTC)

Thanks for the reminder, and apologies that it's taken very long. I've pinged folks in the language committee (Amire80, Jon Harald Søby) who can okay the request so that we can move it forward. — Mohammed Sadat (WMDE) (talk) 08:20, 19 September 2022 (UTC)

~~Yeah, this is fine – sorry about the delay!~~
Sorry, I spoke too quickly (I mixed it with another language). According to the enwiki article on the language, it is a constructed language that is an "experiment in feminist linguistics" – i.e. it doesn't seem to be a general-purpose language with general use outside of hobbyist communities. I would therefore like to know more about what the intended use of the language on Wikidata is. That being said, it should still be fine at least for lexemes, and probably also for monolingual text.

user:Jon Harald Søby, phab:transactions/history/PHID-XACT-TASK-ktk5tmtioyycgnr#T302705-8244649

Regarding the quoted post in the phab thread by @Jon Harald Søby: I presume the other language in the mixup was Ladino (Judaeo-Spanish)? Láadan is indeed quite different from Ladino; as an artificial / constructed / artistic / planned language, ldn has 0 native speakers compared to lad's estimated 137 000. However, this is the case for several conlangs and extinct / classical literary languages already supported by Wikimedia projects, although I understand both categories are increasingly coming into disfavour for new projects...my proximate goal is not to start a new project, though (incubator:wp/ldn exists but is hampered by the creation of new pages being disabled) but instead merely to add & translate strings (including any or all of: content, UI strings, and lexemes) in existing projects, for the benefit of non-native users of the language — of whom a census has to my knowledge never been surveyed.

I would also like the state that the English Wikipedia page for the language is rather poorly structured, a lacking which I hope to remedy someday...as such, it doesn't clarify that the once-experimental status of Láadan and its framing within a field of feminist linguistics each have historical and culturo-critical relevance, but don't reflect the current state of things. I am also not sure what is meant by 'general-purpose'; as one might expect, any concept expressible in another language can also be expressed in Láadan, with more or less compactness (in some cases circumscription might be needed, but in others Láadan will tend to be terser than the compared language)...this concept is rather analogous to equivalence problem (Q65074105) in the context of programming languages.

For additional clarity on my aims, see betawiki:thread:support/Adding a new language, ISO 639-3: ldn (Request) and betawiki:thread:user talk:Álo/Laadan dictionary.

— Arlo Barnes (talk) 06:50, 25 September 2022 (UTC)

Arbitrarily behaviour of the fast 'single entry' item merger

When I implicitly merge two wikidata items such that each is associated with just one wikipedia language version article, by using the only reasonably simple standard procedure, I would expect the older (and lower-numbered) item to be retained, with the recent item becoming a redirect. This is the natural procedure, which in general preserves most of the history; and it is the standard behaviour of the "merge with" tool, which I mostly use for merging wd items with several entries each. However, this is not the ways the simple entry item merger works. I suspect that it simply merges the item from whose single entry the merge is requested into the other entry, without any check whatsoever (except the demand of confirmation of the merge).

A concrete example: The items Q15757292 and Q65335706 had just one entry each, en:Saga (journal) and is:Saga (tímarit), respectively. Thus, I could initiate a merge by clicking the Add links button in either; but had no access to any Edit links button. (At least as most wp's are displayed for me, the Edit link button simply is replaced by an Add links button, if the article as yet has no recognised iw.) This starts 'the single entry item merger'—or whatever its technical name may be. I directly get up a dialogue box asking for a language version and an article to associate with; but no way to influence how the behind-the-scene wd item merge is to be performed. Well, I did this, starting from the short enwiki stub, instead of the longer iswiki article. (I didn't recognise that the enwiki stub was the older article; but I also didn't know that this was to be recommended.) As you can see, this turned the older item (history of Q15757292) into a redir to the new one (history of Q65335706); a not very nice outcome.

Now, I suppose that this situation should be common enough, when wd items for disparate language versions of the same subject start to be united. After all, uniting two of them logically is the first step. Hence, I think that it would be good to tweak the single entry item merger for the special case that also the target is 'single-entried', by in that case always merge the more recent item into the older one, without considering from which article the merge request was made. If a single entry item is merged with one with multiple entries, then you could argue that the multiple one in a sense already is the more complex one, even if it happens to be younger; but I can find no such mitigating circumstance when each item has just one entry each.

Regards, JoergenB (talk) 18:22, 20 September 2022 (UTC)

Interesting, I didn’t realize that this feature can merge items at all. Apparently it compares the number of sitelinks to decide which item to merge into which one (and has done so since 2013); that certainly doesn’t match the recommended practice on Wikidata, you’re right. Lucas Werkmeister (WMDE) (talk) 09:06, 21 September 2022 (UTC)

Hm, or does it? Help:Merge#Select recipient item (collapsed by default) says that The recipient item is usually the item that is used more often (possible indicators are the quality of sitelinks or the number of sitelinks and statements), and When in doubt, it's best to choose the item with the lowest Q#### (emphasis added). Lucas Werkmeister (WMDE) (talk) 09:11, 21 September 2022 (UTC)

FWIW, of the first 488k merged Q items (by whatever index Blazegraph's slicer uses), 99.88% involve merges into the earlier QId, 0.12% into the later QId - https://w.wiki/5j4x - which tells us nothing much w.r.t. Help:Merge's view, but was an interesting query to write. Yay PageConnector for doing it by the book, even if we might have doubts about the book. --Tagishsimon (talk) 10:07, 21 September 2022 (UTC)

You can get a better sample for the statistics by using only redirects whose latest revision has the tags "Sitelink Change from Connected Wiki" and "New redirect". I think it is possible to incorporate in the query using MWAPI with parameters prop=revisions and rvprop=tags. --Dipsacus fullonum (talk) 13:10, 21 September 2022 (UTC)

@Lucas Werkmeister (WMDE): Just a check of whether or not I understand the technical matters here: Would the site link count for 'single-entried' items automatically return 1? If that is the case, for the merge of two 'single-entried' items, we would always get equality in the crucial count comparison

if ( firstSiteLinkCount <= secondSiteLinkCount ),

and thus the value true of the test, shouldn't we? JoergenB (talk) 17:45, 27 September 2022 (UTC)

@JoergenB: I’d need to look into this feature some more before I could answer that question, sorry. If you think the merge behavior should be changed, please file a Phabricator task so it can be prioritized. Lucas Werkmeister (WMDE) (talk) 08:45, 28 September 2022 (UTC)