[Wikidata-bugs] [Maniphest] [Commented On] T40790: Split items in Wikidata

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.

Perhaps easy undoing of a merge would be similar to this?
Currently undoing a merge is 4 separate actions.


TASK DETAIL
  https://phabricator.wikimedia.org/T40790

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher, Addshore
Cc: Addshore, Laddo, Wikidata-bugs, jeblad, He7d3r, Denny, Ricordisamoa, 
Lydia_Pintscher, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T59768: action=wbeditentity: Missing datavalue key for snaks should raise a more specified message

[Addshore]

Addshore added a comment.

> got an array with to few constructor arguments


Well, just looking at this and not the code we could simply also say what is 
expected in this exception?
Or the one that we have detected is missing?

Really this should then also be caught and returned as a UsageException..


TASK DETAIL
  https://phabricator.wikimedia.org/T59768

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Ricordisamoa, Aklapper, Wikidata-bugs, Addshore, JanZerebecki, Lucie, 
Lydia_Pintscher, daniel, hoo, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T97928: wbgetclaims api module should provide resolving of redirects

[Addshore]

Addshore added a subscriber: Addshore.

TASK DETAIL
  https://phabricator.wikimedia.org/T97928

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Ricordisamoa, JanZerebecki, Lokal_Profil, Bene, Aklapper, 
Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T99560: The data format xml is not supported by [Special:EntityData] interface.

[Addshore]

Addshore added a subscriber: Lydia_Pintscher.
Addshore added a comment.

@Lydia_Pintscher @daniel @aude this might be a WontFix?


TASK DETAIL
  https://phabricator.wikimedia.org/T99560

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Lydia_Pintscher, daniel, aude, Addshore, eric.brechemier, Aklapper, 
Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77978: [Story] Support unit conversion

[Liuxinyu970226]

Liuxinyu970226 added a subscriber: Liuxinyu970226.

TASK DETAIL
  https://phabricator.wikimedia.org/T77978

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Liuxinyu970226, mxn, Ricordisamoa, Mbch331, Jc3s5h, Aklapper, daniel, 
Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116547: try computing certains wikidata stats via hadoop (e.g. spark) instead of query.w.o (blazegraph)

[JanZerebecki]

JanZerebecki added a comment.

@Christopher can as he created https://phabricator.wikimedia.org/T115242.


TASK DETAIL
  https://phabricator.wikimedia.org/T116547

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Addshore, Christopher, JanZerebecki, Lydia_Pintscher, Aklapper, 
Ricordisamoa, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T76145: Special:Statistic increments number of content pages when new Item is created

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.
Herald added a subscriber: Aklapper.

Well, it is a content page isn't it?


TASK DETAIL
  https://phabricator.wikimedia.org/T76145

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Aklapper, JanZerebecki, Lucie, daniel, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata-bugs] [Maniphest] [Commented On] T116547: try computing certains wikidata stats via hadoop (e.g. spark) instead of query.w.o (blazegraph)

[Christopher Johnson]

It is possible that a Hadoop  architecture could provide the performance
and scalability needed for robust statistical analysis of the Wikidata RDF
datasets.

It is also possible that Jena may have better integration tools with Hadoop
that Blazegraph.

See https://jena.apache.org/documentation/hadoop/

I do not see a direct relationship however between T115242 and performance
other than that the reasoning behind filtering these "boring" objects is
based on the perceived negative performance impact of allowing them to be
queried from a publicly accessible endpoint.

The intent of T115242 is to provide these objects in a dataset to a
"nonpublic" query interface for metrics evaluation only.

The question that should be asked is whether Blazegraph and the WDQS
platform are robust enough for intense stat analysis and if not, why and
what can be done to improve them?
On 26 Oct 2015 10:00, "JanZerebecki" 
wrote:

> JanZerebecki added a comment.
>
> @Christopher can as he created https://phabricator.wikimedia.org/T115242.
>
>
> TASK DETAIL
>   https://phabricator.wikimedia.org/T116547
>
> EMAIL PREFERENCES
>   https://phabricator.wikimedia.org/settings/panel/emailpreferences/
>
> To: JanZerebecki
> Cc: Addshore, Christopher, JanZerebecki, Lydia_Pintscher, Aklapper,
> Ricordisamoa, Wikidata-bugs, aude
>
>
>
> ___
> Wikidata-bugs mailing list
> Wikidata-bugs@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
>
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T53814: allow editing of statements without JavaScript

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.

Needs a special page


TASK DETAIL
  https://phabricator.wikimedia.org/T53814

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Ricordisamoa, Aklapper, Wikidata-bugs, jayvdb, Denny, 
matej_suchanek, Thgoiter, Lydia_Pintscher, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T99560: The data format xml is not supported by [Special:EntityData] interface.

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.

It looks like XML support was dropped in 
https://github.com/wikimedia/mediawiki-extensions-Wikibase/commit/412624c6d15bb9a6bcf89e83e913474f7a0bc8c7#diff-1a2ecd3e19c9e4cf02d7083138cf2713

That references https://phabricator.wikimedia.org/T93353


TASK DETAIL
  https://phabricator.wikimedia.org/T99560

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, eric.brechemier, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T99560: The data format xml is not supported by [Special:EntityData] interface.

[Addshore]

Addshore added subscribers: aude, daniel.
Addshore set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T99560

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: daniel, aude, Addshore, eric.brechemier, Aklapper, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T116298: SPARQL endpoint should gracefully handle cycles and loops in transitive properties

[Smalyshev]

Smalyshev added a project: Discovery-Wikidata-Query-Service-Sprint.

TASK DETAIL
  https://phabricator.wikimedia.org/T116298

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev
Cc: Jheald, Aklapper, daniel, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T116568: page load stats specific to wikidata.org item? pages

[JanZerebecki]

JanZerebecki created this task.
JanZerebecki added subscribers: Ricordisamoa, Aklapper, Lydia_Pintscher, 
JanZerebecki, Addshore, adrianheine, thiemowmde.
JanZerebecki added a project: Wikidata.

TASK DESCRIPTION
  The goal would be to know our JavaScript page load performance in the field.
  Have page load stats specific to wikidata.org item? pages, similar to 
https://grafana-admin.wikimedia.org/dashboard/db/navigation-timing .

TASK DETAIL
  https://phabricator.wikimedia.org/T116568

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: thiemowmde, adrianheine, Addshore, JanZerebecki, Lydia_Pintscher, Aklapper, 
Ricordisamoa, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T85503: Investigate on rollback on items

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.

