From: Wikipedia Volunteer Response Team
Sent: Saturday, April 21, 2018 6:10 PM
To: John D
Subject: Re: [Ticket#2018032210008751] infobox
Dear John D,
This queue is ONLY for English Wikipedia, you MUST use the Russian queue
info-ru(a)wikipedia.org
There is nothing at all we can do.
Yours sincerely,
Ron Jones
--
Wikipedia - https://en.wikipedia.org/
---
24/03/2018 13:44 - John D wrote:
> https://en.wikipedia.org/wiki/Template:Infobox_religious_building
>
> and uses the russian template.
>
> it is coming from the identifier but stretches the box rather than dropping down
> to the next line. and is based on the rank.to turn it off.
> From: Wikipedia Volunteer Response Team
> Sent: Saturday, March 24, 2018 2:44 AM
> To: John D
> Subject: Re: [Ticket#2018032210008751] infobox
>
> Hi John,
>
> Could you provide an example of an article that has this problem, so that I may
> take a closer look?
>
> Yours sincerely,
> Kevin Payravi
>
> --
> Wikipedia - https://en.wikipedia.org/
> 03/22/2018 14:33 - John D wrote:
>
> > how do you stop the info box on the article page from getting wider from data coming from
> > the hidden wikidata page ?
> >
This editor put the name in all languages in english,
is that right ?
“I added the name in all languages using Latin-script, with the order given name-surname and no declension,
So yes, the name should be the same in all these languages”
“Update 78 language (s) with the labels” " Helen Balfour Morrison"
This editor is saying that all russian church pages are wrong,
is that right ?
“You can't have P279 and P31 in the same item”
they were not in the same box.
Removed claim: subclass of (P279): Eastern Orthodox Church (Q35032))
Removed claim: subclass of (P279): Russian Orthodox Church (Q60995))
“This editor is attacking and removing all instances of location , https://www.wikidata.org/wiki/User_talk:Ksc~ruwiki
06:15, 23 March 2018 (Removed claim: located in the administrative territorial entity (P131): Kozelsk(Q154661))
This editor put it back without looking at history. where i tried to fix.
20:06, 6 April 2018 (Created claim: located in the administrative territorial entity (P131): Kozelsk (Q154661))
This bot is adding country code to local phone no. when p 474 is already there.
(Changed claim: phone number (P1329): +7-812-323-74-36, Normalizes phone number format)
Hi All!
I don't really have anywhere to announce things like this yet, so figured
wikidata-tech will do.
I have just merged https://github.com/wmde/wikibase-docker/pull/13
This change means that the new build of 0.3.0 (in progress) will actually
require a rebuild of the blazegraph index.
If you don't want to have to do this then don't pull the new image from
docker hub.
Hi,
It seems that WikimediaBadges, WikibaseQuality, and
WikibaseQualityConstraints are failing tests due to the PHPUnit 6
upgrade. And to make things painful, they all circularly depend upon
each other.
There are 3 patches to fix this:
* WikibaseQuality: https://gerrit.wikimedia.org/r/#/c/426646/
* WikibaseQualityConstraints: https://gerrit.wikimedia.org/r/#/c/426647/
* WikimediaBadges: https://gerrit.wikimedia.org/r/#/c/426649/
The first two will need to be force merged and the third can go through
Jenkins normally. (The specific order doesn't matter that much, two have
to be force merged regardless).
-- Legoktm
*Dear sir, madamWikimedia Nederland is organizing her very first Women Tech
Storm.This event is a small female-only hackathon. It is also open for
non-binary people. It will be held in The Hague from 10-12 May 2018.It will
be an extended weekend filled with hacking together with other interested
developers. The Hackathon has two targeted groups. One group exists of
female and non-binary developers with some experience programming outside
Wikimedia and who would like to learn Wikimedia coding. The other group
consists of women and non-binary people who are already acquainted with
Wikimedia projects and are interested in learning the coding side of the
projects. You can learn how to make a query with SPARQL or learn to master
Python.The Women Tech Storm - part I will be followed by Part II. This
event will be in October/November and is open for all genders.Participation
is free of charge and it includes entrance, meals and hotel: we ask of
people participating to join us in Part II.Please see the registration form
<https://docs.google.com/forms/d/e/1FAIpQLSfxaMsbZGyaM42zunpdEHpeD6knSzpBsZP…>
or our page on mediawiki.org
<https://www.mediawiki.org/wiki/Netherlands_Hackathon_2018_-_Women_Tech_Storm>
for more information. If you have any questions, please email to
Hackathon(a)wikimedia.nl <Hackathon(a)wikimedia.nl>*
On behalf of the work group,
Kind regards,
Michelle Boon
Event Organiser & Community Support
Wikimedia Nederland
Hello all,
This year, the Wikimedia hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2018> will take place
on 18-20 May in Barcelona. Several Wikidata volunteers and members of the
development team will attend. Like last year, there will also be a
documentation
sprint
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2018/Documentation>
where people can work on improving documentation.
- If you are attending, which Wikidata-related projects do you plan to
work on?
- Do you have ideas of features or fixes that should be worked on during
the hackathon?
- Are there documentation pages that need to be improved? (you can also
participate remotely)
Feel free to add your ideas here
<https://www.wikidata.org/wiki/Wikidata:Project_chat#Your_ideas_of_projects_…>,
you can link to Phabricator tickets. Note that the hackathon is only a
3-days event and some projets need a longer time to be achieved ;)
Cheers,
--
Léa Lacroix
Project Manager Community Communication for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Sorry for cross-posting, but I didn't see this on Wikidata mailing lists.
---------- Forwarded message ----------
From: Ariel Glenn WMF <ariel(a)wikimedia.org>
Date: Mon, Mar 5, 2018 at 12:10 PM
Subject: [Wikitech-l] changes coming to large dumps
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, Wikipedia
Xmldatadumps-l <Xmldatadumps-l(a)lists.wikimedia.org>
Please forward wherever you think appropriate.
For some time we have provided multiple numbered pages-articles bz2 file
for large wikis, as well as a single file with all of the contents combined
into one. This is consuming enough time for Wikidata that it is no longer
sustainable. For wikis where the sizes of these files to recombine is "too
large", we will skip this recombine step. This means that downloader
scripts relying on this file will need to check its existence, and if it's
not there, fall back to downloading the multiple numbered files.
I expect to get this done and deployed by the March 20th dumps run. You
can follow along here: https://phabricator.wikimedia.org/T179059
Thanks!
Ariel
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
A while back I filed a task[1] to clean up the
mediawiki/extensions/Wikibase ACL. It hasn't seen any input from the
Wikidata team so I'm raising it here.
Some of the permissions I think are uncontroversial to remove (no one
should be force pushing), but currently there's a disconnect in which
some humans have the ability to force merge, and others don't.
I'd like for it to either be: no humans can force merge (only bots can
merge), or all humans can force merge (for emergencies, etc.)
[1] https://phabricator.wikimedia.org/T183081
Thanks,
-- Legoktm
Hi all!
This is an announcement for a breaking change to the default value of a
parameter of the WikibaseQualityConstraints constraint checking API, to go
live on 26 February 2018. It potentially affects clients that use the
*wbcheckconstraints* API action. (We are not aware of any such clients
apart from the *checkConstraints* gadget, which is not affected.)
Recently, we added a status parameter to the *wbcheckconstraints* API
action, with the intention that API users can declare ahead of time which
results they’re actually interested in, so that other results don’t need to
be sent to them: specifically, for most items the vast majority of results
indicate compliance with a constraint, which we expect most users aren’t
interested in.
*On 26 February 2018, we will change the default value of the status
parameter to violation|warning|bad-parameters.* We assume that most users
of the API will only be interested in results that actually indicate
problems, and this should significantly reduce the size of API responses.
Users who wish to receive all results, regardless of status, should specify
status=* in their API requests.
Our motivation for this change is that we want to enable caching of
constraint check results, but don’t want to bloat the cache with tons of
compliance and not-in-scope results that we don’t even show in the gadget.
With the status parameter, we can store only problematic results in the
cache, while still guaranteeing that the response we send is complete,
since the request indicated that it only needs these results anyways. This
also means that when we enable caching (see phabricator:T184812
<https://phabricator.wikimedia.org/T184812>), only requests with
status=violation|warning|bad-parameters will benefit from it.
Please let us know if you have any questions.
-- Lucas
Relevant tickets:
- phabricator:T183927 <https://phabricator.wikimedia.org/T183927>
- phabricator:T184812 <https://phabricator.wikimedia.org/T184812>
- phabricator:T184937 <https://phabricator.wikimedia.org/T184937>
--
Lucas Werkmeister
Software Developer (Intern)
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
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.