[Wikidata-bugs] [Maniphest] [Commented On] T173710: Job queue is increasing non-stop

2017-10-28 Thread Jack_who_built_the_house 
Jack_who_built_the_house added a comment.
On ruwiki, many editors are complaining about slow updating of pages with their templates. We have a huge job queue, while no popular templates/modules have been changed in the last days.

Please tell, is there any advice that could be given to us, as well as other local communities suffering from this?TASK DETAILhttps://phabricator.wikimedia.org/T173710EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jack_who_built_the_houseCc: zhuyifei1999, RP88, Jack_who_built_the_house, elukey, debt, mxn, Daimona, YOUR1, Tbayer, mobrovac, Nikerabbit, Mholloway, Legoktm, ema, Joe, GWicke, Nemo_bis, Andreasmperu, BBlack, Peachey88, Liuxinyu970226, daniel, Stashbot, Agabi10, Daniel_Mietchen, XXN, Pasleim, Bugreporter, Sjoerddebruin, Magnus, Mr.Ibrahem, gerritbot, EBernhardson, Esc3300, jcrespo, WMDE-leszek, Jdforrester-WMF, Krinkle, aaron, fgiunchedi, Aklapper, Ladsgroup, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, EBjune, Vali.matei, Avner, Lewizho99, Zppix, Maathavan, Gehel, FloNight, Eevans, Hardikj, Wikidata-bugs, aude, jayvdb, faidon, Mbch331, Jay8g, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread BBlack 
BBlack added a comment.
A while after the above, @hoo started focusing on a different aspect of this we've been somewhat ignoring as more of a side-symptom: that there tend to be a lot of sockets in a strange state on the "target" varnish, to various MW nodes.  They look strange on both sides, in that they spend significant time in the CLOSE_WAIT state on the varnish side and FIN_WAIT_2 on the MW side.  This is a consistent state between the two nodes, but it's not usually one that non-buggy application code spends much time in.  In this state, the MW side has sent FIN, Varnish has seen that and sent FIN+ACK, but Varnish has not yet decided to send its own FIN to finish the active closing process, and MW is still waiting on it.

While staring at the relevant Varnish code to figure out why or how it would delay closing in this case, it seemed like it was possible in certain cases related to connections in the VBC_STOLEN state.  Instead of closing immediately, in some such cases it defers killing the socket until some future eventloop event fires, which could explain the closing-delays under heavy load (and we know Varnish is backlogged in some senses when the problem is going on, because mailbox lag rises indefinitely).  All of that aside, at some point while staring at related code I realized that do_stream behaviors can influence some related things as well, and we had a recent related VCL patch

The patch in question was https://gerrit.wikimedia.org/r/#/c/386616/ , which was merged around 14:13 Oct 26, about 4.5 hours before the problems were first noticed (!).

I manually reverted the patch on cp1067 (current target problem node) as a test, and all of the CLOSE_WAIT sockets disappeared shortly, never to return.  I reverted the whole patch through gerrit shortly afterwards, so that's permanent now across the board.

I think there's a strong chance this patch was the catalyst for start of the problems.  At the very least, it was exacerbating the impact of the problems.  If it turns out to be the problem, I think we still have more post-mortem investigation to do here, because the issues that raises are tricky.  If it's just exacerbating, I think it's still useful to think about why it would, because that may help pin down the real problem.

Operating on the assumption that it's the catalyst and diving a little deeper on that angle:

The patch simply turned off do_stream behavior when the backend-most Varnish was talking to application layer services, when the applayer response did not contain a Content-Length header.  Turning off do_stream makes Varnish act in a store-and-forward mode for the whole response, rather than forwarding bytes onwards to upstream clients as they arrive from the application.  The benefit we were aiming for there was to have Varnish calculate the value of the missing Content-Length so that we can make more-informed cache-tuning decisions at higher layers.  Minor performance tradeoffs aside, turning off do_stream shouldn't be harmful to any of our HTTP transactions under "reasonable" assumptions (more later on what "reasonable" is here).  In fact, that was the default/only mode our caches operated in back when we were running Varnish 3, but streaming became the default for the text cluster when it switched to Varnish 4 just under a year ago.  So this was "OK" a year ago, but clearly isn't ok for some requests today.