Nearly a year on now!
Does this still need to be investigated?


TASK DETAIL
  https://phabricator.wikimedia.org/T85503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Ricordisamoa, Aklapper, Lucie, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T85444: get Wikidata added to LOD cloud

[Addshore]

Addshore added a subscriber: Addshore.

TASK DETAIL
  https://phabricator.wikimedia.org/T85444

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucie, Addshore
Cc: Addshore, mkroetzsch, AnjaJentzsch, Aklapper, Lucie, Lydia_Pintscher, 
daniel, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T89863: Merge on-wiki Wikibase/API documentation into Wikibase apihelp strings.

[Addshore]

Addshore added a comment.

I am indeed talking about those JSON blobs.
For wikidata it would be nice to be able to also provide the json blobs that 
are used in the query strings as a pretty json blob so that people can actually 
read them!

As well as the string link and the description it might be nice to be able to 
also provide a pretty example.
I have no idea how this would all work tbh, but it is the only way I see of 
moving forward and making the wikidata api examples more readable.


TASK DETAIL
  https://phabricator.wikimedia.org/T89863

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Anomie, Ricordisamoa, Qgil, Lydia_Pintscher, aude, daniel, Spage, Lucie, 
Addshore, Christopher, Aklapper, Wikidata-bugs, Ltrlg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T92966: Machine readable interface for dumps.wikimedia.org

[Addshore]

Addshore triaged this task as "Normal" priority.

TASK DETAIL
  https://phabricator.wikimedia.org/T92966

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Hydriz, Lokal_Profil, GWicke, ArielGlenn, hoo, Aklapper, daniel, 
Wikidata-bugs, aude, Svick, Nemo_bis, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T92966: Machine readable interface for dumps.wikimedia.org

[Addshore]

Addshore added a subscriber: Addshore.

TASK DETAIL
  https://phabricator.wikimedia.org/T92966

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Hydriz, Lokal_Profil, GWicke, ArielGlenn, hoo, Aklapper, daniel, 
Wikidata-bugs, aude, Svick, Nemo_bis, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T99796: [Bug] site_identifiers tables are corrupt

[Addshore]

Addshore added a subscriber: Addshore.
Addshore added a comment.

@aude LGTM? :D Just a few comments on the patch it looks like! Doesnt need a 
rabase! :)


TASK DETAIL
  https://phabricator.wikimedia.org/T99796

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, gerritbot, hoo, aude, Aklapper, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T77983: [Story] Use localized unit symbols

[Liuxinyu970226]

Liuxinyu970226 added a subscriber: Liuxinyu970226.

TASK DETAIL
  https://phabricator.wikimedia.org/T77983

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Liuxinyu970226, mxn, Aklapper, daniel, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T109584: [Bug] wbsearchentities API defaults to something else than the given language parameter

[nichtich]

nichtich added a comment.

At least the documentation 
 lacks 
a clear description of this complex language negotiation mechanism (`uselang` 
is not mentioned. Meaning of 'strictlanguage' unclear, examples only refer to 
English).

The broken part in design, however, is the lack of language tags in response 
format. Either language should correspond to `uselang` or it should be marked 
explicitly. How should a client know about DE falls back to EN or know about 
the language inferred from a use cookie? As I understand now, a response can 
include strings in at least three different languages at the same time, so it 
would be better to tag every strings with its language.


TASK DETAIL
  https://phabricator.wikimedia.org/T109584

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: nichtich
Cc: nichtich, Lydia_Pintscher, Jonas, Addshore, thiemowmde, Aklapper, 
Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, 
Luke081515, Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[gerritbot]

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 249000 had a related patch set uploaded (by Aude):
Convert refreshLinks to use start/endAtomic

https://gerrit.wikimedia.org/r/249000


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, 
Luke081515, Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115014: [Story] Display Wikidata pages on Special:Nearby with label instead of Q id titles

[gerritbot]

gerritbot added a comment.

Change 244704 abandoned by Jonas Kress (WMDE):
Display labels instead of Q id titles in Wikibase item namespaces

https://gerrit.wikimedia.org/r/244704


TASK DETAIL
  https://phabricator.wikimedia.org/T115014

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: Jonas, Jdlrobson, Florian, gerritbot, daniel, Bene, Lydia_Pintscher, 
thiemowmde, Aklapper, aude, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

> If we have a use case for emitting two secondary events *to the same topic* 
> that were both triggered by the same primary event (user click / request id), 
> then we can generate a new ID for at least one of those events, and record 
> the parent event id in a separate field (ex: par_id). This way, we can get 
> the right deduplication semantics for each of those events.


?  What's the point of the request_id then?  I thought we wanted X-Request-Id 
so that we can easily tie together events generated by the same http request.

Why not just have `request_id` and `uuid` as separate fields that always exist?

> IMHO, the timestamps of the event ID and explicit timestamp (ts or dt) should 
> always match. This makes it a lot simpler to automatically derive dt from id 
> in the producer REST proxy. Other event-specific times (like the save time as 
> recorded by MediaWiki) should imho go into the event body.


Why?  I agree, that specific schemas can define additional timestamps, but what 
is the harm in having a standard one that is set and used semantically by the 
producer?  What if I wanted to explicitly feed a topic with events dated in the 
past, perhaps for backfilling or recovery reasons?


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac, Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T115014: [Story] Display Wikidata pages on Special:Nearby with label instead of Q id titles

[ReleaseTaggerBot]

ReleaseTaggerBot added a project: WMF-deploy-2015-10-27_(1.27.0-wmf.4).

TASK DETAIL
  https://phabricator.wikimedia.org/T115014

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, ReleaseTaggerBot
Cc: Jonas, Jdlrobson, Florian, gerritbot, daniel, Bene, Lydia_Pintscher, 
thiemowmde, Aklapper, aude, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

What do y'all think about keeping these 'framing' fields in a nested object?  
I'm not sure if this is a good or bad idea.  If later we decide we do want to 
use $ref to share common schema fields between different schemas, it'll be 
easier to do so if these are in a separate object.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac, Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T116480: Adding references on Wikidata causes "Uncaught Error: Required option not specified properly"

[intracer]

intracer added a subscriber: intracer.

