Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

For realtime chat rooms about Wikidata, see Wikidata:IRC.
Start a new discussion
Edit
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/05.

Birth after father's death[edit]

We need to change the calculation so that we do not get the error message unless the difference between death and birth is more than 9 months, perhaps 10. See George Francis Valentine Scott Douglas (Q75268023) RAN (talk) 11:54, 10 April 2024 (UTC)[reply]

People have used "exception to constraint" to get rid of these messages, but this doesn't scale. The next step people tend to use is adding "separator" but "object has role" is too ambiguous for this purpose, we would need a qualifier that is more or less single-purpose. Got any ideas? Make a new one maybe? Infrastruktur (talk) 15:52, 10 April 2024 (UTC)[reply]
Just noticed "separator" only works for the single value constraint. :-( But it does seem like a good way to mark claims that are manually checked. @Lucas Werkmeister (WMDE): Something similar for contemporary constraint might be a good idea. At least it's a solution that doesn't have complexity issues. Infrastruktur (talk) 18:58, 10 April 2024 (UTC)[reply]
@Infrastruktur: I don’t understand what you’re trying to do. What does this have to do with a “separator”? What are the date of birth / date being separated from? Lucas Werkmeister (WMDE) (talk) 10:18, 11 April 2024 (UTC)[reply]
Forget about "separator" that was my mistake. I was interested in hearing if you thought it would be feasible to add a way to manually mark claims such as child (P40) with a qualifier basically telling the constraint checker that this claim have been manually checked so don't show an error message here. Basically doing what "exception to constraint" does except the exception info is moved to the claims themselves so it should be more scalable I guess. Infrastruktur (talk) 16:24, 11 April 2024 (UTC)[reply]
I wouldn’t mind adding that, I think… should be relatively simple to implement in WBQC, at least. It’s not an ideal solution, but it’s not like we have any much better solutions lined up either (“constraint exceptions don’t scale” has been a known issue for a while, and the last proposal I dimly recall, which I think would’ve encoded exception lists as additional items, was probably worse). My main concern would be that people would object to these qualifiers, but maybe I’m being too paranoid there ^^ Lucas Werkmeister (WMDE) (talk) 09:35, 12 April 2024 (UTC)[reply]
I was thinking about how to encode the exception. If we use a single new qualifier "constraints manually checked" that would remove warnings for any and all constraints, which might be ok. Trying to encode information about individual exceptions in the predicate position strikes me as a bad idea, but they could be encoded in the object position if there was a URI prefix reserved for this purpose. The "wdno:" prefix encodes which property it pertains to, so likewise an "wdnoexception:" prefix could encode which property and exception it pertained to e.g. "?statement_node pq:P99999 ("constraint manually checked") wdnoexception:P40-Q25796498". Edit: Or maybe something like "?statement_node wdnoexception:P40 ("constraint manually checked") wd:Q25796498" would be better after all? It would add new things to the data model so it's not something that can be rushed. Edit 2: Or since we know which property from the claim itself, we could do without any new URI prefix at all which is actually way better, e.g. "?statement_node pq:P99999 ("constraint manually checked") wd:Q25796498". Infrastruktur (talk) 13:56, 12 April 2024 (UTC)[reply]
I think any addition to the technical data model is a non-starter, to be honest – if we want this soon, we should just encode it using the normal data model and accept that it won’t be 100% precise. I was thinking we could reuse exception to constraint (P2303)subject type constraint (Q21503250) as a qualifier, and when it appears outside of a property constraint (P2302) statement, reinterpret it as “ignore all constraints of this constraint type in this statement” (i.e. in the main snak, qualifiers and references). Or create a new property, of course. (In theory, we could use a URL-valued property, where the value is the URI of a property constraint like http://www.wikidata.org/entity/statement/P31-A89E967D-82B7-4081-BAE3-BADF28B4E7E3; this would let us distinguish between multiple constraints on the same property with the same constraint type, but it would look ugly in the UI and also be much harder to edit.) Lucas Werkmeister (WMDE) (talk) 15:55, 15 April 2024 (UTC)[reply]
I like your first suggestion. Would it be worth using exception to constraint (P2303) only for the main-snak, and make a similar property that is transitive (applies to qualifiers and references as well)? Infrastruktur (talk) 21:06, 15 April 2024 (UTC)[reply]
We could also do that, sure. Would need a new property proposal, I guess ^^
(Also, disclaimer: right now I’m not sure who’s “responsible” for pushing this proposal forward, if we want to go ahead with it; I’m not sure if I should be doing it as a staff account – I see myself more in the role of implementing it once it’s been decided. But I’m also not sure how much more consensus we need, or if we think it’s enough if nobody objected to reinterpreting P2302 here.) Lucas Werkmeister (WMDE) (talk) 15:38, 17 April 2024 (UTC)[reply]
If you decide to move forward with this, ping me and I'll make the property proposal. On consensus: I suppose you could argue that this is not a new feature but a scalability improvement for an existing feature. Edit: The one thing I could see people possibly objecting to is visual clutter. But if that happens it could be solved by showing the qualifier visually by using an icon instead of writing out the statement in text. Infrastruktur (talk) 08:39, 24 April 2024 (UTC)[reply]
  • Perhaps we can do a search for all the children born within 10 months of the father's death and mark them all object_has_role=born after father's death (Q105083598) and rewrite the rule for the error message so that it is not triggered when object_has_role=born after father's death (Q105083598). I am not familiar with how the error message rules are coded to make the changes myself. Do we have an error message when a child is born after the mother's death, which would indicate that the child belongs to a different spouse of the husband? --RAN (talk) 18:16, 11 April 2024 (UTC)[reply]
I suspect a general implementation of such a check (not limited to humans) would have a high complexity cost. It also trades false positives for false negatives. Infrastruktur (talk) 18:44, 11 April 2024 (UTC)[reply]
Notified participants of WikiProject property constraints

Lucas Werkmeister (WMDE) (talk) 09:36, 12 April 2024 (UTC)[reply]

@Lucas Werkmeister (WMDE) how costly would it be to implement the solution that RAN proposed? ChristianKl ❪✉❫ 23:04, 18 April 2024 (UTC)[reply]
I can’t really answer that question, as I don’t think it’s really an implementable proposal yet… the constraint is defined here, and it’s not really clear to me how you would encode not triggered when object_has_role=born after father's death (Q105083598) in the constraint parameters. Lucas Werkmeister (WMDE) (talk) 13:56, 22 April 2024 (UTC)[reply]
@Lucas Werkmeister (WMDE) We could have "expection to constraint given qualifier" and "expection to constraint given qualifier value" where in this example you would make do both "expection to constraint given qualifier ->object_has_role " and "expection to constraint given qualifier value -> born after father's death (Q105083598)". That would solve this problem and likely be also useable in other contexts. ChristianKl ❪✉❫ 13:00, 25 April 2024 (UTC)[reply]
note that WD has a long extant contemporay constraint bug comparing dates accurate to the day and the year https://phabricator.wikimedia.org/T349971 Vicarage (talk) 05:03, 30 April 2024 (UTC)[reply]

Ability to revert batch edits appears broken[edit]

See Wikidata_talk:Edit_groups#Not_working?. Sdkb talk 18:54, 17 April 2024 (UTC)[reply]

Umm, why isn't this causing alarm? Sdkb talk 17:18, 19 April 2024 (UTC)[reply]
Yes, I am sorry that I haven't been able to fix that yet. I have looked into the problem some weeks ago but did not have enough time to find out what the problem actually is. Superficially, it seems that the tasks queue (stored in redis) is behaving weirdly, with Celery (the tasks runner) not reliably picking up the tasks that are sent to it from Django (the web frontend). If anyone is interested in debugging this I would be very happy to give them access to the Toolforge project. The architecture of the tool is rather thoroughly documented, but I am well aware that that alone doesn't make co-maintainers rush to help. It's a fairly standard stack (even documented on Wikitech) but not one that's so widespread in Wikidata tools as far as I know. I have applied all dependency updates yesterday in the hope that it resolves itself but that was probably not enough. − Pintoch (talk) 07:51, 24 April 2024 (UTC)[reply]
@Pintoch: if you give me access I'll take a look. no promises I'll fix it though. User account is https://toolhub.wikimedia.org/search?author__term=BrokenSegue&ordering=-score&page=1&page_size=12 BrokenSegue (talk) 16:39, 25 April 2024 (UTC)[reply]
@BrokenSegue: thanks a lot! You're in. − Pintoch (talk) 22:00, 26 April 2024 (UTC)[reply]
@BrokenSegue, Sdkb: I've switched from one redis database to another and it seems like it improved things. I think the proper solution would be the proper prefixing of redis keys: https://github.com/Wikidata/editgroups/issues/89. − Pintoch (talk) 07:33, 1 May 2024 (UTC)[reply]

Question[edit]

Is it correct for

⟨ former bridge (Q11486300)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ bridge (Q12280)  View with Reasonator View with SQID ⟩

and/or

⟨ proposed bridge (Q44665130)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ bridge (Q12280)  View with Reasonator View with SQID ⟩

? If not, what is the appopriate way to connect these items? — Martin (MSGJ · talk) 14:15, 19 April 2024 (UTC)[reply]

@MSGJː How about followed by (P156). (Folllowed by, at least for former bridge), I would not use subclass of in that way. Do you see a reason to do so? SM5POR (talk) 16:54, 19 April 2024 (UTC)[reply]
I don't see how P156 would be relevant here. In my naive thinking, a former bridge is a bridge which has fallen down, and a proposed bridge is a bridge which has not yet been built, i.e. they are both bridges. But I understand that other views exist — Martin (MSGJ · talk) 18:25, 19 April 2024 (UTC)[reply]
I would say that something is a bridge within Wikidata if there's a point in time where the claim of it being a bridge is true. There's no good reason for former bridge (Q11486300) to exist. As it's just bridge (Q12280) with end time (P582) and using it makes it harder for people to query correctly.
A proposed bridge however never existed so maybe proposed bridge (Q44665130) fictional or mythical analog of (P1074) bridge (Q12280). ChristianKl ❪✉❫ 20:26, 20 April 2024 (UTC)[reply]
Using instance of (P31) destroyed building or structure (Q19860854) might be better, but dissolved, abolished or demolished date (P576) could be used. As is common with edge cases in WD, you'd get tripped up. Ditto abandoned project (Q21514702). But I don't think the solution for structures is a shadow set of former_X items. Vicarage (talk) 04:14, 21 April 2024 (UTC)[reply]
Yes, that would also be better. Replacing former_x items would be a step forward. ChristianKl ❪✉❫ 18:09, 21 April 2024 (UTC)[reply]
I'd not use P576 because I've often see wikipedia input closure dates whilst the bridge was simply rebuild/refurbished. So P576 does not automatically says it's demolished because of misleading data input by various wikipedias Bouzinac 💬●✒️●💛 19:52, 21 April 2024 (UTC)[reply]
@ChristianKl I think, but this might indeed not be a very popular take, that in a query that a naive query that search for "bridges" (say, using "wdt:" in sparql) should only find actual bridges. There is no harm into it being more complicated if you look for historical data or bridges as a certain date. You'd have to write such a query anyway.
One way to achieve this is to set a "preferred value" to something else in instance of (P31) value. Viewed like that as a general rule, it does not make querying harder at all, just the opposite.
By not using that if you look for, say, french communes or department, you get historical data and you most likely do not want them and you have to after that do something more complicated to exclude the old one. author  TomT0m / talk page 18:19, 21 April 2024 (UTC)[reply]
I don't think properties can work like that. Just for an example. A dead person cannot be a spouse, but when a person dies we do not change statements like spouse to be deprecated. And when we query for a person's spouses, we usually do not want just the current spouse — Martin (MSGJ · talk) 18:31, 21 April 2024 (UTC)[reply]
Persons are different from bridges or administrative juridictions. With persons you get a whole lot of philosophical issues and I think it's best not to change the way we treat people, or animals maybe. For business, or objects, it's not the same issues at all and we can afford something like that, in my opinion, if it's convenient.
With people we typically don't use subclasses of human (Q5) items, it's also generally an exception. author  TomT0m / talk page 18:36, 21 April 2024 (UTC)[reply]
(and also, the you most likely do not want them is not really valid for persons, as we regularly query for deceased persons, it's kind of reversed.) author  TomT0m / talk page 18:55, 21 April 2024 (UTC)[reply]
wdt:P31 wd:Q12280; wdt:P5816 wd:Q56557159 would be better for old bridges : you query "bridge" +"ruined" for instance Bouzinac 💬●✒️●💛 19:49, 21 April 2024 (UTC)[reply]
I don't know who you are responding to but it kind of, I think, is a point in my favor. If most people querying bridges actually searches for bridges they can cross know, they might not want to know all the different ways there is to note that a bridge is no more usable, forever. If there is several clauses to add to the query to take into account all the different possibilities it complicates further the querying.
This is why I'd push the simple principle « if you query (not living organism) entities using wdt: and, say, instance of (P31) you should get entities that are not destroyed or permently out of service ». Minimum knowledge should be the rule for typical usage. author  TomT0m / talk page 19:59, 21 April 2024 (UTC)[reply]
For a building, destruction is rarely total, castles become ruins then archaeological sites, and buildings are reused, factories become museums. Its always going to be muddy.
I think the combination X and NOT destroyed is better than having "former_X" for every sort of physical object. And checking the UK, with 4000 odd bridges, only a half dozen are marked destroyed or former bridges, so its not a common problem. (Oh and we have New London Bridge (Q56739652), now in Arizona!) Vicarage (talk) 20:15, 21 April 2024 (UTC)[reply]
One problem of "former bridge" is that it's unclear whether the items are about a ruin of a bridge or just spot were there used to be bridge in the past. ChristianKl ❪✉❫ 23:09, 21 April 2024 (UTC)[reply]
You don't have to have a statement for every kind of physical objects, for 2 reasons :
  1. if no more appropriate value, you can use a generic "former object" item (high in the class tree) and use it as preferred value for instance of, this does the trick of not showing the result is simple queries
  2. if the instance of (P31) preferred statement change to something like "ruin", for example, this also works.
author  TomT0m / talk page 09:12, 22 April 2024 (UTC)[reply]
@TomT0m: If you look at former bridge (Q11486300) it has a sitelink to a Wikipedia article about abandoned bridges and a link to commons about abandoned bridges. Over a long time, this item was about ruins of bridges until Aiaiaiaiaia reused it in 2020 and gave it the label "former bridge". ChristianKl ❪✉❫ 13:41, 23 April 2024 (UTC)[reply]
I've thought about this some more and I still think they should be classified as bridges. Another example:
⟨ Battle of Hastings (Q83224)  View with Reasonator View with SQID ⟩ instance of (P31) View with SQID ⟨ battle (Q178561)  View with Reasonator View with SQID ⟩
. This happened in the past (they are not still fighting!) but it is definitely a battle. In the same way, a former bridge is still a bridge. And: , a hypothetical war is still a war and is classified as such. — Martin (MSGJ · talk) 14:04, 23 April 2024 (UTC)[reply]
@MSGJ: do you think there should be a diffence between fictional and hypothetical? ChristianKl ❪✉❫ 16:45, 23 April 2024 (UTC)[reply]
Yes I think there is clearly a difference between fictional and hypothetical. But the point is, they should all be classified as wars (or bridges, whatever) — Martin (MSGJ · talk) 14:39, 24 April 2024 (UTC)[reply]
Under the same reasoning that a "project of bridge" is not a bridge, it's a project that may be cancelled, a hypothetical future war is not a war and should not be classified as such. There are such items on Wikidata, project items such as Q809470 and they are link to the kind of items they project to create with has goal (P3712) View with SQID (although this property as used is a bit of a kludge, I see that we have , and "going to" is a very different things than "building" a cathedral.
An "hypothetical war" is not a war, it's a theory or a fantasy about the future. author  TomT0m / talk page 09:38, 25 April 2024 (UTC)[reply]
Wikidata operates under the open-world hypnothesis. If the status of an item changes, that change won't immediately show up in Wikidata. In the semantics in which Wikidata is founded a missing claim about a closure is just data incompleteness. If you think someone should have an expectation of all those items having information about being out of service, that would mean to say that we have wrong data in a lot of cases. ChristianKl ❪✉❫ 22:59, 21 April 2024 (UTC)[reply]
I don't think so, you just have to consider that "end date" might come anytime to an instance of statement, it's semantically totally equivalent to a non updated "conservation status" with no end date or point in time. The information is incomplete in both cases, exactly the same status for an open-world hypothesis.
Except if you gives a special status for instance of (P31) statement beside the OWI compared to over statements, I don't see the difference. Any statement with a "begin date" might be incomplete, any "timed" statement at least, and might even miss a "begin date" (this happens). This is just missing informations, all the time, for stuff that evolves in time. author  TomT0m / talk page 09:19, 22 April 2024 (UTC)[reply]

memory capacity (P2928)[edit]

So is this property about RAM capacity or storage capacity? It's not exactly being clear Trade (talk) 21:42, 22 April 2024 (UTC)[reply]

If you read the property proposal it's supposed to be a qualifier that's used with has part(s) (P527). It seems like some users have used it for different purposes which leads to bad data because sometimes people might mean RAM and otherwise storage. One solution would be to disallow the usage as main value and delete the uses that don't follow the data model that the property proposal suggests. ChristianKl ❪✉❫ 02:03, 23 April 2024 (UTC)[reply]
Would you be against renaming the property to something not deliberately vague?
If we want people to stop using the property to fr RAM capacity then we need a dedicated property that can be used instead Trade (talk) 16:01, 27 April 2024 (UTC)[reply]

Wikidata:Forum#Berlin,_w:Kategorie:Berlin_und_:n:Kategorie:Berlin[edit]

Hello, regarding Wikidata:Forum#Berlin,_w:Kategorie:Berlin_und_:n:Kategorie:Berlin:

In d:Q64 or d:Q1741 for example, the sitelinks to Wikinews link to Categories on Wikinews, instead of the related category objects d:Q4579913 or d:Q7214780.

Why are the Wikinews-Category-Sitelinks not connected to the Wikidata-Category-Objects? Is there a documentation for Wikinews-Sitelinks?

Also see

M2k~dewiki (talk) 11:42, 23 April 2024 (UTC)[reply]

https://www.wikidata.org/wiki/Wikidata:Wikinews/Sitelinks says "Summary: Wikinews categories (topics) correspond to Wikipedia articles and to similar items in other wikiprojects." and links to https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/09#Wikinews_linking ChristianKl ❪✉❫ 13:21, 23 April 2024 (UTC)[reply]
I am using an automatic translator in this discussion. I edit the Polish-language Wikinews. Recently there was a discussion (I couldn't find the link now) that most often Wikinews categories should not link to category-items. I am aiming for Wikinews-categories to be linked to topics on Wikidata.
Example: n:pl:Kategoria:Berlin
Marek Mazurkiewicz (talk) 21:41, 23 April 2024 (UTC)[reply]
Wikinews (mostly ru) wanted to be different, so some WN categories are linked to categories ando some to items. Its mess. JAn Dudík (talk) 18:57, 24 April 2024 (UTC)[reply]
Are you proposing to change the rule? Marek Mazurkiewicz (talk) 21:22, 26 April 2024 (UTC)[reply]
@Marek Mazurkiewicz I would agree with change, but now I have few time and energy to argue with them. JAn Dudík (talk) 06:02, 30 April 2024 (UTC)[reply]

Unmerge[edit]

@Alessot merged BankID (Q116980761) and bank ID (Q116980735) a year ago, but they refer to different concepts. Here are the links before the merge:

  • BankID - name of a system used in Sweden (bankid.com)
  • bank ID - electronic identification system implemented in several countries

Could someone help unmerge these? Thanks! Skalman (talk) 21:32, 23 April 2024 (UTC)[reply]

Should be fixed now.  – The preceding unsigned comment was added by Infrastruktur (talk • contribs).
Thank you very much! Skalman (talk) 17:01, 24 April 2024 (UTC)[reply]

Useless User items[edit]

User:Kaliru Created some items for his User Talk page, User page navbar, User page template. If I am right, These items are useless and should be deleted. It's allowed to make a deletion requests in this subject? Please anyone clarify me. Thank you Sriveenkat|talk/{PING ME} 09:06, 24 April 2024 (UTC)[reply]

Deletion request has been raised here. Dogfennydd (talk) 10:13, 24 April 2024 (UTC)[reply]
You're right. There shouldn't be Wikidata items for personal pages on other wikis. If you want to tell him, that would be great, since you speak tamil. You can tip him of this link as well: https://meta.wikimedia.org/wiki/Help:Interwiki_linking#Interlanguage_links . Most of the time people just write {{subst:Uw-notability}} ~~~~ on their user talk page. As well as requesting page deletion. Infrastruktur (talk) 12:38, 24 April 2024 (UTC)[reply]
It's allowed to make deletion requests for any subject, it's just that some deletion request won't lead to a deletion. ChristianKl ❪✉❫ 13:33, 24 April 2024 (UTC)[reply]

Galicia[edit]

The table is incorrect. Galicia is in the northwest not southwest The content should be changed to:

”Galicia é unha comunidade autónoma e antigo país no noroeste de península ibérica.” 77.27.100.234 21:04, 24 April 2024 (UTC)[reply]

It would help if you provided a link to the page where you have found a problem. There is not much we can do by guesswork. From Hill To Shore (talk) 21:43, 24 April 2024 (UTC)[reply]
The Galician-language label here does not contradict with the facts and Wikidata rules. It says just 'comunidade autónoma de España'. Probably not a Wikidata task. --Wolverène (talk) 09:14, 26 April 2024 (UTC)[reply]

Vote now to select members of the first U4C[edit]

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through May 9, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

On behalf of the UCoC project team,

RamzyM (WMF) 20:19, 25 April 2024 (UTC)[reply]

I took my time to read about every member and cast votes for each and I encourage everyone to do the same. ChristianKl ❪✉❫ 11:22, 26 April 2024 (UTC)[reply]

QuickStatements[edit]

I'm trying to figure out how to use QuickStatements to replace a value, and having a lot of trouble. For a trial run, I'm trying to replace an inaccurate coordinate value at Q21942340. Here's my input:

-Q21942340|P625|30°9'55"S, 153°14'5"E|S248|Geographic Names Server|S577|11 June 2018|S2326|11382401

Q21942340|P625|30°9'39.3804"S 153°13'37.182"°E|S854|https://maps.six.nsw.gov.au/

All I get is error messages which don't even say what the problem is. I tried putting all strings in quotes, but that didn't help. Please, what is wrong with my input? Cremastra (talk) 21:37, 25 April 2024 (UTC)[reply]

QuickStatements is very particular about how its input is formatted, read more about it in its manual (example: Q3669835 TAB P625 TAB @43.26193/10.92708). Interestingly for coordinates it will only do exact matching, even if anything that rounds to the same number with four decimal places should be considered good enough for a match assuming the precision is 4 decimal places or better [1]. It might be simpler to ask it to remove the statement by giving it the statement ID instead. Infrastruktur (talk) 11:56, 26 April 2024 (UTC)[reply]
Thanks, but I fixed it manually and it took about thirty seconds. :) Cremastra (talk) 20:04, 26 April 2024 (UTC)[reply]

Oversight candidacy[edit]

As per policy, candidacies for oversight here on Wikidata have to be linked to the project chat and administrators' noticeboard; thus, doing so for transparency: Wikidata:Requests for permissions/Oversight. EPIC (talk) 21:41, 25 April 2024 (UTC)[reply]

Sitelink for voy:zh:白河[edit]

Hi, this Chinese Wikivoyage page is a disambiguation page, and we have Bai He (Q9164254) and Shirakawa (Q255636), both are Wikimedia disambiguation page (Q4167410) item but with different label. Q9164254 is for Chinese Mandarin pronunciation and Q255636 should be Japanese pronunciation. But for w:zh:白河 and voy:zh:白河, they are mixture of Bai He (Q9164254) and Shirakawa (Q255636) (and maybe White River (Q348739)), will create a new item for zhwiki and zhwikivoyage one be good idea?--S8321414 (talk) 07:01, 26 April 2024 (UTC)[reply]

edit limit[edit]

Hello, I use several semi-automatic tools for editing and I regularly run into the edits per second limit. Are my only two solutions are to request administrator or bot status? For the first, I doubt that it would be granted to me for this request alone (there would also be the one for IP blocking exemption and flood flag, but I already have that). For the second, I don't want to create a new account to contribute. Simon Villeneuve (talk) 13:20, 26 April 2024 (UTC)[reply]

i believe those are the only options. BrokenSegue (talk) 15:34, 26 April 2024 (UTC)[reply]
No, neither of those are your options. The limit is there for a reason.
Administrators are in fact not rate limited since some admin functions would not work properly otherwise, but they should not run large automated batches beyond 90 edits per minute using the admin account (a rather informal agreement). Bots and non-admin users are limited to 90 edits per minute in order to avoid capacity issues. —MisterSynergy (talk) 17:35, 26 April 2024 (UTC)[reply]
@Simon Villeneuve: Some edit tools are a bit inefficient - for example QuickStatements can use more edits than necessary to make changes. So if you are doing that many edits you may want to create a custom tool that does a better job of consolidating several edits on an item into one, if that's an issue. ArthurPSmith (talk) 17:52, 26 April 2024 (UTC)[reply]
Nice one. I've noticed Wikibase-CLI tends to be overall faster on edits in general (noticeably so) even though I don't think it attempts to smoosh together edits either. Wikibase-CLI will allow you to create entire items in one go however which is a huge win if you do new item creations. It also pairs nicely with the jq tool for many tasks. Infrastruktur (talk) 19:39, 26 April 2024 (UTC)[reply]
the problem occur when I launch many tabs of authordisambiguator at once, as I've said to you here. Now, I understand here (and I should have known it) that we must respect the limit, whatever your status. Simon Villeneuve (talk) 19:56, 26 April 2024 (UTC)[reply]
What's your problem with seeking bot approval for this task? ChristianKl ❪✉❫ 21:43, 29 April 2024 (UTC)[reply]

Harvesting coordinates[edit]

Is there a tool that could collect coordinates from wikiarticles coordinates templates or infobox into coordinate location (P625) wikidata ? Bouzinac 💬●✒️●💛 19:49, 26 April 2024 (UTC)[reply]

I'm not sure about tools, but far too often we have to revert overeager editors who import co-ordinates for human (Q5) items when they should be instead imported to the connected item at place of burial (P119). You will need to cleanse any gathered data to filter out co-ordinates that should be used on the connected location rather than directly imported to the Wikidata item related to the article. Any tool that makes the import directly must be used with caution. From Hill To Shore (talk) 00:31, 27 April 2024 (UTC)[reply]
It was about railways stations, I believe the coordinates in the article would be the very coordinates of the station. But yes, massive import is cautionable for some other data, such as closures dates (it could have been a simple close date for works and then reopening for instance). They can be done with "Harvest templates" [which does not support coordinates].Bouzinac 💬●✒️●💛 06:37, 27 April 2024 (UTC)[reply]
Pywikibot's coordinate_import.py. --Matěj Suchánek (talk) 10:17, 27 April 2024 (UTC)[reply]
Thanks Bouzinac 💬●✒️●💛 13:47, 27 April 2024 (UTC)[reply]

Hello everyone I would like to be welcomed first of all[edit]

all in good I came I peace ❤🤞 41.114.141.166 23:43, 26 April 2024 (UTC)[reply]

If you want to be a part of the community, registering an account is a good first step. ChristianKl ❪✉❫ 01:13, 27 April 2024 (UTC)[reply]

Help: Image property not showing[edit]

Hey guys, I have a question to you about images. As i understand, when i create a new image property for an entry, and assign a Wikipedia Commons image to it, the picture is supposed to appear, like it does on this page: https://www.wikidata.org/wiki/Q623099 However, on our page, you can't see the picture, only the image id: https://itidata.abtk.hu/wiki/Item:Q12650 Is this an error in the settings? What am i doing wrong? Thanks. Palapparon (talk) 11:47, 27 April 2024 (UTC)[reply]

I would expect that this isn't done by Wikibase by default but by some extension. It's not really a Wikidata question. ChristianKl ❪✉❫ 23:45, 28 April 2024 (UTC)[reply]
So you are saying i don't have the correct extension installed? 2001:4C4C:182E:2B00:B1AB:69A2:CA4E:7A51 09:47, 29 April 2024 (UTC)[reply]
Your coordinate location is also not showing a map — Martin (MSGJ · talk) 10:10, 29 April 2024 (UTC)[reply]

idrize supernatural[edit]

i an musican Idris shittu (talk) 15:04, 27 April 2024 (UTC)[reply]

Good for you. However, we recommend that editors don't create items about themselves. If you are notable, another editor will create an item about you. I expect Q125638413 will be deleted soon. You will be better off creating a profile on social media sites rather than Wikidata. From Hill To Shore (talk) 15:13, 27 April 2024 (UTC)[reply]

how do i add fulcrum or University of Michigan Press doi on Settlers of Unassigned Lands (Q60186754)[edit]

i want to add https://doi.org/10.3998/tfcp.13240728.0001.001 on Settlers of Unassigned Lands (Q60186754). there seems to be no identifier for fulcrum or michigan press. how do i add? Id,Ik'+(&sZP4^m (talk) 15:31, 27 April 2024 (UTC)[reply]

The vdo what I found, want to see more. 120.88.155.250 16:16, 27 April 2024 (UTC)[reply]

i'm not sure i understand. what identifier? just a url? BrokenSegue (talk) 03:50, 29 April 2024 (UTC)[reply]

Update Property url[edit]

Hello, I need your technical help
I'm trying to update the MarketScreener business leaders ID (P7845) property because the url has changed.
Old formatter URL : https://www.marketscreener.com/business-leaders/$1/biography/
New formatter URL : https://www.marketscreener.com/insider/$1
When I update the file, the new url is not taken into account.
How do I go about it?
Thanks 🙂
WKPDA3 (talk) WKPDA3 (talk) 17:49, 28 April 2024 (UTC)[reply]

@WKPDA3: i updated it for you. it takes a few hours for the update to take effect. BrokenSegue (talk) 19:07, 28 April 2024 (UTC)[reply]

Vexing technical problem[edit]

I went to Special:Watchlist, saw an issue with Template:Watchlist summary/PP where "Transportation" was evidently invalid, so I removed it. Same problem at Wikidata:Property proposal. No clue how to resolve it and Wikidata:Property proposal/Transportation. Can someone help dumb old me? —Justin (koavf)❤T☮C☺M☯ 07:29, 29 April 2024 (UTC)[reply]

It's because User:DeltaBot removed the parameter. I think it would be better to leave it as Transportation = 0. Let's ping the bot operator User:Pasleim — Martin (MSGJ · talk) 10:14, 29 April 2024 (UTC)[reply]
Did not realise that Pasleim is inactive. Pinging MisterSynergy instead — Martin (MSGJ · talk) 21:37, 29 April 2024 (UTC)[reply]
Fixed via Topic:Y3thcovjyke1fkgj —MisterSynergy (talk) 21:52, 29 April 2024 (UTC)[reply]

Wikidata weekly summary #625[edit]

Here's your quick overview of what has been happening around Wikidata over the last week.

Events

  • Nubuke Wikidata Workshop - Sat. 27 April 1100 - 1400 GMT at the Nubuke Foundation, Lome Close Accra, Ghana.
  • There's still time for nominating your favorite tool in the Coolest Tool Award! To nominate, follow this link. Deadline: 10 May 2024 - winners unveiled at Wikimania 2024
  • Coordinate Me 2024 - an international Wikidata competition around content with geodata. The competition starts on 1 May 2024 and ends on 31 May 2024.
  • Wikimedia Hackathon 2024 is just around the corner, taking place in Tallinn, Estonia from 02 - 06 May. We hope there will be lots of Wikidata hacking projects worked on.

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

Weekly Tasks

Zvuk artist ID[edit]

Please, add 784929 to Q292265 as a property 10524. I cannot because item is locked. --5.43.76.87; 18.10, 2024-04-29 (UTC)

✓ Done — Martin (MSGJ · talk) 21:38, 29 April 2024 (UTC)[reply]

New Schema Validation Tool UI[edit]

Hello everyone, As part of my thesis project I've made a new UI mode for the Schema Validator used by Wikidata. The new UI represents validation reports as a table rather than a very long string, and replaces most links with hyperlinks with some of the text behind them. I just started hosting it yesterday on https://shex-validator.toolforge.org/packages/shex-webapp/doc/shex-simple-improved.html. I'm also looking for people willing to participate in evaluating the user experience and the ease of use of this new UI in a roughly 1 hour interview sometime in may. For more information, check out my user page. If you want to registed for the evaluation interviews, you can do so at https://datumprikker.nl/event/index/fuwv62b5tatqq4vr. M.alten.tue (talk) 11:00, 30 April 2024 (UTC)[reply]

Pages that mis-identify[edit]

I'm new to the community and processing WikiData locally. One utility index I built goes from enwiki titles to WikiData items and back. Running this script over all of WikiData revealed 40 "Key conflicts": two WikiData pages that link to the same Wikipedia article.

One really odd type of key conflict is posed by pages like https://www.wikidata.org/wiki/Special:EntityData/Q20203111.json which claims to be Q118874608; a perfect duplicate.

Can anyone shed light on this? The full list: https://pastebin.com/MunHZjWP AdamVcoding (talk) 16:23, 30 April 2024 (UTC)[reply]

Nothing misindentifies here. The situation is easily understood by looking at the actual items in the Wikidata UI and looking at the item history.
Sitelinks sometimes get moved from one page to another and if your data is out-of-sync this means you won't end up at the same page in every case.
Q20203111 is a redirect and behaves like a redirect is supposed to act. ChristianKl ❪✉❫ 17:04, 30 April 2024 (UTC)[reply]
Thanks for elaborating Christian! Is there a mapping of redirects available?
In other words, where does the information (including the redirect notice) at https://www.wikidata.org/w/index.php?title=Q20203111&action=info live?
I made the assumption my version coincided with the live version on this weird subset, but mine still lists `"id": "Q20203111"`.
Nonetheless, I'll (locally) merge the pages with the same enwiki links like Q703702 (since the enwiki link has been removed) and Q125399268. AdamVcoding (talk) 17:57, 30 April 2024 (UTC)[reply]
Did you read the page? It seems to me like the information on it is pretty straightforward.
As I said above, sometimes the claim is just moved from one page to another. While merging a redirect with the page toward which it's pointing makes sense it does not make sense when the link moves from item A to item B. ChristianKl ❪✉❫ 23:43, 1 May 2024 (UTC)[reply]

Wikidata disambiguation pages[edit]

We currently create Wikimedia disambiguation pages if a disambiguation page exists in Wikipedia. Do we ever create a Wikimedia disambiguation page at Wikidata even if none exists at Wikipedia? We have more people needing diasambiguation at Wikidata since our inclusion criteria is more generous. See for example: Jeremiah Creedon (Q125707529). Is there anything that can be added to help someone looking for the correct one to easily see which one is the one they are looking for without clicking on each link or hovering the cursor? RAN (talk) 18:56, 30 April 2024 (UTC)[reply]

The description field can be used for disambiguation on Wikidata. I believe that disambiguation items on Wikidata should only exist if there is a corresponding disambiguation page on one of the other Mediawiki projects (see guidelines). Dogfennydd (talk) 21:51, 30 April 2024 (UTC)[reply]

Main_Page: Current highlights[edit]

The "Current highlights" on the main page are apparently broken? The items visible now that are the same as a week (or more) ago. RVA2869 (talk) 07:51, 1 May 2024 (UTC)[reply]

@MisterSynergy: who i believe runs the bot that does the updates. BrokenSegue (talk) 15:21, 1 May 2024 (UTC)[reply]
Thanks, I am already aware. Something went wrong with my bot and shared pywikibot on Toolforge on April 22nd, but it does not seem obvious how to fix it. —MisterSynergy (talk) 15:23, 1 May 2024 (UTC)[reply]
Found something, now it's back —MisterSynergy (talk) 18:48, 1 May 2024 (UTC)[reply]
Thanks @MisterSynergy
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 21:45, 1 May 2024 (UTC)[reply]

Properties on Wikimedia list article (Q13406463) items[edit]

Is there a WikiProject guideline or past discussion that details what properties should be used with these items? There have been many recent batches that added country (P17) to thousands of list items (example: https://www.wikidata.org/w/index.php?title=Q115767416&diff=2141785849&oldid=1986343405), and has part(s) (P527) is often used too. My understanding is that instance of (P31), is a list of (P360) and category related to list (P1754) are pretty much the only ones that should be used? Xezbeth (talk) 09:18, 1 May 2024 (UTC)[reply]

I think P361 and P527 are correct in lists such as list of aircraft beginning with M (Q6605098) where a list is on multiple pages and the parts are sections of a list, or a list is composed of multiple lists; not sure about Gallery of the Royal Saxon milestones (Q1491902) where the parts are members of the list. Peter James (talk) 12:37, 1 May 2024 (UTC)[reply]
Generally, Wikidata is quite open with different properties being used and I can't think of an example where I would say that only a few properties can be used. Wikimedia list article (Q13406463) itself does have a few properties for this type (P1963) statements which suggests that country (P17) is quite proper. ChristianKl ❪✉❫ 23:50, 1 May 2024 (UTC)[reply]

Jack Hall/Sam Hall Q6112885 Q2216488[edit]

In 2022, the enwp article Jack Hall (song) was moved to Jack Hall (highwayman), and the scope of the article changed from the song to the person it was about, as there was already an article about the song at Sam Hall (song) (the title of the song was originally "Jack Hall", but "Sam Hall" is now more frequent, and its common name; it's considered the same song by secondary sources, and has the same Roud Index folk song identifier).

But the Wikidata item Jack Hall (Q6112885) hasn't been changed, and so is still about the song. I was considering removing the enwp article on that item (and the link to Hall, John (d.17Dec1707) (DNB00) (Q19020924)), and merging it into Sam Hall (Q2216488), before creating a new item for the person, but wasn't sure what to do with the Freebase ID, and thought I'd check here first. Yodin (talk) 15:48, 1 May 2024 (UTC)[reply]

Need to merge[edit]

Please merge Q123160974 into Q503592. According to Wikipedia links, both refer to the same topic. Massol1360 (talk) 17:21, 1 May 2024 (UTC)[reply]

It looks like one is about the brand and one is about the (defunct) company that used the brand, so I think they should probably stay separate. Perhaps the article links should be rationalised, though. M2Ys4U (talk) 17:44, 1 May 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2142373464"