Most clients get thumbnail URLs via the API (e.g. the imageinfo module) and thus would be unaffected by URL format changes. This task tries to collect which clients use thumb URLs directly as a de facto API instead, and what assumptions those clients have about the URL.
- MediaViewer: reads an existing image URL from the page, plus the original size encoded as data attributes, and resizes it (logic). Can do thumb->original conversion.
- mobile media viewer:
- Mobile Content Service (JavaScript): requests the largest thumbnail it needs then creates a few variations with smaller widths using regex [[ https://phabricator.wikimedia.org/diffusion/GMOA/browse/master/lib/mwapi.js;26578326e317f77e41099029562c917d0b330ef3$24 | /(\d+)px- ]].
- Android app (Java): changes existing thumbnail URLs to smaller widths using regex /(\\d+)px- sometimes.
- iOS app: Adjusts thumbnail width by looking for px-. Uses data-file-width and data-file-height to ensure the app doesn't request larger than the original. source 1 and source 2
- DBpedia: Uses /Special:FilePath/ URLs to access 300-pixel wide images (source code)
- Navigation popups gadget: seems to use imageinfo api
- Commons Gallery: image info
- Weekipedia uses a title to construct a thumbnail URL using md5 as thumbnail not present in API request for images. A similar method was previously used in MobileFrontend on queries that returned Wikidata image fields.
- ...