TASK DETAIL
  https://phabricator.wikimedia.org/T116480

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: intracer
Cc: intracer, matej_suchanek, Aklapper, He7d3r, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115014: [Story] Display Wikidata pages on Special:Nearby with label instead of Q id titles

[gerritbot]

gerritbot added a comment.

Change 246115 abandoned by Jdlrobson:
Show displaytext as title in Special:Nearby [WIP]

Reason:
See https://phabricator.wikimedia.org/T115646

https://gerrit.wikimedia.org/r/246115


TASK DETAIL
  https://phabricator.wikimedia.org/T115014

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: Jonas, Jdlrobson, Florian, gerritbot, daniel, Bene, Lydia_Pintscher, 
thiemowmde, Aklapper, aude, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T116503: Dates are in English formats at nowiki when using property parser function

[Lydia_Pintscher]

Lydia_Pintscher added subscribers: Lydia_Pintscher, hoo, Addshore.

TASK DETAIL
  https://phabricator.wikimedia.org/T116503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Addshore, hoo, Lydia_Pintscher, jeblad, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Merged] T100123: API code 'readonly' not handled

[Legoktm]

Legoktm added a subscriber: Legoktm.
Legoktm merged a task: T116517: Make sure pywikibot handles readonly databases 
properly.

TASK DETAIL
  https://phabricator.wikimedia.org/T100123

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Legoktm
Cc: Legoktm, XZise, Multichill, pywikibot-bugs-list, jayvdb, Aklapper, 
Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115014: [Story] Display Wikidata pages on Special:Nearby with label instead of Q id titles

[gerritbot]

gerritbot added a comment.

Change 246282 merged by jenkins-bot:
Hygiene: Generalise search api requests across MobileFrontend

https://gerrit.wikimedia.org/r/246282


TASK DETAIL
  https://phabricator.wikimedia.org/T115014

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: Jonas, Jdlrobson, Florian, gerritbot, daniel, Bene, Lydia_Pintscher, 
thiemowmde, Aklapper, aude, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T89863: Merge on-wiki Wikibase/API documentation into Wikibase apihelp strings.

[Anomie]

Anomie added a comment.

The pretty-printed JSON I see on 
https://www.mediawiki.org/wiki/Wikibase/API#wbgetentities is all in the output 
from the examples, which will already be pretty-printed when the user actually 
clicks on it to see that output (e.g. here 
).
 Where JSON is occurring in the request URIs, I see no pretty-printing going on 
on that page.

I see some of the pseudo-examples don't even bother with a URI, and just show 
the query parameters as either a partial PHP array or partial JSON object 
format, but even there the JSON blobs being passed as parameters are strings 
rather than being pretty-printed.

Or are you trying to say you want to //add// pretty-printing to the JSON blobs 
in the URI parameters?


TASK DETAIL
  https://phabricator.wikimedia.org/T89863

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Anomie
Cc: Anomie, Ricordisamoa, Qgil, Lydia_Pintscher, aude, daniel, Spage, Lucie, 
Addshore, Christopher, Aklapper, Wikidata-bugs, Ltrlg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[GWicke]

GWicke added a comment.

In https://phabricator.wikimedia.org/T116247#1754698, @Ottomata wrote:

> > If we have a use case for emitting two secondary events *to the same topic* 
> > that were both triggered by the same primary event (user click / request 
> > id), then we can generate a new ID for at least one of those events, and 
> > record the parent event id in a separate field (ex: par_id). This way, we 
> > can get the right deduplication semantics for each of those events.
>
>
> ?  What's the point of the request_id then?  I thought we wanted X-Request-Id 
> so that we can easily tie together events generated by the same http request.
>
> Why not just have `request_id` and `uuid` as separate fields that always 
> exist?


Sure, optionally having a separate request ID (in addition to the event ID) 
sounds good to me as well. We should always require / auto-gereate the event ID 
(and use it for event deduplication, derived event timestamp etc), while the 
reqid can be added to events that are indeed request-triggered.

> > IMHO, the timestamps of the event ID and explicit timestamp (ts or dt) 
> > should always match. This makes it a lot simpler to automatically derive dt 
> > from id in the producer REST proxy. Other event-specific times (like the 
> > save time as recorded by MediaWiki) should imho go into the event body.

> 

> 

> Why?  I agree, that specific schemas can define additional timestamps, but 
> what is the harm in having a standard one that is set and used semantically 
> by the producer?  What if I wanted to explicitly feed a topic with events 
> dated in the past, perhaps for backfilling or recovery reasons?


That's exactly what the event ID and dt should support well. MW edit timetamps 
are low resolution, and in a custom format, which imho makes them less than 
ideal for general event ids / timestamps.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac, GWicke
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T54136: [Epic] Redesign Item UI for Wikidata repo

[Ash_Crow]

Ash_Crow added a subscriber: Ash_Crow.

TASK DETAIL
  https://phabricator.wikimedia.org/T54136

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ash_Crow
Cc: Ash_Crow, Agabi10, Aklapper, MGChecker, Wikidata-bugs, Bene, Nemo_bis, 
Yair_rand, thiemowmde, He7d3r, jayvdb, Denny, Micru, adrianheine, aude, 
Glaisher, matej_suchanek, SJu, Snaterlicious, Ricordisamoa, Yamaha5, 
Lydia_Pintscher, Danmichaelo



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T71753: [Story] Wikibase / Wikidata support on Wikiquote

[Ash_Crow]

Ash_Crow added a subscriber: Ash_Crow.

TASK DETAIL
  https://phabricator.wikimedia.org/T71753

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ash_Crow
Cc: Ash_Crow, Nemo_bis, Ricordisamoa, Aklapper, Wikidata-bugs, Bene, 
Lydia_Pintscher, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[gerritbot]

gerritbot added a comment.

Change 249000 merged by jenkins-bot:
Remove begin/commit transaction calls in refreshLinks.php

https://gerrit.wikimedia.org/r/249000


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, 
Luke081515, Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116381: When enabling GeoData and populating coordinates, CirrusSearch needs to bypass ParserCache

[gerritbot]

gerritbot added a comment.

Change 249036 had a related patch set uploaded (by Aude):
Add --forceParse UpdaterFlag and option in forceSearchIndex script

https://gerrit.wikimedia.org/r/249036


TASK DETAIL
  https://phabricator.wikimedia.org/T116381

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: gerritbot, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T116381: When enabling GeoData and populating coordinates, CirrusSearch needs to bypass ParserCache

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T116381

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: gerritbot, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T105126: Evaluate pattern constraints (safely)

