Page MenuHomePhabricator

Yurik (Yuri Astrakhan)
User

Projects (10)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

User Since
Oct 7 2014, 6:43 PM (258 w, 2 d)
Availability
Available
LDAP User
Yurik
MediaWiki User
Yurik [ Global Accounts ]

Recent Activity

Sat, Sep 14

Yurik updated the task description for T232930: Unable to create lexeme talk pages (permission error).
Sat, Sep 14, 7:20 PM · Wikidata, Lexicographical data
Yurik created T232930: Unable to create lexeme talk pages (permission error).
Sat, Sep 14, 7:18 PM · Wikidata, Lexicographical data

Fri, Sep 13

Yurik added a comment to T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites.

P.S. to sum up -- Wiktionary just needs just a single Lua function for the minimum viable product: getEntity('L100000') that simply returns the whole Lexeme JSON. Everything else is optional.

Fri, Sep 13, 7:14 PM · Wiktionary, Wikidata, Lexicographical data
Yurik added a comment to T212843: [EPIC] Access to Wikidata's lexicographical data from Wiktionaries and other WMF sites.

I have imported some Russian nouns (~20,000 so far, but will be more soon), plus added a link from Wiktionary to the corresponding Lexeme. I think the simplest use case for Lexemes would be to allow Wiktionary Lua script to be able to load Lexeme by its ID. This will instantly make Lexemes useful to Wiktionary because the Lua script will be able to:

  • generate table of the word forms
  • generate etymology and pronunciation sections
  • do the above for every lexeme if more than one is used on the page.
Fri, Sep 13, 2:53 AM · Wiktionary, Wikidata, Lexicographical data

Wed, Sep 11

Yurik added a comment to T232670: `maxlag` is ignored, instead returning `readonly` error.

@Anomie thx for the explanation. Several weeks ago by bot was banned for a short time because it didn't have the maxlag param. Are you saying that it was a mistake because WMF MW doesn't actually pay any attention to it? Also, would it be possible to update the documentation to indicate what the proper bot should do when running on WMF servers? Thanks!

Wed, Sep 11, 9:07 PM · Core Platform Team, MediaWiki-API
Yurik updated the task description for T232670: `maxlag` is ignored, instead returning `readonly` error.
Wed, Sep 11, 8:27 PM · Core Platform Team, MediaWiki-API
Yurik created T232670: `maxlag` is ignored, instead returning `readonly` error.
Wed, Sep 11, 8:25 PM · Core Platform Team, MediaWiki-API
Yurik created T232557: Lexeme's Grammatical features are created in random order.
Wed, Sep 11, 2:27 AM · Lexicographical data, Wikidata

Tue, Sep 3

Yurik added a comment to T231741: Allow displaying the one pageview number of a page in plain text form.

In theory it should be fairly straightforward to create a <graph> that outputs a single number, but that would still be an image, not text (and it might look slightly off - e.g. fuzzier or in different font)

Tue, Sep 3, 6:19 PM · Graphs, MediaWiki-Templates

Wed, Aug 21

Yurik added a comment to T98940: graphoid fails if page_props is out of sync with parser cache, or on old revisions of a page.

However, that seems pretty unlikely, because Graphoid only sends these API requests in order to graph requests that come from parsed HTML, so if we're getting an API request we probably recently displayed the page and the parser cache should still be warm.

Wed, Aug 21, 4:35 AM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Graphoid
Yurik closed T222806: Security Review for Vega 5 and Vega-Lite JavaScript Libraries as Resolved.

Thanks, closing for now, waiting for the Vega team and the students.

Wed, Aug 21, 3:23 AM · Security-Team-Reviews, Upstream, JavaScript, Maps, Graphs

Aug 18 2019

Yurik added a comment to T98940: graphoid fails if page_props is out of sync with parser cache, or on old revisions of a page.

@Catrope thanks for tackling it! I always thought parser cache is non-persisted, so if a page does not get any edits in 2 months, the relevant data might not be there?

Aug 18 2019, 5:13 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Graphoid

Aug 16 2019

Yurik added a comment to T134617: Implement CSV/TSV import/export for tabular data set.

This is awesome, thank you @TheDJ and @JeanFred ! One kinda important issue -- it breaks on localized columns, e.g. Data:I18n/No_globals.tab -- CSV outputs empty values, and Excel shows English (I think).

Aug 16 2019, 9:51 PM · Wikimania-Hackathon-2019, Commons-Datasets

Aug 7 2019

