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

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


Wrong result via SPARQL endpoint

The following query works fine via GUI and returns labels: 

SELECT ?child ?childLabel
WHERE
{
  ?child wdt:P22 wd:Q1339;
         wdt:P25 wd:Q57487.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
}
Try it!

However when I run it via endpoint it returns keys instead of labels: 

child,childLabel
http://www.wikidata.org/entity/Q76428,Q76428
http://www.wikidata.org/entity/Q107277,Q107277
http://www.wikidata.org/entity/Q470198,Q470198
http://www.wikidata.org/entity/Q15079141,Q15079141
http://www.wikidata.org/entity/Q21029009,Q21029009
http://www.wikidata.org/entity/Q21029016,Q21029016
http://www.wikidata.org/entity/Q30075271,Q30075271

Fusanari Shimizu (talk) 20:04, 5 June 2022 (UTC)

@Fusanari Shimizu Try replacing "AUTO_LANGUAGE" with a legit langcode, like "en". It’s the query service web interface that does the trick if I’m not wrong. author  TomT0m / talk page 20:18, 5 June 2022 (UTC)
Great, thank you. Works fine now. In the most of examples I have it typically states "[AUTO_LANGUAGE],en" but exactly in this one there was no "en" :) Fusanari Shimizu (talk) 20:35, 5 June 2022 (UTC)

Merge lexeme and sense back reference

Tracked in Phabricator
Task T310894

When merging two lexemes, we have an issue with sense ID - reference.

For example, if we have

  • L1 with L1-S1 and
  • L2 with L2-S1 ;

L3 with a statement like L3-S1 hyperonym L2-S1

and me merge L1 with L2 … in L1, we get

  • L1-S1
  • L1-S2
  • L2 -redirect> L1

but unfortunately we stay with

  • L3-S1 hyperonym L2-S1

with no way to track what L2-S1 is became except trying to guess using the history …

I guess it’s known ? author  TomT0m / talk page 18:14, 6 June 2022 (UTC)

@TomT0m: Yes, this is a known issue, thanks for reporting it here. Do people have ideas on how the situation can be improved? (you may add them directly to the linked ticket).

Moldavian langcode

This sparql query shows that a monolingual text value in Moldovian language returns « mo », which is the wikimedia language code. The language code should be the IETF one ( ro-MD according to Help:Wikimedia_language_codes/lists/all) isn’t it ? There is errors in infoboxes that uses such values on frwiki. author  TomT0m / talk page 15:29, 2 June 2022 (UTC)

@TomT0m: I think those are two separate issues. The RDF / SPARQL part is covered by T243428 – but I wouldn’t expect that to affect infoboxes. The infoboxes probably need to convert from a MediaWiki language code to an HTML (BCP-47) one; I’m surprised that there doesn’t seem to be an existing function for this in Scribunto (I would expect a wrapper around LanguageCode::bcp47() in PHP). Where are you seeing these infobox errors? Lucas Werkmeister (WMDE) (talk) 15:45, 2 June 2022 (UTC)
@Lucas Werkmeister (WMDE) On the article fr:Alexandre_Ier_Mavrocordato for example. If the language codes in lua are the wikimedia ones indeed this is a bug in frwiki, that’s our first thought on this discussion but the whole stuff is quite confusing :) author  TomT0m / talk page 15:52, 2 June 2022 (UTC)
@TomT0m: Okay, to me this doesn’t look like a bug in Wikibase at least… fr:Module:Langue/Data says mo is an invalid language code, and fr:Module:Langue shows an error for invalid language codes (lines 275 to 281, if I’m not mistaken). I think this needs some kind of solution within the French Wikipedia modules – I would argue it’s correct for Wikidata to make the MediaWiki language code mo available to Lua without mapping it. (It would still be useful to have LanguageCode::bcp47() available in Lua, but I don’t think it would directly solve this problem.) Lucas Werkmeister (WMDE) (talk) 16:08, 2 June 2022 (UTC)
@Lucas Werkmeister (WMDE) The frwiki language code assumes an IETF code, can you confirm this is incorrect ? Is there a reference lua module somewhere in the Mediawiki galaxy for the correct mapping ?
I’m reading data model reference and this section about « UserLanguageCode » and I think this is a bit not helpful either. a short string for identifying languages, based on the language preference setting of logged in Wikipedia users. Wait what the mapping itself depends on the user language ??. (a better wording and) A link to the mapping / doc should be useful in the reference. The doc should mention that some representation of the data model, the RDF one of course, does not use those « UserLanguageCode » but the IETF one like RDF requires. author  TomT0m / talk page 16:50, 2 June 2022 (UTC)
@TomT0m: I can confirm that not all language codes used by Wikibase are IETF language tags. I believe all the Wikibase-specific ones are standard codes, but MediaWiki itself has some deprecated and some nonstandard language codes, and those can be used for labels and monolingual text (mo isn’t the only one; another example would be simple, which should really be en-simple). Regarding the data model page, I have to admit I don’t look at that one very often, and I don’t know why it uses “UserLanguageCode” like that. Lucas Werkmeister (WMDE) (talk) 08:28, 3 June 2022 (UTC)
@TomT0m: FYI, I just created phabricator:T310581 for the missing LanguageCode::bcp47() function. Lucas Werkmeister (WMDE) (talk) 08:52, 14 June 2022 (UTC)
Thanks ! author  TomT0m / talk page 08:56, 14 June 2022 (UTC)