[Popcorndude]

Popcorndude added a comment.

I messed with the constraints a bit, and it would be pretty easy to get up to 
~50% with the constraints you outlined (the numbers I gave before may have 
forgotten to skip newlines, lowering the count). Adding + and * covers 3/4, and 
most of the rest could be rewritten without to much trouble (other than 
https://phabricator.wikimedia.org/P1793 and possibly a few others that are 
really basically impossible).

  (\\.|[^(){}\[\]\\]|\{\d+(,\d+)?\}|\[(?!^)(\\\[|\\\]|[^\[\]])*\])*

should work (though it does let character classes through).

After a bit more fiddling:

https://phabricator.wikimedia.org/P234, https://phabricator.wikimedia.org/P274, 
https://phabricator.wikimedia.org/P305, P353, 
https://phabricator.wikimedia.org/P395, https://phabricator.wikimedia.org/P428, 
https://phabricator.wikimedia.org/P529, https://phabricator.wikimedia.org/P866, 
https://phabricator.wikimedia.org/P998, 
https://phabricator.wikimedia.org/P1190, 
https://phabricator.wikimedia.org/P1256, 
https://phabricator.wikimedia.org/P1257, 
https://phabricator.wikimedia.org/P1472, 
https://phabricator.wikimedia.org/P1612, 
https://phabricator.wikimedia.org/P1662, 
https://phabricator.wikimedia.org/P1793, 
https://phabricator.wikimedia.org/P1986, 
https://phabricator.wikimedia.org/P2015 are the only properties where I don't 
see a way to rewrite the format with your constraints plus infinite repetition 
(i.e. no groups), and with a lot of these there probably is a upper limit, it's 
just that no one bothered to write it into the format.

With that in mind, the list shortens to https://phabricator.wikimedia.org/P234, 
https://phabricator.wikimedia.org/P274, https://phabricator.wikimedia.org/P428, 
https://phabricator.wikimedia.org/P1472, 
https://phabricator.wikimedia.org/P1612, 
https://phabricator.wikimedia.org/P1793 (most of which are probably things you 
didn't intend to support anyway).


TASK DETAIL
  https://phabricator.wikimedia.org/T105126

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Popcorndude
Cc: Nikki, Popcorndude, Aklapper, daniel, Wikidata-bugs, aude, GWicke, csteipp



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)

[kaldari]

kaldari added a comment.

Are we still investigating this or have we reached the conclusion that +/- 0.5 
is the most sensible default for rounding and unit conversion?


TASK DETAIL
  https://phabricator.wikimedia.org/T105623

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: kaldari
Cc: Jonas, JanZerebecki, harej-NIOSH, Thryduulf, Mike_Peel, Jc3s5h, thiemowmde, 
kaldari, daniel, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, 
Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, 
Kelson, MSGJ, Wolfvoll, Aklapper, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[ReleaseTaggerBot]

ReleaseTaggerBot added projects: WMF-deploy-2015-10-27_(1.27.0-wmf.4), 
MW-1.27-release-notes.

TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ReleaseTaggerBot
Cc: gerritbot, demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, 
Luke081515, Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115482: [Task] Enable GeoData extension on wikidata.org

[gerritbot]

gerritbot added a comment.

Change 248868 merged by jenkins-bot:
Enable GeoData extension on Wikidata

https://gerrit.wikimedia.org/r/248868


TASK DETAIL
  https://phabricator.wikimedia.org/T115482

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: dcausse, EBernhardson, daniel, hoo, Lydia_Pintscher, MaxSem, Multichill, 
aude, Wikidata-bugs, Sjoerddebruin, Ricordisamoa, Nemo_bis, Aklapper, 
gerritbot, Matanya, JanZerebecki, Luke081515, Snowolf, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T116459: Parsed summary for Wikidata changes has broken links

[Anomie]

Anomie moved this task to Non-core-API stuff on the MediaWiki-API workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T116459

WORKBOARD
  https://phabricator.wikimedia.org/project/board/200/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Anomie
Cc: daniel, Anomie, Schnark, Aklapper, Wikidata-bugs, aude, jayvdb, Legoktm



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T115482: [Task] Enable GeoData extension on wikidata.org

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T115482

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: dcausse, EBernhardson, daniel, hoo, Lydia_Pintscher, MaxSem, Multichill, 
aude, Wikidata-bugs, Sjoerddebruin, Ricordisamoa, Nemo_bis, Aklapper, 
gerritbot, Matanya, JanZerebecki, Luke081515, Snowolf, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115482: [Task] Enable GeoData extension on wikidata.org

[gerritbot]

gerritbot added a comment.

Change 248868 had a related patch set uploaded (by Aude):
Enable GeoData extension on Wikidata

https://gerrit.wikimedia.org/r/248868


TASK DETAIL
  https://phabricator.wikimedia.org/T115482

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: dcausse, EBernhardson, daniel, hoo, Lydia_Pintscher, MaxSem, Multichill, 
aude, Wikidata-bugs, Sjoerddebruin, Ricordisamoa, Nemo_bis, Aklapper, 
gerritbot, Matanya, JanZerebecki, Luke081515, Snowolf, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T95686: [Task] write a maintenance script to migrate properties from string to new identifier datatype

[Ricordisamoa]

Ricordisamoa added a comment.

In https://phabricator.wikimedia.org/T95686#1751996, @daniel wrote:

> I can only recommend against using data from XML dumps. We do not give *any* 
> guarantees to the format of the content blobs you find in there. They may 
> change without notice, and contain serializations in various forms.


Where can I find reliable dumps of Wikidata's full history?


TASK DETAIL
  https://phabricator.wikimedia.org/T95686

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo, Ricordisamoa
Cc: JanZerebecki, jayvdb, gerritbot, MGChecker, daniel, Multichill, 
Ricordisamoa, Liuxinyu970226, Aklapper, Lydia_Pintscher, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T116459: Parsed summary for Wikidata changes has broken links

[Anomie]

Anomie added subscribers: Anomie, daniel.
Anomie added a comment.

This ties in with T111676: [Task] Linker::formatComment should support comments 
that refer to another wiki. , 
although I'm not seeing a way to actually make use of that here. Probably also 
ties in with T108688: [Story] meaningful edit summaries on the client 
.


