Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to navigation Jump to search

Contact the development team

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

Regarding the accounts of the Wikidata development team, we have decided on the following rules:

  • Wikidata developers can have clearly marked staff accounts (in the form "Fullname (WMDE)"), and these can receive admin and bureaucrat rights.
  • These staff accounts should be used only for development, testing, spam-fighting, and emergencies.
  • The private accounts of staff members do not get admin and bureaucrat rights by default. If staff members desire admin and bureaucrat rights for their private accounts, those should be gained going through the processes developed by the community.
  • Every staff member is free to use their private account just as everyone else, obviously. Especially if they want to work on content in Wikidata, this is the account they should be using, not their staff account.
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 2019/04.

Project
chat

Lexicographical
data

Administrators'
noticeboard

Development
team

Translators'
noticeboard

Request
a query

Requests
for deletions

Requests
for comment

Bot
requests

Requests
for permissions

Property
proposal

Properties
for deletion

Partnerships
and imports

Interwiki
conflicts

Bureaucrats'
noticeboard

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


Sitelink to local private mediawiki[edit]

Dear Devs,
One question about my private Wikibase installation.

I'm up to using Sitelinks, pointing to my local Mediawiki installation, which has $wgGroupPermissions false for all (i.e. private wiki). I added my site to the Sites table, "Wikipedia" group, via maintenance/exportSites.php and importSites.php. This works, and my new Site is found at the autocomplete, when I Edit the sitelinks in one Item.

Unfortunately, the problem is that no page is found.

By checking the logs, I see that actually, a call is made to the api.php?search="Page" and a "readapidenied" is returned.

In fact, if I turn the $wgGroupPermissions to True in LocalSettings.php, it all works, I get the pages found.

However, I need my wiki to stay private.

What would be possible options? Could I activate API:Login somehow for these calls? Any other way out?

Many thanks in advance

Kind regards

Thanos Siaperas A.siaperas (talk)

Hi Thanos, this is a case we are not supporting so far it seems. Can you file a ticket on phabricator.wikimedia.org? --Lydia Pintscher (WMDE) (talk) 14:19, 31 March 2019 (UTC)

Using commons sitelinks rather than P373 in the sidebar?[edit]

I'm not sure if this is the right place to ask this or not. At the moment, on Wikipedias and elsewhere, Commons category (P373) is used in the left-hand sidebar to link to Commons. Ideally that should use the Commons sitelink, though - and it should follow through topic's main category (P910) to get that sitelink from the category item if needed. It should only use P373 as a fallback if no suitable sitelink (to a commons category) is available. Should I file this as a ticket on Phabricator, or does it need consensus to be established somewhere first, and if so, where? Thanks. Mike Peel (talk) 19:24, 29 March 2019 (UTC)

Hey Mike :) The current implementation is based on what people asked for back then so I don't think we should change it unless there is broader consensus to do so. --Lydia Pintscher (WMDE) (talk) 14:21, 31 March 2019 (UTC)
@Lydia Pintscher (WMDE): Do you know where that discussion took place, please? That might be a suitable venue for me to seek consensus for this change. Thanks. Mike Peel (talk) 17:52, 31 March 2019 (UTC)
The thing I can find is phabricator:T145279. I am reasonably sure there were other discussions as well but I am not sure where. --Lydia Pintscher (WMDE) (talk) 10:45, 2 April 2019 (UTC)

Wrong copy[edit]

Hello.When a statement is copied, edit is automatically copied.Please correct this error.Thanks David (talk) 08:10, 31 March 2019 (UTC)

Hi David :) Can you clarify what you want to do please? Are you highlighting a statement to copy it into a text editor for example? Or something else? --Lydia Pintscher (WMDE) (talk) 14:23, 31 March 2019 (UTC)
Example: Copy made today and was corrected in the following edit David (talk) 15:21, 31 March 2019 (UTC)
Hello :) What are you using to copy a statement? Do you select and copy/paste the value with your cursor? Do you use a gadget or script? Lea Lacroix (WMDE) (talk) 08:01, 3 April 2019 (UTC)
No, using only the arrow David (talk) 16:25, 3 April 2019 (UTC)

