Wikidata:Contact the development team

Contact the development team

Wikidata development is ongoing. You can leave notes for the development team here or report bugs on Phabricator. (See the list of open bugs on Phabricator.)

If you have questions or bug reports related to the Wikidata Query Service or search on Wikidata, please add them to this page. If you have suggestions or requests regarding the entity suggester ranking, please see this page.

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2021/03.

Development plan Usability and usefulness Status updates Development input Contact the development team


DaduEdit

You probably noticed that project chat keeps getting spam regularly [1]. Would you do something about it? Thanks --- Jura 09:11, 28 January 2021 (UTC)

Perhaps the community could consider adding some more filter controls to curb some of these behaviors. Pinging Matěj Suchánek. -Mohammed Sadat (WMDE) (talk) 17:42, 29 January 2021 (UTC)
Sorry, but I currently cannot catch up. Tell other admins at WD:AN whether spam blacklist or edit filters can be set up. --Matěj Suchánek (talk) 11:30, 31 January 2021 (UTC)
  • We actually tried but that didn't quite work out. As we have specialist staff to deal with IT problems, maybe they could look into it. --- Jura 12:32, 31 January 2021 (UTC)
Hello Jura! The spam-blacklist or edit filters are currently the most effective tools that we have, and the Admins know better how to use them. -Mohammed Sadat (WMDE) (talk) 13:06, 1 February 2021 (UTC)
Can you email them and explain them how that should be using it effectively? --- Jura 10:09, 22 February 2021 (UTC)

Possible watchlist "hide" optionsEdit

There are two types of edits I'd like to be able to hide from my watchlist in Preferences: 1) Edits to labels, aliases, descriptions, and links to sister project pages in languages I don't speak, and 2) Edits that simply add a Wikidata property for an identifier (Q19847637). These two types of edits comprise the majority of my watchlist, but are not ones I'm interested in tracking. I imagine the ability to hide them would be appreciated by many editors. Thoughts? Swpb (talk) 17:46, 2 February 2021 (UTC)

This is to some extent possible using User:Yair rand/DiffLists.js via Special:MyPage/common.js. However, the entire watchlist and also some other special pages are styled differently and use Javascript excessively, which some editors do not like at all. —MisterSynergy (talk) 18:12, 2 February 2021 (UTC)
@Swpb: Thanks for bringing this here. There are open tickets that already describe this issue which I'm going to link here. -Mohammed Sadat (WMDE) (talk) 18:27, 12 February 2021 (UTC)

HTTPError: HTTP Error 403: ForbiddenEdit

Hello,

I am coding an ontology diagram generator in python using SPARQLWrapper. Yesterday, my code worked fine just having some Too Many Requests errors. But today I receive the error HTTP Error 403: Forbidden almost in every query I throw. You can see my code in:

https://github.com/AlexInigo94/TFM_Alejandro_Inigo/blob/main/Generador_de_Diagramas_Ontologicos_a_partir_de_un_ID.ipynb

As you can see it worked fine yesterday but not today. What is the problem ?

Alejandro

I’m not sure if it’s the cause of your error, but you should set a proper User-Agent (pass agent="..." into the SPARQLWrapper constructor). Requests without a User-Agent header, or with a standard one (e.g. the default user agent of the Python requests library), may be blocked. --Lucas Werkmeister (WMDE) (talk) 09:15, 8 February 2021 (UTC)

Qualifier constraint doesn't seem to workEdit

This constraint: one-of qualifier value property constraint (Q52712340) is used on flag bearer (P3022), but it doesn't seem to actually work anymore. For example, the usage on this page doesn't give any error, despite it being a violation of the rule as far as I can tell (the "of" qualifier on this property should only have the values opening ceremony (Q3010369) or closing ceremony (Q13454063)) https://www.wikidata.org/wiki/Q18072557#P3022

I tried adding it for the "platform" constraint on Steam application ID (P1733) because games available on Steam only support Windows, macOS, and Linux, but it doesn't trigger any constraint violation warnings on items that use other platforms as a qualifier for the property. (e.g. https://www.wikidata.org/wiki/Q19360224#P1733, the usage of SteamOS as a value for the platform qualifier should be a constraint violation)

You can see that, at one point, there were a lot of violations caught by this constraint on flag bearer (P3022) (https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Complex_constraint_violations/P3022&diff=1288979675&oldid=1288482881&diffmode=visual), but at some point they seemingly started erroring?

Is this a bug or is this constraint not actually properly built? I'm not super familiar with how the constraint definitions work so I apologize if I'm misunderstanding anything.

Thanks :) -Nicereddy (talk) 01:42, 11 February 2021 (UTC)

