Wikidata:Contact the development team/Archive/2020/06

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

Warning when trying to save an exact number

Hello. When trying to save an exact number, entered as 10±0, the following warning appears:

Warning: Number values should no longer be added with "±0" at the end unless there is a good reason for it. Please, delete "±0" and try again.

What does that mean, exactly? What are valid good reasons? How should exact numbers be entered instead? Thanks. Toni 001 (talk) 13:20, 30 May 2020 (UTC)

@Toni 001: The right way to enter exact numbers is “10” – Wikibase no longer adds an automatic “±1” as it used to. --Lucas Werkmeister (WMDE) (talk) 09:34, 2 June 2020 (UTC)

@Lucas Werkmeister (WMDE): Thanks, that looks like an improvement in the case of integers. But the message also shows up when entering, say 0.001±0 (say for an exact unit conversion). Is 0.001 (without the ±) therefore implicitly assumed to be exact? I'd be curious to look at some developer discussions (phabricator, ...), if available, to better understand the changes. Toni 001 (talk) 09:52, 2 June 2020 (UTC)

@Toni 001: I’m not sure how to find community discussions at the time, but from the development team’s side this was announced in two emails to the wikidata and wikidata-tech mailing lists, and the main Phabricator task was T115269. I hope this helps. --Lucas Werkmeister (WMDE) (talk) 12:55, 2 June 2020 (UTC)

@Lucas Werkmeister (WMDE): Thanks, those documents are clear and I agree with the decision to not assume any uncertainty. So, what could be improved then is the message, maybe like: Number values should only be added with "±0" at the end if they are known to be exact. (Looking at the API result after entering 100 does indicate that it is not assumed to be exact, which is good.) Toni 001 (talk) 16:44, 2 June 2020 (UTC)

@Toni 001: The error/warning and message are defined by the community, not the development team, in abuse filter #93. I’m not sure what the usual place to discuss abuse filters is, but it looks like Wikidata talk:Abuse filter has some discussions; you could try bringing it up there. --Lucas Werkmeister (WMDE) (talk) 17:48, 2 June 2020 (UTC)

Warn me if I want leave the page without saving

Tracked in Phabricator
Task T55478

User:Akela suggested @huwiki that Wikidata (in the main namespace) should have a pop-up warning when you try to leave editing without saving the page. Please consider the idea (is there already a Phabricator task for this?). Thanks! Bencemac (talk) 08:31, 2 June 2020 (UTC)

Thanks! The ticket is this one. Lea Lacroix (WMDE) (talk) 15:12, 2 June 2020 (UTC)

Changes to rank are not reverted when cancelling an edit

Tracked in Phabricator
Task T173557

Steps to reproduce:

• Click edit on any statement
• Change the rank of the statement
• Cancel the edit

Expected result: The rank is shown as it was before the edit.

Actual result: The rank is shown as if the user clicked "publish".

--Haansn08 (talk) 09:21, 2 June 2020 (UTC)

This is phab:T173557 - Nikki (talk) 09:29, 2 June 2020 (UTC)

Query server result view: flipped table (26 May)

How can I activate the above view explicitly? It is supposed to be active when the results are lengthy compared to the screen, but it doesn't always happen.

Sample query: [1]

I had left a note about it at Wikidata:Request_a_query#Result_view_table_(flipped). --- Jura 13:11, 26 May 2020 (UTC)

Hello,

Unfortunately, this view is not something that can be explicitly configured in the Query Service. It is part of the library used for the mobile display of the query results, and it's not related to the size of the results, only the size of the screen (562px or less).

We could imagine adding it as a type of view, like the graphs, maps, etc. but it would require a certain amount of work, because it is not configured as such at the moment. Lea Lacroix (WMDE) (talk) 10:03, 27 May 2020 (UTC)

Actually, setting it to 562px could work, but I don't see this happen consistently nor does it only happen with that size. How could I make sure it happens?

The idea is to display a record (several flipped columns) and a link to quickstatement to merge or add a statement, similar to the links in the rightmost column at Wikidata:Database reports/identical birth and death dates/1.

An alternative could be to allow to define a (short) link text for URI (I think there was a request for that), but there may be other reasons why we don't want to allow that. --- Jura 04:45, 28 May 2020 (UTC)

• A simple workaround could be to use "imagegrid" with some random image [2]. Too bad QuickStatements currently doesn't work for such links.
  To insert this in your list of possible developments, do you need more information? --- Jura 09:01, 5 June 2020 (UTC)

defaultView:Table{"hide":["?coor","?img"]} (June 6)

#defaultView:Map{"hide":["?coor","?country"]}
#defaultView:Table{"hide":["?coor","?img"]}
#defaultView:ImageGrid{"hide":["?coor"]}
SELECT DISTINCT  ?item ?itemLabel ?coor ?img ?country
{
	?item wdt:P31 wd:Q797765 . 
    ?item wdt:P625 ?coor .
    ?item wdt:P17 ?country . 
    OPTIONAL { ?item wdt:P18 ?img }  
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

A recent discovery of mine: multiple #defaultView are possible and, when switching views, the defined {"hide":[".."]} settings take effect. By default, the last view is activated. (short sample above).

One thing that doesn't seem to work is "hide" in combination with "defaultView:Table". It would allow to omit columns that are mainly there for one of the other views. --- Jura 19:01, 6 June 2020 (UTC)

Conversion to external-id (June 8)

There seems to be consensus regarding ISIN (P946). Thanks as always, --Epìdosis 08:01, 8 June 2020 (UTC)

Thanks for letting me know. (the previous batch of conversion has been done, by the way)

I was wondering if there are other identifiers that are ready or almost ready to be converted? It's more convenient for us if we convert several IDs together instead of one by one. Lea Lacroix (WMDE) (talk) 10:50, 8 June 2020 (UTC)

Lea Lacroix (WMDE), yes two others are ready:

1. 2019-11-05 Linguasphere code Property_talk:P1396#This_should_really_be_an_identifier
2. 2020-05-31 KOATUU ID Property_talk:P1077#external_ID?

no other "almost ready". Re "It's more convenient for us if we convert several IDs together instead of one by one." - Fulfilled, would be more convenient. Since there are three, you could even drop one and still have more than one. MrProperLawAndOrder (talk) 19:44, 9 June 2020 (UTC)

Lea Lacroix (WMDE) would you bother to proceed? MrProperLawAndOrder (talk) 03:54, 11 June 2020 (UTC)

1. Lea Lacroix (WMDE) reminder. MrProperLawAndOrder (talk) 19:57, 11 June 2020 (UTC)
2. Lea Lacroix (WMDE) reminder. MrProperLawAndOrder (talk) 23:23, 13 June 2020 (UTC)

Please stop pinging me every day. It is not going to make the convert process any faster, and it is definitely not going to make us consider your requests in the future. Lea Lacroix (WMDE) (talk) 06:15, 14 June 2020 (UTC)

Lea Lacroix (WMDE)

1. I didn't ping you "every day", stick to facts and don't say things that imply things regarding other users that didn't happen. Respect WD:NPA.
2. "It is not going to make the convert process any faster" - but you didn't proceed, despite your original request being fulfilled. You are altering the requirements, hacking the process while running, changing conditions etc.:
   1. 2020-06-08 08:01 User:Epìdosis wrote "There seems to be consensus regarding ISIN (P946).
   2. 2020-06-08 10:50 User:Lea Lacroix (WMDE) wrote (without pinging) "I was wondering if there are other identifiers that are ready or almost ready to be converted? It's more convenient for us if we convert several IDs together instead of one by one." - since it was without pinging and User:Epìdosis didn't make his request transparent at the ISIN page your "wondering" stayed unnoticed to many.
   3. 2020-06-09 00:58 User:MrProperLawAndOrder posted a list of properties under discussion, including start date and links to the discussions, and revealing that apart from ISIN, two others are "ready" namely Linguasphere and KOATUU. That meant proceeding with these three would mean "convert several IDs together instead of one by one" would be fulfilled.
   4. 2020-06-09 16:46 User:Lea Lacroix (WMDE) wrote "As you have seen in the previous section, adding up giving enough time for community to give and actually completing the conversion, it can easily take 2 to 3 weeks. Let's proceed like we previously did with Epìdosis: if you gather a list of IDs to convert, after making sure that there's a community consensus, I can create a ticket for the batch and make sure that they get converted." - note: "I can", not "I will" and that in a list of six, three that had consensus have been named just ~15:00 hours ago
   5. 2020-06-09 20:10 User:Epìdosis wrote "So, I personally not see any problem in the conversion of Linguasphere code (P1396), ISIN (P946) and KOATUU ID (P1077), given the above data. I don't see potential problems of recriminations after conversion."
   6. 2020-06-11 06:46 User:Lea Lacroix (WMDE) wrote "So from what I see in the discussion, we have 3 IDs ready and 3 that still need a bit of discussion:" and "We'll start a batch when the 6 of them are ready to go. @Epìdosis:, can I let you check the discussions and let me know when they are all approved, as we did before? Then I'll take care of the ticket and the rest. Thanks!"
   7. 2020-06-11 19:56 User:MrProperLawAndOrder wrote "User:Lea Lacroix (WMDE) why do you alter the procedure while it is running? Why do you make up "3 that still need a bit of discussion"? And couple it with "We'll start a batch when the 6 of them are ready to go." - So, if one won't be "ready to go", the whole process is locked up?"
   8. 2020-06-11 20:38 User:Epìdosis wrote "@Lea Lacroix (WMDE): Just to clarify: I think, seeing the actual development of the discussions, that ICD-9-CM (P1692), HomoloGene ID (P593), NIOSH Pocket Guide ID (P1931) probably will never be ready for conversion, while Linguasphere code (P1396), KOATUU ID (P1077), ISIN (P946) are already ready for conversion."
3. "and it is definitely not going to make us consider your requests in the future" - it would be helpful to the Wikidata community if the reminders would make you consider what they are meant for, namely remind you on answering the question if you would bother to proceed. It's now 2020-06-15 and you still didn't answer if you would bother to do so. Would you? MrProperLawAndOrder (talk) 07:09, 15 June 2020 (UTC)

Stop. This is not how you can talk to Léa. And it's also really not how we want to treat each other here on Wikidata. Thank you. --Lydia Pintscher (WMDE) (talk) 16:49, 15 June 2020 (UTC)

Lydia Pintscher (WMDE), can you explain in more detail what you refer to by your commander-like "Stop. This is not how you can talk to Léa."? User:Lea Lacroix (WMDE) is denying three conversions for which consensus by the Wikidata community exists the way "how we want to treat each other here on Wikidata"? At first she gave the impression she would do it, then she changed the rules. Is that the way "how we want to treat each other here on Wikidata"? 9 days of consensus by the Wikidata community - WMDE not acting. MrProperLawAndOrder (talk) 04:23, 17 June 2020 (UTC)

ISIN is the last ISO ID that has datatype string instead of external-id. Given the general importance of ISO IDs it would be nice to have this one processed fast track. A new section for ISO IDs has been created at MediaWiki:Wikibase-SortedProperties#ISO IDs, ISIN is now missing.

There are other proposals to convert from string to external-id:

1. 2019-10-15 ICD-9-CM Property_talk:P1692#Proposal_-_Change_Data_type_of_{{P|1692}}_from_{{Datatype|string}}_to_{{Datatype|external-id}}
2. 2019-10-15 HomoloGene ID Property_talk:P593#Proposal_-_Change_Data_type_of_HomoloGene_ID_(P593)_from_String_to_External_identifier
3. 2019-11-05 Linguasphere code Property_talk:P1396#This_should_really_be_an_identifier
4. 2020-05-31 KOATUU ID Property_talk:P1077#external_ID?
5. (2020-06-04 ISIN Property_talk:P946#Identifier) - the one mentioned by User:Epìdosis
6. 2020-06-05 NIOSH Pocket Guide ID Property_talk:P1931#Convert_datatype_from_string_to_external-id

@Epìdosis: I think it would be safe to include Linguasphere and KOATUU. The other three can be done in another batch, maybe done much later with more added to form a larger batch. But ISIN is important, so it should start and take anything what is ready now with it, but not wait for more. So, this one is exceptionally a small batch. MrProperLawAndOrder (talk) 00:58, 9 June 2020 (UTC) // added bold MrProperLawAndOrder (talk) 16:26, 9 June 2020 (UTC)

• Most seem to have open issues or only (re-)added recently. They still need to be reviewed by other users. --- Jura 05:00, 9 June 2020 (UTC)

  "Most":

  In a list of 6 this is easily verified and restated by an exact number: 3 of 6 is half. And this has been done 00:58. MrProperLawAndOrder (talk) 16:13, 9 June 2020 (UTC)

  Among the three proposed in this batch (ISIN, KOATUU ID, Linguasphere ID), none seems to have an issue. If any has, then users should say so on the talk pages. MrProperLawAndOrder (talk) 16:26, 9 June 2020 (UTC)

Lea Lacroix (WMDE), how long will it take, can you proceed? MrProperLawAndOrder (talk) 16:12, 9 June 2020 (UTC)

As you have seen in the previous section, adding up giving enough time for community to give and actually completing the conversion, it can easily take 2 to 3 weeks.

Let's proceed like we previously did with Epìdosis: if you gather a list of IDs to convert, after making sure that there's a community consensus, I can create a ticket for the batch and make sure that they get converted. Lea Lacroix (WMDE) (talk) 16:46, 9 June 2020 (UTC)

User:Lea Lacroix (WMDE), you didn't address the fact that ISIN is an ISO code and the only one that is not an external-id, preventing it from showing up on item pages, where all other ISO IDs show up. It was a decision by WMDE to treat external-id differently and to not allow the Wikidata Community to sort them as they can do with properties having another datatype. WMDE didn't create tools that allow the Wikidata Community to perform the conversion from string to external-id on their own.

You bolded "after", so let me state this in bold: The list of three items is ready. If you think one on the list is not ready enough for WMDE, then apply what I wrote above: "But ISIN is important, so it should start and take anything what is ready now with it, but not wait for more." (bold added)

Last time it took 3 weeks, 1 day, 12 hours and a bit more until the process started on this page was reported as finished on this page.

If you are not happy with the three items, then only do ISIN. The other two can be done later, even much later.

ISIN is an ISO ID to be included in MediaWiki:Wikibase-SortedProperties#ISO IDs. It isn't to be sorted among ~5000 identifiers, but on the very top. We would like to communicate this new feature of having ISO IDs on top, but it is more useful if ISIN is there too. Do you see the difference? I perfectly understand that WMDE wants to do it in batches. Since there will be some more to convert another batch outside the 3 or even the 6 above is needed anyway. All the others can be put into this later batch. Please do ISIN exceptionally fast track, so we can communicate the progress regarding MediaWiki:Wikibase-SortedProperties#ISO IDs. MrProperLawAndOrder (talk) 17:06, 9 June 2020 (UTC)

You seem to care about this very much but I'm sorry I can't ok this unless there are more people who believe this is really urgent. In the grand scheme of things it costs us more time to do conversions individually as opposed to doing them in batches and that time seems to be better spend on other things that many people request and care about. On top of that I don't want us to do the conversion more quickly than prudent just to find out shortly after that people disagreed with the conversion - that'd be even more of a waste of everyone's time. So please understand that it's more efficient to do conversions in batches and have a bit of patience for this. It'll get done in time. --Lydia Pintscher (WMDE) (talk) 17:56, 9 June 2020 (UTC)

Of course you can ok it, but you don't want to. Don't say you cannot. Take responsibility.

Re "In the grand scheme of things it costs us more time to do conversions individually as opposed to doing them in batches and that time seems to be better spend on other things that many people request and care about." - That is because WMDE decided

1. to create the datatype "external-id" without clearly defining what it is for in the light of the existing datatype "string"
2. to not create tools for listing candidates
3. to not create tools that allow the conversion be done by the Wikidata Community
4. to not create a tool for WMDE to do the conversion easily (3 weeks 1 day 12 hours for the May batch)

Re "On top of that I don't want us to do the conversion more quickly than prudent just to find out shortly after that people disagreed with the conversion - that'd be even more of a waste of everyone's time." - it's not more "more quickly than prudent", it is running since February 2016 - how many more years does WMDE need?

Re "So please understand that it's more efficient to do conversions in batches" - I already said I understood this. But if two batches are coming anyway, then WMDE could do the Wikidata Community a one time favor and start the first batch now. MrProperLawAndOrder (talk) 19:12, 9 June 2020 (UTC)

So, personally I have never any hurry for conversions, since ordering is purely formal and also the difference of string/external-id is merely concerning ordering. So I think one week before or after constitutes no problem at all. Given that premise, I can say that, of the above six points

• there are objections on points 1, 2 and 6, so it's definitely better to wait for them
• for points 3 and 5 there are no objections after months of discussion and the number of unique-value violations is very low, so I see no problem in conversion
• for point 4 there are no objections after months of discussion and, while the number of unique-value violation is not so low, it can probably be mostly fixed in a semi-automatic way after discussing the issue with some Ukrainian user

So, I personally not see any problem in the conversion of Linguasphere code (P1396), ISIN (P946) and KOATUU ID (P1077), given the above data. I don't see potential problems of recriminations after conversion. Good evening and thank you as always for your patience, --Epìdosis 20:10, 9 June 2020 (UTC)

User:Epìdosis but one week for what? For the three Linguasphere code (P1396), ISIN (P946) and KOATUU ID (P1077) there is nothing to be gained. Do you think the other three will be finished in one week? You opposed switch of VIAF/ISNI, so that needs to be presented to more people. This should be done while presenting the whole ISO ID section. It was exactly my point to wait with the other three, but this can take longer than one week. So, in one week they will likely be not ready, nothing gained by waiting. Only problems. Can you reconsider? There are others for which I plan to open discussions, that can take longer. One could be done now, the other batch in July. We both are the major persons working on this, very unlikely others start new requests, much was sleeping for years. One now, other in July, we can influence that. MrProperLawAndOrder (talk) 23:21, 9 June 2020 (UTC)

User:Epìdosis but one week for what? MrProperLawAndOrder (talk) 03:57, 11 June 2020 (UTC)

• I agree with Lea Lacroix (WMDE) and Lydia Pintscher (WMDE). There's no reason for fast tracking anything here. If editing doesn't work on Wikidata because there's a big that would be a reason to fast track, but in this case there's no urgent need to change the way things worked for years. When changing how things have worked for years it's rather makes sense to wait for time to build community consensus.

There's a huge difference between a user asking for a favor for himself and a favor for the community. It's good for the community when WMDE in general waits for community opinions to form before doing things.

Asserting that it's important to do this conversation now, while not cleaning up the distinct values issues of the existing items also seems a bit strange.

It's not the job of WMDE to decide how we are going to use a new datatype like external-id. That's something that our community can decide. An RfC would be a way to decide that. ChristianKl ❪✉❫ 00:29, 10 June 2020 (UTC)

User:ChristianKl:

• "I agree with Lea Lacroix (WMDE) and Lydia Pintscher (WMDE)." - Why?
• "There's no reason for fast tracking anything here." - Has been presented.
• "If editing doesn't work on Wikidata because there's a big that would be a reason to fast track, but in this case there's no urgent need to change the way things worked for years." - What big? What change?
• "When changing how things have worked for years it's rather makes sense to wait for time to build community consensus." - What change?
• "There's a huge difference between a user asking for a favor for himself and a favor for the community." - Nobody asked for a favor for himself here, so what are you talking about?
• "It's good for the community when WMDE in general waits for community opinions to form before doing things." - But that is not under discussion here. The "community opinions" have been formed with regard to the conversion of ISIN, KOATUU, Linguasphere.
• "Asserting that it's important to do this conversation now, while not cleaning up the distinct values issues of the existing items also seems a bit strange." ??? What are you talking about? What conversation? What "distinct values issues of the existing items"? What does that have to do with the proposed conversion of ISIN, KOATUU, Linguasphere?
• "It's not the job of WMDE to decide how we are going to use a new datatype like external-id." - What does that have to do with the proposed conversion of ISIN, KOATUU, Linguasphere?

MrProperLawAndOrder (talk) 03:54, 11 June 2020 (UTC)

You complained above that WMDE did "create the datatype "external-id" without clearly defining what it is for". That definition is not up to WMDE. ChristianKl ❪✉❫ 13:39, 11 June 2020 (UTC)

User:ChristianKl, again, stop claiming things about others that didn't happen. MrProperLawAndOrder (talk) 19:59, 11 June 2020 (UTC)

It's easy for anybody to use Crtl+f to find that you did write "create the datatype "external-id" without clearly defining what it is for". ChristianKl ❪✉❫ 11:47, 12 June 2020 (UTC)

User:ChristianKl, whether that is true is irrelevant, stop claiming things about others that didn't happen. MrProperLawAndOrder (talk) 23:28, 13 June 2020 (UTC)

So it's your position that whether a claim is true has nothing todo with what is claimed happening? ChristianKl ❪✉❫ 22:30, 14 June 2020 (UTC)

If that is my "position" is irrelevant. Just "stop claiming things about others that didn't happen". MrProperLawAndOrder (talk) 07:20, 15 June 2020 (UTC)

So from what I see in the discussion, we have 3 IDs ready and 3 that still need a bit of discussion:

• ICD-9-CM
• HomoloGene ID
• Linguasphere code
• KOATUU ID
• ISIN
• NIOSH Pocket Guide ID

We'll start a batch when the 6 of them are ready to go. @Epìdosis:, can I let you check the discussions and let me know when they are all approved, as we did before? Then I'll take care of the ticket and the rest. Thanks! Lea Lacroix (WMDE) (talk) 06:46, 11 June 2020 (UTC)

User:Lea Lacroix (WMDE) why do you alter the procedure while it is running? Why do you make up "3 that still need a bit of discussion"? And couple it with "We'll start a batch when the 6 of them are ready to go." - So, if one won't be "ready to go", the whole process is locked up? @Epìdosis: why do you block the process? MrProperLawAndOrder (talk) 19:56, 11 June 2020 (UTC)

@Lea Lacroix (WMDE): Just to clarify: I think, seeing the actual development of the discussions, that ICD-9-CM (P1692), HomoloGene ID (P593), NIOSH Pocket Guide ID (P1931) probably will never be ready for conversion, while Linguasphere code (P1396), KOATUU ID (P1077), ISIN (P946) are already ready for conversion. Thanks, --Epìdosis 20:38, 11 June 2020 (UTC)

Thank you. Léa filed the ticket for it here: phab:T255241. --Lydia Pintscher (WMDE) (talk) 16:48, 15 June 2020 (UTC)

I'm missing something here. I thought the only way to 'convert' a property to a new datatype was to create a new property, migrate things over, and delete the old one - which is why P3722 (P3722) is now category for maps (P7867). What am I missing? Thanks. Mike Peel (talk) 20:50, 11 June 2020 (UTC)

@Mike Peel: Conversion from datatype string to datatype external-id is perfectly possible through @Maintenance script:, see also above #Conversion to external-id (May 16). --Epìdosis 21:00, 11 June 2020 (UTC)

@Epìdosis: OK, but only between those datatypes, or are more general conversions possible? Thanks. Mike Peel (talk) 21:01, 11 June 2020 (UTC)

@Mike Peel: I think only between those datatypes, but I'm not 100% sure. --Epìdosis 21:05, 11 June 2020 (UTC)

@Epìdosis: Got it. I created phab:T255241, and I'll ping you when it's done. Thanks for your patience.

@Mike Peel: Indeed, we're able to convert a string property to an external ID one, but other cases are more complex, that's why for most of the other cases we suggest to delete and recreate the property. Lea Lacroix (WMDE) (talk) 08:29, 12 June 2020 (UTC)

I believe you can convert between those with "The value type for this data type is string." back and forth. --Matěj Suchánek (talk) 09:20, 12 June 2020 (UTC)

This section was archived on a request by: --- Jura 08:47, 28 June 2020 (UTC)

Hey @Epìdosis:, the 3 properties Linguasphere code (P1396), KOATUU identifier (P1077) and ISIN (P946) are now converted. Lea Lacroix (WMDE) (talk) 12:16, 1 July 2020 (UTC)

Bug item merge - same value in two statements

[3] result:

• https://www.wikidata.org/w/index.php?title=Q2362334&oldid=1203349781#P569 - 1822 with three refs [from merge target] and 1822 with one ref [from merge source].

MrProperLawAndOrder (talk) 23:08, 9 June 2020 (UTC)

It seems that the two items don't have the same value in the statement: one has "+1822-01-01T00:00:00Z" and the other "+1822-00-00T00:00:00Z" (day and month 0 rather than 1). However they display the same. Lea Lacroix (WMDE) (talk) 10:21, 11 June 2020 (UTC)

When will WMDE fix this? MrProperLawAndOrder (talk) 23:22, 13 June 2020 (UTC)

This section was archived on a request by: --- Jura 08:48, 28 June 2020 (UTC)

Toolforge problems (June 2)

It seems that QuickStatements stopped working as some people switched around toolforge. Can you check what is happening and how this could be fixed? It seems odd that urls are changed during COVID .. --- Jura 17:42, 2 June 2020 (UTC)

It looks like Magnus is moving tools ahead of the toolforge.org migration (the soft deadline ended a few days ago, the hard deadline is in two weeks). The new OAuth consumer already seems to making plenty of changes, so it looks like it’s working to some extent, at least. --Lucas Werkmeister (WMDE) (talk) 17:57, 2 June 2020 (UTC)

Good to hear that he is looking into it.

https://quickstatements.toolforge.org/index_old.html is borked, same for https://wikidata-todo.toolforge.org/quick_statements.php

Wonder who came up with the idea to move this this during these days. Plenty of urls will need to be changed.--- Jura 18:03, 2 June 2020 (UTC)

The announcement about this WMF change can be found here (April 2020) and was recently shared in the Wikidata newsletter. They have a migration plan and support tool maintainers who need help. I guess some issues may still happen when tool maintainers proceed with the migration. As usual, let's be patient, both with staff who are doing their best to make this transition smooth, and with volunteers who are maintaining tools for the community and making sure that they keep working. Lea Lacroix (WMDE) (talk) 08:44, 3 June 2020 (UTC)

Is this a WMF request? Why would one do that during COVID on such short notice? --- Jura 11:40, 3 June 2020 (UTC)

Apparently it is WMF project during for COVID. Was WMDE Wikibase development consulted on this change? How did you assess availability during COVID for this request? --- Jura 11:52, 3 June 2020 (UTC)

• Maybe a separate server could be set up for the Magnus tooliverse? --- Jura 07:42, 12 June 2020 (UTC)

• A status at Help:Toolserver migration. --- Jura 08:36, 13 June 2020 (UTC)
• It seems that many tools remain on the old server. --- Jura 08:47, 28 June 2020 (UTC)

I'm afraid that's nothing that the Wikidata development team at WMDE can actively solve. Lea Lacroix (WMDE) (talk) 08:59, 29 June 2020 (UTC)

• Maybe it's more of a communication role that is needed: someone within WMDE knowleadable about the tools used for Wikidata could assess what still needs to be migrated and then contact the various devs plus the people at WMF who want to shut this down too early. Otherwise we end up with gaps in functionalities. @Lydia Pintscher (WMDE): what do you think? --- Jura 10:11, 29 June 2020 (UTC)

Communication has been done, by WMF folks, on various platforms, and they provided documentation and a timeline, cf links that I posted above. We announced the migration in the Wikidata newsletter. WMF gave two more weeks after the original deadline. They are tracking things that are left to do on Phabricator, like here. Plenty of people already updated their tools, and now it's mostly a matter of time for people to finish updating. Again, there's nothing much WMDE can do here. Lea Lacroix (WMDE) (talk) 12:44, 29 June 2020 (UTC)

defaultView:Table{"hide":["?coor","?img"]} (June 6)

#defaultView:Map{"hide":["?coor","?country"]}
#defaultView:Table{"hide":["?coor","?img"]}
#defaultView:ImageGrid{"hide":["?coor"]}
SELECT DISTINCT  ?item ?itemLabel ?coor ?img ?country
{
	?item wdt:P31 wd:Q797765 . 
    ?item wdt:P625 ?coor .
    ?item wdt:P17 ?country . 
    OPTIONAL { ?item wdt:P18 ?img }  
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

A recent discovery of mine: multiple #defaultView are possible and, when switching views, the defined {"hide":[".."]} settings take effect. By default, the last view is activated. (short sample above).

One thing that doesn't seem to work is "hide" in combination with "defaultView:Table". It would allow to omit columns that are mainly there for one of the other views. --- Jura 19:01, 6 June 2020 (UTC)

• @Lydia Pintscher (WMDE): --- Jura 08:47, 28 June 2020 (UTC)

After investigation, it seems that the issue doesn't come from multiple defaultViews, but from the fact that hide is not implemented for the Table view, and possibly some other ones.

If you want the hide feature to be implemented for table view, you could create a Phabricator ticket for it. Lea Lacroix (WMDE) (talk) 14:06, 29 June 2020 (UTC)

Sort statements of same property when saving (June 7)

Some properties tend to draw many statements. For some, it should be possible to determine a qualifier by which statements could be sorted directly when saving. Anything without the qualifier could sorted last.

Properties:

• population (P1082) by point in time (P585)
• Elo rating (P1087) by point in time (P585)
• number of cases (P1603) by point in time (P585)
• number of medical tests (P8011) by point in time (P585)
• number of deaths (P1120) by point in time (P585)
• number of recoveries (P8010) by point in time (P585)
• life expectancy (P2250) by point in time (P585)
• nominal GDP (P2131) by point in time (P585)

Sample uses of these properties:

• Q62#P1082
• Q106807#P1087
• Q87833915#P1603
• Q87833915#P8011
• Q87833915#P1120
• Q87833915#P8010
• Q183#P183
• Q183#P2131

This would make items with these statements much more readable. --- Jura 08:49, 7 June 2020 (UTC)

• Related discussion at Wikidata:Project_chat/Archive/2020/04#Reordering_different_values_datewise with @Adithyak1997, SilentSpike, Ghouston, Matěj_Suchánek:, general ticket at phab:T173432 --- Jura 09:42, 7 June 2020 (UTC)
  • Maybe that would work for most properties with quantity datatype that have a P585.
    I thought about adding some with series ordinal (P1545), but that would only be useful if it is sorted as a number when possible, not a string (1,2,3,10,11 instead of 1,10,11,2,3). --- Jura 05:06, 8 June 2020 (UTC)

I would plus that need with a "+"/"-" toggle button if there are many many statements for same property, that would make the page much more readable. And help the reader unfold the property he is interested on. Bouzinac (talk) 05:35, 8 June 2020 (UTC)

Thanks for your ideas. Would this script help? "This script enables users to easily change order of values in any statement. It puts a blue button to all statements with multiple values. Upon clicking it, two (up and down) arrows appear near each value, which can be used to move values up or down relative to neighboring values." Lea Lacroix (WMDE) (talk) 08:44, 8 June 2020 (UTC)

I thought the dev had done away with manual sorting as it was considered useless. The idea is to do this by Wikibase when an edit is saved so users don't need to fiddle with the order. --- Jura 08:50, 8 June 2020 (UTC)

• @Lea Lacroix (WMDE), Lydia Pintscher (WMDE): do you need more input on this or could we move a step further with this? I think it's a fairly simple fix with a good overall improvement. --- Jura 07:40, 12 June 2020 (UTC)
  • Hey Jura, I think your observation from above is still right. My plan for automating the sorting based on qualifiers and ranks still stands. That's unfortunately far from a small technical change :/ What would you like to see happen before then that's smaller? --Lydia Pintscher (WMDE) (talk) 09:00, 12 June 2020 (UTC)
    • @Lydia Pintscher (WMDE): Hard to say. Some of the things in the general ticket seem more complex.

Maybe collapsing properties with many statements in a way similar to statements in Reasonator (or additional languages in the termbox)? I have in mind notably items about locations that can have many statements for population, but are otherwise reasonably sized. Entries with many "cites work" and "author name string" are probably already beyond (simple) manual editing. --- Jura 09:15, 14 June 2020 (UTC)

Unfortunately, this would not be a simple fix and would require a fair amount of development time. Lea Lacroix (WMDE) (talk) 12:48, 29 June 2020 (UTC)

• • • An other option could a user configurable list to collapse them .. (maybe that exists already). Could help filter statements one considers secondary. --- Jura 13:30, 21 June 2020 (UTC)

Another use case is that property patronage (P3872), see here for instance (relatively simple https://www.wikidata.org/wiki/Q1977535#P3872  ; relatively complex : https://www.wikidata.org/wiki/Q204853#P3872 . Statements are plentiful and thus difficult to maintain/check, all the more as they aren't sorted. WEF tool helped zoom and sort statements, but that tool does no longer work. Bouzinac (talk) 08:44, 29 June 2020 (UTC)

Untranslated languages

Table "In more languages"

There are untranslated names of languages in "Language" section in table with labels. There is "Belarusian (Taraškievica orthography)" instead of "białoruski (taraszkiewica)" or "Kazakh (Latin script)" intead of "kazachski (alfabet łaciński)". There should be also a button like "translate" or "report error" if translation in your language is missing and it would redirect you to certain talk page otherwise they will stay untranslated forever like in Polish, not even mentioning low populated languages like Estonian or Albanian. Eurohunter (talk) 08:33, 14 June 2020 (UTC)

@Eurohunter: Generally speaking, those names come from the Common Locale Data Repository (Q2986828) database; for languages not represented in that database, including the two you mentioned (be-tarask and kk-latn), Extension:CLDR maintains local lists of names, and it looks like nobody created such a list for Polish yet, which means that so far, MediaWiki only knows the Polish language names that are defined in the CLDR database. As far as I’m aware, there’s currently no strict process for adding new local language names (i. e. language names beyond the CLDR database) – T231755 suggests that should happen on translatewiki.net, but that doesn’t seem to be implemented yet. But I imagine you could create a Phabricator task, or (if you’re technically inclined) directly upload a Gerrit change, to define those additional names. --Lucas Werkmeister (WMDE) (talk) 10:26, 15 June 2020 (UTC)

Yes, there is some inquiries about languages not present in Wikidata (for instance lij-MC/Monégasque (Q56422)). Bouzinac (talk) 10:57, 15 June 2020 (UTC)

@Raymond: If I'm not mistaken, you're involved in adding languages for Mediawiki. Maybe you know how and where to add the missing languages? Lea Lacroix (WMDE) (talk) 10:53, 22 June 2020 (UTC)

@ Lea: As Lucas already said missing translations of language names can be added as LocalNamesPl.php to the CLDR extension. Ideally hese translations should be added to the CLDR project too, but this is a longer process. @Eurohunter: Please create a task on the Phabricator with the needed languages and add me to the task. I will create a patch for you if needed. Raymond (talk) 11:48, 22 June 2020 (UTC)

@Raymond: Could you open task for me? I don't have account there. Eurohunter (talk) 15:54, 22 June 2020 (UTC)

@Eurohunter: Feel free to create a subpage of your user page with a table of the translations instead. Similar to this page for German but in Polnish. Start with the most important languages. Raymond (talk) 20:30, 22 June 2020 (UTC)

• Can we note this somewhere? It seems this comes up occasionally and it would be good to have a page to point to. --- Jura 08:51, 28 June 2020 (UTC)