Hi,
between 5:30 and 7:10 UTC on 2023/09/27 the WDQS servers running in the
eqiad datacenter have returned results with more than 10 minutes of lag.
This caused bots using MW maxlag [0] to stop functioning properly during
that time.
The incident started after a failure of the mirroring system between two of
our kafka clusters [1], such incident should not have impacted WDQS but it
uncovered improper sandboxing of the WDQS updater test setup [2].
Sorry for the inconvenience.
--
David Causse
Software Engineer, Wikimedia Foundation
0: https://www.mediawiki.org/wiki/Manual:Maxlag_parameter
1:
https://wikitech.wikimedia.org/wiki/Incidents/2023-09-27_Kafka-jumbo_mirror…
2: https://phabricator.wikimedia.org/T347515
Hello all,
Sorry for cross-posting.
The Technical Decision-Making Forum Retrospective
<https://www.mediawiki.org/wiki/Technical_decision_making> team invites you
to join one of our “listening sessions” about the Wikimedia's technical
decision-making processes.
We are running the listening sessions to provide a venue for people to tell
us about their experience, thoughts, and needs regarding the process of
making technical decisions across the Wikimedia technical spaces. This
complements the survey
<https://wikimediafoundation.limesurvey.net/885471?lang=en>, which closed
on August 7.
Who should participate in the listening sessions?
People who do technical work that relies on software maintained by the
Wikimedia Foundation (WMF) or affiliates. If you contribute code to
MediaWiki or extensions used by Wikimedia, or you maintain gadgets or tools
that rely on WMF infrastructure, and you want to tell us more than could be
expressed through the survey, the listening sessions are for you.
How can I take part in a listening session?
There will be four sessions on two days, to accommodate all time zones. The
two first sessions are scheduled:
- Wednesday, September 13, 14:00 – 14:50 UTC
<https://zonestamp.toolforge.org/1694613630>
- Wednesday, September 13, 20:00 – 20:50 UTC
<https://zonestamp.toolforge.org/1694635220>
The sessions will be held on the Zoom platform.
If you want to participate, please sign up for the one you want to attend: <
https://www.mediawiki.org/wiki/Technical_decision_making/Listening_Sessions>.
If none of the times work for you, please leave a message on the talk page.
It will help us schedule the two last sessions.
The sessions will be held in English. If you want to participate but you
are not comfortable speaking English, please say so when signing up so that
we can provide interpretation services.
The sessions will be recorded and transcribed so we can later go back and
extract all relevant information. The recordings and transcripts will not
be made public, except for anonymized summaries of the outcomes.
What will the Retrospective Team do with the information?
The retrospective team will collect the input provided through the survey,
the listening sessions and other means, and will publish an anonymized
summary that will help leadership make decisions about the future of the
process.
In the listening sessions, we particularly hope to gather information on
the general needs and perceptions about decision-making in our technical
spaces. This will help us understand what kind of decisions happen in the
spaces, who is involved, who is impacted, and how to adjust our processes
accordingly.
Are the listening sessions the best way to participate?
The primary way for us to gather information about people’s needs and wants
with respect to technical decision making was the survey
<https://wikimediafoundation.limesurvey.net/885471?lang=en>. The listening
sessions are an important addition that provides a venue for free form
conversations, so we can learn about aspects that do not fit well with the
structure of the survey.
In addition to the listening sessions and the survey, there are two more
ways to share your thoughts about technical decision making: You can post
on the talk page
<https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec…>,
or you can send an email to <tdf-retro-2023(a)lists.wikimedia.org>.
Where can I find more information?
There are several places where you can find more information about the
Technical Decision-Making Process Retrospective:
-
The original announcement about the retrospective from Tajh Taylor:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
-
The Technical Decision-Making Process general information page:
https://www.mediawiki.org/wiki/Technical_decision_making
-
The Technical Decision-Making Process Retrospective page:
https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision…
-
The Phabricator ticket: https://phabricator.wikimedia.org/T333235
Who is running the technical decision making retrospective?
The retrospective was initiated by Tajh Taylor. The core group running the
process consists of Moriel Schottlender (chair), Daniel Kinzler, Chris
Danis, Kosta Harlan, and Temilola Adeleye. You can contact us at <
tdf-retro-2023(a)lists.wikimedia.org>.
Thank you for participating!
--
Benoît Evellin - Trizek (he/him)
Community Relations Specialist
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi there,
I am trying to perform the token refresh operation (https://www.wikidata.org/wiki/Wikidata:REST_API/Authentication#Non-owner-on…), but I get a 404:
curl --request POST \
--url https://www.wikidata.org/w/rest.php/w/rest.php/oauth2/access_token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data grant_type=client_credentials \
--data client_id=abc \
--data client_secret=xyz
{"messageTranslations":{"en":"The requested relative path (/w/rest.php/oauth2/access_token) did not match any known handler"},"httpCode":404,"httpReason":"Not Found"}%
Even with some invalid data for my client_id / client_Secret I would expect a different HTTP status telling me that the credentials are invalid etc.
Any idea what goes wrong?
Thanks and kind regards,
Tobias
Hello,
This is an announcement about an upcoming breaking change related to the
list=wbsubscribers API Query module, which has inconsistencies in its
response.
Currently, calling the action=query&list=wbsubscribers API endpoint on a
Wikibase returns a response with two different keys that could potentially
contain results: subscribers and wbsubscribers. In addition, the XML
response format is not structured as expected.
We have identified the root cause of this issue, which was a typo in the
code that sets up the API module. We have fixed the issue and made the
necessary changes to ensure that the results are now added to only one key,
namely wbsubscribers instead of subscribers, and in the correct XML
structure. The fix is already deployed on Test Wikidata, and we plan to
deploy it to Wikidata on or after 2023-05-18.
Currently, an example API response may look like this:
JSON format
XML format
{
"batchcomplete": true,
"query": {
"wbsubscribers": {},
"subscribers": {
"Q42": {
"subscribers": [
{
"site": "enwiki"
}
]
}
}
}
}
<?xml version="1.0"?>
<api batchcomplete="">
<query>
<wbsubscribers />
<subscribers>
<Q42>
<subscribers>
<subscriber site="enwiki" />
</subscribers>
</Q42>
</subscribers>
</query>
</api>
With the change, it will instead look like this:
JSON format
XML format
{
"batchcomplete": true,
"query": {
"wbsubscribers": {
"Q42": {
"subscribers": [
{
"site": "enwiki"
}
]
}
}
}
}
<?xml version="1.0"?>
<api batchcomplete="">
<query>
<wbsubscribers>
<entity id="Q42">
<subscribers>
<subscriber site="enwiki" />
</subscribers>
</entity>
</wbsubscribers>
</query>
</api>
As an API user, you can prepare for this change by first checking if the
wbsubscribers element in the response is empty or not. If it is nonempty,
use it (the response is using the new format); if it is empty, fall back to
using the subscribers element instead (it is still using the old format).
This way, your code will work both before and after the change is deployed.
(Later, you can remove the fallback code.)
If you have any questions or concerns about this change, please don’t
hesitate to reach out to us in this ticket (phab:T300458
<https://phabricator.wikimedia.org/T300458>).
Cheers,
--
Mohammed Sadat
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
Keep up to date! Current news and exciting stories about Wikimedia,
Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
<https://www.wikimedia.de/newsletter/>.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello,
This is a significant change announcement about the way entity labels are
displayed in parsed edit summaries in API requests.
As a Wikidata editor, you may have noticed that links in edit summaries are
formatted using the label of the linked entity, for example, [[Property:P460]]:
[[Q112795079]] becomes “said to be the same as (P460)
<https://www.wikidata.org/wiki/Property:P460>: Wikidata Sandbox 4
(Q112795079) <https://www.wikidata.org/wiki/Q112795079>”. However, this is
disabled in API requests, initially done to fix a previous bug. This made
it difficult for edit summaries to be understood outside of Wikidata.org,
especially when shown in tools.
To address this issue, we have fixed the original bug and will now enable
the display of entity labels in parsed edit summaries in API requests. API
requests that return edit summaries will now show formatted links with
entity labels, including action=query + prop=revisions +
rvprop=parsedcomment.
We have already deployed this change to Test Wikidata, where you can test
it now (example API request
<https://test.wikidata.org/w/api.php?action=query&format=json&prop=revisions…>).
We will deploy it to Wikidata on or shortly after May 18th.
We assume that users who analyze edit summaries to determine what changed
in an edit generally use the unparsed comment (e.g., /*
wbsetclaim-update:2||1|1 */ [[Property:P460]]: [[Q112795079]]), which will
be unaffected.
Please let us know on this phabricator ticket
<https://phabricator.wikimedia.org/T327062> if you have any questions or
concerns.
Cheers,
--
Mohammed Sadat
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
Keep up to date! Current news and exciting stories about Wikimedia,
Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
<https://www.wikimedia.de/newsletter/>.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello! This is a breaking change announcement regarding the WikibaseClient
wblistentityusage API module. This API module is used for listing all pages
that make use of data from a given entity via Lua, parser functions, or
Sitelinks.
Currently, this API module has two issues:
-
When using this module as a value for the list parameter in an API query
action, the results are added to the query.pages key in the response
object. However, this key is reserved for use with the following
parameters: generator, titles, pageids, and revids. This could lead to a
collision if used alongside one of these parameters, potentially causing a
runtime exception.
-
The API parameter prefix wbeu is shared between list=wblistentityusage
and prop=wbentityusage (a different module that instead lists all
entities used on a given page). However, the module prefix must be globally
unique.
We are addressing both issues at the time. Starting today, you can use the
wblistentityusage API with the parameter prefix wbleu instead of wbeu, and
the results will be added under query.entityusage instead of query.pages.
However, the old prefix (wbeu) is still supported for some time, and will
continue to produce the same output as before (with an additional
deprecation warning).
On or shortly after 2023-05-17, we will remove support for the old prefix
and output format from the API. Thus, you now have two weeks to migrate to
the new prefix and output format. For a comparison between the old and new
methods of using the API, please refer to the wbeu version
<https://test.wikidata.org/w/api.php?action=query&list=wblistentityusage&wbe…>
and wbleu version
<https://test.wikidata.org/w/api.php?action=query&list=wblistentityusage&wbl…>
examples.
If you have any questions or concerns about this change, please don’t
hesitate to reach out to us via tickets T196962
<https://phabricator.wikimedia.org/T196962> or T300460
<https://phabricator.wikimedia.org/T300460>.
Cheers,
--
Mohammed Sadat
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
Keep up to date! Current news and exciting stories about Wikimedia,
Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
<https://www.wikimedia.de/newsletter/>.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Dear Wikidata API team,
I am writing to request that you whitelist my domain, hindibox.co.in,
for Cross-Origin Resource Sharing (CORS). I am currently working on a
project that requires fetching data from the Wikidata API, but I am
encountering the "Cross-Origin Request Blocked" error due to the
Same-Origin Policy.
I have tried using the https://cors-anywhere.herokuapp.com proxy to
bypass this issue, but I am now getting a 403 error. After researching
this issue, I found that the best solution is to request that my domain
be added to your CORS whitelist.
I would greatly appreciate it if you could add hindibox.co.in to your
CORS whitelist so that I can continue working on my project. Please let
me know if there is any additional information or steps that I need to
take to make this happen.
Thank you for your attention to this matter.
Best regards,
Hindibox Team
Dear all,
on FactGrid wikibase I created some 300 Items with erroneous Wikidata sitelinks.
Is there a way to remove these sitelinks or to overwrite them with the correct Wikidata references using QuickStatements?
Best,
Olaf
Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Am Schlossberg 2
99867 Gotha
Büro: +49-361-737-1722
Mobil: +49-179-5196880
Privat: Hauptmarkt 17b/ 99867 Gotha
Hi everyone,
We are working on making it easier to use Wikidata's data to build
applications. A big part of that is a better API. Over the past months
we have been developing the first version and gotten testing and
feedback for it. Last week we made it available on test.wikidata.org.
Today the first version of the new Wikibase REST API is available on
Wikidata. I'd like to thank everyone who helped along the way by
providing feedback and testing.
You can find more information on what you can already do with the new
Wikibase REST API at https://www.wikidata.org/wiki/Wikidata:REST_API.
We will continue to build out its functionality and your input on what
would be most useful for you will help prioritize the next steps.
Please leave your thoughts at
https://www.wikidata.org/wiki/Wikidata_talk:REST_API_feedback_round#The_Wik….
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher - WD:Q18016466
Product Manager for Wikidata
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
https://wikimedia.de
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e.
V. Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207.
*(apologies for cross posting)* Hello everyone,
As you may already know, we are developing a new REST API to improve
programmatic access to data from Wikidata and other Wikibase instances.
Many thanks to everyone who gave us the initial feedback on the proposed
implementation plan of the REST API and subsequently tested the
experimental phase of it on Beta Wikidata
<https://wikidata.beta.wmflabs.org>.
All the items listed in our previous communication
<https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/me…>
as still needing to be completed for the initial release have now been
completed and we are pleased to announce that the Wikibase REST API is
planned to go live on Wikidata about a week later.
What is the current state capable of doing?
-
Retrieve the data of an Item with ‘GET /entities/items/{item_id}’ and
filter what fields (i.e. type, labels, descriptions, aliases, statements,
sitelinks) are returned when reading the Item data
-
Retrieve all statements of an Item with ‘GET
/entities/items/{item_id}/statements’
-
Retrieve the data of a single statement of an Item with ‘GET
/entities/items/{item_id}/statements/{statement_id}’ or ‘GET
/statements/{statement_id}’
-
Conditionally request the data only if it has changed since the
specified revision/timestamp (using If-None-Match, If-Modified-Since
HTTP headers)
-
Create a statement on an Item with ‘POST
/entities/items/{item_id}/statements’
-
Authenticate and authorize as a Beta Wikidata user when making edits
using the API, as well as provide edit tags and edit comment, and mark an
edit as one made by a bot.
-
Replacing the statement on an Item with ‘PUT
/entities/items/{item_id}/statements/{statement_id}’ or ‘PUT
/statements/{statement_id}’
-
Removing the statement from an Item with ‘DELETE
/entities/items/{item_id}/statements/{statement_id}’ or ‘DELETE
/statements/{statement_id}’
-
Automated edit summaries
The following functionality is still awaiting a final security review of a
library <https://phabricator.wikimedia.org/T316523> and will be enabled
once that is finished:
-
Editing a statement on an Item with ‘PATCH
/entities/items/{item_id}/statements/{statement_id}’ or ‘PATCH
/statements/{statement_id}’
Please note that the following items previously listed under "The following
will likely not be available in the first version but follow later" have
not yet been finished and will not be available in this initial release:
-
Creating or deleting an Item
-
Getting a statement from an Item based on the Property ID in the
statement
-
Any operation (reading, adding, editing, removing) on sitelinks, labels,
descriptions and aliases
-
Any operation on entity types other than Items (i.e. Properties,
Lexemes, …)
-
Translated error messages
However, we will continue to work on these items in the future to provide a
more comprehensive REST API. In order to prioritize our next steps, we
would greatly appreciate feedback on which missing features you would find
most useful to add next.
If you have any questions or want to provide feedback please let us
know at Wikidata
talk:REST API feedback round
<https://www.wikidata.org/wiki/Wikidata_talk:REST_API_feedback_round#The_Wik…>.
As this new API is more tailored to the Wikibase data model than the Action
API, we have outlined the differences in the JSON data format between the
two
<https://doc.wikimedia.org/Wikibase/master/php/rest_data_format_differences.…>
for you for easy comparison.
Thank you for your patience and support as we continue to improve the
Wikibase REST API.
Cheers,
--
Mohammed Sadat
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
Keep up to date! Current news and exciting stories about Wikimedia,
Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
<https://www.wikimedia.de/newsletter/>.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.