Page MenuHomePhabricator

Yurik (Yuri Astrakhan)
User

Projects (13)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Wednesday

  • Clear sailing ahead.

User Details

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

Recent Activity

Sat, Mar 16

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.

Sat, Mar 16, 9:23 PM · Wikimedia-Hackathon-2017, Story, Wikidata-Gadgets, Wikidata, Need-volunteer, MediaWiki-extensions-WikibaseRepository

Tue, Mar 12

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

@Yurik any progress on bot based one?

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

Fri, Mar 8

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.

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

Sun, Mar 3

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 :)

Sun, Mar 3, 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.

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

Fri, Mar 1

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.

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

Thu, Feb 28

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

Thu, Feb 21

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.

Thu, Feb 21, 8:06 PM · Core Platform Team Backlog (Watching / External), Services (watching), Release-Engineering-Team (Kanban), 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 Node 10.

@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, Reading-Infrastructure-Team-Backlog
Yurik added a comment to T213077: Migrate Kartotherian/Tilerator to Node 10.

@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, Reading-Infrastructure-Team-Backlog
Yurik updated subscribers of T213077: Migrate Kartotherian/Tilerator to Node 10.

@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, Reading-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 · Need-volunteer, MediaWiki-extensions-JsonConfig, Reading-Infrastructure-Team-Backlog, Maps, Commons-Datasets
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 · Core Platform Team Backlog (Watching / External), Reading-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), Patch-For-Review, 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), Patch-For-Review, 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 · Core Platform Team Backlog (Watching / External), Reading-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 · Core Platform Team Backlog (Watching / External), Reading-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 · Core Platform Team Backlog (Watching / External), Reading-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 · Core Platform Team Backlog (Watching / External), Reading-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 (Security, stability, performance and scalability (TEC1)), Patch-For-Review, Core Platform Team Kanban (Waiting 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
Yurik created T212069: API action=wbgetentities does not handle formatversion=2.
Dec 16 2018, 4:36 AM · Wikidata, MediaWiki-API

Dec 13 2018

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

@akosiaris also, please add usage before the Varnish - to see how often graphoid objects are actually requested by the user, rather than how often there is a cache miss. Plus a similar stats for getting map snapshots.

Dec 13 2018, 7:48 PM · Core Platform Team Backlog (Watching / External), Services (watching), Release-Engineering-Team (Kanban), Operations, Code-Stewardship-Reviews, Graphoid
Yurik added a comment to T211881: graphoid: Code stewardship request.

However, that begs a question. If the caller of the graphoid service API already knows the hash of the graph, that means they either got it via talking to mediawiki, or that they calculated it themselves (aka they already have the entire graph). If they already have the entire graph, why not POST it to the service and obtain the resulting PNG themselves? Things become even more convoluted if the user is mediawiki itself (that's to my knowledge actually the case) at which case having mediawiki instruct another service to create requests back to it (the API endpoint actually) causes a cascading number of requests hitting the mediawiki API. Up to now this hasn't caused an outage, in my opinion simply because of the low traffic the graphoid receives.

Dec 13 2018, 5:38 PM · Core Platform Team Backlog (Watching / External), Services (watching), Release-Engineering-Team (Kanban), Operations, Code-Stewardship-Reviews, Graphoid

Dec 11 2018

Yurik added a comment to T184933: Display map for geocoordinate statements.

Fancy...
Just a followup/enhancement idea: since we have precision.. wouldn't this be a good place to draw a precision circle ?

This is a very good point: Basically we can alter the generated mapframes like in any article… in fact we generate them from wikitext (see CachingKartographerEmbeddingHandler::getWikiText).

I created a new task (T211676) for this… suggestions on how exactly to implement this are very welcome there :)

Dec 11 2018, 4:01 PM · MW-1.33-notes (1.33.0-wmf.6; 2018-11-27), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), Maps, Wikidata, Wikidata-Gadgets

Dec 7 2018

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

I suspect the same issue is in Graphoid - it pulls the same bin data blobs via api

Dec 7 2018, 10:02 PM · Core Platform Team (Security, stability, performance and scalability (TEC1)), Patch-For-Review, Core Platform Team Kanban (Waiting for Review), Maps (Kartographer), MediaWiki-API

Dec 6 2018

Yurik added a comment to T211149: Ubuntu to Debian migration for maps-warper2 instance of the wikimaps warper .

After some extensive work with Docker containers, it seems they are much cleaner, more portable, and much easier to deploy approach, without any performance or other issues. I would highly recommend repackaging under Docker.

Dec 6 2018, 7:07 PM · Cloud-VPS (Ubuntu Trusty Deprecation), wikimaps-warper

Dec 4 2018

Yurik created T211072: Page preview stopped working when it contains a map and user has "preview without reload" enabled.
Dec 4 2018, 12:42 AM · Maps (Kartographer)

Nov 30 2018

Yurik updated the task description for T210692: WDQS should not add (...) to VALUES.
Nov 30 2018, 6:26 PM · Wikidata Query UI, Wikidata
Yurik added a comment to T210692: WDQS should not add (...) to VALUES.

Upstream issue

Nov 30 2018, 6:26 PM · Wikidata Query UI, Wikidata
Yurik added a comment to T210692: WDQS should not add (...) to VALUES.

@Lucas_Werkmeister_WMDE I think both should be fixed - it should never use unneeded parenthesis for single values, and when the VALUES list is short enough, it should be shown singleline. For a very long list, it should be shown like this:

Nov 30 2018, 6:07 PM · Wikidata Query UI, Wikidata

Nov 29 2018

Yurik created T210692: WDQS should not add (...) to VALUES.
Nov 29 2018, 3:48 AM · Wikidata Query UI, Wikidata

Nov 23 2018

Yurik committed rWDQGe443e77b5e5c: Handle the hint case when the term contains a ":" character (authored by Yurik).
Handle the hint case when the term contains a ":" character
Nov 23 2018, 4:39 AM
Yurik committed rWDQG37979ad324f2: Ability to override default data updated icon (authored by Yurik).
Ability to override default data updated icon
Nov 23 2018, 3:42 AM
Yurik committed rWDQG8e1ee2cc014b: Ability to override default data updated icon (authored by Yurik).
Ability to override default data updated icon
Nov 23 2018, 3:36 AM

Nov 19 2018

Yurik closed T209807: osmUpdate throws exceptions importing OSM Wikibase as Resolved.

Turns out the --conceptUri http://wiki.openstreetmap.org should have been http instead of https. Thanks @Smalyshev for your help!

Nov 19 2018, 4:02 PM · Wikidata, Wikidata-Query-Service
Yurik created T209807: osmUpdate throws exceptions importing OSM Wikibase.
Nov 19 2018, 5:04 AM · Wikidata, Wikidata-Query-Service

Nov 11 2018

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

I added bot approach to the wish list -- https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Miscellaneous/Shared_Multilingual_Templates_and_Modules_available_to_all_wikis
Please comment and help improve. Thanks!

Nov 11 2018, 3:01 PM · Language-strategy, Core Platform Team Backlog (Watching / External), Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, Category, Community-Wishlist-Survey-2015
Liuxinyu970226 awarded T195628: Support Vega Lite 2.0 in Graphoid a Like token.
Nov 11 2018, 12:53 PM · Graphoid, Graphs
Liuxinyu970226 awarded T195627: Support Vega 3.0 in Graphoid a Like token.
Nov 11 2018, 12:53 PM · Graphoid, Graphs
Liuxinyu970226 awarded T154071: Allow non-CC0 licensed data for datasets a Love token.
Nov 11 2018, 12:17 PM · WMF-Legal, Commons-Datasets
Liuxinyu970226 awarded T146534: Add external map service limited to location a Like token.
Nov 11 2018, 11:16 AM · Maps (Kartographer)
Liuxinyu970226 awarded T152971: Allow per-wiki customization of the map detail list a Like token.
Nov 11 2018, 11:16 AM · Maps (Kartographer)
Liuxinyu970226 awarded T137253: Migrate GeoHack to <maplink> a Like token.
Nov 11 2018, 11:15 AM · Reading-Infrastructure-Team-Backlog, Epic, Maps (Kartographer)
Liuxinyu970226 awarded T146343: Introduce global or per-wiki styles a Like token.
Nov 11 2018, 11:13 AM · Maps (Kartographer)
Liuxinyu970226 awarded T151524: Maps fast preview is broken on 2nd attempt a Like token.
Nov 11 2018, 10:08 AM · Maps (Kartographer)
Liuxinyu970226 awarded T141715: <maplink> and/or <mapframe>: Markers with white labels on light backgrounds a Like token.
Nov 11 2018, 9:44 AM · Maps (Kartographer)
Liuxinyu970226 awarded T155601: Stabilizing Interactive Products a Heartbreak token.
Nov 11 2018, 9:44 AM · Commons-Datasets, Graphs, Maps, Discovery, Maps-Sprint
Liuxinyu970226 awarded T113008: Epic: Borders aren't always marked as disputed a Like token.
Nov 11 2018, 9:43 AM · Reading-Infrastructure-Team-Backlog, Epic, Maps (Map-Styles)
Liuxinyu970226 awarded T153282: [epic] Migrate to a new vector tile structure a Like token.
Nov 11 2018, 9:43 AM · Reading-Infrastructure-Team-Backlog, Patch-For-Review, Epic, Maps (Maps-data)
Liuxinyu970226 awarded T193198: Use Wikidata international labels when OSM data is not available a Love token.
Nov 11 2018, 9:42 AM · Maps (Kartotherian), Discovery
Liuxinyu970226 awarded T153598: Support Data namespace redirects a Like token.
Nov 11 2018, 8:36 AM · Commons-Datasets
Liuxinyu970226 awarded T153966: Track Commons Dataset usage across wikis (what links here) a Like token.
Nov 11 2018, 8:36 AM · Commons-Datasets
Liuxinyu970226 awarded T155290: Add a data-page-only wiki markup header to datasets a Doubloon token.
Nov 11 2018, 8:36 AM · Need-volunteer, MediaWiki-extensions-JsonConfig, Reading-Infrastructure-Team-Backlog, Maps, Commons-Datasets
Liuxinyu970226 awarded T125539: Add property editing in Maps VE a Like token.
Nov 11 2018, 7:16 AM · Maps (Kartographer)

Nov 6 2018

Yurik added a comment to T185858: <mapframe> doesn't work so well at the poles.

IIRC, OSM can store polar regions just fine, but it is the OSM's own rendering that causes problems. Wikipedia does not use OSM's renderer, but it is similar in structure.

Nov 6 2018, 5:57 PM · Maps
Mholloway awarded T137253: Migrate GeoHack to <maplink> a Cup of Joe token.
Nov 6 2018, 3:59 PM · Reading-Infrastructure-Team-Backlog, Epic, Maps (Kartographer)

Nov 5 2018

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

@Anomie I don't think that task will have anyone working on it any time soon - that's why I proposed a bot-based solution. The good thing about that solution is that:

  • it doesn't need to wait for MW to change
  • it is multilingual
  • once MW implements something, all shared templates and modules can be switched to the new system without much effort (essentially just disable the bot)
Nov 5 2018, 6:43 PM · Wikimedia-General-or-Unknown
Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

@Capankajsmilyo AFAIK, WMF is not working on this. When I have some time, I will try to set up a bot to make this possible with the existing technology. A typical workflow:

  • A template or a module is created on mediawiki.org (MW is better because its community is more dev-focused, whereas Commons tends to be content-focused)
    • all localization strings are placed in the tabular data on Commons to simplify translation
    • template parameters are also placed in a tabular data on Commons
    • All strings are used via the Module:TNT
  • Some well known infobox is placed at the top of the template/module documentation to indicate that this module is shared between multiple wikis, and should not be changed anywhere else.
  • A bot looks for all modules/templates on MW.org that have that infobox, and copies them automatically to all other wikis using the sitelink list in Wikidata
  • If someone wants to use that template/module in a wiki X, they just need to copy/paste it to the wiki X, and add the sitelink - the bot will automatically keep it up to date from there on.
  • If a wiki decides to "fork" their version, they can simply remove the infobox from the docs.
Nov 5 2018, 6:38 PM · Language-strategy, Core Platform Team Backlog (Watching / External), Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, Category, Community-Wishlist-Survey-2015

Nov 1 2018

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

P.S. I am not sure Commons is the good place for the shared modules - simply because Commons community tends to be much less technical than the mediawiki.org community. Maybe the main source of templates and modules should be there instead, with the proper things like unit testing.

Nov 1 2018, 5:31 PM · Wikimedia-General-or-Unknown
Yurik added a comment to T208437: Consolidate and migrate Module namespace to mediawiki.org.

I agree this is needed, but perhaps we can already set this up without waiting for the complicated change in the system. There is one big reason modules and templates differ - language. So if we move translations out of the templates and modules, we can simply copy/paste them without any changes between wikis. Moreover, I think we can even automate that - e.g. any template or module that has some sort of a flag (e.g. embedded well known template) will be automatically copied from the central wiki to all other ones that want to use it. I wrote a Module:TNT that allows for the translations to be stored on Commons using shared data tables. This way, when you update a message on commons, all existing templates will automatically start using the new translation.

Nov 1 2018, 5:29 PM · Wikimedia-General-or-Unknown

Oct 30 2018

MSantos awarded T128941: map dialog not updating map node's attributes a Like token.
Oct 30 2018, 7:32 PM · Maps (Kartographer)
Yurik closed T128941: map dialog not updating map node's attributes as Resolved.

Seems to have been fixed in the past? Thx @MSantos !

Oct 30 2018, 7:31 PM · Maps (Kartographer)

Oct 26 2018

Yurik added a comment to T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

@Krinkle the (1) was to give instant feedback to the user -- that's the part that I don't think is feasible in all cases -- because template could grow in size, and blob formation happens post-save. In some cases it might be possible when we are doing page preview to show a warning in case templates already exceed blob size. I do agree the extension should handle it gracefully, and remove some of the data to keep the JSON structure.

Oct 26 2018, 10:27 PM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error
Yurik updated subscribers of T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

Adding a new table shouldn't be too hard, just requires someone to work on it :) @MaxSem actually had some prototype of this a few years back :)
Changing data would help because that data is essentially a key-value dictionary of objects. Each object is independent, and represents a separate graph. If there is a giant single graph on the page, this won't help. But if there are multiple large graphs, deleting some of them would make it possible for at least some of them to show up, rather than the whole page to fail.

Oct 26 2018, 10:02 PM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error
Yurik reopened T184712: Page.title(asUrl=True) should encode also slashes as "Open".
Oct 26 2018, 9:11 PM · Patch-For-Review, Pywikibot
Yurik added a comment to T184712: Page.title(asUrl=True) should encode also slashes.

Turns out this does break the 3rd party sites, e.g. wiki.openstreetmap.org. I think we should revert and introduce a separate path for the rest API.

Oct 26 2018, 9:11 PM · Patch-For-Review, Pywikibot
Yurik added a comment to T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

More than 64KB is too large? That sounds ... strange when discussing modern systems that are perfectly capable of storing much bigger data rows. Especially when we clearly have a valid use case for it.

Oct 26 2018, 7:33 PM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error
Yurik added a comment to T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

The only graceful thing we can do is something like this:

while (True) {
  gzData = gzip(rawData);
  if (length(gzData) < XXX) break;
  unset(rawData[length(rawData)-1]);  // delete last element
}

Could be optimized further.

Oct 26 2018, 12:56 AM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error

Oct 24 2018

Yurik added a comment to T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

Ahem... you did not offer any better alternatives :-) The proper solution is to simply change blob to large storage. That said, I don't think page props should be used for it. Instead, it should be a general "large blob storage" key-value store, where different extensions could store hash-based data. This way multiple page revisions could reuse the same blob, and at the same time updates to templates would create new blobs. This would also require usage counting (tricky). There is another big task about this.

Oct 24 2018, 9:19 PM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error
Yurik added a comment to T184128: "PHP Warning: data error" from gzdecode() in ApiGraph.php and ApiQueryMapData.php.

(1) is not feasible -- if I build a page with the geojson or a complex graph, and some article adds multiple templates (e.g. an article with 10 graphs), the article blob may not fit all the data, causing this issue. In many cases, there is no way to even give feedback to the user, e.g. if the template gets updated after the article is created.

Oct 24 2018, 9:09 PM · MW-1.33-notes (1.33.0-wmf.1; 2018-10-23), Patch-For-Review, Reading-Infrastructure-Team-Backlog (Kanban), Maps (Kartographer), Editing-team, Graphs, Wikimedia-production-error
Yurik added a comment to T207017: Create an #OSM tag to identify tasks with OpenStreetMap relevance.

Agree.

Oct 24 2018, 2:49 AM · Project-Admins

Oct 23 2018

Yurik added a comment to T207017: Create an #OSM tag to identify tasks with OpenStreetMap relevance.

Thx @Aklapper , I think WIWOSM wouldn't be part of it, because, just like Kartotherian and other techs, WIWOSM is using OSM tech/data, but does not affect the OSM project itself. On the other hand, some bug in MediaWiki could affect OSM community because OSM wiki uses MediaWiki engine. Essentially this tag would indicate the affected audience. BTW, the multilingual map efforts would probably fall under this tag because Wikipedia drives contributors back to OSM to contribute the name translations.

Oct 23 2018, 2:19 PM · Project-Admins

Oct 18 2018

Yurik added a comment to T165118: Support Vega 3.0 and Vega Lite 2.0.

@Milimetric v3 and v4+ are not very different. Just some minor integration API changes. 4 is 99% backward compatible. So yes, we could just skip to 4.3

Oct 18 2018, 7:45 PM · Outreach-Programs-Projects, Graphs

Oct 15 2018

MGChecker awarded T207017: Create an #OSM tag to identify tasks with OpenStreetMap relevance a Like token.
Oct 15 2018, 8:11 PM · Project-Admins
Yurik updated the task description for T207017: Create an #OSM tag to identify tasks with OpenStreetMap relevance.
Oct 15 2018, 11:50 AM · Project-Admins
Yurik created T207017: Create an #OSM tag to identify tasks with OpenStreetMap relevance.
Oct 15 2018, 11:49 AM · Project-Admins

Oct 7 2018

Yurik created T206426: Storing multiple sitelinks to a multilingual wiki.
Oct 7 2018, 7:24 PM · Wikidata

Oct 5 2018

Yurik added a comment to T86517: [Story] Add a new datatype for multilingual text.

Another possible use case: multiple sitelinks to the same site. For example, Wikidata may have a project page for postal codes in English, and someone wants a similar page in German. But the community does not want direct translation, because English page may want to cover the whole world, while the corresponding German page may only want to concentrate on the aspects specific to Germany.

Oct 5 2018, 10:22 PM · Story, MediaWiki-extensions-WikibaseRepository, Wikidata

Oct 2 2018

Yurik added a comment to T163274: Move JCMapDataContent from JsonConfig to Kartographer.

See my previous comment, I don't think this task should be done at all.

Oct 2 2018, 7:46 PM · Continuous-Integration-Config, Patch-For-Review, Reading-Infrastructure-Team-Backlog, Technical-Debt, Maps (Kartographer), MediaWiki-extensions-JsonConfig

Sep 27 2018

Yurik updated the task description for T189490: Solve search inconsistencies. Suggestion: Replace item selector search box with normal search box.
Sep 27 2018, 8:18 AM · Wikidata, Tracking, Wikidata.org

Sep 26 2018

Yurik added a comment to T205560: Add option to disable Wikibase’ custom search box.

@Smalyshev correct. Ideally we should have T190454, but unless we want to stop using wikibase until it is ready, this is a good interim solution.

Sep 26 2018, 7:28 PM · MW-1.33-notes (1.33.0-wmf.2; 2018-10-30), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞), User-Ladsgroup, MediaWiki-extensions-WikibaseRepository, Wikidata