@Nicereddy: In the WikibaseQualityConstraints extension, which provides the live constraint reports, we’ve never supported this constraint type. (If you want, you can create a Phabricator task for adding support for it – I don’t see an existing task below [Tracking] Request for new constraint types.) The diff you linked is on one of the periodically-updated constraint report pages, which are maintained by bots; I can’t say much about which constraint types they do or don’t support. --Lucas Werkmeister (WMDE) (talk) 10:13, 11 February 2021 (UTC)
@Lucas Werkmeister (WMDE): Thanks for the explanation! I've created a ticket for it and added it to the subtasks on the one you've linked. Nicereddy (talk) 23:59, 11 February 2021 (UTC)

language of https://wikisource.org/ : currently "en" ( phab:T138332)Edit

At Wikidata:Project_chat#Sitelinks_to_Incubator, there was a short discussion about https://wikisource.org/ among others.

It appears that the language of sitelinks is currently "en" (see the query there). It's applied the schema:name value and added as value schema:inLanguage .

Given that https://wikisource.org/ hosts pages in a series of languages, I don't think the language can be determined in advance. Accordingly, I think it should be "und" (code for "undetermined language").

If individual pages at https://wikisource.org/ would include multiple languages at the same time, the code would be "mul". It's true the global code for https://wikisource.org/ would be "mul", but that doesn't apply to individual sitelinks.

Given the above, the patch currently in the pipeline (phab:T138332) should be updated to use "und". I don't think the question about the language code to use was discussed somewhere (if yes, please provide a link). --- Jura 10:16, 11 February 2021 (UTC)

@Jarekt, matej_suchanek: who participated in some of the discussions around https://wikisource.org/ . --- Jura 10:16, 11 February 2021 (UTC)


BadgesEdit

A simple way to do that would to include the language as a badge, probably by adding (e.g.) Mingrelian (Q13359) directly as badge. The languages on the above list would need to be made available.
Bots that maintain other badges could added them when needed. --- Jura 13:22, 11 February 2021 (UTC)
  • Instead of
?article schema:isPartOf <https://wikisource.org/> ; schema:inLanguage ?lang .
the language code would be at:
?article schema:isPartOf <https://wikisource.org/> ; wikibase:badge/wdt:P424 ?lang .
--- Jura 21:33, 11 February 2021 (UTC)

@Lydia Pintscher (WMDE): do you need more info on the two above? --- Jura 08:30, 19 February 2021 (UTC)

The default content language as I understand it for wikisource.org is English. Until that is changed I don't think we should do something different. Moving that information to badges is an option but to be honest too much disruption for little gain as far as I can see. It'd mean creating a lot of new badges of questionable use and re-users would need to look at two different places for the same type of information. That doesn't seem right. --Lydia Pintscher (WMDE) (talk) 14:32, 20 February 2021 (UTC)
@Lydia Pintscher (WMDE): I hope we agree that being able to query the language of page on a sitelink is a feature that is needed, both for contributors and re-users.
I suppose one could use content language of wikisource.org. This can be set on a page level in page properties.
If not, where else would we be querying the language instead? Especially, as you seem to prefer that a single feature gives the info? --- Jura 14:49, 20 February 2021 (UTC)
In an ideal world I agree with you that each multilingual Wikisource sitelink should have the language code of the article itself. I've talked to a few more people and given their lack of enthusiasm for the problem and the effort that'd be required to do this it doesn't seem worth the effort at this point. We have more pressing fish to fry unfortunately :( --Lydia Pintscher (WMDE) (talk) 17:32, 22 February 2021 (UTC)
@Lydia Pintscher (WMDE): Agree that the ideal solution probably requires too much development resources. Syncing with page properties might not be simple.
Accordingly, it might be worth having a second look at the proposal(s) above.
- The use of badges seems fit for the purpose and could easily be maintained by bot as most other badges. Further, adding badges is a task that could probably be handled by relatively junior members of your development team, if not directly by the community liaison(s). The solution could also work for the few cases where we have permanent duplicated item (P2959) (the old story of some wikis having the same page in several languages).
- As far as the default language code for https://wikisource.org/ goes, I'm still not convinced that using "en" is a good idea if the wiki actually uses page properties to override it. "en" might just be the default of the interface (which is another question). Also, we would have two Wikisource editions with the same language code. Where was "en" determined? If it wasn't actively done, leaving it undetermined ("und") seems preferable. Afterall sushi preparation is fairly delicate and frying it might be safer.
--- Jura 08:33, 23 February 2021 (UTC)
  • @Lydia Pintscher (WMDE): It's seems that there isn't much interest in the question. How shall we fix this? In the way suggested above or in the way announced by Mohammed Sadat? At least we seem to agree that it shouldn't be in "en", as Sourceswiki has works in >150 languages that would appear as being being in "en". --- Jura 10:04, 26 February 2021 (UTC)
    • Hey :) to be honest I think we'll just leave it as is until there is enough demand to justify spending time on it. Everyone else I've asked so far was "whatever", which to me means I should be spending the team's time on other things. --Lydia Pintscher (WMDE) (talk) 17:32, 28 February 2021 (UTC)
      • @Lydia Pintscher (WMDE): Who did you ask? I don't see any communication with either community. If you just talk to WMDE staff, this isn't really development for the Wikidata community. It would be good to at least try to implement it as announced to the community. Clearly, the implementation at Sourceswiki is somewhat below community expectations and needs finishing. Interwikis that don't appear as interwikis, how could that even happen? --- Jura 13:09, 1 March 2021 (UTC)