Alias UI should wrap

Tracked in Phabricator
Task T87579

Labels and Descriptions wrap in the data entry UI, both when editing and when viewing; Aliases do not wrap, making editing hard, and, often, obscuring key information. Example at Bridge of Auchernach (Q56621966). Please make Aliases wrap in the same way as Labels and Descriptions. --Tagishsimon (talk) 08:56, 4 June 2022 (UTC)

The issue is that, in contrast to labels and descriptions, an item can have multiple aliases, which are currently separated by line breaks. If aliases would be allowed to break, it wasn’t clear whether the new line is a new alias or just the same long alias. Maybe a hanging indent could help at the cost of making long aliases break into even more rows. —Tacsipacsi (talk) 19:44, 5 June 2022 (UTC)
@Tagishsimon, Tacsipacsi: We have an open task to investigate solutions for items with many aliases. See phab:T87579 -Mohammed Sadat (WMDE) (talk) 07:18, 13 June 2022 (UTC)

Link rot update for 'reference URL' property

I started a discussion at Property_talk:P854#Link_rot_update. Request responses at that page. Thanks Arjunaraoc (talk) 07:07, 2 June 2022 (UTC)

This looks more like a data modeling issue rather than a technical problem. -Mohammed Sadat (WMDE) (talk) 14:57, 17 June 2022 (UTC)

Remove property using pywikibot

Hi, I'm sure this is simple, but I can't work out how to remove a property (P625), when not applied as a qualifier, but directly on to the item, from a given ItemPage. It seems to be something like 

claim = pywikibot.Claim(site, '625')
page.removeClaims(claim, u'Summary')


but I can't quite work it out. I can give.more context if necessary. (Please ping on reply.) Qwerfjkl (talk) 20:55, 14 June 2022 (UTC)

@Qwerfjkl: claim must refer to an existing claim of the item. You need to do something like claim = page.claims['P625'][0]. --Matěj Suchánek (talk) 12:46, 15 June 2022 (UTC)
Thanks, that worked. Qwerfjkl (talk) 19:01, 15 June 2022 (UTC)

Central-Login

To whom it may concern:

Central-Login aka Central Authentication Service, as it is implemented beetween other project-servers (wp/meta/commons etc.) is not functional on wikidata, at least in my case (Firefox Release 101.0.1 / Linux-Mint / Kernel 5.4.0-120).

Somebody should pls. test/try/fix this. Best Ｔｏｍ (talk) 07:03, 16 June 2022 (UTC)

@Ｔｏｍ This is probably due to the new “Total Cookie Protection” in Firefox 101; T255366 seems to be the best issue we have for tracking this so far, though I wouldn’t be surprised to see a more specific Phabricator task appear sooner or later. Lucas Werkmeister (WMDE) (talk) 16:36, 16 June 2022 (UTC)
OK Lucas Werkmeister (WMDE) Thanks for response. Hopefully someone can fix this sooner or later for this server. With commons.wikimedia.org & and meta.wikimedia.org i am fine. --Ｔｏｍ (talk) 16:43, 16 June 2022 (UTC)
@Ｔｏｍ: Commons and Meta work probably because they use the same second-level domain (wikimedia.org) as the login server (login.wikimedia.org), and thus the login wiki’s cookies don’t count as third-party there. I also experience this in Firefox 102 beta: if I log in through Wikidata, Commons and Meta log in automatically, while Wikipedia, mediawiki.org etc. don’t; if I log in through another wiki, Wikidata doesn’t log in automatically either. Except when I turn off tracking protection for a wiki, as then auto-login works (sometimes I need to open the login form, but the login form always automatically logs me in without me providing the user name and password if tracking protection is off for the given domain). —Tacsipacsi (talk) 18:19, 16 June 2022 (UTC)
thx. as result most of the time i simply do my edits as ip. lets hope for a bug-fix. Ｔｏｍ (talk) 18:53, 16 June 2022 (UTC)
PS I eventually check it backwards: when logged in with de.wikipedia.org and wikidata.org the following happens:
when log-out on de.wikipedia.org the log-out on wikidata.org is effected dito. Ｔｏｍ (talk) 07:25, 17 June 2022 (UTC)
Yes, because when you log out, your session is invalidated at server side too (otherwise you couldn’t prevent a hacker from using your login session stolen from you before you logged out), and the server side is fine here. —Tacsipacsi (talk) 15:29, 19 June 2022 (UTC)

Little bug with Italian dates

Tracked in Phabricator
Task T311383
Tracked in Phabricator
Task T167788
Tracked in Phabricator
Task T87764