Link hijacking[edit]

See [1] — an old perfectly valid link is now a link to a porn site / content. It’s been deprecated (but the correct rank should be « normal » if we follow the rule that its historical information that had been valid at some point.

@Jmabel: asks if there could be a way to make the link not clickable at all, which is a good point. My guess is that in an ideal world it would need to add a flag to the « url » datatype to add the information that the link is dead or invalid, as deprecation don’t make it unclickable and the first point about the meaning on deprecation, we may use the « normal » rank.

PS: I’m unconfortable with the rank interpretation in that case. It may be considered as historic information, which is cited by mw:Wikibase/DataModel#Ranks_of_Statements as stuff that could be in « normal » rank, and at the same time an old link has value as archive information, but at the same time it’s erroneous and misleading today, which fits better to the « deprecated » rank. A lot of people would of course consider it’s nitpicking and would not bother to deprecate … But personally this kind of conflicts makes me uncomfortable author  TomT0m / talk page 10:14, 31 March 2019 (UTC)

  • Maybe any link with an "end date"- or "end cause"-qualifier could be made unclickable. --- Jura 10:28, 31 March 2019 (UTC)
    • Probably, but tricky to implement as it would make features on the data model depends on actual property values on some wiki. The stuff that works that way is property ordering, to make stuff a little bit generic there could be a special page per Wikibase datatype (if relevant) with a user/admin defined list of qualifiers that would « deactivate » a statement main value. author  TomT0m / talk page 10:34, 31 March 2019 (UTC)
      • I wonder if it's that much an issue. People who complain about it seem active Wikipedia users without much activity in Wikidata and who seem to go out of their way to "inadvertently" click on them. --- Jura 13:53, 31 March 2019 (UTC)
  • Ah the internet... ;-) We could look into building an elaborate system but tbh I am not sure it is worth it. From the data side it is perfectly valid to keep this as normal and add a new preferred value. Even if we make it unclickable here that'll not help much because most of the use of Wikidata isn't here but through other places like Wikipedia where we don't have that influence. --Lydia Pintscher (WMDE) (talk) 14:28, 31 March 2019 (UTC)
    • As a Wikidata editor looking at this after it was posted on chat, I clicked and was not at all happy with where it took me. I can live with that, but what if it had been actual malware? - Jmabel (talk) 18:59, 31 March 2019 (UTC)
  • I have created (and applied, using has quality (P1552)) cybersquatted domain name (Q62606058). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:09, 31 March 2019 (UTC)
    • @Pigsonthewing: I am not sure that's the right way to use P1552. Per the property examples, P1552 should normally be used to indicate a question that can be asked about members of the class, eg: place --> location?, rather than being used as a qualifier to annotate a feature of the statement value. I think there would be value in keeping P1552 to its originally intended narrow meaning. Jheald (talk) 11:30, 1 April 2019 (UTC)
      • I'm not seeing any conflict between my use and the property description; between my use and the examples, nor between my use and asking a question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 1 April 2019 (UTC)
  • I think the truthy value shouldn't be the link to the squatted domain. I would therefore advocate that we depricate the main value as end time (P582) doesn't affect what the truthy value is. reason for deprecation (P2241) cybersquatted domain name (Q62606058) seems appropriate. We could make depricated links by default nonclickable. ChristianKl ❪✉❫ 10:48, 1 April 2019 (UTC)

concurrent.ExecutionException[edit]

When clicking on the 3-dot symbol, to the right of a formula datatype value, the window that pops up attempts to execute a SPARQL query that fails with the above exception. Tested with defining formula (P2534) on mass–energy equivalence (Q35875) and Bernoulli's principle (Q181328). LaddΩ chat ;) 13:59, 4 April 2019 (UTC)

!admin on IRC[edit]

If I know it correctly, #wikidata IRC's !admin command does not send us (administrators) notification. I would like to ask that could you build a similar system to #wikimedia-stewards? I do not check my IRC very often, so I would really appreciate notifications from the command. I believe that it will cause faster admin reactions and actions; could you make it possible? Thank in advance! Bencemac (talk) 15:39, 6 April 2019 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team&oldid=905922259"