Yurik updated the task description for T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST.
Aug 7 2019, 8:57 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API
Yurik added a project to T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST: Operations.
Aug 7 2019, 8:50 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API
Yurik renamed T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST from wikidata.org handles GET MWAPI requests, but silently redirects on POST to wikidata.org handles GET MWAPI requests, but silently fails on POST.
Aug 7 2019, 8:49 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API
Yurik renamed T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST from Wikidata breaks MW-API response format on (some?) errors to wikidata.org handles GET MWAPI requests, but silently redirects on POST.
Aug 7 2019, 8:49 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API
Yurik updated the task description for T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST.
Aug 7 2019, 6:23 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API
Yurik created T230051: wikidata.org handles GET MWAPI requests, but silently fails on POST.
Aug 7 2019, 6:04 PM · Traffic, Core Platform Team Workboards (Clinic Duty Team), Operations, Wikidata-Campsite, Wikidata, MediaWiki-API

Aug 4 2019

Yurik added a comment to T229742: mw.ext.data.get sometimes return false.

Recently someone also raised this as an issue with graphs. Has anything changed to destabilize mw.ext.data.get() method?

Aug 4 2019, 5:58 PM · MediaWiki-extensions-Scribunto, Commons-Datasets

Aug 1 2019

Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

Vega1 doesn't need it - it doesn't support external URLs. Vega2 approach sounds correct. Thx for digging into it!

Aug 1 2019, 8:44 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs
Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

@Pchelolo Graphoid first calls the action=graph to get the data, but then it should also call to the WDQS directly using that query. Also, you can see what that request looks like if you go to the wiki page with a graph, click edit source, and do a page preview -- your browser should make very similar request to WDQS, except that unlike Graphoid, browser forces a few headers like user agent (IIRC)

Aug 1 2019, 5:28 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs
kaldari awarded T206426: Storing multiple sitelinks to a multilingual wiki a Like token.
Aug 1 2019, 3:13 PM · Wikidata

Jul 29 2019

Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

@Lea_Lacroix_WMDE not from my side - I'm a bit overbooked at the moment with my main job (elastic.co) and family. It will take me some effort to get the system running again on my laptop to see what Graphoid sends to the servers. It might be easier to track it from the server side logs if anyone has that access.

Jul 29 2019, 2:57 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs

Jul 24 2019

Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

vegaErr: Error: Load failed with response code 403. -- Vega attempts to call Wikidata API to get the needed data, and I suspect that API returns 403. I would look at the HTTP request Vega makes (it should be very similar to the query stored in the graph on the wiki page), and try to find it in WDQS logs. Perhaps WDQS now blocks some HTTP requests that do not appear to originate from the browser (i.e. have fewer headers than expected)?

Jul 24 2019, 7:17 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs

Jul 15 2019

Yurik added a comment to T227731: Archive ZeroPortal and ZeroBanner.

Rest in Peace Zero, it was fun... 😢

Jul 15 2019, 1:22 PM · translatewiki.net, ZeroPortal, ZeroBanner, MediaWiki-extensions-General, Repository-Admins, Technical-Debt

Jul 2 2019

Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

Thanks, it makes sense. I was only suggesting to search the logs for the same query as being ran from the in-browser's page preview.

Jul 2 2019, 9:49 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs
Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

@Smalyshev the query should be identical as being issues from the browser when you do a "page preview" with a graph that uses WDQS query. Graphoid does exactly the same steps as the browser - essentially making all the requests and putting together a resulting image.

Jul 2 2019, 9:36 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs
Yurik added a comment to T226250: Graph not displayed if linked to a wikidata query.

@Smalyshev i would love to help, but it is a bit hard to say without access to the logs or the servers

Jul 2 2019, 8:22 PM · Patch-For-Review, Core Platform Team Workboards (Clinic Duty Team), Graphoid, Graphs

Jun 25 2019

Richard_Nevell_WMUK awarded T154071: Allow non-CC0 licensed data for datasets a 100 token.
Jun 25 2019, 12:44 PM · WMF-Legal, Commons-Datasets

Jun 19 2019

Kozuch awarded T145688: [epic] Improve OSM-Wikipedia collaboration a Like token.
Jun 19 2019, 7:12 PM · Epic, Maps (Kartographer)

Jun 15 2019

Yurik added a comment to T216431: Graphs create img tags without width and height.

@stjn I don't think there is any reliable way to compute the image height/width ahead of time without going through the full graph rendering. PHP could call out to Graphoid during the post-save, but that may require even more work than simply updating to Vega 3+ and implementing the above logic (defaulting to autosize=fit model).