Hi! Using the interface in Italian, when I try to add a date in a property with datatype date (e.g. date of birth (P569), date of death (P570) etc.), the date is accepted when I write the name of the month with minuscule initial (e.g. "13 gennaio 1803" or "13 gen 1803"), but not with the majuscule initial (e.g. "13 Gennaio 1803" o "13 Gen 1803"). While the use of majuscule initials for months is discouraged and rare in Italian, I think it would be nevertheless worth to accept majuscule initials. Thanks, --Epìdosis 08:34, 16 June 2022 (UTC)

Same issue in French. But IMHO, this is not the major issue with this datatype. What is really a source of error is that "01/02/2022" is saved as "2 January 2022" while "13/02/2022" is saved as "13 February 2022". MDY format is used almost exclusively in the U.S. I still do not understand why it is preferred here. Ayack (talk) 11:55, 16 June 2022 (UTC)
Thanks for reporting this issue @Epìdosis, it seems to affect other languages we are yet to discover. I've created this ticket so we can investigate the issue.
@Ayack: the MDY / DMY format issue is tracked here. We are yet to work on it under the broader collection of time datatype tickets. -Mohammed Sadat (WMDE) (talk) 07:32, 27 June 2022 (UTC)

Suggestion to P143

I hope this is the right place for my suggestion: In conjunction with imported from Wikimedia project (P143), Wikimedia import URL (P4656) should be displayed as the first search suggestion in the hit list, followed by retrieved (P813). It would be helpful for everyone if you could set it up like this. Best regards --HarryNº2 (talk) 16:37, 16 June 2022 (UTC)

Hello HarryNº2 Unfortunately we do not directly influence the order of the suggested properties. The entirysuggester ranks them based on the frequency of how they are used on similar items. -Mohammed Sadat (WMDE) (talk) 07:32, 27 June 2022 (UTC)
This is extremely stupid. As a result, the import URL is missing for almost every source. It would be nice if this could be changed in the future. HarryNº2 (talk) 07:44, 27 June 2022 (UTC)
@HarryNº2: None of the two properties should be promoted, as these are not "valid" sources. In fact, they are hidden from the suggestions on purpose. Matěj Suchánek (talk) 08:15, 27 June 2022 (UTC)
I thought so. But if you use imported from Wikimedia project (P143), Wikimedia import URL (P4656) should definitely appear as the next property. --HarryNº2 (talk) 08:28, 27 June 2022 (UTC)

Invalid normalization for Japan Search name ID(P6698) : unnecessary URI encoding

Wikidata has Japan Search name ID (P6698) properties, so I can retrieve their ids using wdt:P6698 or p:P6698/ps:P6698 in Literal form. However, in case of retrieving IRI(Internationalized Resource Identifier), wdtn:P6698 or p:P6698/psn:P6698 indicates invalid IRIs.

For instance, Wikidata item Hokusai(Q5586) has "葛飾北斎" as Japan Search name ID in literal, and <https://jpsearch.go.jp/entity/chname/%E8%91%9B%E9%A3%BE%E5%8C%97%E6%96%8E> in normalized value.

The problem is encoding of multi-byte letters. "Japan Search name ID" uses IRIs, so appropriate value is <https://jpsearch.go.jp/entity/chname/葛飾北斎> , without Percent-Encoding. I think that current situation brings inconvenience in situation of using federated query. Insted of using wdtn:P6698, I currently use IRI() and CONCAT() function for workaround, like: https://w.wiki/5JFt . Perhaps it is needed flag to identify IRI. Thank you.

(I reposted this from Project Chat, following Bovlb's advice.) da1blue (talk) 03:15, 24 June 2022 (UTC)

Hi da1blue, thank you for your message! As far as I know, IRIs and their URI encoding are semantically equivalent and thus compatible/exchangeable. Can you explain what you mean by "indicates invalid IRIs". Does this mean that we make the URI normalization incompatible somehow? Can you give an example of why you think it could bring inconvenience in situations of using federated queries? --Manuel (WMDE) (talk) 14:50, 27 June 2022 (UTC)
Hello Dr. Manuel Merz, thank you for comment. The problem I experienced is the situation I request outer SPARQL endpoint (such as SPARQL Endpoint of Japan Search) with federated query to Wikidata. You can see this case the request like this. When I use "p:P6698/psn:P6698", the IRIs were percent-encoded, and federated query does not work as expected. (I do not know much about SPARQL or URIs/IRIs, so I perhaps missed something... ) da1blue (talk) 12:13, 29 June 2022 (UTC)

Possible vandalism detected when adding Google Scholar ID

[1] Why?--Zoobesuch (talk) 22:51, 25 June 2022 (UTC)

@Zoobesuch: This was generated by the abuse filter as a potential inappropriate edit, possibly triggered by the string sBxdmMwAAAAJ which looks like random typing on the keyboard made by a new user account. See Wikidata:Patrol. -Mohammed Sadat (WMDE) (talk) 10:14, 30 June 2022 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Report_a_technical_problem/Archive/2022/06&oldid=1692795963"