TASK DETAIL
  https://phabricator.wikimedia.org/T116459

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Anomie
Cc: daniel, Anomie, Schnark, Aklapper, Wikidata-bugs, aude, jayvdb, Legoktm



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T76145: Special:Statistic increments number of content pages when new Item is created

[Addshore]

Addshore added a comment.

So in-fact the issue is with initSiteStats.php?


TASK DETAIL
  https://phabricator.wikimedia.org/T76145

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Aklapper, JanZerebecki, Lucie, daniel, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

To avoid possible conflicts, I'd suggest we call this not just `id`.  How about 
`uuid`?  That's what EventLogging capsule does: 
https://meta.wikimedia.org/wiki/Schema:EventCapsule


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T116185: When running updateSearchIndexConfig.php for test.wikidata, the script chokes on the analyzers

[ReleaseTaggerBot]

ReleaseTaggerBot added a project: WMF-deploy-2015-10-13_(1.27.0-wmf.3).

TASK DETAIL
  https://phabricator.wikimedia.org/T116185

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ReleaseTaggerBot
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

I'm still a little confused about how this reqid/id will work?  You are 
suggesting that it comes from the x-request-id that we want varnish to set, 
right?  Won't this mean that multiple events (those produced during the same 
http request at varnish level) will have the same reqid?


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T76145: Special:Statistic increments number of content pages when new Item is created

[JanZerebecki]

JanZerebecki added a comment.

The problem here is that the maintenance script recomputes the number 
differently than the incremental update process.


TASK DETAIL
  https://phabricator.wikimedia.org/T76145

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Addshore, Aklapper, JanZerebecki, Lucie, daniel, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

Also, this is just a personal preference, but I'd prefer if we had a convention 
differentiating integer/second based 'timestamps' and string/date based 
'datetimes'.  For webrequest data, the ISO8601 is called `dt`.

https://wikitech.wikimedia.org/wiki/Analytics/Data/Webrequest


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

> Hm, I think duplicates should be detected based on the content of the message 
> itself and the time stamp.


EventLogging explicitly uses the uuid in MySQL as a unique key for all tables.  
Having it standardized on a single field means that the unique index creation 
is standard for all events.  This keeps duplicate events from ever being 
inserted into a single table.

MySQL unique indexes aren't really a consideration here, and I'd be fine if we 
could define a unique index across multiple keys, but I'd want those keys to be 
standardized in the framing of all events.  A `uuid` like EventLogging does 
would be an easy way to do this.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T115325: [Task] run refreshLinks on wikidatawiki

[aude]

aude claimed this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T115325

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: jeremyb, Lydia_Pintscher, Aklapper, aude, thiemowmde, daniel, hoo, Jonas, 
JanZerebecki, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T115325: [Task] run refreshLinks on wikidatawiki

[aude]

aude moved this task to Doing on the Wikidata-Sprint-2015-10-13 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T115325

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1551/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: jeremyb, Lydia_Pintscher, Aklapper, aude, thiemowmde, daniel, hoo, Jonas, 
JanZerebecki, Wikidata-bugs



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

> Manual schema versions. We could increase the schema version every time we 
> change something in the schema. Easy to achieve but it's also easy to forget 
> to bump the version when something has been changed.


FWIW, this is how EventLogging does it, although the revisions are managed by 
Mediawiki revision IDs.  I'm still not sure, but I think it would make sense to 
keep each schema iteration present in the HEAD of the repo, so it would be 
fairly easy to manually bump revision IDs.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116185: When running updateSearchIndexConfig.php for test.wikidata, the script chokes on the analyzers

[aude]

aude added a comment.

backported the --justMapping patch and the problem is resolved now


TASK DETAIL
  https://phabricator.wikimedia.org/T116185

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T116485: Echo should not notify the user about his own linking activity

[Legoktm]

Legoktm edited the task description.
Legoktm triaged this task as "High" priority.
Legoktm set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T116485

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Legoktm
Cc: Sjoerddebruin, He7d3r, Aklapper, Luke081515, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T116247: Define edit related events for change propagation

[mobrovac]

mobrovac edited the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T104750: Low year numbers can be confused with days of the month

[gerritbot]

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 236010 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Avoid exponential years in MwTimeIsoFormatter

https://gerrit.wikimedia.org/r/236010


TASK DETAIL
  https://phabricator.wikimedia.org/T104750

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, thiemowmde, Nikki, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T104750: Low year numbers can be confused with days of the month

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T104750

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, thiemowmde, Nikki, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Ottomata]

Ottomata added a comment.

> I don't see a conflicting problem with id (even though id is a JSONSchema 
> keyword, but it relates to the schema, not its properties, so we're good 
> there). uuid is not a good choice, IMHO, it's like naming a field string 
> because its value is a string. The most accurate name would be reqid, since 
> that's what it is.


Ok cool, if that's the case, then `reqid` or even `request_id` (I like long 
names...what can I say?) sounds good.  EventLogging gives every event a really 
unique uuid, based on the message itself, so that you can always uniquely ID 
any event.  It mainly uses this for avoiding duplicates.  Can we add this to 
the description too?   See: 
https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/server/eventlogging/parse.py#L69


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Ottomata
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T104750: Low year numbers can be confused with days of the month

[gerritbot]

gerritbot added a comment.

Change 248895 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Always output 4-digit years in dates like "1 January 2"

https://gerrit.wikimedia.org/r/248895


TASK DETAIL
  https://phabricator.wikimedia.org/T104750

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, thiemowmde, Nikki, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[mobrovac]

mobrovac added a comment.

In https://phabricator.wikimedia.org/T116247#1753398, @Ottomata wrote:

> Ok cool, if that's the case, then `reqid` or even `request_id` (I like long 
> names...what can I say?) sounds good.


`request_id` works for me. I also happen to like //snake_case//. Let's 
standardise on that?

> EventLogging gives every event a really unique uuid, based on the message 
> itself, so that you can always uniquely ID any event.  It mainly uses this 
> for avoiding duplicates.  Can we add this to the description too?   See: 
> https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/server/eventlogging/parse.py#L69


Hm, I think duplicates should be detected based on the content of the message 
itself and the time stamp.

In https://phabricator.wikimedia.org/T116247#1753399, @Eevans wrote:

> I don't object to including the redundant iso8601 timestamp, I just wanted to 
> make sure it was clear that it's not at all difficult to extract a timestamp 
> from a v1 UUID (and even less onerous when you figure that code like this 
> would be tucked away in a helper somewhere).