Lack of whitespace hampers find-on-page in Wikidata itemsEdit

The Edit > Find command in the current Safari/macOS, and the Find on Page in Safari/ipadOS, both use “Begins with” matching to find text strings on the page. If I search, for example, on the page universe (Q1) for the third value name “studied by,” nothing is found. But if I search for “by”, then I find the end of the string. If I search for “valuestudied by”, then I find the end of the “+ add value” link in the previous statement run together with the heading of the “studied by” statement.

Looking at the source code, I see that the only white space between the strings is some UNIX linefeed characters, contained in HTML block elements but not in inline elements. The addition of some real whitespace in the templates where it wouldn’t interfere with the page layout would probably correct this.

As a workaround, I can switch to “Contains” matching on the Mac (but not on the iOS device). Most editors probably aren’t aware this option exists.

This inconsistent findability of items on the page is confusing and hampers the usability of editing interface, especially in items with a lot of statements. It makes it difficult or impossible for editors to find statements or verify their existence or absence on the page, and could lead to the creation of duplicate statements. —Michael Z. 18:33, 15 February 2021 (UTC)

I've just tried find with Safari/MacOS, and indeed a) the search mode was 'Begins with' and b) the 'studied by' value was found  Y. Can't at the moment speak for iOS. But I would raise a concern about amending wikidata to make good what seems to be a deficiency in the browser search, presuming the issue does exist in iOS. --Tagishsimon (talk) 22:09, 15 February 2021 (UTC)
Hm, then I will try turning off gadgets and see if it’s one of them. —Michael Z. 01:59, 16 February 2021 (UTC)
@Mzajac: Do you have updates about what happened when you turned off gadgets? -Mohammed Sadat (WMDE) (talk) 15:20, 25 February 2021 (UTC)

WQS : display a scrollbar when long text queryEdit

Hello would it be possible to show a scrollbar inside the query window, so that the blue arrow, which is needed to launch the query, would always be visible on the screen when arriving into a long-text with many lines query ? --Bouzinac💬✒️💛 20:02, 16 February 2021 (UTC)

@Bouzinac: Thanks for your message. I’ve created a ticket for this task so we can work on it. For long-text queries the scroll bar is always available in desktop view (for different browsers that I tried with) but not for mobile. Is this the same experience that you have? -Mohammed Sadat (WMDE) (talk) 15:24, 25 February 2021 (UTC)
Hello, the problem is not the scrollbar in itself, but that the blue arrow is not immediately visible when arriving on the page, eg fr:Aéroport de Vágar#En_graphique , hit the blue link, you arrive in the query service whithin a long text query. (in the shoes for a newbie : start puzzle and wonder, whoah, what do I do with that query?)--Bouzinac💬✒️💛 15:32, 25 February 2021 (UTC)
@Bouzinac: if the link’s target audience includes users who aren’t familiar with the query service, and you only want them to click the “run query” button, wouldn’t it be better to directly link to embed.html? --Lucas Werkmeister (WMDE) (talk) 17:29, 25 February 2021 (UTC)
Hi there@Lucas Werkmeister (WMDE):, could you please developp the embed.html stuff? Might be worth asking the {{Graph:Lines}} to be showing directly the results instead of the SPARQL code, which could be off-putting for newbies. Pinging @Yurik:, if he could amend the graph line template in that way. --Bouzinac💬✒️💛 18:25, 25 February 2021 (UTC)

Wikidata and ERCOTEdit

Does Wikidata also rely on ERCOT for its secondary datacenter ( CyrusOne in Carrollton, Texas)? --- Jura 10:46, 22 February 2021 (UTC)

Hello Jura. All the datacenter administration is managed by our colleagues from WMF and we trust them to handle it well. -Mohammed Sadat (WMDE) (talk) 16:42, 22 February 2021 (UTC)
Can you relay with however does it and check? --- Jura 20:09, 22 February 2021 (UTC)

New 'Potential issue' message when using CORE id propertyEdit