Jun 15 2019, 3:36 PM · Patch-For-Review, Readers-Web-Backlog (Tracking), Mobile, Graphs
Yurik added a comment to T216431: Graphs create img tags without width and height.

@stjn this is a fairly complex issue. I have done a lot of work with the Vega lib since then, integrating it as part of Kibana (Elasticsearch), so I can elaborate on a "better" way to address it. I will try to be brief :) Also, take a look here on how I did it in Kibana.

Jun 15 2019, 2:27 PM · Patch-For-Review, Readers-Web-Backlog (Tracking), Mobile, Graphs
Kozuch awarded T137253: Migrate GeoHack to <maplink> a Like token.
Jun 15 2019, 1:04 PM · Product-Infrastructure-Team-Backlog, Epic, Maps (Kartographer)

Jun 11 2019

Yurik added a comment to T222806: Security Review for Vega 5 and Vega-Lite JavaScript Libraries.

sounds good, thanks @sbassett !

Jun 11 2019, 5:45 PM · Security-Team-Reviews, Upstream, JavaScript, Maps, Graphs
Yurik added a comment to T222806: Security Review for Vega 5 and Vega-Lite JavaScript Libraries.

@sbassett sorry, unsure what you mean. Some code has already been completed -- https://github.com/nyurik/mw-graph-shared/commit/b97fd309897f701bd0db6b1d60635d0786d84887 -- making it possible to integrate the future v3+. The next step would be to create a patch for graphoid & graph ext using that shared code.

Jun 11 2019, 5:17 PM · Security-Team-Reviews, Upstream, JavaScript, Maps, Graphs

May 24 2019

Mvolz awarded T212069: API action=wbgetentities does not handle formatversion=2 a Cookie token.
May 24 2019, 10:52 AM · Wikidata, MediaWiki-API

May 21 2019

NavinoEvans awarded T155290: Add a data-page-only wiki markup header to datasets a Doubloon token.
May 21 2019, 1:39 PM · Commons-Datasets, Maps, Product-Infrastructure-Team-Backlog, MediaWiki-extensions-JsonConfig, patch-welcome, Patch-For-Review

May 17 2019

Yurik updated the task description for T135845: Convert any module as central or centralisable.
May 17 2019, 3:25 PM · Community-Tech (2015-2017), Developer-Advocacy, MediaWiki-extensions-Scribunto

May 12 2019

Yurik added a comment to T172938: Security review new version of the Vega lib.

@Bawolff I was re-reading our notes in light of the resumed interest in this project. Assuming we are not yet rolling out the sandbox approach per our discussion, I have began looking closely at the issues you raised:

May 12 2019, 3:31 AM · Security, Security-Team-Reviews, Graphs, Graphoid
Yurik updated subscribers of T223026: Add Vega 4 support to MediaWiki.
May 12 2019, 1:44 AM · Patch-For-Review, Graphs
Yurik added a comment to T223026: Add Vega 4 support to MediaWiki.

@Xiaoyanghaitao if you want to target Vega 5.4.0 initially, you might as well put that version in the subject (or you could just say "latest production version")

May 12 2019, 1:43 AM · Patch-For-Review, Graphs

May 9 2019

Yurik renamed T165118: Support Vega 3.0+ and Vega Lite 2.0+ from Support Vega 3.0 and Vega Lite 2.0 to Support Vega 3.0+ and Vega Lite 2.0+.
May 9 2019, 4:48 AM · Outreach-Programs-Projects, Graphs

May 8 2019

Yurik added a comment to T169027: Provide iframe sandboxing for rich-media extensions (defense in depth).

Agree this would be great to have. I think this should be an API-level rather than an extension-level feature, because in many cases an extension would need to bridge the communication between inside and outside the frame. The system should allow:

  • set up a separate initial configuration blob
  • set up a separate resource loading for the iframe
  • designate some resources as only available via the iframe loading (to restrict accidental loading by the primary site)
  • establish a clear usage pattern for extensions to follow (this is more of a documentation than coding)
  • ...?
May 8 2019, 7:55 PM · Security, Security-General, Technical-Debt, MediaWiki-File-management, Commons, Multimedia
Yurik added a comment to T222806: Security Review for Vega 5 and Vega-Lite JavaScript Libraries.