I'm not so sure actually that these will always be redundant. I think the 
request ID should be persisted to track the same event throughout the system. 
Imagine a user clicks on something which produces an event in the queue and 
that event triggers another one to be enqueued. Then, both of them should have 
the same request id, but different time stamps, shouldn't they?


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unblock] T115482: [Task] Enable GeoData extension on wikidata.org

[aude]

aude closed blocking task T116185: When running updateSearchIndexConfig.php for 
test.wikidata, the script chokes on the analyzers as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T115482

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: dcausse, EBernhardson, daniel, hoo, Lydia_Pintscher, MaxSem, Multichill, 
aude, Wikidata-bugs, Sjoerddebruin, Ricordisamoa, Nemo_bis, Aklapper, 
gerritbot, Matanya, JanZerebecki, Luke081515, Snowolf, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T116185: When running updateSearchIndexConfig.php for test.wikidata, the script chokes on the analyzers

[aude]

aude closed this task as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T116185

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T116185: When running updateSearchIndexConfig.php for test.wikidata, the script chokes on the analyzers

[aude]

aude added a project: Wikidata-Sprint-2015-10-13.

TASK DETAIL
  https://phabricator.wikimedia.org/T116185

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T116185: When running updateSearchIndexConfig.php for test.wikidata, the script chokes on the analyzers

[aude]

aude moved this task to Done on the Wikidata-Sprint-2015-10-13 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T116185

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1551/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: JanZerebecki, aude, Aklapper, Wikidata-bugs, Deskana, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[mobrovac]

mobrovac added a comment.

In https://phabricator.wikimedia.org/T116247#1752974, @Ottomata wrote:

> I'm still a little confused about how this reqid/id will work?  You are 
> suggesting that it comes from the x-request-id that we want varnish to set, 
> right?  Won't this mean that multiple events (those produced during the same 
> http request at varnish level) will have the same reqid?


That's the idea, yes, so that different requests that fire off in the system 
can be tied to the same request ID.

In https://phabricator.wikimedia.org/T116247#1752975, @Ottomata wrote:

> To avoid possible conflicts, I'd suggest we call this not just `id`.  How 
> about `uuid`?  That's what EventLogging capsule does: 
> https://meta.wikimedia.org/wiki/Schema:EventCapsule


I don't see a conflicting problem with `id` (even though `id` is a JSONSchema 
keyword, but it relates to the schema, not its properties, so we're good 
there). `uuid` is not a good choice, IMHO, it's like naming a field //string// 
because its value is a string. The most accurate name would be `reqid`, since 
that's what it is.

In https://phabricator.wikimedia.org/T116247#1752979, @Ottomata wrote:

> Also, this is just a personal preference, but I'd prefer if we had a 
> convention differentiating integer/second based 'timestamps' and string/date 
> based 'datetimes'.  For webrequest data, the ISO8601 is called `dt`.


That can be seen from the fields type, I guess: if it's integer, it's a unix 
time stamp, otherwise an ISO8601 date. But I see your point. Will `s/ts/dt/` in 
the description.

In https://phabricator.wikimedia.org/T116247#1753027, @Ottomata wrote:

> Also, over at T88459#1694274 
> , I commented:
>
> If we adopt a convention of always storing schema name and/or revision in the 
> schemas themselves, then we can do like EventLogging does and infer and 
> validate the schema based on this value. This would especially be helpful in 
> associating a message with an Avro Schema when serializing into binary.


I'd be in favour of that as well. Two ideas:

- Manual schema versions. We could increase the schema version every time we 
change something in the schema. Easy to achieve but it's also easy to forget to 
bump the version when something has been changed.
- Use the git commit SHA1. Here the event bus would attach the current git 
commit SHA1 to the message. Also rather straightforward to achieve. The problem 
here might be that different messages for the same topic might have different 
SHA1's, but still point to the same version of the schema.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[Eevans]

Eevans added a comment.

In https://phabricator.wikimedia.org/T116247#1749452, @Ottomata wrote:

> Right, but how would you do this in say, Hive?  Or in bash?


In bash:

  $ sudo apt-get install uuid
  $ ID=$(uuid -v 1)
  $ grep "content: time" <(uuid -d $ID)
  content: time:  2015-10-26 15:16:20.026434.0 UTC

In Java (applicable to Hive?):

  import java.util.Date;
  import java.util.UUID;
  
  public class Time {
  public static void main(String...args) {
  UUID id = UUID.fromString(args[0]);
  double timestamp = (id.timestamp() - 0x01b21dd213814000L)*100/1e6;
  System.out.println(new Date((long)timestamp));
  }
  }

Anyway, I don't object to including the redundant iso8601 timestamp, I just 
wanted to make sure it was clear that it's not at all difficult to extract a 
timestamp from a v1 UUID (and even less onerous when you figure that code like 
this would be tucked away in a helper somewhere).


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Eevans
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[GWicke]

GWicke added a comment.

> If we adopt a convention of always storing schema name and/or revision in the 
> schemas themselves, then we can do like EventLogging does and infer and 
> validate the schema based on this value. This would especially be helpful in 
> associating a message with an Avro Schema when serializing into binary.


The topic configuration will take precedence, so we wouldn't use 
client-supplied values for these fields, and would basically just write a part 
of the topic configuration into each event. We also decided that we will only 
evolve schemas in backwards-compatible ways. In practice, this means that we'll 
only add fields, and the latest schema will be able to validate both new and 
old data in each topic.

@ottomata, which value do you see in recording the schema configured for a 
topic at enqueue time in each event?


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GWicke
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T116485: Echo should not notify the user about his own linking activity

[Legoktm]

Legoktm claimed this task.
Legoktm edited projects, added Collaboration-Team-Current; removed 
Collaboration-Team-Backlog.

TASK DETAIL
  https://phabricator.wikimedia.org/T116485

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Legoktm
Cc: Sjoerddebruin, He7d3r, Aklapper, Luke081515, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T116247: Define edit related events for change propagation

[GWicke]

GWicke added a comment.

> I'm not so sure actually that these will always be redundant. I think the 
> request ID should be persisted to track the same event throughout the system. 
> Imagine a user clicks on something which produces an event in the queue and 
> that event triggers another one to be enqueued. Then, both of them should 
> have the same request id, but different time stamps, shouldn't they?


