Yurik (Yuri Astrakhan)
User

Projects (13)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Oct 7 2014, 6:43 PM (189 w, 1 d)
Availability
Available
LDAP User
Yurik
MediaWiki User
Yurik

Recent Activity

Mon, May 14

Yurik added a comment to T187582: Move from Mapbox.js to Leaflet.

I think the initial idea was to use client-side rendering, and mapbox offers a better path for that.

Mon, May 14, 1:34 PM · User-Abbe98, Maps (Kartographer), Maps-Sprint

Fri, May 11

Yurik added a comment to T191585: Release mapframe to all NON-Flagged Revs wikipedia (and a few who do have Flagged Revs). .

Note that ruwiki has similar settings, and has mapframe enabled, but has not observed any issues (or at least they have not reported them).

Fri, May 11, 8:47 PM · Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), TCB-Team, German-Community-Wishlist, Discovery, Maps (Kartographer)
Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

Old revisions are not in the parser cache (AFAIK), so they'd have to be reparsed every time.

Fri, May 11, 7:56 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)
Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

Architecture: parser for graph/kartographer generates JSON blobs and their hashes. The hash goes into img URL. Browser fetches image from backend service, which uses the hash to get the original JSON blob from MW API and renders it into an image. There are two levels of caching: image cache (Varnish), and memcached used by the MW API (per hash).

Fri, May 11, 3:19 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)
Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

Sure, that's fine. The problem is the cache. If you include revisionID in the URL, your image MUST regenerate on each save (regardless if it depends on time or not). This is an expensive operation, plus users may be annoyed that their graphs/maps don't show up right after saving. If you don't include revID, you cannot regenerate the page, but only get it from the cache when available. BTW, currently json blobs are already stored in memcached, with the longest possible expiration.

Fri, May 11, 1:38 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)
Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

similar - you re-run parser for the specific page revision (either new or old), for the whole page, and as part of that process you get a JSON blob. That json blob is what the graphoid/kartotherian services need to render the image. Hash is just a way to uniquely identify that blob. Most of the time, the blob would be identical between revisions, or oven across multiple pages in the same wiki. But in some cases, e.g. when time-related constants are used, the blob will be different with each parsing.

Fri, May 11, 1:24 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)
Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

@Tgr the main problem with cache is that sometimes it might not be there when needed, and it would have to be rebuilt. But to rebuild something, you have to somehow provide the context required for the rebuilding. Currently each graph is identified with the hash, making it impossible. The map/graph would have to use a different URL structure, and include all the needed info (e.g. page revision ID and graph index), and graphoid/kartotherian would have to pass all that info to MW API for regeneration. But the moment you include revision ID, you destroy the image cache, because each image would have to be regenerated on each page save - and regenerating these images may take longer that page parsing itself.

Fri, May 11, 1:15 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)

Wed, May 9

Yurik updated subscribers of T112948: All map location names should be in the user's language.

@Ghuron use nolabels parameter.

Wed, May 9, 5:18 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n

Tue, May 8

Yurik added a comment to T112948: All map location names should be in the user's language.

@Ghybu I believe it's already available - https://maps.wikimedia.org/?s=osm#4/40.75/-73.96 (style = "osm")

Tue, May 8, 11:23 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n

Mon, May 7

Yurik added a comment to T155290: Add a data-page-only wiki markup header to datasets.

I think having a separate description slot, where you could put categories, templates, bot instructions, human instructions, etc. would be the best solution. Trying to make JSON into what it's not meant for is far inferior.

Mon, May 7, 8:38 PM · Maps, Discovery, Commons-Datasets
Yurik added a comment to T155290: Add a data-page-only wiki markup header to datasets.

We do it this way in js and css.

Mon, May 7, 6:57 PM · Maps, Discovery, Commons-Datasets
Yurik added a comment to T155290: Add a data-page-only wiki markup header to datasets.

@daniel while i do agree with you in principle, it might be a while to implement. Adding a single field to JSON and passing it through parser is about 5 lines of code, and should take at most an hour of a skilled dev. Also, I wouldn't separate categories from the wiki markup here, simply because most of the time you want templates with categories to auto-add stuff, rather than each page having individual category fields. Also, this method does not preclude future migration to the multi-part system - rather it will be very straightforward.

Mon, May 7, 3:06 PM · Maps, Discovery, Commons-Datasets
IKhitron awarded T155290: Add a data-page-only wiki markup header to datasets a Doubloon token.
Mon, May 7, 1:38 PM · Maps, Discovery, Commons-Datasets

Sun, May 6

Yurik created T193955: Include default_language into all features with names.
Sun, May 6, 2:58 AM · Maps, Discovery

Thu, May 3

Abbe98 awarded T193198: Use Wikidata international labels when OSM data is not available a Party Time token.
Thu, May 3, 7:05 AM · Maps (Kartotherian), Discovery
Pigsonthewing awarded T193198: Use Wikidata international labels when OSM data is not available a Like token.
Thu, May 3, 6:48 AM · Maps (Kartotherian), Discovery

Tue, May 1

Raymond awarded T193198: Use Wikidata international labels when OSM data is not available a Love token.
Tue, May 1, 9:07 PM · Maps (Kartotherian), Discovery
Yurik added a comment to T112819: tile source requires at least two characters, should be one.

This might be a bug/limitation of the express engine routing matching?

Tue, May 1, 4:39 PM · Maps (Kartotherian), Discovery
Yurik added a comment to T193458: Complex maps began to fail.

Awesome, thanks @SBisson for figuring out. At first I thought it was something much more substantial as it coincided with various deployments.

Tue, May 1, 4:37 PM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Regression, Discovery, Maps
Yurik added a comment to T112819: tile source requires at least two characters, should be one.

@Abbe98 have you tried creating a single-letter source? I'm ok with closing this issue, as its not really "issue-worthy"

Tue, May 1, 3:05 PM · Maps (Kartotherian), Discovery
Yurik updated subscribers of T193458: Complex maps began to fail.
Tue, May 1, 3:28 AM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Regression, Discovery, Maps
Yurik updated subscribers of T193458: Complex maps began to fail.
Tue, May 1, 3:27 AM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Regression, Discovery, Maps
Yurik created T193458: Complex maps began to fail.
Tue, May 1, 3:26 AM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Regression, Discovery, Maps

Mon, Apr 30

Yurik added a comment to T189883: Enable <mapframe> on kannada wikipedia.

@Urbanecm this is not accurate. changes to existing systems take a long time - people need to agree that the "new" system is better and it is ok to change. That's why introducing a new media viewer was messed up - it required every community to agree on the new way to see images for everyone, and the change wasn't well accepted/delivered.

Mon, Apr 30, 3:01 PM · Collaboration-Team-Triage, Collaboration-Feature-Rollouts (Collaboration-Maps), Patch-For-Review, Maps-Sprint, User-Jayprakash12345, Wikimedia-Site-requests, Maps (Kartographer)

Thu, Apr 26

Yurik created T193198: Use Wikidata international labels when OSM data is not available.
Thu, Apr 26, 8:08 PM · Maps (Kartotherian), Discovery

Wed, Apr 25

Yurik added a comment to T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

Storing just the keyvalue hash->spec is not a very good solution, because graphs/map templates/lua may rely on dynamic things like time, which means the data will keep changing with every map rendering, polluting this table without any hope of cleaning it up.

Wed, Apr 25, 3:32 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)

Apr 21 2018

Yurik updated subscribers of T192695: Move GeoJSON for <mapframe> tags to its own table instead of page_props (in order to fix Flagged Revs with mapframe).

I think @MaxSem was working on this a while back, and might have even had some code. ]

Apr 21 2018, 1:21 AM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Kartographer)
Yurik added a comment to T192662: name:<local name code> is not always available in OSM.

@SBisson I think adding an extra tag to every single OSM object with the name tag is a bit excessive - there are 62 million of them. A much better solution IMO is to make it possible to calculate that language based on the geo position of the object. My suggestion was to create a new "language meta-regions" with the language tags. Another solution is to add language tags to the existing regions. Both have pros/cons, but so far it was only discussed in that mailing thread (link above). If either of these solutions are implemented, it should be possible to generate a geo index for lookups - something that can be done during vtile data generation.

Apr 21 2018, 1:13 AM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps, Discovery

Apr 20 2018

Yurik added a comment to T192662: name:<local name code> is not always available in OSM.

I think you meant name=<local name>, not name:<local name>. "name" should be the last fallback if other options are not available. "int_name" should also be considered (it's the most common tag besides the name itself -- over 400,000). As for telling the language of the "name", I proposed OSM to have regions with primary language code) - currently being discussed. Please participate.

Apr 20 2018, 3:55 PM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps, Discovery

Apr 17 2018

Yurik added a comment to T192249: Support for non-integer Wikidata IDs (or alternative).

@daniel sorry, let me clarify.

Apr 17 2018, 8:30 PM · Wikidata

Apr 16 2018

Yurik added a comment to T192249: Support for non-integer Wikidata IDs (or alternative).

@daniel this is awesome, thanks! The sitelink hack would probably be the best approach for the tag keys (e.g. name, address etc.) I am not yet sure of the best approach for the "enum-like" values -- some tags, e.g. religion tend to have a well-known list of values. It would be good to have a separate namespace for all the possible values for them. Enforcing uniqueness for them does not make sense -- same value could be used for more than one tag, and could have very different meaning. One option to store tag value would be to allow duplicates (use a regular string property to store the actual value), to reference all tag entities, and to use a bot to ensure that tags are referenced only ones per each unique value. Or it could be some on-db-update check...

Apr 16 2018, 3:29 PM · Wikidata
Yurik added a comment to T192249: Support for non-integer Wikidata IDs (or alternative).

thx, clearly this wouldn't be used for wikidata. @daniel could you point me to the relevant code plz, or perhaps something similar, or maybe sketch the implementation approach? I was thinking that this would be the only real path to solve this, possibly with a custom database table to prevent accidental duplicates.

Apr 16 2018, 8:17 AM · Wikidata
Yurik updated subscribers of T112948: All map location names should be in the user's language.

Might be related to @Cwek's T98836#4093634

Apr 16 2018, 6:57 AM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n
Yurik updated the task description for T192249: Support for non-integer Wikidata IDs (or alternative).
Apr 16 2018, 12:58 AM · Wikidata
Yurik created T192249: Support for non-integer Wikidata IDs (or alternative).
Apr 16 2018, 12:49 AM · Wikidata

Apr 14 2018

Yurik added a comment to T112948: All map location names should be in the user's language.

Getting OSM to even discuss standardization is very hard - there are always "territorial" people who say that they prefer things as is for their neck of the woods, even for small things like these (I had a fair share of fights on this one). I do agree that the system should be flexible to cover all use cases, but I also think all communities should work together to harmonize the data in order to increase its value, and to allow data consumers to actually make sense of it.

Apr 14 2018, 11:41 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n
Yurik added a comment to T112948: All map location names should be in the user's language.

Not sure if this was discussed before. Many labels in OSM are encoded with an extra param, e.g. Latn (75k), _rm (250k+), _kana, _pinyin, hira, and other. Search for "name:" for the full list. How should these be handled? I think babel used to have some support for it, but it might have been recently removed.

Apr 14 2018, 10:52 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n
Yurik added a comment to T192187: Allow custom language in <mapframe>.

It does use the content language, not the user language. $this->getLanguage() ends up using $this->parser->getTargetLanguage(), which is the page language (which is generally the content language, except in weird cases like translated pages).

Apr 14 2018, 12:55 AM · MW-1.32-release-notes (WMF-deploy-2018-04-24 (1.32.0-wmf.1)), MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)
Yurik added a comment to T192187: Allow custom language in <mapframe>.

I don't think https://gerrit.wikimedia.org/r/426322 should have been merged. Besides the no tests, it uses user language, not content language. As such, this ends up with weird behavior: if content author created a <mapframe lang=xx>, it will always show the map in xx, but if they didn't specify lang param, it will use User's language, not the content language.

Apr 14 2018, 12:38 AM · MW-1.32-release-notes (WMF-deploy-2018-04-24 (1.32.0-wmf.1)), MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)

Apr 12 2018

Lea_WMDE awarded T151665: Investigate how <mapframe/link> work with the Flagged Revisions extension a Love token.
Apr 12 2018, 7:51 AM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), TCB-Team, German-Community-Wishlist, Discovery, Maps (Kartographer)

Apr 11 2018

Yurik added a comment to T112948: All map location names should be in the user's language.

@Pnorman makes sense. @Catrope wrt caching, I was thinking more in terms of caching fully identical tiles in an efficient way (e.g. if tiles is identical in multiple languages, or even if it has identical content such as water to use some optimized caching strategy, but I guess since tiles are tiny, the mgmt overhead won't make it worth while)

Apr 11 2018, 11:06 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n
Yurik added a comment to T112948: All map location names should be in the user's language.

@Catrope @Next2u 's propsal doesn't preclude all that work. It could be a one line change in Varnish - simply change domain name into a lang parameter, and let the backend handle it as before. My only only other concern with the proposal is that lang parameter allows anything at all, whereas domain name usually comes from a whitelist. Not sure which is better - merits for both.

Apr 11 2018, 7:38 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n
Yurik updated subscribers of T112948: All map location names should be in the user's language.

@Next2u I actually really like this idea! Makes testing and serving much better, and avoids ugly URL parameters. I just wonder if some sort of caching optimization is needed/possible in this case (cc: @Gehel)

Apr 11 2018, 7:14 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n

Apr 6 2018

Yurik added a comment to T191484: Use a different config file on maps-test2004.

@Pnorman no, the compilation of tm2source yaml -> mapnik xml still has to be done outside of Kartohterian. PRs are welcome :)

Apr 6 2018, 4:09 PM · Maps-Sprint

Apr 5 2018

Yurik added a comment to T175739: Switch geoline/geoshape to new schema.

i have solved this a bit differently with Sophox's region service (github). I think this approach is much better because it decouples tile generation from the regions service, and because the database is much smaller and can be regenerated and updated much more frequently/rapidly.

Apr 5 2018, 11:33 PM · Discovery, Maps, Maps-Sprint

Apr 4 2018

Yurik added a comment to T151665: Investigate how <mapframe/link> work with the Flagged Revisions extension.

Update: more specifically, on English Wikipedia, flagged revs is mostly enabled on biographies of living people (not very map related) - see https://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions -- which means English wiki doesn't have to be prevented from mapframe on the account of flaggedrevs.

Apr 4 2018, 4:59 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), TCB-Team, German-Community-Wishlist, Discovery, Maps (Kartographer)
Yurik added a comment to T151665: Investigate how <mapframe/link> work with the Flagged Revisions extension.

@jmatazzoni both lists are correct. I listed just the Wikipedias, whereas @MaxSem listed all other projects too. Note that mapframe is already enabled in all those other projects, and, to my knowledge, noone had any issues. Also note that the <graph> tag uses identical system of data storage to maps, and it has been enabled on all wikis for many years, and noone has raised any major issues either. So while flagged rev issue is real, in reality it seems to affect almost noone. For example, flaggedrev is enabled on enwiki, but there are very limited number of actual articles that enable it.

Apr 4 2018, 4:46 PM · Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), TCB-Team, German-Community-Wishlist, Discovery, Maps (Kartographer)

Mar 30 2018

Yurik added a comment to T22825: Change default font for EasyTimeline on zh projects to something that actually has glyphs for Chinese characters.

Crosslinking with T156191 and T127683 - might be related, or addressed in the same way?

Mar 30 2018, 3:23 AM · Chinese-Sites, EasyTimeline, Patch-For-Review, Wikimedia-log-errors, I18n, Wikimedia-Site-requests
Yurik added a comment to T98836: Graph Extension doesn't render Chinese in Graph images.

@Cwek thx for the heads up on this! I wonder if this also addressed T156191 and T127683

Mar 30 2018, 3:21 AM · Chinese-Sites, Services (watching), Graphoid, I18n, Graphs

Mar 29 2018

Yurik added a comment to T187288: maps.wikimedia.org copyright attribution should be translated.

I also think this is not needed for the test endpoint.

Mar 29 2018, 3:51 PM · Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartotherian)
Yurik added a comment to T112948: All map location names should be in the user's language.

@jmatazzoni as far as I know, most consumers of OSM, e.g. Mapbox and Klokane, use Wikidata for international labels. Simply because OSM's international coverage is nowhere as good as what Wikidata has. I have built Sophox query service (based on Wikidata's query service) - its a database that combines both the Wikidata and OSM data into one place, thus allowing to easily merge the two results.

Mar 29 2018, 3:23 PM · Patch-For-Review, Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), Maps (Map-Styles), I18n

Mar 22 2018

Yurik closed T164773: Error replicating wikidata blazegraph setup as Invalid.

Seem like lowering the upload batch size fixed most of the memory issues. The system still crashes on occasion, but works okayish otherwise. Thx!

Mar 22 2018, 9:06 PM · Discovery, Wikidata-Query-Service, Wikidata

Mar 21 2018

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

@Rical take a look at Template:Graph:Lines -- that template's localized parameter documentation is stored in one place at the single location, and can be changed there without going to each wiki and copy/pasting things inside the complex template. Beyond that, the caption under the graph is also localized -- the string "See or edit raw graph data." is localized using the {{#invoke:TNT|msg|I18n/Template:Graphs.tab|source_table|{{#invoke:TNT|link|{{{table}}}}}}} (a bit cryptic, I know - it uses TNT twice, once to render the link, and once to render the whole message). The localized messages are actually stored here.

Mar 21 2018, 11:33 PM · Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, MediaWiki-Platform-Team, Category, Community-Wishlist-Survey-2015
Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

@Rical take a look at the https://www.mediawiki.org/wiki/Module:TNT module -- it already allows one global translation table that can be used in any template anywhere. This allows a template or a module to be copy/pasted to any wiki without a single modification. Only requirement - the TNT module must be present on the wiki (many wikis already have it).

Mar 21 2018, 7:28 PM · Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, MediaWiki-Platform-Team, Category, Community-Wishlist-Survey-2015
Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference.

It depends on the use-case. Some of the past discussions focused on the difference between use-cases like Help pages v. User pages v. Template and Module pages. They may require different solutions, even though they can feel like similar problems.

Mar 21 2018, 7:25 PM · Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, MediaWiki-Platform-Team, Category, Community-Wishlist-Survey-2015
Yurik added a comment to T121470: Central Global Repository for Templates, Lua modules, and Gadgets.

@MZMcBride I think this task is the implementation of one aspect of T66475 . Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference. Shadow implies local (per-language) override, whereas most of the time you don't want to override per language, you want to override per usecase, and that override may be useful for more than one language. To give an example, lets say you have an infobox that most wikis find useful, but it breaks in RTL wikis. You have two options - either fix the infobox so that it works on both (preferable, but might be very hard), or you could create a new infobox for RTL wikis, in which case it is useful to all RTL wikis, not just a single one. So instead of having a global + several local overrides, there should be two globals.

Mar 21 2018, 4:37 PM · Community-Tech (2015-2017), Epic, Wikimedia-General-or-Unknown, MediaWiki-Platform-Team, Category, Community-Wishlist-Survey-2015

Mar 19 2018

Yurik added a comment to T187291: Maps: Remove Wikidata info from attribution overlay.

I disagree - I find sourcing data extremely useful, but either of these are hearsay. I agree that we should first and foremost honor the licensing requirement - so the easiest solution is to actually show copyright info first, followed by wikidata links. This will solve the immediate need, and we can work on a proper solution without removing otherwise perfectly useful feature.

Mar 19 2018, 9:14 PM · MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)
Yurik added a comment to T187291: Maps: Remove Wikidata info from attribution overlay.

I agree, it would be great to have a separate "source data" UI separate from copyrights. While this UI is not there, I think we should simply set a maximum of how many WD items are shown (e.g. at most 3, plus add an ellipses if needed) - this will quickly address the problem without sacrificing the useful feature others rely on.

Mar 19 2018, 8:00 PM · MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)

Mar 18 2018

Yurik added a comment to T141750: <maplink> and/or <mapframe>: clickable marker area too big.

I merged it - as it seemed a valid patch. @MaxSem could you think of a better alternative to dynamically patch upstream lib? We could also submit it upstream.

Mar 18 2018, 6:46 PM · MW-1.31-release-notes (WMF-deploy-2018-04-10 (1.31.0-wmf.29)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer), Discovery

Mar 17 2018

Yurik added a comment to T189883: Enable <mapframe> on kannada wikipedia.

Shouldn't all small wikis that do not use flagged revisions extension just get this? Otherwise this seems like a busy work - there are 300 wikis, each "enablement" takes probably around 5 hours of combined human time, making this into a two months of wasted human time... that doesn't really gain anything. WMF has never done anything remotely similar to any of its content features that have been so widely requested. Most of these 2 months of time is being paid by the donations too...

Mar 17 2018, 12:25 AM · Collaboration-Team-Triage, Collaboration-Feature-Rollouts (Collaboration-Maps), Patch-For-Review, Maps-Sprint, User-Jayprakash12345, Wikimedia-Site-requests, Maps (Kartographer)

Mar 15 2018

Yurik added a comment to T187596: Kartotherian should accept (and propagate) a language parameter for tiles.

Not exactly - this.lang always depends on which "source" you are talking about. The this.lang in babel instance is different from the this.lang in tilelive-vector instance. The pipeline is initiated during the startup - the global storage stores one instance per "source ID", and if one source gets data from another source, that chaining is set up initially. E.g. if view is using generator, there will be one instance of view, which internally references one instance of generator. When user asks for a tile, Kartotherian gets the named instance (e.g. "view" or "osm-intl"), and calls getTile (now its getAsync), passing all the params. Kartotherian would not be able to set any params on the "generator" source because at that point it doesn't know that generator source will be used by the view source.

Mar 15 2018, 8:56 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter)
Yurik added a comment to T187596: Kartotherian should accept (and propagate) a language parameter for tiles.

Interesting idea! The problem is that this (IIRC) is not per request, it's per tilelive instance. Each instance gets its state from the config file, so you have as many instances as sources. Per-request state is only passed via parameters, and that's where the limitation comes in - original tilelive API params are only x,y,z, not opts. That's why I had to introduce a new getAsync method to pass additional state.

Mar 15 2018, 7:42 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter)
Yurik added a comment to T187596: Kartotherian should accept (and propagate) a language parameter for tiles.

@SBisson the custom version of vector should handle that, but I don't remember if that was fully implemented (most of it was for sure). See https://github.com/kartotherian/tilelive-vector ...

Mar 15 2018, 6:25 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter)

Mar 14 2018

Yurik added a comment to T187598: Pass MW user language to Kartotherian from Kartographer.

@MaxSem I think static map should still be site-language based, which would prevent cache bloat, while still be useful to the readers (map in Japanese wiki will show in Japanese)

Mar 14 2018, 10:41 PM · MW-1.31-release-notes (WMF-deploy-2018-03-20 (1.31.0-wmf.26)), Patch-For-Review, Maps (Kartographer), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n
Yurik added a comment to T187598: Pass MW user language to Kartotherian from Kartographer.

@Mooeypoo are you sure about that? I was under the impression that the parser has user (or at least site) language, which means it could generate a proper language-dependent url for the static image.

Mar 14 2018, 10:32 PM · MW-1.31-release-notes (WMF-deploy-2018-03-20 (1.31.0-wmf.26)), Patch-For-Review, Maps (Kartographer), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n
Yurik added a comment to T187595: Implement a language selection processing step for vector tiles.

That seems correct. Try looking at the tile at every state, see if labels are there initially, and if so, when does it disappears

Mar 14 2018, 3:38 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n
Yurik added a comment to T187595: Implement a language selection processing step for vector tiles.

@SBisson I wrote some docs in https://github.com/kartotherian/babel#usage-examples -- I think prod source configs should follow that pattern. The tilerator config should use the json2tags as part of the tile generation pipeline - converting one giant json string into proper pbf tags. The babel should be used in kartotherian config, to convert the tile on the fly for the user. I would recommend using a language map option with it - to create a proper language fallback map.

Mar 14 2018, 2:42 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n

Mar 12 2018

Yurik added a comment to T189401: document the timelines format.

@Gryllida you are right. There is an extensive Vega doc site, which also includes a number of tutorials, but unfortunately it documents Vega 3, whereas Wikipedia is still using Vega 2. The concepts are very similar, but there are some syntax changes between versions. Also, there is a much simpler language called Vega-Lite, used for the most typical X/Y graphs, and eventually I hope WP will support both.

Mar 12 2018, 11:16 PM · Documentation, Graphs

Mar 9 2018

Yurik added a comment to T187291: Maps: Remove Wikidata info from attribution overlay.

@kaldari I agree that when we have this many data points, they become bad. This was initially designed when you have just a few wikidata objects, e.g. the outline of a single country or the shape of some famous street. This allows users to quickly navigate to the Wikidata item in question, similar to how French Wikipedia has "edit" link next to each item in the infobox that gets generated from Wikidata.

Mar 9 2018, 3:07 AM · MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)

Mar 7 2018

Yurik added a comment to T187291: Maps: Remove Wikidata info from attribution overlay.

I think the links to Wikidata should remain, but need to be restyled. The reason these links were placed there is to allow users to view the source of the data, not to satisfy a legal requirement. One option would be to restrict the links to just the first few - this will help when the map has only a few items, but won't clutter it.

Mar 7 2018, 5:50 PM · MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)

Mar 6 2018

Yurik added a comment to T188894: Tabular Data support in pywikibot.

I replied to https://www.mediawiki.org/w/index.php?title=Topic:U8qudxbgf2xujfsw&topic_showPostId=u8rrlm6pbjgyg7gz&fromnotif=1#flow-post-u8rrlm6pbjgyg7gz -- take a look at this example -- you need to set "contentmodel": "Tabular.JsonConfig"

Mar 6 2018, 6:35 AM · Commons-Datasets, Pywikibot-core

Feb 28 2018

Yurik added a comment to T181319: Support external tabular datasets in WDQS.

@Smalyshev the reason I made type as a string is to allow additional parsing parameters, e.g. ?start tabular:startDate 'date:yyyy-mm-dd'

Feb 28 2018, 9:40 PM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata

Feb 24 2018

Liuxinyu970226 awarded T122086: RFC: Sharing templates and modules between wikis - poor man's version (investigation) a Dislike token.
Feb 24 2018, 12:28 PM · RfC, Pywikibot-RfCs

Feb 16 2018

Yurik added a comment to T187595: Implement a language selection processing step for vector tiles.

Kartotherian's babel does exactly this, but it needs to be configured with the right fallback rules.

Feb 16 2018, 11:54 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n
Yurik added a comment to T187599: Implement fallback handling in Kartotherian's language selection.

Just FYI, Kartotherian babel already supports the fallback. The big question is actually decide what to fall back to for each language. Currently it simply accepts a dictionary of language -> [ fallback chain ]

Feb 16 2018, 11:53 PM · Maps (Kartotherian), Collaboration-Feature-Rollouts (Collaboration-Maps), Collaboration-Team-Triage (Collab-Team-This-Quarter), I18n

Feb 14 2018

Yurik updated the task description for T187291: Maps: Remove Wikidata info from attribution overlay.
Feb 14 2018, 8:30 AM · MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)), Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)

Feb 12 2018

Yurik added a comment to T186779: Enable zoom 19 in kartographer / mapframe / maplink.

snapshot service might not allow z19, but this is probably in a config somewhere.

Feb 12 2018, 11:13 AM · Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps-Sprint, Maps (Kartographer), Discovery

Feb 11 2018

Yurik added a comment to T141304: Only a part of MAKI symbols is available (previously map icon "castle" broken).

There could be a different, more powerful alternative to improving [[ https://github.com/mapbox/simplestyle-spec | simplestyle support (e.g. maki icons, etc), especially as it appears to have been mostly abandoned by Mapbox (at least I haven't heard of any changes with it)

Feb 11 2018, 9:48 PM · Maps (Kartographer), Discovery

Feb 9 2018

Yurik added a comment to T186779: Enable zoom 19 in kartographer / mapframe / maplink.

snapshot service needs to accept zoom 19 too.

Feb 9 2018, 9:16 PM · Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), Collaboration-Feature-Rollouts (Collaboration-Maps), Maps-Sprint, Maps (Kartographer), Discovery

Feb 4 2018

Yurik created T186473: Wikibase Docker should (optionally) use OAauth2 against WP.
Feb 4 2018, 9:38 PM · Wikidata, Wikibase-Containers, MediaWiki-Containers

Jan 29 2018

Yurik added a comment to T120809: Generate location maps dynamically, producing actual images.

I think this task can be closed because it can be done with https://en.wikipedia.org/wiki/Template:OSM_Location_map

Jan 29 2018, 11:45 PM · Maps (Kartographer), Commons, MediaWiki-extension-requests, Discovery
Mrjohncummings awarded T138057: Epic: Enable <mapframe> on Wikipedia a Love token.
Jan 29 2018, 10:42 AM · Discovery, Maps, Epic

Jan 17 2018

Yurik added a comment to T177019: Don't reference git masters in package.json.

@Pnorman my apologies, added.

Jan 17 2018, 9:58 PM · Maps (Kartotherian), Maps-Sprint
Yurik added a comment to T177019: Don't reference git masters in package.json.

@Pnorman, I have added you to the kartotherian npmjs project a week ago. Were you not able to publish?

Jan 17 2018, 9:27 PM · Maps (Kartotherian), Maps-Sprint

Dec 26 2017

Yurik added a comment to T181319: Support external tabular datasets in WDQS.

The first version of this feature has been implemented in Sophox -- see docs. At this point, it supports any GET request that returns CSV-style data (parsable by Java's CSVParser, with many parameters).

Dec 26 2017, 4:10 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata

Dec 18 2017

Yurik added a comment to T181319: Support external tabular datasets in WDQS.

@Lucas_Werkmeister_WMDE I agree - I am planning to implement this feature for both WDQS and Sophox QS. For WDQS, it should only support tabular datasets, or possibly other respected sources.

Dec 18 2017, 11:48 PM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata
Yurik updated the task description for T181319: Support external tabular datasets in WDQS.
Dec 18 2017, 3:08 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata

Nov 28 2017

Yurik updated the task description for T181319: Support external tabular datasets in WDQS.
Nov 28 2017, 2:11 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata
Yurik updated the task description for T181319: Support external tabular datasets in WDQS.
Nov 28 2017, 2:11 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata

Nov 25 2017

Yurik updated the task description for T181319: Support external tabular datasets in WDQS.
Nov 25 2017, 12:21 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata
Yurik updated the task description for T181319: Support external tabular datasets in WDQS.
Nov 25 2017, 12:20 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata
Yurik created T181319: Support external tabular datasets in WDQS.
Nov 25 2017, 12:19 AM · User-Smalyshev, Commons-Datasets, Discovery, Wikidata-Query-Service, Wikidata

Nov 13 2017

Yurik added a comment to T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.

Label service is also very slow, like 2 times slower than to just query labels a normal way, considering that map data processing is probably more complex than just fetching a label I am afraid that it won't work for any real queries with current timeout…

Nov 13 2017, 12:32 PM · Need-volunteer, Discovery, Commons-Datasets, Wikidata-Query-Service, Wikidata
Yurik updated subscribers of T180314: WDQS geof:distance() throws an error on some P625 value.

Duplicate of T175578?

Nov 13 2017, 12:11 PM · Patch-For-Review, Discovery, Wikidata, Wikidata-Query-Service
Yurik updated the task description for T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.
Nov 13 2017, 8:52 AM · Need-volunteer, Discovery, Commons-Datasets, Wikidata-Query-Service, Wikidata
Yurik updated the task description for T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.
Nov 13 2017, 8:50 AM · Need-volunteer, Discovery, Commons-Datasets, Wikidata-Query-Service, Wikidata
Yurik updated the task description for T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.
Nov 13 2017, 8:27 AM · Need-volunteer, Commons-Datasets, Discovery, Wikidata, Wikidata-Query-Service
Yurik updated the task description for T180314: WDQS geof:distance() throws an error on some P625 value.
Nov 13 2017, 8:12 AM · Patch-For-Review, Discovery, Wikidata, Wikidata-Query-Service
Yurik updated the task description for T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.
Nov 13 2017, 8:01 AM · Need-volunteer, Commons-Datasets, Discovery, Wikidata, Wikidata-Query-Service
Yurik updated the task description for T179991: Add a geo lookup service to WDQS based on the .map pages on Commons.
Nov 13 2017, 7:43 AM · Need-volunteer, Commons-Datasets, Discovery, Wikidata, Wikidata-Query-Service