Do we want a separate ticket for Vega-Lite? Vega-Lite can be thought of as an "add-on" converter library that simply converts one JSON into a different JSON, without any other functionality (e.g. no XHR calls, no UI, etc). This way users can use a much simpler language VegaLite, and it will be dynamically converted to a full Vega.

May 8 2019, 6:54 PM · Security-Team-Reviews, Upstream, JavaScript, Maps, Graphs
Yurik updated the task description for T222806: Security Review for Vega 5 and Vega-Lite JavaScript Libraries.
May 8 2019, 6:52 PM · Security-Team-Reviews, Upstream, JavaScript, Maps, Graphs
Yurik added a comment to T172938: Security review new version of the Vega lib.

@Bawolff is there anything in this ticket that is sensitive? There is a discussion about GSOC student tackling the Vega 3 upgrade, and they would need access to this discussion.

May 8 2019, 2:59 PM · Security, Security-Team-Reviews, Graphs, Graphoid
Yurik added a comment to T165118: Support Vega 3.0+ and Vega Lite 2.0+.

@Milimetric has any team at WMF decided to adapt it yet? From what I was told, there is already a GSOC student about to get started on this, and we could ask them to do some restructuring work as well. Which restructuring steps did you have in mind? BTW, it would be great if you could co-mentor this person as well (we already have @domoritz and myself signed up as mentors)

May 8 2019, 2:56 PM · Outreach-Programs-Projects, Graphs

May 4 2019

Yurik created T222506: wikidata conflict error message has missing param.
May 4 2019, 6:02 AM · Wikidata

Apr 19 2019

Smalyshev awarded T122086: RFC: Sharing templates and modules between wikis - poor man's version (investigation) a Like token.
Apr 19 2019, 6:52 PM · Pywikibot, Proposal, Pywikibot-RfCs

Apr 12 2019

Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

A bot has been implemented and documented for this functionality. Needs a whole bunch of bot approvals, or a global bot flag. For now running it by hand for a few pages. Anyone interested in this functionality, we can now start building cross-site templates and lua modules...

Apr 12 2019, 2:47 AM · Language-strategy, Core Platform Team Legacy (Watching / External), Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, Phlogiston-Category, Community-Wishlist-Survey-2015
Yurik added a comment to T122086: RFC: Sharing templates and modules between wikis - poor man's version (investigation).

A bot has been implemented and documented for this functionality. Needs a whole bunch of bot approvals, or a global bot flag. For now running it by hand for a few pages.

Apr 12 2019, 2:44 AM · Pywikibot, Proposal, Pywikibot-RfCs

Apr 10 2019

Yurik added a comment to T211881: graphoid: Code stewardship request.

@Milimetric I think the removal of Graphoid will be far more difficult than just keeping it. If you remove it, you will have to support multiple Vega versions on the client - not as trivial to do as it is for the Graphoid service (which was built with that support).

Apr 10 2019, 3:24 PM · Release-Engineering-Team-TODO (201908), Release-Engineering-Team (Code Health), Core Platform Team Legacy (Watching / External), Services (watching), Operations, Code-Stewardship-Reviews, Graphoid
Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

It's not about "allowing", it's just a matter of me (or someone else) to sit down and implement it :) Afterwards, I will have to document it in detail, and apply for a bot flag for my YurikBot (it has been dormant for a while now), preferably to be allowed on all wikis at once.

Apr 10 2019, 2:04 AM · Language-strategy, Core Platform Team Legacy (Watching / External), Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, Phlogiston-Category, Community-Wishlist-Survey-2015

Apr 9 2019

Yurik added a comment to T211881: graphoid: Code stewardship request.

Another, not yet mentioned consideration: There was a significant syntax change between Vega 1.5, Vega 2, and 3+. Graph extension & Graphoid support both 1.5 and 2, but Graph ext does it in an imperfect way: browser only loads the latest version required, so if a page has both 1.5 and 2, it would just load 2. This only affects dynamic graphs (v2 only), but it really breaks during page preview -- only v2 graphs are previewed if both are present. When used as images from Graphoid, there are no issues (regular page viewing).

Apr 9 2019, 9:29 PM · Release-Engineering-Team-TODO (201908), Release-Engineering-Team (Code Health), Core Platform Team Legacy (Watching / External), Services (watching), Operations, Code-Stewardship-Reviews, Graphoid
Yurik added a comment to T211881: graphoid: Code stewardship request.