IMHO, the timestamps of the event ID and explicit timestamp (`ts` or `dt`) 
should always match. This makes it a lot simpler to automatically derive `dt` 
from `id` in the producer REST proxy.

If we have a use case for emitting two secondary events *to the same topic* 
that were both triggered by the same primary event (user click / request id), 
then we can generate a new ID for at least one of those events, and record the 
parent event id in a separate field (ex: `par_id`). This way, we can get the 
right deduplication semantics for each of those events.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GWicke
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T116622: Duplicate rows in Wikidata sparql

[Fnielsen]

Fnielsen created this task.
Fnielsen added a subscriber: Fnielsen.
Fnielsen added a project: Wikidata.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
  I am getting duplicate rows on a specific SPARQL query with 
query.wikidata.org. The duplicates seem to arise when a value has been edited 
in the references. Besides a BlazeGraph issue this could be my misunderstanding 
of SPARQL.
  
  For a query that has the issue see: 
https://www.mediawiki.org/wiki/Talk:Wikidata_query_service and the below:
  
  
PREFIX wikibase: 
PREFIX wd:  
PREFIX wdt: 
PREFIX rdfs: 
prefix pr: 
PREFIX wd: 
PREFIX wdt: 
PREFIX wikibase: 
PREFIX p: 
PREFIX v: 
PREFIX q: 
PREFIX rdfs: 
PREFIX prov:  
  
SELECT ?work ?workLabel ?author ?authorLabel ?genre ?location 
?locationLabel ?geo ?location_statement ?citat  WHERE {
  ?work wdt:P31/wdt:P279* wd:Q386724 . 
  ?work wdt:P50 ?author .
  ?work p:P840 ?location_statement .
  ?location_statement v:P840 ?location .
  ?location wdt:P17 wd:Q35 .
  ?location wdt:P625 ?geo . 
  OPTIONAL {
?location_statement prov:wasDerivedFrom ?ref .
?ref pr:P1683 ?citat .
  }

  SERVICE wikibase:label { bd:serviceParam wikibase:language "da,en" . }
}

TASK DETAIL
  https://phabricator.wikimedia.org/T116622

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Fnielsen
Cc: Fnielsen, Aklapper, Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T116611: Enable the Wikidata personal talk opt-in Beta Feature on Wikidata.org

[Catrope]

Catrope added subscribers: Catrope, Quiddity.

TASK DETAIL
  https://phabricator.wikimedia.org/T116611

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Catrope
Cc: Quiddity, Catrope, Aklapper, Lydia_Pintscher, Jdforrester-WMF, Matanya, 
Luke081515, Wikidata-bugs, Snowolf, matthiasmullie, aude, Gryllida, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T116611: Enable the Wikidata personal talk opt-in Beta Feature on Wikidata.org

[Catrope]

Catrope added a subscriber: Trizek-WMF.

TASK DETAIL
  https://phabricator.wikimedia.org/T116611

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Catrope
Cc: Trizek-WMF, Quiddity, Catrope, Aklapper, Lydia_Pintscher, Jdforrester-WMF, 
Matanya, Luke081515, Wikidata-bugs, Snowolf, matthiasmullie, aude, Gryllida, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T116622: Duplicate rows in Wikidata sparql

[Fnielsen]

Fnielsen added a project: Wikidata-Query-Service.
Fnielsen set Security to None.
Herald added a project: Discovery.

TASK DETAIL
  https://phabricator.wikimedia.org/T116622

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Fnielsen
Cc: Fnielsen, Aklapper, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, 
Deskana, Manybubbles



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[demon]

demon added a subscriber: demon.
demon added a comment.
Herald added a subscriber: Aklapper.

This has started showing up fairly regularly again.


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: demon
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[demon]

demon added a project: Wikimedia-log-errors.

TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: demon
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, Luke081515, 
Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[demon]

demon moved this task to Production Impact on the Wikimedia-log-errors 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T75456

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1055/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: demon
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, Luke081515, 
Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[aude]

aude added a comment.

i was running refresh links to populate page_props (page_image) and geo_tags, 
but maybe we can do this in an alternative way


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, Luke081515, 
Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[aude]

aude added a comment.

https://gerrit.wikimedia.org/r/#/c/248061/ is my proposed alternative :)  if 
sensible approach, I can add some tests and we can go with it.


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, Luke081515, 
Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T116611: Enable the Wikidata personal talk opt-in Beta Feature on Wikidata.org

[Jdforrester-WMF]

Jdforrester-WMF triaged this task as "Normal" priority.
Jdforrester-WMF set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T116611

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jdforrester-WMF
Cc: Aklapper, Lydia_Pintscher, Jdforrester-WMF, Matanya, Luke081515, 
Wikidata-bugs, Snowolf, matthiasmullie, aude, Gryllida, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T113731: [Task] make core wmf branches only use submodule branches that run with it in CI

[hashar]

hashar added a subscriber: hashar.

TASK DETAIL
  https://phabricator.wikimedia.org/T113731

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hashar
Cc: hashar, gerritbot, mmodell, aude, hoo, Krinkle, JanZerebecki, Aklapper, 
Wikidata-bugs, AndyRussG, Pcoombe, atgo, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T113731: [Task] make core wmf branches only use submodule branches that run with it in CI

[hashar]

hashar edited projects, added Continuous-Integration-Config; removed 
Continuous-Integration-Infrastructure.

TASK DETAIL
  https://phabricator.wikimedia.org/T113731

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hashar
Cc: hashar, gerritbot, mmodell, aude, hoo, Krinkle, JanZerebecki, Aklapper, 
Wikidata-bugs, AndyRussG, Pcoombe, atgo, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T105126: Evaluate pattern constraints (safely)

[daniel]

daniel added a comment.

In https://phabricator.wikimedia.org/T105126#1752074, @Popcorndude wrote:

> Those criteria accept 62 (8%) of the current constraints.
>  Adding character classes (\d is everywhere) brings it up to 166 (23%)


Yea, I can imagine. My goal was to suggest a minimal set of patterns that would 
allow us to cover all the use cases, not a set that would cover most current 
patterns. The idea is to force people to use simpler tools when making the 
patterns. That prevents patterns with bad runtime behavior.


TASK DETAIL
  https://phabricator.wikimedia.org/T105126

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Nikki, Popcorndude, Aklapper, daniel, Wikidata-bugs, aude, GWicke, csteipp



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T113731: [Task] make core wmf branches only use submodule branches that run with it in CI

[hashar]

