Bojan (User:Bjankuloski06) a bureaucrat on the Macedonian Wikipedia (mk.wikipedia.org) would like to have Kartographer installed. However, he says, "We would like to have Kartographer installed, but none of us admins or bureaucrats know how to do it at all. Could you help us? It would be very nice if you can actually install it for us, as we are sure that we'll mess something up."
I've reached out to Bojan to ask if there is community support for this and will update the task when I hear back.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable Kartographer on Meta, ca:, he: and mk: | operations/mediawiki-config | master | +4 -0 |
@Urbanecm, this is incorrect. Production status is required for this task to proceed, not the other way around.
@Yurik Do they want to install https://www.mediawiki.org/wiki/Extension:Maps or https://www.mediawiki.org/wiki/Extension:Kartographer ?
By reading Bojan (User:Bjankuloski06) a bureaucrat on the Macedonian Wikipedia (mk.wikipedia.org) would like to have Kartographer installed I think they want https://www.mediawiki.org/wiki/Extension:Kartographer . And it is possible to install https://www.mediawiki.org/wiki/Extension:Kartographer .
@CKoerner_WMF Could you explain it please?
@Urbanecm, I suspect its Kartographer. Maps ext might violate our privacy policy, and we have no plans to enable it on any of WMF wikis. We plan to roll out the Kartographer ext to all wikis fairly soon, once the ops finish up productionazing our backend maps cluster.
@Urbanecm, I will be happy to enable it first on the smaller wikis with the tech-savy communities so we can get better feedback. Don't worry about the patch.
The conversation about enabling this service is happening on the Macedonian Wikipedia here:
Thanks for the link. As @Yurik wrote above there is another problem which is described in T133744 and https://phabricator.wikimedia.org/T139946#2448289 . External maps violate our privacy policy and there is no plan to be deployed now. The Kartographer extension is being reviewed and after it it'll be deployed in every WMF wiki.
Removing dependency on T133744. We are ok with enabling Kartographer on smaller wikis at this point. So there isn't any technical blocker from Ops for this task.
Change 299870 had a related patch set uploaded (by Yurik):
Enable Kartographer on Meta, ca:, he: and mk:
This is a really bad idea. This task should be blocked on T138057. It was one thing to deploy this extension to WikiVoyage where it was replacing to policy-violating code and existing features - but to prematurely deploy it to Wikipedias before we have implemented features for the most basic use cases (e.g. captions and framing) it just inviting a mountain of technical debt. No doubt to work around these missing features the local wikis will create a bunch of templates, and we'll be left in the same situation where the VE map editing tool is completely unusable.
I strongly suggest reverting this ASAP.
@Esanders, I agree that maps are not finalized for the general Wikipedia deployment, but I think it would be great to work with the smaller, tech-savvy communities to get some early feedback. Otherwise we might spend tons of time perfecting it, while we miss the stuff important to the communities. And yes, frame & caption is on top of our list right now.
CC: @MaxSem, @JGirault
Adding the features to support the most basic use case is not "perfecting it". We can already get technical feedback from WikiVoyage, we aren't going to get much useful feedback from Wikipedia's because we don't support their use case, and that will soon dwindle to none as they start using templates.
Already the second comment on ca.wiki: https://ca.wikipedia.org/wiki/Tema:T878phn3qofp76bh "...perhaps we should incorporate it into a template...".
Whatever we do next you have guaranteed that someone has to spend a bunch of time writing a bot to go around fixing these uses (either removing them, or switching out the inevitable template).
We can already get technical feedback from WikiVoyage, we aren't going to get much useful feedback from Wikipedia's because we don't support their use case, and that will soon dwindle to none as they start using templates.
This is actually incorrect. We already got useful feedback that wouldn't have come from WV - maps are not working in the apps. As for the usecases, this might also be different than what we have anticipated: Community has been adding maps to the info cards, which are themselves templates based on wikidata. I understand and support the use-case of adding a map with a lot of article specific information as part of the non templated article space, but so far not many users have wanted that. Perhaps this is due to how hard it is to edit the geojson, or to store it outside of the article. And yes, we should address that somehow, but we shouldn't say "maps cannot be used from templates" because there are many cases when they might be used as part of infobox, e.g. for "show where this place is on the map". Requiring users to add it by hand to each article might be bad.
In any case, we cannot launch mapframe to all wikis just yet because there is no good static service that would produce map + per-article layers. Once that is done, we can move forward. @JGirault plans to add frame & caption fairly soon.
In fact maps won't work in any non Grade-A browser. This would make it pretty much the only piece of article content that is not shown to Grade-C browsers (which aren't served JS). If users start replacing static maps with these we will be significantly degrading the experience on a live site for users who aren't served JS.
I thought android and iphone apps can use javascript, but i could be wrong. This is actually pretty bad, because all interactive vega graphs are also broken. Created T141596. Strangely enough, it doesn't even show the static image that graphoid generates. Basically, for the maps & graphs, the backend should produce static images that are shown in the apps for now, until they can do fully interactive stuff.