@mobrovac @dr0ptp4kt there is a much larger issue -- performance, and this is identical to maps: when a page loads, do you want to show a map / graph right away, e.g. if it is at the top, or do you want to load a large library, load all the data for it, and only then show the page? Or to show an empty box that eventually gets loaded? Live map requires leaflet, tile images, could get data from commons, could run sparql query (potentially overloading the server), etc. The exact same issues are for the graph - load Vega lib, load data, run sparql qeuries, etc. So if map needs it, graph needs it, and if servers can take both - sure. I would much rather have interactive content from the start.

Apr 9 2019, 7:42 PM · Release-Engineering-Team-TODO (201908), Release-Engineering-Team (Code Health), Core Platform Team Legacy (Watching / External), Services (watching), Operations, Code-Stewardship-Reviews, Graphoid
Yurik awarded T220487: Display label and description in user's preferred language, on item talk pages a Like token.
Apr 9 2019, 11:22 AM · Wikidata

Apr 8 2019

Yurik added a comment to T144482: ISO date format not honored by Mediawiki API (arvbadtimestamp_arvstart).

@Anomie you are right that documentation does not say it will handle the entire ISO 8601, but I do think MW should handle at least a very common 2019-04-08T04:12:45+00:00-style format (only +00:00 / -00:00, not other timezones). It is, for better or worse, fairly common with Python, and supporting it shouldn't be a significant undertaking.

Apr 8 2019, 4:48 AM · Core Platform Team Workboards (Done with CPT), MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Patch-For-Review, Timestamp, MediaWiki-API

Apr 5 2019

Mill <mill@mail.com> committed rWDQG1927d4be5e44: y2baaaaaaaaaaa (authored by Yurik).
y2baaaaaaaaaaa
Apr 5 2019, 10:30 PM

Mar 21 2019

Mill <mill@mail.com> committed rWDQG26763ef3d585: !7aaaaaaaaaaaa (authored by Yurik).
!7aaaaaaaaaaaa
Mar 21 2019, 12:40 AM

Mar 20 2019

Yurik created T218749: Allow own Wikidata ID to be used inside the Formatter URL.
Mar 20 2019, 12:02 AM · Wikidata

Mar 16 2019

Yurik added a comment to T47224: [Story] Custom edit summaries.

Here's a working implementation using the browser's prompt text box, based on the original idea by @Ricordisamoa. Copy it into your https://wiki.openstreetmap.org/wiki/User:___username___/common.js page. Note that the save will happen even if the user clicks Cancel because there is no good way to abort saving without crashing. This code can be directly used as a gadget.

Mar 16 2019, 9:23 PM · Wikimedia-Hackathon-2017, Story, Wikidata-Gadgets, Wikidata, patch-welcome, MediaWiki-extensions-WikibaseRepository

Mar 12 2019

Yurik added a comment to T208437: Consolidate and migrate Module namespace to mediawiki.org.

@Yurik any progress on bot based one?

Mar 12 2019, 4:40 PM · Wikimedia-General-or-Unknown

Mar 8 2019

Yurik added a comment to T47224: [Story] Custom edit summaries.

This feature has been requested several times when adding Wikibase to OpenStreetMap wiki. I think the very first step we can already do is to make it possible for gadgets to add edit summary string during the "save" command. This way we can experiment with the UI implementation.

Mar 8 2019, 5:54 PM · Wikimedia-Hackathon-2017, Story, Wikidata-Gadgets, Wikidata, patch-welcome, MediaWiki-extensions-WikibaseRepository
Yurik updated the task description for T217873: Allow custom user summaries to be added to Wikibase edits.
Mar 8 2019, 12:36 AM · Wikidata
Yurik updated the task description for T217873: Allow custom user summaries to be added to Wikibase edits.
Mar 8 2019, 12:35 AM · Wikidata
Yurik created T217873: Allow custom user summaries to be added to Wikibase edits.
Mar 8 2019, 12:32 AM · Wikidata

Mar 3 2019

Yurik added a comment to T217357: MediaWiki:Talkpageheader message does not handle language fallbacks.

@A2093064 I think a much more intuitive behavior would be to use the "root" page, e.g. MediaWiki:talkpageheader as a fallback when a language-specific page does not exist, and use /en to override just English -- thus treating /en the same as any other language. Yes, it is possible to run a bot to generate all such pages, but ... ew :)

Mar 3 2019, 6:03 PM · MediaWiki-Interface, MediaWiki-Internationalization, I18n
Yurik added a comment to T217357: MediaWiki:Talkpageheader message does not handle language fallbacks.

@A2093064 The talkpageheader message is set to a "-" by default - see code. This seems like a very strange behavior, especially because it makes this message useless for non-WP installations, or for any multi-lingual sites like Commons.

Mar 3 2019, 3:18 AM · MediaWiki-Interface, MediaWiki-Internationalization, I18n

Mar 1 2019

Yurik added a comment to T217357: MediaWiki:Talkpageheader message does not handle language fallbacks.

@Yurik You need to create MediaWiki:Talkpageheader/xx. xx is any language code you want to show this message. For example: en-ca.

Mar 1 2019, 4:35 PM · MediaWiki-Interface, MediaWiki-Internationalization, I18n

Feb 28 2019

Yurik created T217357: MediaWiki:Talkpageheader message does not handle language fallbacks.
Feb 28 2019, 6:02 PM · MediaWiki-Interface, MediaWiki-Internationalization, I18n

Feb 21 2019

Yurik added a comment to T211881: graphoid: Code stewardship request.

Note that Graphoid already supports POST approach (see v2 Graphoid api). You can post a graph spec to it, and it will return an image. But v2 was never actually used by any services, even though it is in production, just not exposed to end users. The issue with v2 is that we don't want to make MW parser (HTML rendering) dependent on an external service because of potential (unverified) speed concern - we need to generate some graph image URL without waiting for Graphoid to actually generate that image.

Feb 21 2019, 8:06 PM · Release-Engineering-Team-TODO (201908), Release-Engineering-Team (Code Health), Core Platform Team Legacy (Watching / External), Services (watching), Operations, Code-Stewardship-Reviews, Graphoid

Feb 13 2019

Yurik added a comment to T215484: Unable to get page redirect targets when using list=allpages.

@Umherirrender that's an interesting idea, thx. It is not exactly the same because this wouldn't get me the redirect to redirect - e.g. A->B->C would only get me B->C without A->C.

Feb 13 2019, 11:03 PM · MediaWiki-API

Feb 11 2019

Yurik added a comment to T213077: Migrate Kartotherian/Tilerator to Mapnik v3.1.x when released.

@Pchelolo @Gehel I agree that Node 8 upgrade is urgent and must happen. This ticket was discussing Node 10, and mentioned that it was blocked on some dependencies, so I was proposing how to help with the difficulties of dependency upgrades, and k8s might be a good solution to that. I will be happy to chat on IRC. Thanks!!!

Feb 11 2019, 8:13 PM · Maps (Kartotherian), Epic, Product-Infrastructure-Team-Backlog
Yurik added a comment to T213077: Migrate Kartotherian/Tilerator to Mapnik v3.1.x when released.

@Gehel is there a doc/procedure describing limits to docker deployment? E.g. would WMF have a docker repository and a well established build process that uploads to it, does it limit to the base images like "must use base Debian but not base Alpine", etc.

Feb 11 2019, 7:52 PM · Maps (Kartotherian), Epic, Product-Infrastructure-Team-Backlog
Yurik updated subscribers of T213077: Migrate Kartotherian/Tilerator to Mapnik v3.1.x when released.

@MSantos and @Jhernandez , would it perhaps make things far simpler to migrate to use Kubernetes/Docker? Each maps service will be able to use any version of Node, or any native package, or even a different version/distribution of Linux as needed, and it will not affect any other services even if they are running on the same physical hardware. Even migration will be easier, because you will be able to use different version of Node on the same machine by different instances of Tilerator/Kartotherian.

Feb 11 2019, 6:36 PM · Maps (Kartotherian), Epic, Product-Infrastructure-Team-Backlog

Feb 7 2019

Yurik created T215484: Unable to get page redirect targets when using list=allpages.
Feb 7 2019, 5:17 AM · MediaWiki-API

Feb 4 2019

Yurik added a comment to T173052: Show OpenStreetMap features associated with Wikidata items.

Note that this is also possible with Sophox -- e.g. a SPARQL query can use Wikidata via federation together with all of OSM data itself (tags), plus attach the OSM geometry shapes to each wikidata ID it sees in the query result. Click "run query" under the example.

Feb 4 2019, 10:30 PM · Wikidata, Maps (Kartographer), Wikimania-Hackathon-2017

Feb 1 2019

Yurik updated subscribers of T215073: OSM map layers other than the default should be displayable in the Wikidata Query Service.

It is very irresponsible if the reliability of the map is questioned, yet it is been implicatied that "we will use the map because its free". In fact, the map that has been provided (OSM) is very different https://openstreetmap.in/#4/25.32/77.17 and accurate than the one rendered by Wikimedia, it is an act of intentional vandalism, then. If Wikimedia use what OSM provide then please restore it to that version instead of creating a new coined version.