I hope this is the right place to post my query: I have been adding some institutional theses to Wikidata, and including CORE identifiers. This has so far worked smoothly, but today I noted that I'm now seeing a 'potential issue' message to say 'Entities using the CORE ID property should be instances of scholarly article (or of a subclass of it), but xxx currently isn't.' See https://www.wikidata.org/wiki/Q98702656 as an example. CORE https://core.ac.uk/ includes theses, so could entities using the CORE ID property be extended to include instances of doctoral thesis? HelsKRW (talk) 13:01, 22 February 2021 (UTC)

Hi HelsKRW, what you are seeing is a constraint violation. The rules for them are defined on the Property, so in this case Property:P6409. You can see the exact rule that's causing your violation here: Property:P6409#P6409$6bf20208-44e1-8982-7d23-80ff8ebd99c5. Since this is an editorial decision it is best to bring it up on the discussion page of that Property. --Lydia Pintscher (WMDE) (talk) 17:36, 22 February 2021 (UTC)

Error message trying to update info in Taxon Name (P225)Edit

If you attempt to add data to an already existing taxon name statement which is empty, for instance add the year of taxon name qualifier (P574) as well as a reference, upon attempting to publish, you get an error message as follows: 'Warning: The value for taxon name (P225) in this (or any) item shouldn't be changed (except for spelling corrections). If a taxonomic paper or book introduces a name change, create a new item for the new name (if needed) and add a statement with taxon synonym (P1420) to that item.'

Nothing in that edit is attempting to change the name, it is simply adding additional data to a name which is unchanged. If you hit publish a 2nd time it saves, if you enter and publish the changes separately, no error, just something causes the error if you try to publish both at the same time. CanadianCodhead (talk) 15:19, 22 February 2021 (UTC)

It looks like you are running into an abuse filter. Those are set up by the editors. I hope one of them reads this and can look into it for you. --Lydia Pintscher (WMDE) (talk) 17:36, 28 February 2021 (UTC)

Please stop page banner field on Wikidata from overriding edits in individual WikivoyagesEdit

I don't know if I'm starting this thread in the right place, but you can see discussion of this issue at voy:Talk:San Gimignano#Banner, which I would summarize as follows:

We tried to change the pagebanner for voy:San Gimignano locally, and got these problematic results (we were considering banner options A-D):

This is superweird. I applied option D — File:Italy-0996 (5198642354) (cropped).jpg — but what appears is the cityscape I proposed at the beginning — File:Wv San Gimignano banner2.jpg. I can't figure out why that is happening. Ground Zero (talk) 13:07, 20 February 2021 (UTC)
Solved it. In the Wikidata page (desktop version), there is an entry for Wikivoyage banner, which seems to override anything we put directly on the page. This applies the banner across various language versions of Wikivoyage, but it raises issues, I think, in that (a) I doubt many Wikivoyagers are aware of this, and (b) it is not clear where discussion would take place about changing a banner. (This change was applied across all Wikivoyages except Italian and Hebrew, which still have banner 2, and German, which does not have a banner.) Ground Zero (talk) 14:59, 22 February 2021 (UTC)
Yeah, that's not good at all. We can't have Wikidata overriding the choices of individual Wikivoyages. What should we do about that, start a thread in the equivalent of the pub in Wikidata? Ikan Kekek (talk) 20:38, 22 February 2021 (UTC)

tldr version: The "banner" field on Wikidata is overriding the choices of individual Wikivoyages without their consent. Can we please stop that from happening and let individual Wikivoyages make their own choices locally? Ikan Kekek (talk) 17:44, 23 February 2021 (UTC)

@Ikan Kekek, Ground Zero: I think the problem is that the pagebanner template at voy:San Gimignano was formatted incorrectly. Seems to be fixed now. Please let me know if I'm mistaken. Mx. Granger (talk) 20:36, 23 February 2021 (UTC)
If that's all it was, please disregard this thread. Thanks, Mx. Granger. Ikan Kekek (talk) 20:56, 23 February 2021 (UTC)

Search is very intolerant of mis-spellingsEdit

I'm sure there may be an open ticket on this already, but it does seem to me that search is very very intolerant of mis-spellings.

For example, search for "p:constraint" and there are lots of hits for properties relating to constraints. Mis-spell it even only very slightly, eg search "p:constriant" and there is nothing.

For something like looking for properties this is just an annoyance. But where this can get really damaging is when people are looking for items -- because if they don't find what they're searching for (because we have a slight variant spelling) then they may start a new item -- and then we get into the nightmare of there being a duplicate on the system, and all the avoidable manual work that that leads to, having to try to find and chase down such items and fix them.

It would be really good to know that there was a plan for looking into this. Jheald (talk) 11:17, 24 February 2021 (UTC)

@Jheald: There's no ticket directly related to this yet. We'll run it with the WMF's Search Platform team (they are responsible for the various search features) in the coming week and let you know what plans they may have for looking into this. -Mohammed Sadat (WMDE) (talk) 18:59, 25 February 2021 (UTC)