hashar added a comment.

The idea of mediawiki-extensions-* jobs was to test ahead of time what the 
result of wmf branch will be. As early as when a patch is proposed to `master` 
branches.

I proposed it back in Nov 2014 
https://www.mediawiki.org/wiki/Requests_for_comment/Extensions_continuous_integration
 and it is half completed :-/

The idea was to have a reference of extensions/skins to be deployed on 
Wikimedia production. I though the list in make-wmf-branch would be of good use 
since we update it before creating the branches. From there we have several 
scenario:

Adding a new extension to make-wmf-branch
-

Propose a patch that which adds it to make-wmf-branch
We trigger a job that has all the extensions listed in make-wmf-branch using 
their `master` branches
Run the tests.

If tests pass, that mean the extension can be added to the next wmf branch 
since it will be made of the master branches.

That scenario needs a reference of extensions/skins to clone outside of the wmf 
branches.

Patch to extensions master branches
---

Clone of the extensions listed in make-wmf-branch at `master`.
Run the tests.
A failure will prevent the tests from falling in the next wmf branch

That scenario needs a reference of extensions/skins to clone outside of the wmf 
branches.

Patch to mediawiki wmf branches
---

There we can simply use the submodules of mediawiki/core

- git submodule update --init --recursive
- include all extensions and skins
- run the tests

If that pass the patch to mediawiki/core wmf branch get merged.

Patch to extensions wmf branches


That is where it becomes scary.

We would clone mediawiki/core wmf branch and process submodules

Then read the /.gitmodules and have zuul-cloner apply the proper references 
crafted by gate-and-submit. One trouble is that it might fall back a tip of a 
branch that has been updated in the extension but has not yet updated the 
submodule.

Example:

- extension A updates its wmf branch  mediawiki/core wmf branch is NOT updated
- extension B updates its wmf branch
- a patch proposes to update B in mediawiki/core wmf branch

When doing the submodule update, extension A does no't include the patch above. 
But zuul-cloner will checkout the branch from the repo.

--

Potentially we could have mediawiki/core wmf branches to be automatically 
updated whenever a patch is merged in an extension wmf branch.

Or we could get rid of the submodules in mediawiki wmf branches and just use 
the tip of the wmf branches from each extensions.


TASK DETAIL
  https://phabricator.wikimedia.org/T113731

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hashar
Cc: hashar, gerritbot, mmodell, aude, hoo, Krinkle, JanZerebecki, Aklapper, 
Wikidata-bugs, AndyRussG, Pcoombe, atgo, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T114656: [Bug] Frequent "request has exceeded memory limit" fatals in EntityUsageTable::extractProperty

[demon]

demon moved this task to Done on the Wikimedia-log-errors workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T114656

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1055/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo, demon
Cc: gerritbot, hoo, Aklapper, daniel, Luke081515, Wikidata-bugs, aude, Jay8g, 
Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T116611: Enable the Wikidata personal talk opt-in Beta Feature on Wikidata.org

[Jdforrester-WMF]

Jdforrester-WMF created this task.
Jdforrester-WMF added subscribers: Jdforrester-WMF, Lydia_Pintscher.
Jdforrester-WMF added projects: Collaboration-Team-Current, Wikidata, 
Wikimedia-Site-Requests, Flow.
Jdforrester-WMF moved this task to Untriaged on the Collaboration-Team-Current 
workboard.
Herald added subscribers: Matanya, Aklapper.

TASK DESCRIPTION
  Discussed with Lydia (copied).

TASK DETAIL
  https://phabricator.wikimedia.org/T116611

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1384/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jdforrester-WMF
Cc: Aklapper, Lydia_Pintscher, Jdforrester-WMF, Matanya, Luke081515, 
Wikidata-bugs, Snowolf, matthiasmullie, aude, Gryllida, Krenair, MarcoAurelio



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T116611: Enable the Wikidata personal talk opt-in Beta Feature on Wikidata.org

[Luke081515]

Luke081515 moved this task to Special handling on the Wikimedia-Site-Requests 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T116611

WORKBOARD
  https://phabricator.wikimedia.org/project/board/178/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Luke081515
Cc: Aklapper, Lydia_Pintscher, Jdforrester-WMF, Matanya, Luke081515, 
Wikidata-bugs, Snowolf, matthiasmullie, aude, Gryllida, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T40971: API: Access old versions of items

[Legoktm]

Legoktm added a comment.

I've been thinking about this a bit, and it would be really nice if we could 
just use prop=revisions and get the nice wbgetentities output. Instead of 
outputing the stored serialized text which is really a JSON blob, it could 
output the actual JSON structure. That way API clients could use the normal 
data access method instead of having to implement fetching old revisions, etc., 
again in a different manner.


TASK DETAIL
  https://phabricator.wikimedia.org/T40971

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Legoktm
Cc: Ladsgroup, Aklapper, Wikidata-bugs, Legoktm, Addshore, jayvdb, Denny, 
Ricordisamoa, daniel, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T75456: DatabaseBase::deadlockLoop: Transaction already in progress (from RefreshLinks::fixLinksFromArticle)

[aude]

aude added a comment.

wikidatawiki wfLogDBError ERROR: DatabaseBase::deadlockLoop: Transaction 
already in progress (from RefreshLinks::fixLinksFromArticle),  performing 
implicit commit! 
{"db_server":"10.64.32.28","db_name":"wikidatawiki","db_user":"wikiadmin","method":"DatabaseBase::begin","fname":"DatabaseBase::deadlockLoop"}


TASK DETAIL
  https://phabricator.wikimedia.org/T75456

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: demon, Aklapper, Wikidata-bugs, aude, Lydia_Pintscher, hoo, Luke081515, 
Jay8g, Krenair, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T114576: [Bug] OutOfBoundsException triggered by ParserOutputDataUpdater

[demon]

demon moved this task to Done on the Wikimedia-log-errors workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T114576

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1055/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo, demon
Cc: gerritbot, Aklapper, hoo, Luke081515, Wikidata-bugs, aude, Jay8g, Krenair, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T116247: Define edit related events for change propagation

[mobrovac]

mobrovac claimed this task.
mobrovac added a comment.

PR 5  proposes the schema 
definitions for the basic MW events: article edit / delete / undelete / move 
and revision visibility changes.


TASK DETAIL
  https://phabricator.wikimedia.org/T116247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac
Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, 
mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, 
Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, 
jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs