openzim
White-on-white text for geo markers on Wikivoyage
Working from the Arusha article on Wikivoyage. Rendering tested via Kiwix-JS chrome extension or Kiwix-server.
The same entry on Wikivoyage (2024-08) shows that text is missing where the maps templates are.
The same thing on Wikivoyage (2024-06) works fine.
Since the templates don't seem to have changed between June and August I suspect that the problem lies with this parsoid-related announcement that showed up on the page
Same in 2024-10, see https://library.kiwix.org/viewer#wikivoyage_en_all_maxi_2024-10/A/Arusha . The same issue shows in Kiwix JS Browser Extension in the latest ZIM (in ServiceWorker mode), but not in the Wikivoyage by Kiwix desktop app nor the PWA. I suspect it's to do with the transformation of listings to transform the geo: link and add the World icon. The PWA does its own transform here to use map pins rather than a world icon (the code goes back to the days of the Windows Mobile app, which plugged these links into the WM10 offline maps app that also exists in Windows 10/11), but it explains why these show correctly in the PWA and packaged app, but not in Kiwix Serve or the Browser Extension (which doesn't do any specific transform of its own).
The CSS directive which causes the issue is following one:
span.org {
color:#fff !important
}
This class comes from https://meta.wikimedia.org/api/rest_v1/data/css/mobile/pcs
This CSS module comes from https://en.wikivoyage.org/api/rest_v1/page/mobile-html-offline-resources/Test (additional CSS for Wikimedia mobile)
To me it looks like this is an abusive directive of the mobile pcs CSS which has been added for something else but conflicts on Wikivoyage.
@kelson42 should we open a Phabricator ticket? How to ensure it is assigned to proper team which will be able to help us on this.
I confirm that issue is only present with WikimediaMobile API, WikiDesktop API is exempt from this bug
@kelson42 should we open a Phabricator ticket? How to ensure it is assigned to proper team which will be able to help us on this.
AFAIK, PCS is for the old Parsoid mobile-section. Either we abusively get it for a backend which does not need it... or there is a bug upstream. I can hardly assess this fully so far.
So, to be clear, we need to check first if mwOffliner is incorrectly getting old PCS stylesheets from meta.wikimedia.org/api/rest_v1/... whereas it should be getting different CSS from en.wikivoyage.org/api/rest_v1/ or elsewhere?
I don't think PCS stylesheets are unneeded. When I remove PCS stylesheets from https://en.wikivoyage.org/api/rest_v1/page/mobile-html-offline-resources/Test then the content misses quite a significant share of styles. Maybe the name is just "abused" (like they never changed the name of the file when changing Parsoid).
https://en.wikivoyage.org/api/rest_v1/data/css/mobile/pcs is strictly identical to https://meta.wikimedia.org/api/rest_v1/data/css/mobile/pcs
OK, thanks for the clarification. I'd say that tips the balance towards it being an upstream issue, then.
However, rather than working extensively on this broken API, might I tentatively suggest, that your having discovered that using the the desktop-html API solves a bunch of issues while still producing responsive, mobile-ready HTML might be quite fortuitous, and that we should at least experiment (in another issue/PR) with seeing what kind of article format we would get from doing the same with, say, a Climate Change or other small sample Wikipedia ZIM?
One thing that's likely to result from that is the old, extremely irritating issue of misplaced hatnotes for most Wikipedia articles (https://github.com/openzim/mwoffliner/issues/182) may at last be fixed , since the desktop-html API doesn't move these elements around.
I realize this is a different (albeit tangentially related) issue.
This is indeed off-topic and FYI, this already happening, we already confirmed on a small selection that everything looks acceptable (besides unrelated bugs), and are currently trying to process a full project.