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

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

type constraint not working with normal (non-best) rank

Q191769#P31 has Q14827288 with normal rank (another value has preferred/best rank), but Special:ConstraintReport/Q229760 currently lists a constraint violation for imported from Wikimedia project (P143) (it's at Q229760#P106).

I think we changed the type constraint to no longer work with deprecated statements (see Wikidata_talk:WikiProject_property_constraints#Need input: deprecated rank and type/value type constraint checks), but somehow normal (non-best) rank got thrown out too.

Notified participants of WikiProject property constraints --- Jura 12:22, 2 February 2022 (UTC)

WikibaseQualityConstraints uses best-rank statements when following type constraints, see T170401. Lucas Werkmeister (WMDE) (talk) 13:04, 2 February 2022 (UTC)

It seems the current approach needs adjustment to meet the users requirements.

How could we fix it? Return back to the earlier version or make a more complex query if wdt: fails? --- Jura 15:29, 2 February 2022 (UTC)

Can't merge two items

Hello, Q24397124 (Categoria:Opere di Giordano Bruno) should be merged into Q30861089 (Category:Books by Giordano Bruno). I tried "Merge two Items" but it says "Error: Conflicting descriptions for language bg." which is a meaningless dead-end for normal people. Sorry, I give up and dump it in your lap. 77.147.79.62 18:37, 4 February 2022 (UTC)

I've merged those two items. Not quite sure what kind of problems you'd met with, but here you go. —— Eric Liu_{（留言．百科用戶頁）} 05:44, 5 February 2022 (UTC)

@Ericliu1912: It may be that you didn't try Special:MergeItems? If so, please undo the merge so that the problem report can be professionally investigated and resolved. --- Jura 10:29, 5 February 2022 (UTC)

So I can't use merge.js? —— Eric Liu_{（留言．百科用戶頁）} 10:48, 5 February 2022 (UTC)

I think the bug report was about Special:MergeItems and IPs can't. --- Jura 11:02, 5 February 2022 (UTC)

I've undone the merge, tested Special:MergeItems myself, and it does have problem. Though for user experience, if the problem can't be solved in a period of time, I would merge those two items again using merge.js. —— Eric Liu_{（留言．百科用戶頁）} 09:55, 6 February 2022 (UTC)

Jura is right: If Merge.js can do what Special:MergeItems can't, this could mean (at best) that Special:MergeItems should be upgraded with Merge.js's secret sauce, or (at worst) that Merge.js can damage the database with ops the official software knows shouldn't be done. Just my $0.02... 77.147.79.62 19:13, 6 February 2022 (UTC)

Disable "zh", "zh-hans" and "zh-hant" in label language options

Tracked in Phabricator
Task T301245

Discussion in PC. This would prevent edit war of different Chinese language variants. ~~So, if an item contains label information in zh, it should be converted to zh-hans and zh-hant, filled into the corresponding field.~~ User should be able to modify zh variant except zh, zh-hans and zh-hant, and those variant should be generated automatically. Thanks. Stang 11:03, 14 December 2021 (UTC)

Minor changes for title and description. Stang 12:59, 1 February 2022 (UTC)

Thanks for bringing our attention on this topic. Before moving forward, I'd love to have the opinion of people who are knowledgeable about languages and language codes; @Jon Harald Søby, Amire80: do you have any input to add to the current discussion? Thanks a lot! Lea Lacroix (WMDE) (talk) 19:58, 14 December 2021 (UTC)

I know very little about Chinese, but from the little I do know, it makes sense. The more similar it is to the practices in the Chinese Wikipedia, the better (probably).

This should also get some input from the people who maintain the Chinese Language Converter in core. Amir E. Aharoni {{🌎🌍🌏}} talk 09:23, 15 December 2021 (UTC)

@Amire80 Do you mind pinging some of the people working on the zh language converter? Mohammed Sadat (WMDE) (talk) 13:40, 21 December 2021 (UTC)

No, I haven't. I barely know who they are. I recommend that you do it. Amir E. Aharoni {{🌎🌍🌏}} talk 05:46, 22 December 2021 (UTC)

I maintained the language converter more than 10 years ago. I suggest the conversion from zh into zh-hans or zh-hant on Wikidata should be a one-time operation and the results should be stored in the database but not calculated on fly - this will allow us to fix conversion errors much easier. We can use robots to maintain the conversion between different variants since people usually don't fill in all the Chinese variants.

However, I'm not fully persuaded to use zh-hans and zh-hant instead of zh. If to prevent edit war is the purpose, we should use the 6 regional variants zh-cn, zh-tw, zh-hk, zh-mo, zh-my, and zh-sg since they can prevent conflicts of both the characters and the commonly used words. For example, "table tennis (Q3930)" is "乒乓球" in mainland China and Hong Kong (zh-cn and zh-hk) but "桌球" in Taiwan (zh-tw). If only zh-hans and zh-hant are used there will be conflicts between Hong Kong and Taiwan editors since both of them use Traditional Chinese characters. This example gets even complicated because "cue sports (Q3341285)" is "撞球" in Taiwan but also "桌球" in Hong Kong. The zh-hant cannot distinguish this without using disambiguation parentheses. --Philip Tzou (talk) 22:35, 25 January 2022 (UTC)

Labels are not used for disambiguation. Descriptions are. GZWDer (talk) 19:25, 26 January 2022 (UTC)

Right. But how you prevent an edit war changing from "桌球" to "撞球" back-and-forth in zh-hant? I know that you can protect a certain item/page but I thought to avoid edit wars is the proposal's purpose. I want to point out that zh-hans and zh-hant is insufficient for avoiding such edit wars. --Philip Tzou (talk) 17:59, 28 January 2022 (UTC)

So the point is human should be able to edit all other zh variant except zh, zh-hans and zh-hant (just like what we do on Chinese Wikipedia to hide these convert option), and those variant should be generated automatically, if I understand you correctly. Stang 12:23, 30 January 2022 (UTC)

Yes. Philip Tzou (talk) 17:08, 30 January 2022 (UTC)

Hi there, any progress of this proposal? Stang 21:46, 2 January 2022 (UTC)

@Chiefwei: as one of the people who's made most of the changes in core, what are your thoughts about this? -Mohammed Sadat (WMDE) (talk) 08:51, 7 January 2022 (UTC)

They seems has no edit for a while (since Dec 27, 2021). Stang 16:03, 20 January 2022 (UTC)

I personally would support this proposal. But I am slightly concerned about what language should we use at various parts of the interface - that is to say, in mobile apps' search interface, new vector skin's search bar, and more. Can they change in accordance with the language variant? --Milky·Defer 16:30, 25 January 2022 (UTC)

Isn't the interface language separable with content language? Just like in Chinese Wikipedia. —— Eric Liu_{（留言．百科用戶頁）} 03:00, 26 January 2022 (UTC)

Not really I am afraid. If you switch to new vector skin, and type into the search box, you can see a short description from search results. It is taken from here under [zh] label, no matter what variant you use. The same is also true in mobile apps, although this time the short description is directly under the title, and you can even edit that description (of wikidata) directly from wikipedia iOS app. Milky·Defer 13:33, 26 January 2022 (UTC)

I oppose - currently there are no fully reliable way to convert between Chinese variant and it may be a good idea to keep an unspecified variant.--GZWDer (talk) 18:35, 26 January 2022 (UTC)
- Read the title of this page please. This page deals with the technical problems. You might be concerned about technical viability, but here is the place to deal with it. Milky·Defer 04:01, 27 January 2022 (UTC)
  What I mean is: it is useful to have a "zh" variant for labels in unspecified variant, as (for example) page titles in Chinese Wikipedia may be in either variants and there are no fully reliable way to convert them automatically. GZWDer (talk) 22:52, 28 January 2022 (UTC)
Looks good, but there still have technical issues. The mobile version (including the web and client) only distinguishes between Traditional Chinese and Simplified Chinese, but as User:PhiLiP indicated, the regional variants are more detailed, and for Traditional Chinese, some words are also different. Language settings for mobile versions may require a more detailed distinction. However, based on the existing situation, it may be necessary to apply for not only the configuration adjustment of wikidata, but also the development adaptation of the mobile version; or select a regional variant as the content display representative of Traditional Chinese or Simplified Chinese. In addition, disable the label and description of "zh" language should not affect other functions of "zh" language, because other data still belong to "zh" language. --Cwek (talk) 01:55, 31 January 2022 (UTC)
(Sorry in Chinese. But Google's English writing is indeed better then mine.) 在中文維基百科，多個變種是從單一原始碼轉換出來的。也就是說，編者輸入一個"zh"，系統根據轉換表計算出文字變種，再呈現給不同讀者。但在Wikidata中，編者可以直接定義不同變種。因此，手工定義zh、zh-hans、zh-hant就沒有必要；且如上所言，這會引發一個潛在地爭議。對於未指定區域變種的用戶（或語言設定為zh、zh-hans、zh-hant的讀者），系統可以自動轉換。--Lopullinen (talk) 18:31, 31 January 2022 (UTC)
- Google Translation as a service: "In Chinese Wikipedia, multiple variants are converted from a single source code. That is to say, the editor enters a "zh", the system calculates the text variant according to the conversion table, and then presents it to different readers. But in Wikidata, editors can define different variants directly. Therefore, it is not necessary to manually define zh, zh-hans, zh-hant; and as mentioned above, this can lead to a potential controversy. For users who do not specify regional variants (or readers whose language is set to zh, zh-hans, zh-hant), the system can automatically convert" --Manuel (talk) 10:49, 8 February 2022 (UTC)
It's in Chinese, so I don't have much of an opinion about it, but GZWDer's point seems valid. A pratical approach could be to delete the zh label once the same string is present in one of the subtags. --- Jura 13:35, 1 February 2022 (UTC)

Wikidata:Development plan

This page should be updated for 2022.--GZWDer (talk) 18:12, 13 January 2022 (UTC)

It will :)

We're currently working on it. -Mohammed Sadat (WMDE) (talk) 09:22, 14 January 2022 (UTC)

FYI @GZWDer: Wikidata:Development plan was shared today. -Mohammed Sadat (WMDE) (talk) 14:53, 10 February 2022 (UTC)

Bad parameter for format constraints on Special:ConstraintReport/Q229760

Currently there is:

Status	Property	Message	Constraint
Bad parameters	Facebook ID	/^(?:[\p{L}\d.-\\/\-]*)$/u is not a valid regular expression.	format constraint
Bad parameters	IMDb ID	/^(?:ev\d{7}\\/(19|20)\d{2}(\\/[12])?|tt\d{7,8}\\/characters\\/nm\d{7,8}|(tt|ni|nm)\d{8}|(ch|co|ev|tt|nm)\d{7}|)$/u is not a valid regular expression.	format constraint
Bad parameters	Elle.fr person ID	/^(?:[^\s\\/]+)$/u is not a valid regular expression.	format constraint [...]
Bad parameters	Giphy username	/^(?:(channel)?[\S\\/]+)$/u is not a valid regular expression.	format constraint
Bad parameters	Wikimedia import URL	/^(?:((?!wikidata\.org\\/(wiki\\/|w\\/index\.php\?title=)Q).)*)$/u is not a valid regular expression.	format constraint
Bad parameters	Wikimedia import URL	/^(?:((?!wikidata\.org\\/(wiki\\/|w\\/index\.php\?title=)Q).)*)$/u is not a valid regular expression.	format constraint
Bad parameters	KKBox artist ID	/^(?:[^\s\\/]+)$/u is not a valid regular expression.	format constraint
Bad parameters	fernsehserien.de ID	/^(?:[-a-z_\d]+(\\/filmografie)?)$/u is not a valid regular expression.	format constraint
Bad parameters	Rate Your Music artist ID	/^(?:[^\s\\/]+)$/u is not a valid regular expression.	format constraint [...]
Bad parameters	Rate Your Music artist ID	/^(?:[^\s\\/]+)$/u is not a valid regular expression.	format constraint [...]

Maybe the validation doesn't work. At least some queries work when run on query service. --- Jura 12:28, 2 February 2022 (UTC)

The problem seems to be fairly widespread.

Also, it's not clear if the "bad parameters" should really be detailed. Afterall, there is nothing that can be done about them on the item itself.

One could just summarize them similar to "Not in scope" and "To do". --- Jura 12:52, 4 February 2022 (UTC)

Tracked in Phabricator
Task T301473

Thanks for reporting this bug Jura. I created a ticket so we can work on the error handling bit. -Mohammed Sadat (WMDE) (talk) 14:51, 10 February 2022 (UTC)

@Mohammed Sadat (WMDE) Thanks. BTW I got the impression that the regexes (and values) are actually correct, at least for KrBot. See, e.g. Wikidata:Database_reports/Constraint_violations/P3812#"Format"_violations. So the problem might rather with Special:ConstraintReport. --- Jura 20:24, 10 February 2022 (UTC)

descriptions for categories, templates, disambiguation

Following a discussion at Wikidata:Project_chat#Typical_descriptions, I tried doing some statistics for the Blazegraph failure playbook about the size of these in the database.

It seems that >700 million triples are only descriptions for these (queries here).

While many are added in one shot, this still implies a considerable number of edits.

To improve data quality on these items, a default description could be displayed at Wikidata instead and there isn't much use to export these to Query Service. I can't even think of a query where description of a category item is needed. --- Jura 08:37, 10 February 2022 (UTC)

One case where they may be useful is when the query returns both concept items and category/template/disambiguation items and one wants to show the descriptions for all of the results. However, in this case probably the wikibase:label service should be used, so the service can modified to return these default descriptions just like the Wikidata UI, without requiring the triples (at least I hope it’s possible). —Tacsipacsi (talk) 11:29, 11 February 2022 (UTC)

alias as option to open with the triangle

Tracked in Phabricator
Task T301761

items with many alias eg Albrecht Dürer (Q5580) make it difficult to handle as you have a lot to scroll, can we make the visibility of the complete aliases optional, perhaps keep up to five chosen with a high ranking?--Oursana (talk) 20:53, 7 February 2022 (UTC)

@Oursana: Improving the usability for cases like these seems like a good idea. I created phab:T301761 so we can look into this. What criteria do you think should determine the ranking of aliases on an item? Mohammed Sadat (WMDE) (talk) 10:10, 15 February 2022 (UTC)

Thank you. Looking at the many aliases of Dürer it is difficult to answer in general. But perhaps I should initialize references for aliases, because I doubt most of them here. The rankung might be best choosable by the community. Oursana (talk) 14:37, 15 February 2022 (UTC)

A key purpose of aliases - as I understand them - is to enable an item to be found via search. You may 'doubt' any number of aliases on an item, Oursana, but you can be fairly sure that somewhere there is something which refers to the item subject by that alias. Users don't tend to add aliases just for fun, but because they're used, somewhere. Right now aliases have no rank, nor are they referenced. There is, as you point out, no very good basis for ranking aliases. Hide/expand aliases is a good idea. Rank & references for aliases, not so much. --Tagishsimon (talk) 16:16, 15 February 2022 (UTC)

geographic shape urls on Query Service broken

Tracked in Phabricator
Task T178184
review in 2017/2018, triage as "high priority", reload in November 2017 was meant to fix it

Tracked in Phabricator
Task T176593
WQS reload in 2017 (done but didn't fix it)

Please see Property_talk:P3896#links_not_working_on_Query_Service

SELECT ?item ?value WHERE { ?item wdt:P3896 ?value. FILTER(CONTAINS(STR(?value), "+")) }

Try it!

This currently finds 21991 broken links. --- Jura 12:30, 16 February 2022 (UTC)

Thanks for the link to phab:T178184, however this dates from 2017/2018 and hasn't seen any review since. The reload mentioned there didn't seem to have fixed it.

Uses for P3896 have greatly increased in 2020 (by about >23,000, currently 28,210), so it could be the occasion to revisit the question once more. Required fix seems to be trivial. --- Jura 14:49, 16 February 2022 (UTC)

The reload was never supposed to fix it on its own, only to be part of a fix. Lucas Werkmeister (WMDE) (talk) 16:08, 16 February 2022 (UTC)

Map marker change

"Old" map marker.

Hello, I've just noticed a slight change of the map marker (on Q41795664 for example). The inner white marker is bigger and closer to the top of the blue one. Is it intentional? IMHO the previous one (cf. screenshot) was nicer and less disturbing. Ayack (talk) 14:25, 16 February 2022 (UTC)

I could not find any noticeable difference with the map marker. Do you mind sharing a screenshot of what you see on Q41795664#P625? - Mohammed Sadat (WMDE) (talk) 08:22, 17 February 2022 (UTC)

It's weird, it is now "normal" again. Next time I'll take a screenshot. Thanks. Ayack (talk) 09:39, 18 February 2022 (UTC)

You were not the only one who saw it larger. At least, I think I recall it as well. --- Jura 09:47, 18 February 2022 (UTC)

Missing wdtn on identifiers

As mentioned in this thread, items using Steam application ID (P1733) does not set a "wdtn" value even though it is an external identifier and has a formatter url set. This looks like a bug. Infrastruktur (talk) 18:25, 22 February 2022

@Infrastruktur: Could you post a query showing a wtdn: working (for some other ID)? I've had no success finding any. --Tagishsimon (talk) 19:18, 22 February 2022 (UTC)

DESCRIBE wd:Q382108

Try it!

Certainly. Looking at the dump for «Team Fortress 2» we see values for wdt:P1733 and p:P1733, but no wdtn:P1733, and the statement node has no normalized values either.

But you do see normalized simple values for wdtn:P268, wdtn:P436, wdtn:P435 and wdtn:646. Infrastruktur (talk) 19:33, 22 February 2022 (UTC)

@Infrastruktur: There is no bug here. As Toni 001 already mentioned in that thread, the wdtn: predicate is derived from formatter URI for RDF resource (P1921), not formatter URL (P1630). Steam application ID (P1733) has no formatter URI for RDF resource (P1921) statement, therefore Steam IDs don’t get exported as wdtn: triples. --Lucas Werkmeister (WMDE) (talk) 14:47, 23 February 2022 (UTC)

format query on Query Service

aspect

current

new

initial {

SELECT ?s ?p ?o ?a ?b {
  ?s ?p ?o.
  ?o ?a ?b.
}
LIMIT 10

Try it!

SELECT ?s ?p ?o ?a ?b
{
  ?s ?p ?o.
  ?o ?a ?b.
}
LIMIT 10

Try it!

initial WHERE {

SELECT ?s ?p ?o ?a ?b WHERE {
  ?s ?p ?o.
  ?o ?a ?b.
}
LIMIT 10

Try it!

SELECT ?s ?p ?o ?a ?b
WHERE
{
  ?s ?p ?o.
  ?o ?a ?b.
}
LIMIT 10

Try it!

non capturing

SELECT * 
WHERE
{
  _:b5 ?p ?o.
  _:b6 ?p ?q.
}
LIMIT 10

Try it!

SELECT * 
WHERE
{
  [] ?p ?o.
  [] ?p ?q.  
}
LIMIT 10

Try it!

When using the "format query" button with the diamond icon on the GUI, the code gets changed to the format on left column ("current").

The version in the right column ("new") seems a slight improved, symmetric version of the same, with the same number of characters involved.

For [], it might not be cosmetics. If so, the current version is preferred.

On the next update to the GUI, would you kindly include the above? --- Jura 11:53, 13 February 2022 (UTC)

Thanks for the suggestions Jura, but these seem like purely stylistic choices to me, where one could choose either one or the other. Besides, we practically have very limited possibilities to change the formatting anyways because we simply ask the SPARQL.js library to parse and then format the query, so it ends up in a formatting that SPARQL.js wants. If there was an actual bug in there, we could try to fix it and send a pull request to the library. - Mohammed Sadat (WMDE) (talk) 10:19, 28 February 2022 (UTC)

coordinate (P625) showing "unknown value"

Seemingly an issue with importing coordinates may occur where after the import P625 is showing unknown value. The entry cannot be edited but has to be removed and newly added. An example is P625 under Elif (Q5360798). --Katpatuka (talk) 05:54, 23 February 2022 (UTC)

@Katpatuka: unknown value Help is a normal part of the Wikidata data model, see Help:Statements § Unknown or no values. To change it to a custom value, use the button. Lucas Werkmeister (WMDE) (talk) 14:49, 23 February 2022 (UTC)

@Lucas Werkmeister (WMDE): Well, since values of coordinates usually have to fulfill a constraint to be recognized as valid coordinates I thought erroneous entered values would be rejected with an error message when entered - sımılar to trying to add a coordinate like 37.3766/37.8795 immediately a message pops up reading Malformed value. --Katpatuka (talk) 16:40, 23 February 2022 (UTC)

@Katpatuka: That’s true, but it’s different from unknown value Help. If you somehow managed to save an invalid coordinate value (e.g. through a software bug), then it would also look different than that. Lucas Werkmeister (WMDE) (talk) 17:07, 23 February 2022 (UTC)

Vector 2022 skin bug

Hi - the Vector 2022 skin causes the interwiki link sidebar to be pushed right down to the bottom of the page, which is really annoying. Could somebody please knock together some CSS for the skin to prevent this happening? Many thanks. Theknightwho (talk) 04:33, 26 February 2022 (UTC)

It’s not “knocking together some CSS”, but more substantial changes are needed if we want to do it in a future-proof way. (Strictly speaking it’s not even a bug, rather simply that new Vector’s limited content width forces the one-column layout on all screen sizes, while on legacy Vector it happened only on narrower screens.) The developers working on new Vector know about this issue, see phab:T300182. —Tacsipacsi (talk) 00:55, 27 February 2022 (UTC)

Many thanks. Theknightwho (talk) 01:20, 27 February 2022 (UTC)

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

Tracked in Phabricator
Task T302705

Hi! Unfortunately I can't use Phabricator myself (borked two-factor setup) so per help:monolingual text languages#Getting a language code added I'm requesting the addition of Láadan (Q35757). This is a constructed language that uses a Latin character set (rather, a much restricted subset thereof but that's neither here nor there). My use case (to pick one example) is being able to avoid having to use mis in my lexeme data editing for the language (including for toponyms from the language in mainspace -- for instance, name (P2561) of Arkansans (Q100699808)). Arlo Barnes (talk) 11:11, 27 February 2022 (UTC)

I created a ticket for this task. -Mohammed Sadat (WMDE) (talk) 10:48, 28 February 2022 (UTC)

Thank you. (Regarding the most recent Phabricator comment: Oh, do lexemes use a different system or something?) Arlo Barnes (talk) 14:14, 28 February 2022 (UTC)

Yes, there are three different sets of language codes (with considerable overlap, of course): those for “terms” (labels, descriptions, and aliases), those for monolingual text values (like name (P2561)), and those for “lexicographical terms” (lexeme lemmas, form representations, and sense glosses). For your use case, it sounds like you would need it to be added to the latter two sets, but not terms? Lucas Werkmeister (WMDE) (talk) 14:25, 28 February 2022 (UTC)

Gotcha. I mean, if 'terms' are enabled I'll fill them out for sure, they just weren't the priorities I had in mind. Arlo Barnes (talk) 16:01, 28 February 2022 (UTC)