Feb 1 2019, 10:00 PM · Patch-For-Review, Maps (Map-Styles), Wikidata Query UI, Wikidata
Yurik added a comment to T215073: OSM map layers other than the default should be displayable in the Wikidata Query Service.

FYI, there has been a number of discussions at OSM on how to document disputed territories. See the latest proposal.

Feb 1 2019, 7:40 PM · Patch-For-Review, Maps (Map-Styles), Wikidata Query UI, Wikidata

Jan 27 2019

domoritz awarded T195627: Support Vega 3.0 in Graphoid a Like token.
Jan 27 2019, 9:55 PM · Graphoid, Graphs
domoritz awarded T195628: Support Vega Lite 2.0 in Graphoid a Like token.
Jan 27 2019, 9:55 PM · Graphoid, Graphs

Jan 22 2019

Mrjohncummings awarded T155290: Add a data-page-only wiki markup header to datasets a Love token.
Jan 22 2019, 10:19 PM · Commons-Datasets, Maps, Product-Infrastructure-Team-Backlog, MediaWiki-extensions-JsonConfig, patch-welcome, Patch-For-Review
Mrjohncummings awarded T154071: Allow non-CC0 licensed data for datasets a Mountain of Wealth token.
Jan 22 2019, 3:53 PM · WMF-Legal, Commons-Datasets
Mrjohncummings awarded T154071: Allow non-CC0 licensed data for datasets a Mountain of Wealth token.
Jan 22 2019, 3:52 PM · WMF-Legal, Commons-Datasets
Mrjohncummings awarded T154071: Allow non-CC0 licensed data for datasets a Mountain of Wealth token.
Jan 22 2019, 3:52 PM · WMF-Legal, Commons-Datasets

Jan 19 2019

Yurik added a comment to T119043: Graph/Graphoid/Kartographer - data storage architecture.

@akosiaris at the moment, yes, graphs are shown if they are in page-props db - i.e. generated from the last page revision. If you try to view an older version of the page, you will only see the graph image if it hasn't changed since then, otherwise you will see a broken image (because the hash would be different, and that hash would not be stored in the page props). On the other hand, you can view the older variant if you use page preview -- graphs will be rendered on the client, without using page props.

Jan 19 2019, 7:38 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Patch-For-Review, Product-Infrastructure-Team-Backlog, Services (watching), Maps (Kartographer), TechCom-RFC, Graphoid, Graphs, Service-Architecture, RESTBase-architecture

Jan 18 2019

Yurik updated subscribers of T214179: mw.ext.data.get Lua call returns false.
Jan 18 2019, 7:27 PM · MW-1.33-notes (1.33.0-wmf.17; 2019-02-12), Regression, MediaWiki-extensions-JsonConfig, Commons-Datasets, MediaWiki-extensions-Scribunto
Yurik added a comment to T214179: mw.ext.data.get Lua call returns false.

The actual data table is present. Was there any related code changes in MW?

Jan 18 2019, 7:10 PM · MW-1.33-notes (1.33.0-wmf.17; 2019-02-12), Regression, MediaWiki-extensions-JsonConfig, Commons-Datasets, MediaWiki-extensions-Scribunto
Yurik added a comment to T119043: Graph/Graphoid/Kartographer - data storage architecture.

Step 0: Resource more storage for the relevant servers. Probably a lot more storage.

Jan 18 2019, 6:44 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Patch-For-Review, Product-Infrastructure-Team-Backlog, Services (watching), Maps (Kartographer), TechCom-RFC, Graphoid, Graphs, Service-Architecture, RESTBase-architecture
Yurik added a comment to T119043: Graph/Graphoid/Kartographer - data storage architecture.

I think we should have a "snapshot" capability - whenever page is edited, the previous page version in HTML should be preserved, and shown whenever one looks at the history.

That would be nice to have, but it should be done for everything, or nothing. Having some things show the current version of included data, and other things showing the old version of included data, is very confusing.

I think the first step is to save HTML (preserve template/module parsing results). Next step - when snapshoting, switch to image permalinks. Lastly, implement "computed blobs storage" as this ticket describes, and also use permalinks when snapshoting.
These things don't need to happen at the same time. Even making it possible to view proper text of the older version of an article is a good first step.

