A unit test was broken by an underlying content change that switched Wikvoyage to use the page indicators. The functionality of the API was thus broken and coordinates are no longer surfaced by the API.
I skipped it for now so it's not blocking other work. We should fix or remove the test. (Why are we testing against Wikivoyage? [edit: because we are Wikimedia not Wikipedia and our APIs should be useful... and this bug will hit Wikipedia in the future if we are not careful?])
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Source coordinates from GeoData | mediawiki/services/mobileapps | master | +61 -43 |
There was a specific patch to make this work for Wikivoyage, too. See T145003: Service should surface coordinates in Wikivoyage.
We currently incorrectly assume that coordinates are always in the HTML e.g. inside span#coordinates .geo
This is not the case for all wikis and the mobileapps API is very Wikipedia centric in that regard so we should test on more wikis.
Really we should be using Wikidata or the GeoData api for this information.
If the test is failing we should investigate why rather than disabling as that means coordinates are no longer being surfaced there...
Change 368520 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/services/mobileapps@master] Fix broken tests (do not skip)
"Paris" wikivoyage test is broken because....
https://en.wikivoyage.org/w/index.php?title=Template:Geo&diff=prev&oldid=3097457
converted the non-standard #geoCoord id into an indicator.
It looks like Parsoid render this as the following:
<span typeof="mw:Extension/indicator mw:Transclusion" about="#mwt151" data-mw="{"parts":[{"template":{"target":{"wt":"geo","href":"./Template:Geo"},"params":{"1":{"wt":"48.856"},"2":{"wt":"2.351"}},"i":0}}]}" id="mwBQc">
</span>Thus it makes it impossible to pull out the coordinates.
Indicators are slowly being adopted by all our projects.... so this will bite us in other places too.
As far as I'm aware the MobileView API doesn't make the coordinates prop accessible, but to be future proof we should rely on this:
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=coordinates&titles=Paris
Maybe MobileFrontend should be updated to surface that or MCS should stop using the Mobileview Api...?
Comparing
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=pageprops%7Ccoordinates&titles=Paris
with
https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=coordinates%7Cpageimages%7Crevisions%7Cpageprops%7Cpageterms&titles=Paris&formatversion=2&ppprop=wikibase_item%7Cdisambiguation%7Cwikibase_description%7Cwbptterms%7Cprotection&wbptterms=description
there isn't really a strong reason to use the mobile view api and we should aim to disentangle the mobileview api from it. MCS should not need to depend on MobileFrontend.
It's a bunch of work, but it looks like the main problems are going to be:
In the short term we could add an additional API request for coordinates.
Change 368954 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/services/mobileapps@master] Source coordinates from GeoData
Change 368954 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Source coordinates from GeoData
Mentioned in SAL (#wikimedia-operations) [2017-08-15T17:55:00Z] <bsitzmann@tin> Started deploy [mobileapps/deploy@34a1304]: Update mobileapps to 33b80dd (T172829 T152441 T172021 T103362)
Mentioned in SAL (#wikimedia-releng) [2017-08-15T17:57:51Z] <bearND> Update mobileapps to 33b80dd (T172829 T152441 T172021 T103362)
Mentioned in SAL (#wikimedia-operations) [2017-08-15T17:59:00Z] <bsitzmann@tin> Finished deploy [mobileapps/deploy@34a1304]: Update mobileapps to 33b80dd (T172829 T152441 T172021 T103362) (duration: 04m 00s)