That there was always a singular chash target within the text cluster for the problems also resonates here: there's probably only one special URI out there which breaks the "reasonable" assumption.  Another oddity that we didn't delve into much before was that when we restarted the problematic varnish, it only depooled for a short period (<1 min), yet the problem would move *permanently* to its next chash target node and stay there even after the previous target node was repooled.  This might indicate that the clients making these requests are doing so over very-long-lived connections, and even that the request->response cycle itself must be very-long-lived  It moves via re-chashing when a backend is restarted, but doesn't move on repool because everything's still connected and transacting...

My best hypothesis for the "unreasonable" behavior that would break under do_stream=false is that we have some URI which is abusing HTTP chunked responses to stream an indefinite response.  Sort of like websockets, but using the normal HTTP protocol primitives.  Client sends a request for "give me a live stream of some events or whatever", and the server periodically sends new HTTP response chunks to the client containing new bits of the event feed.  Varnish has no way to distinguish this behavior from normal chunked HTTP (where the response chunks will eventually reach a natural end in a reasonable timeframe), and in the do_stream=false store-and-forward mode, Varnish would consume this chunk stream into its own memory buffers indefinitely, waiting for the stream to end

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread BBlack 
BBlack added a comment.
Updates from the Varnish side of things today (since I've been bad about getting commits/logs tagged onto this ticket):


18:15 - I took over looking at today's outburst on the Varnish side
The current target at the time was cp1053 (after elukey's earlier restart of cp1055 varnish-be above)
18:21 - I manually reduced the backend timeouts for api+appservers to from defaults of connect/firstbyte/betweenbytes of 5/180/60 to 3/20/10
cp1053 had already been under assault for quite a while though, and this didn't seem to help much.
18:39 - restarted varnish-be on cp1053 to clear it of issues and move to a new target
18:41 - identified cp1065 as the new target (more on identifying these below!)
18:42 - Merged->deployed https://gerrit.wikimedia.org/r/#/c/387024/ to apply the shorter-timeouts workaround above to all text caches
at this point, cp1065 was showing various signs of the issue (rising connection counts + mailbox lag), but connection counts stabilized much lower than before, ~200-300 instead of rising towards ~3K, an apparent success of the timeout-reduction mitigation.
18:56 - Identified the first slow-running requests in cp1065 logs with the reduced timeouts:


18:56 < bblack> -   BereqURL   
/w/api.php?action=""
18:56 < bblack> -   BereqHeaderHost: www.wikidata.org
18:56 < bblack> -   Timestamp  Bereq: 1509216884.761646 0.42 0.42
18:56 < bblack> -   Timestamp  Beresp: 1509216965.538549 80.776945 80.776903
18:56 < bblack> -   Timestamp  Error: 1509216965.538554 80.776950 0.05
18:56 < bblack> -   Timestamp  Start: 1509216970.911803 0.00 0.00


after this, identified several other slow requests.  All were for the same basic flow-parsoid-utils API + www.wikidata.org
19:39 - hoo's parsoid timeout reduction for Flow (above) hits
19:39 - restarted varnish-backend on cp1065 due to rising mailbox lag
19:41 - new target seems to be cp1067, briefly, but within a minute or two it recovers to normal state and stops exhibiting the symptoms much?  Apparently the problem-causing traffic may have temporarily died off on its own.


For future reference by another opsen who might be looking at this: one of the key metrics that identifies what we've been calling the "target cache" in eqiad, the one that will (eventually) have issues due to whatever bad traffic is currently mapped through it, is by looking at the connection counts to appservers.svc.eqiad.wmnet + api-appservers.svc.eqiad.wmnet on all the eqiad cache nodes.  For this, I've been using:

bblack@neodymium:~$ sudo cumin A:cp-text_eqiad 'netstat -an|egrep "10\.2\.2\.(1|22)"|awk "{print \$5}"|sort|uniq -c|sort -n'

Which during the latter/worst part of cp1053's earlier target-period produced output like:

= NODE GROUP = 
(1) cp1068.eqiad.wmnet 
- OUTPUT of 'netstat -an|egre...|uniq -c|sort -n' -
  1 10.2.2.18:8080 
 15 10.2.2.17:7231 
 79 10.2.2.1:80
111 10.2.2.22:80
= NODE GROUP = 
(1) cp1066.eqiad.wmnet 
- OUTPUT of 'netstat -an|egre...|uniq -c|sort -n' -
  1 10.2.2.18:8080 
 14 10.2.2.17:7231 
 92 10.2.2.1:80
111 10.2.2.22:80
= NODE GROUP = 
(1) cp1052.eqiad.wmnet

[Wikidata-bugs] [Maniphest] [Created] T179241: Enable the ArticlePlaceholder for Northern Sami (sewiki)

2017-10-28 Thread hoo 
hoo created this task.hoo added projects: Wikidata, ArticlePlaceholder.Herald added subscribers: jhsoby, Aklapper.
TASK DESCRIPTIONI've just been approached by @jhsoby-WMNO, telling me that we might be to enable the ArticlePlaceholder on https://se.wikipedia.org/.

@jhsoby-WMNO will ask the (very small) community for consensus soon.

I already checked the traffic levels and this is well below our biggest wikis (which are non-problematic as well), so there's no reason not to enable this!TASK DETAILhttps://phabricator.wikimedia.org/T179241EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Aklapper, jhsoby, Lea_Lacroix_WMDE, Lydia_Pintscher, Lucie, hoo, jhsoby-WMNO, Lahi, GoranSMilovanovic, QZanden, cmadeo, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread Stashbot 
Stashbot added a comment.
Mentioned in SAL (#wikimedia-operations) [2017-10-28T19:39:06Z]  Synchronized wmf-config/CommonSettings.php: Half the Flow -> Parsoid timeout (100s -> 50s) (T179156) (duration: 00m 51s)TASK DETAILhttps://phabricator.wikimedia.org/T179156EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: StashbotCc: Smalyshev, TerraCodes, Jay8g, Liuxinyu970226, Paladox, Zppix, Stashbot, gerritbot, thiemowmde, aude, Marostegui, Lucas_Werkmeister_WMDE, Legoktm, tstarling, awight, Ladsgroup, Lydia_Pintscher, ori, BBlack, demon, greg, Aklapper, hoo, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Mkdw, Liudvikas, srodlund, Luke081515, Wikidata-bugs, ArielGlenn, faidon, zeljkofilipin, Alchimista, He7d3r, Mbch331, Rxy, fgiunchedi, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread gerritbot 
gerritbot added a comment.
Change 387025 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/extensions/Wikibase@master] Add special case handling for some forms of IDs

https://gerrit.wikimedia.org/r/387025TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: Liuxinyu970226, gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T179130: chomp leading spaces and tabs from lookahead function in wikidata field entry

2017-10-28 Thread gerritbot 
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T179130EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Liuxinyu970226, Smalyshev, Aklapper, Billinghurst, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179130: chomp leading spaces and tabs from lookahead function in wikidata field entry

2017-10-28 Thread gerritbot 
gerritbot added a comment.
Change 387025 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/extensions/Wikibase@master] Add special case handling for some forms of IDs

https://gerrit.wikimedia.org/r/387025TASK DETAILhttps://phabricator.wikimedia.org/T179130EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Liuxinyu970226, Smalyshev, Aklapper, Billinghurst, Lahi, GoranSMilovanovic, Jrbranaa, QZanden, EBjune, Avner, debt, Gehel, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T178579: Include wikibase-api npm package as a submodule of Wikibase git repo

2017-10-28 Thread thiemowmde 
thiemowmde moved this task from Review to Done on the Wikidata-Sprint board.thiemowmde removed a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T178579WORKBOARDhttps://phabricator.wikimedia.org/project/board/2351/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, thiemowmdeCc: Aklapper, Addshore, Lydia_Pintscher, WMDE-leszek, Lahi, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T178578: Include wikibase-serialization npm package as a submodule of Wikibase git repo

2017-10-28 Thread thiemowmde 
thiemowmde removed a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T178578EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, thiemowmdeCc: Aklapper, Addshore, Lydia_Pintscher, WMDE-leszek, Lahi, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T179239: Make shorter timeout for Wikibase fetches

2017-10-28 Thread Smalyshev 
Smalyshev created this task.Smalyshev added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONDue to the effects of T179156, some requests to Wikidata take inordinate amount of time (tens to hundreds of seconds), which blocks Updater progress. In this case, it may be better to abandon the bad requests and try again, since not all hosts are affected by the slowdown.TASK DETAILhttps://phabricator.wikimedia.org/T179239EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Gehel, Smalyshev, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread Stashbot 
Stashbot added a comment.
Mentioned in SAL (#wikimedia-operations) [2017-10-28T16:51:54Z]  restart varnish backend on cp1055 - mailbox lag + T179156TASK DETAILhttps://phabricator.wikimedia.org/T179156EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: StashbotCc: Smalyshev, TerraCodes, Jay8g, Liuxinyu970226, Paladox, Zppix, Stashbot, gerritbot, thiemowmde, aude, Marostegui, Lucas_Werkmeister_WMDE, Legoktm, tstarling, awight, Ladsgroup, Lydia_Pintscher, ori, BBlack, demon, greg, Aklapper, hoo, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Mkdw, Liudvikas, srodlund, Luke081515, Wikidata-bugs, ArielGlenn, faidon, zeljkofilipin, Alchimista, He7d3r, Mbch331, Rxy, fgiunchedi, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread Paladox 
Paladox triaged this task as "Unbreak Now!" priority.Paladox added a comment.Herald added subscribers: Liuxinyu970226, Jay8g, TerraCodes.
Spoke to hoo on irc, who agreed it's an UBN now.TASK DETAILhttps://phabricator.wikimedia.org/T179156EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PaladoxCc: TerraCodes, Jay8g, Liuxinyu970226, Paladox, Zppix, Stashbot, gerritbot, thiemowmde, aude, Marostegui, Lucas_Werkmeister_WMDE, Legoktm, tstarling, awight, Ladsgroup, Lydia_Pintscher, ori, BBlack, demon, greg, Aklapper, hoo, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Mkdw, Liudvikas, srodlund, Luke081515, Wikidata-bugs, ArielGlenn, faidon, zeljkofilipin, Alchimista, He7d3r, Mbch331, Rxy, fgiunchedi, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread hoo 
hoo added a comment.
Also on mw1180:

$ sudo -u www-data ss --tcp -r -p > ss
$ cat ss | grep -c FIN-WAIT-2
16
$ cat ss | grep -c cp1055
18
$ cat ss | grep -v cp1055 | grep -c FIN-WAIT-2
0TASK DETAILhttps://phabricator.wikimedia.org/T179156EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Paladox, Zppix, Stashbot, gerritbot, thiemowmde, aude, Marostegui, Lucas_Werkmeister_WMDE, Legoktm, tstarling, awight, Ladsgroup, Lydia_Pintscher, ori, BBlack, demon, greg, Aklapper, hoo, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Mkdw, Liudvikas, srodlund, Luke081515, Wikidata-bugs, ArielGlenn, faidon, zeljkofilipin, Alchimista, He7d3r, Mbch331, Rxy, Jay8g, fgiunchedi, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179156: 503 spikes and resulting API slowness starting 18:45 October 26

2017-10-28 Thread hoo 
hoo added a comment.
Happening again, this time on cp1055.

Example from mw1180:

$ ss --tcp -r | grep -oP 'cp\d+' | sort | uniq -c
  2 cp1053
 20 cp1055
  2 cp1066
  1 cp1068

Also:

$ cat /tmp/apache_status.mw1180.1509206746.txt | grep 10.64.32.107 | wc -l
31
$ cat /tmp/apache_status.mw1180.1509206746.txt | grep 10.64.32.107 | grep NULL | wc -l
12TASK DETAILhttps://phabricator.wikimedia.org/T179156EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Paladox, Zppix, Stashbot, gerritbot, thiemowmde, aude, Marostegui, Lucas_Werkmeister_WMDE, Legoktm, tstarling, awight, Ladsgroup, Lydia_Pintscher, ori, BBlack, demon, greg, Aklapper, hoo, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, Mkdw, Liudvikas, srodlund, Luke081515, Wikidata-bugs, ArielGlenn, faidon, zeljkofilipin, Alchimista, He7d3r, Mbch331, Rxy, Jay8g, fgiunchedi, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T179195: Decide whether we want to use .eslintignore or ignore over GruntFile.js

2017-10-28 Thread thiemowmde 
thiemowmde triaged this task as "Low" priority.thiemowmde added projects: Wikidata, Need-volunteer.thiemowmde added a subscriber: WMDE-leszek.thiemowmde added a comment.
I vote for removing the separate .eslintignore files for the given reasons. Personally, I prefer having less clutter in the root directories of these projects. I wish the exclusions are closer to the rest of the configuration, either in the .eslintrc.json file (if this is possible), or in Gruntfile.js, as discussed.

I would love to hear @WMDE-leszek's opinion. If he agrees (or does not care) I would say go for it. I will then merge such patches.TASK DETAILhttps://phabricator.wikimedia.org/T179195EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: WMDE-leszek, Aklapper, Samwilson, Paladox, Krinkle, Reedy, Florian, Addshore, Jdforrester-WMF, thiemowmde, hashar, Legoktm, Umherirrender, Lahi, SilvioAryneutro, Timoavax79, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, enigmaeth, rohitt, Zoranzoki21, Dixtosa, Wikidata-bugs, aude, TheDJ, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T155109: Wikibase API should support adding change tags

2017-10-28 Thread matej_suchanek 
matej_suchanek added a parent task: T179236: Tag edits from sister projects.
TASK DETAILhttps://phabricator.wikimedia.org/T155109EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: Lydia_Pintscher, putnik, Esc3300, matej_suchanek, Aklapper, Lahi, GoranSMilovanovic, QZanden, MGChecker, Wikidata-bugs, aude, TTO, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T179236: Tag edits from sister projects

2017-10-28 Thread matej_suchanek 
matej_suchanek added a subtask: T155109: Wikibase API should support adding change tags.
TASK DETAILhttps://phabricator.wikimedia.org/T179236EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: hoo, jhsoby, Lydia_Pintscher, matej_suchanek, Aklapper, Lahi, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread thiemowmde 
thiemowmde added a comment.
What about utilizing a try-catch? You can wrap it in a private passesEntityIdParsing function if you like.TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T179235: "Create article" with translation causes "this.config is undefined mw.cx.SiteMapper.prototype.getPageUrl"

2017-10-28 Thread hoo 
hoo created this task.hoo added projects: Wikidata, ArticlePlaceholder.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONWhen trying to create a new article from a translation, for example on https://sq.wikipedia.org/wiki/Speciale:AboutTopic/Q1660290, the interface get's stuck and I get:

jQuery.Deferred exception: this.config is undefined mw.cx.SiteMapper.prototype.getPageUrl@https://sq.wikipedia.org/w/load.php?debug=false=sq=ext.cx.model%2Csitemapper=vector=1lbm4le:1:1245
mw.cx.SiteMapper.prototype.getCXUrl@https://sq.wikipedia.org/w/load.php?debug=false=sq=ext.cx.model%2Csitemapper=vector=1lbm4le:3:700
CreateArticleTranslationDialog.prototype.onSubmit/<@https://sq.wikipedia.org/w/load.php?debug=false=sq=ext.articleplaceholder.createArticle%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cite.a11y%7Cext.dismissableSiteNotice%2CeventLogging%2CnavigationTiming%2Cpopups%2CwikimediaEvents%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.math.scripts%7Cext.popups.images%7Cext.uls.common%2Ccompactlinks%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CbyteLength%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2Chidpi%2ChighlightText%2Cmw-jump%2Csuggestions%2CtabIndex%2CtextSelection%2Cthrottle-debounce%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CTitle%2CUri%2Capi%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.api.options%2Cuser%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.wikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.template.mustache%2Cregexp%7Cmediawiki.ui.button%2Cicon%7Cmmv.bootstrap%2Chead%7Cmmv.bootstrap.autostart%7Coojs%2Coojs-ui%2Coojs-ui-core%2Coojs-ui-toolbars%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Coojs-ui.styles.icons-editing-advanced%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.vector.js%7Cuser.defaults=vector=1gg4yzp:5:47
mightThrow@https://sq.wikipedia.org/w/load.php?debug=false=sq=jquery%2Cmediawiki%7Cmediawiki.legacy.wikibits&_only_=scripts=vector=0v61to4:49:590
resolve/TASK DETAILhttps://phabricator.wikimedia.org/T179235EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Aklapper, Lucie, Lydia_Pintscher, hoo, Lahi, GoranSMilovanovic, QZanden, cmadeo, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T179236: Tag edits from sister projects

2017-10-28 Thread matej_suchanek 
matej_suchanek created this task.matej_suchanek added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONPer request.TASK DETAILhttps://phabricator.wikimedia.org/T179236EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: hoo, jhsoby, Lydia_Pintscher, matej_suchanek, Aklapper, Lahi, GoranSMilovanovic, QZanden, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T178993: Use absolute URIs in DCAT-AP document

2017-10-28 Thread thiemowmde 
thiemowmde added projects: Need-volunteer, Patch-For-Review, Dumps-Generation.thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.thiemowmde triaged this task as "Low" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T178993WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: Aklapper, nichtich, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Soteriaspace, Jayprakash12345, Lunewa, Th3d3v1ls, JakeTheDeveloper, Ramalepe, Liugev6, QZanden, Zoranzoki21, Lewizho99, Maathavan, gnosygnu, Wikidata-bugs, aude, TheDJ, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T179228: geoPrecision exported to RDF as decimal, but is in fact float

2017-10-28 Thread Smalyshev 
Smalyshev added a comment.
On coordinates, see T174504. Precision, however, is different. Right now we generate invalid RDF due to mixup between decimal and float. We could fix it by generating proper decimals, but since we store floats and not strings internally, that would generate inconsistent dumps. OTOH, in general precision numbers we generate now make little sense - e.g we have precisions of 0.00010057698125102 and 0.00010057719731271 and 0.00010059051031334 - I have super hard time believing anybody can differentiate between those and make sense out of them. But this is a separate question from us generating invalid RDF - whatever we use, we should at least keep RDF valid. 
So to make legal RDF we could either do "+0.00010057698125102"^^xsd:decimal or "1.0057698125102e-4"^^xsd:float. Both would work (right now we're doing "1.0057698125102e-4"^^xsd:decimal which is invalid). For the former, we'd need to import float into DecimalValue and then print it. Technically possible, but I am not sure whether it is a good way to go. I'd rather make some order into these precision values before we deal with more refined questions like moving them to decimals.TASK DETAILhttps://phabricator.wikimedia.org/T179228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: thiemowmde, mkroetzsch, Lucas_Werkmeister_WMDE, daniel, Aklapper, Smalyshev, Lahi, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T176413: Make AffectedPagesFinder take STATEMENT_USAGE into account

2017-10-28 Thread thiemowmde 
thiemowmde triaged this task as "Normal" priority.thiemowmde moved this task from incoming to ready to go on the Wikidata board.
TASK DETAILhttps://phabricator.wikimedia.org/T176413WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: daniel, DixonD, Aklapper, Bianjiang, aude, jeremyb, liangent, Wikidata-bugs, Abraham, Legoktm, Tobi_WMDE_SW, Daniel_Mietchen, jayvdb, Micru, Ricordisamoa, MZMcBride, Liuxinyu970226, Ainali, Sannita, Lydia_Pintscher, Eloquence, zhuyifei1999, Hall1467, TomT0m, jcrespo, Halfak, gerritbot, Stashbot, Ladsgroup, PokestarFan, Ottomata, eranroz, Bawolff, hoo, Lahi, GoranSMilovanovic, QZanden, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T168411: Set Babel AutoCreate to connect categories on Wikidata

2017-10-28 Thread thiemowmde 
thiemowmde added a project: Need-volunteer.thiemowmde triaged this task as "Lowest" priority.thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.
TASK DETAILhttps://phabricator.wikimedia.org/T168411WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: Iniquity, Aklapper, Superchilum, Lahi, GoranSMilovanovic, TheDragonFire, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, Zoranzoki21, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, APerson, Wikidata-bugs, Xqt, aude, SPQRobin, Gryllida, Shizhao, Arrbee, KartikMistry, TheDJ, Jackmcbarn, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread Smalyshev 
Smalyshev added a comment.
EntityIdParser throws exception on parse error. Is there any API that allows to check whether something is a valid ID without throwing?TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T179228: geoPrecision exported to RDF as decimal, but is in fact float

2017-10-28 Thread thiemowmde 
thiemowmde added subscribers: daniel, Lucas_Werkmeister_WMDE, mkroetzsch, thiemowmde.thiemowmde triaged this task as "Low" priority.thiemowmde moved this task from incoming to needs discussion or investigation on the Wikidata board.thiemowmde added a comment.
On geo coordinates, all latitude, longitude, as well as the precision can be integers as well as floats internally. We believe this was a mistake when this datatype was designed, because floats aren't entirely stable across languages and platforms. We already run into issues with fluctuating hash calculations on coordinate values. Quantities, on the other hand, use strings internally.

Could it be that the mapping to decimal was done intentional to "hide" this mistake?

If it turns out this causes issues it should be fixed, of course.TASK DETAILhttps://phabricator.wikimedia.org/T179228WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: thiemowmde, mkroetzsch, Lucas_Werkmeister_WMDE, daniel, Aklapper, Smalyshev, Lahi, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread thiemowmde 
thiemowmde added a comment.
I believe that even pasting a partial URL like "ata.org/wiki/Q42" should work. And it easily can, as I already tried to show above. Just try to apply two steps:


Try to parse the users input as an entity ID. We do have WikibaseRepo::getEntityIdParser() which should be used for this.
If this fails, fetch the last alphanumeric character sequence from the users input and try again. The regex /.*(\b\w{2,})/s I used for this can even be simplified if you like: /.*(\b\w+)/s.
TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread Smalyshev 
Smalyshev added a comment.
Yes this is a problem... I wonder though whether we should cover all of these. I can see why one would paste the first one into the selector, but the other ones one would have to take from RDF or specially construct... Is it a reasonable expectation that search would cover all of them?TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T179061: pasting full URL into entity selector no longer works

2017-10-28 Thread Multichill 
Multichill added a comment.
The url can be in different formats:


https://www.wikidata.org/wiki/Q42
http://www.wikidata.org/entity/Q42
https://www.wikidata.org/wiki/Special:EntityPage/Q42


Not sure how many variants we have. Not to hard to catch in a regex, might be a bit more clutter when you add these urls to preprocessing.TASK DETAILhttps://phabricator.wikimedia.org/T179061EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MultichillCc: gerritbot, hoo, thiemowmde, Smalyshev, Multichill, Aklapper, Lydia_Pintscher, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Jrbranaa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Avner, Lewizho99, Maathavan, debt, Gehel, Jdrewniak, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T179130: chomp leading spaces and tabs from lookahead function in wikidata field entry

2017-10-28 Thread Smalyshev 
Smalyshev added a project: User-Smalyshev.
TASK DETAILhttps://phabricator.wikimedia.org/T179130EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Billinghurst, Lahi, GoranSMilovanovic, Jrbranaa, QZanden, EBjune, Avner, debt, Gehel, FloNight, Wikidata-bugs, aude, jayvdb, Mbch331, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T179228: geoPrecision exported to RDF as decimal, but is in fact float

2017-10-28 Thread Smalyshev 
Smalyshev added a project: User-Smalyshev.
TASK DETAILhttps://phabricator.wikimedia.org/T179228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Block] T179091: Add case-insensitive title match capability for Wikidata search

2017-10-28 Thread Smalyshev 
Smalyshev reopened subtask T179045: Wikibase prefix search for IDs is case sensitive as "Open".
TASK DETAILhttps://phabricator.wikimedia.org/T179091EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, EBernhardson, dcausse, Smalyshev, Lahi, GoranSMilovanovic, Jrbranaa, QZanden, EBjune, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T179228: geoPrecision exported to RDF as decimal, but is in fact float

2017-10-28 Thread Smalyshev 
Smalyshev created this task.Smalyshev added projects: Wikidata, Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added a project: Discovery.
TASK DESCRIPTIONThe geoPrecision value of GlobeCoordinateValue is exported to RDF as decimal, but it is in fact stored and parsed as PHP float (which matches RDF double type). We should export it as double especially as RDF does not allow scientific notation in decimals.

We should also check for other float values typed as decimal because the format and precision expectations are different for those.TASK DETAILhttps://phabricator.wikimedia.org/T179228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, Lahi, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T178564: SVG Image query result downloads use incorrect encoding

2017-10-28 Thread gerritbot 
gerritbot added a comment.
Change 386880 merged by jenkins-bot:
[wikidata/query/gui@master] Don’t escape unescape characters in SVG download

https://gerrit.wikimedia.org/r/386880TASK DETAILhttps://phabricator.wikimedia.org/T178564EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, TerraCodes, thiemowmde, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, Avner, Lewizho99, Maathavan, debt, Gehel, Jonas, FloNight, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs