Once Kartographer is stable in the labs, deploy it to production for Wikivoyage
|Resolved||MaxSem||T127136 Deploy Kartographer extension to Wikivoyage|
|Resolved||Yurik||T125686 RFC: Decide the interface of the <mapframe>, <maplink>, and <mapdata> tags|
|Resolved||MaxSem||T125301 <mapframe> should be shown left/right/center aligned frame|
I would -2 this based on the fact we still have <mapdata>. Once that feature has been deployed it will be nearly impossible for us to remove it from the extension and it is a bad architectural direction.
An email to ops@ talked about also deploying to mw.org but I can't find any Phabricator task mentioning that?
(In general, I appreciate transparency of plans by updating related venues.)
Update (Copying from T125686)
@Esanders and I spoke today about the potential way forward. Our tentative agreement (Ed please correct) is that if we address these issues, the deployment may proceed as planned.
- (done) Kartographer will remove the <mapdata>, as it implies there is a page-level data scope vs tag-level. If needed, the same functionality can be achieved with the hidden <maplink> tag.
- For T125301, Kartographer will for now implement the <mapframe> as right-aligned (left-aligned on RTL) by default. @Esanders will suggest the best way to specify alignment with the <mapframe ...> attributes for the future version.
- Kartographer on Wikivoyage will run under a scary™ flag, e.g. $wgKartographerWikivoyageMode = true;
- For non-Wikivoyage, we should have an additional, wider discussion. For now, non-Wikivoyage mode will not support cross-tag data sharing, so any data defined inside one mapframe or maplink will have no affect on any other map tags.
For the very first version, we will only support right alignment and only wikivoyage, thus won't be a blocker.
@Esanders, I plan to deploy it to just one small wiki (Ru Wikivoyage) so that community can experiment with it and give us feedback. I prefer to release early and release often -- I'm sure there will be plenty of changes regardless of how "polished" we make it. It will be a while until any significant amount of content will be using it, so any changes will be OK at first.
There are breaking changes we have lined up compared to the current state (e.g. captions). Enabling on a production wiki, however small, is a big step because we immediately start accruing content we need to support, so it won't hurt to not rush it.
@greg, @Esanders, this is NOT a blocker. Neither @MaxSem nor I see an immediate need for the caption - maps are different from images. Map is a map, especially for wikivoyage. This feature could be added, and it might be "nice to have", but it bears nearly not the same weight as a caption for an image.
@greg, b/c = backwards compatible. Severity is minimal simply because we don't know if/how we want it done. Its absolutelly not critical (or might not even be needed) for wikivoyage. I think we will still add it because in Wikipedia it would be good to mark things like "the map of the oil spill" in the article about the disaster. Still contemplating it to provide the MVP so that we won't have to remove the features later.
It is if we get rid of the inline mode, or change whether inline/captioned in the default mode that is a breaking change. Let's just give ourselves the time to work it out properly, instead of creating an arbitrarily tight deadline.
@Esanders, we do NOT have the inline mode. As we discussed yesterday, we will only provide right align frame by default (left for RTL), and we will provide a way to specify left/center/right alignment for that frame. Since we won't have captioning from the beginning, it won't be a breaking change to add it later if we choose to do so.
The deadline is not tight, but I will be going on vacation soon. So the earlier we release it, the more time we will have to address community-raised issues, which I suspect will be much more severe than the lack of caption. And again, this is being deployed for a very small community at first, so not an issue regardless.
My apologies, I realized the reason for the confusion - we still had the "inline" mode as a blocking task, even though we already decided not to do inline for the MVP. The issue has been updated and resolved.
@Esanders of course we will need to speak with the community about the visual aspects of the map's frame, and for that the community needs to experiment with it, decide how it should look, and tell us what they think. Once decided, we can easily add some gray frame around the map, or however it is needed. But this won't happen until the community plays with it first. This won't be a big deal - the map will simply change from no-frame to a small frame, just a minor visual adjustment.
As for wrapping in a template - wikivoyage already wraps all their maps in templates, and we will try to provide enough functionality for this not to happen with the new tags. VE geojson editor should be a good-enough incentive for that. But initial migration will use a template regardless, simply because it is easier to modify one template than to update every page on the wiki.
@Johan, from IRC today:
19:36:36 <yurik> edsanders, i still don't know if we should have captions for WV or not, and it is a minor issue that can be added later, right? So are we on the same page? Or is there a blocker? 19:39:07 <edsanders> we should base that decision on WP, not WV, but yes - I am OK with you proceeding
@Esanders please confirm.
<yurik> edsanders, sure, i can rename it, but i'm not sure how to make tests with non-default config <yurik> it will be set to false in commonsettings <edsanders> I think we do it in VE <edsanders> I'll have a look ... <yurik> edsanders, its in both php and parsertests <edsanders> ok - if you can't work it out, mark it with a TODO and create a bug <yurik> ok