Jan 18 2019, 3:11 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Patch-For-Review, Product-Infrastructure-Team-Backlog, Services (watching), Maps (Kartographer), TechCom-RFC, Graphoid, Graphs, Service-Architecture, RESTBase-architecture

Jan 17 2019

Yurik added a comment to T119043: Graph/Graphoid/Kartographer - data storage architecture.

Most of the time, Vega is used via a template, because otherwise you have a massive copy/paste of code without any benefit, while having no way to fix issues or improve appearance of all graphs en mass. Thus, per what @Anomie said - MCR is an orthogonal (in its current form) to the generated content. This actually has more similarities with the image thumb service than MCR (content is generated from "master" - wiki markup, and cached for usage by both the rendering service like Graphoid and directly from the client via the dynamic graph loading).

This does contradict however with requirement 6. BonusB: When user looks at an older revision of an article, they should see the graphs for that revision. given above. Just noting it, effectively reiterating what I think Tim has better phrased it in his comment at T119043#1868557

Jan 17 2019, 5:54 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Patch-For-Review, Product-Infrastructure-Team-Backlog, Services (watching), Maps (Kartographer), TechCom-RFC, Graphoid, Graphs, Service-Architecture, RESTBase-architecture

Jan 16 2019

Yurik added a comment to T119043: Graph/Graphoid/Kartographer - data storage architecture.

Most of the time, Vega is used via a template, because otherwise you have a massive copy/paste of code without any benefit, while having no way to fix issues or improve appearance of all graphs en mass. Thus, per what @Anomie said - MCR is an orthogonal (in its current form) to the generated content. This actually has more similarities with the image thumb service than MCR (content is generated from "master" - wiki markup, and cached for usage by both the rendering service like Graphoid and directly from the client via the dynamic graph loading).

Jan 16 2019, 6:54 PM · MW-1.34-notes (1.34.0-wmf.20; 2019-08-27), Patch-For-Review, Product-Infrastructure-Team-Backlog, Services (watching), Maps (Kartographer), TechCom-RFC, Graphoid, Graphs, Service-Architecture, RESTBase-architecture

Jan 3 2019

Yurik closed T141231: Many more OSM features are tagged with a Wikipedia link, but not Wikidata ID as Resolved.

done :)

Jan 3 2019, 12:37 PM · Maps (Maps-data)
Yurik closed T141231: Many more OSM features are tagged with a Wikipedia link, but not Wikidata ID, a subtask of T142043: [Epic] Improve interlinkedness of OSM and Wikidata, as Resolved.
Jan 3 2019, 12:37 PM · Epic, Upstream, Maps (Maps-data)

Jan 2 2019

Yurik added a comment to T90492: [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons.

Are there any updates/progress on this issue? The OpenStreetMap Wikibase has both the local images and it supports Commons, which means every OSM Wikibase "image" property is actually two properties - one of "image" type, and another being a manually copy/pasted string of the local (OSM) wiki file - in case the file is not on Commons. It would greatly simplify things for OSM community if an image property would be a single "media", regardless of where it is actually stored. What could be done to solve this?

Jan 2 2019, 8:24 AM · Wikidata-Campsite, Patch-For-Review, Wikidata, MediaWiki-extensions-WikibaseRepository
Yurik awarded T90492: [Task] Make Wikibase Repo work with a custom File collection, not only Wikimedia Commons a Mountain of Wealth token.
Jan 2 2019, 8:16 AM · Wikidata-Campsite, Patch-For-Review, Wikidata, MediaWiki-extensions-WikibaseRepository

Dec 20 2018

Yurik added a comment to T210548: gzip-encoded page properties can't be exported from the API.

I agree with @Legoktm -- storing data blobs in page props was a hack. But to my knowledge, there is no good alternative storage for the parser-generated blobs. Essentially any system that needs independent access to those blobs would require something like this, essentially solving T119043

Dec 20 2018, 9:12 PM · Core Platform Team Workboards (Clinic Duty Team), Patch-For-Review, Maps (Kartographer), MediaWiki-API
Yurik added a comment to T56140: Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot.

See related approach by Module:TNT -- it stores templatedata as a table (example). In this case <templatedata> will be dynamically generated during the parse time, and is available to every language/every wiki.

Dec 20 2018, 9:07 PM · VisualEditor-MediaWiki, VisualEditor, TemplateData

Dec 16 2018

Yurik updated the task description for T212069: API action=wbgetentities does not handle formatversion=2.
Dec 16 2018, 4:37 AM · Wikidata, MediaWiki-API