Retina, localized about screen screenshots

[nacin]

We need HiDPI screenshots on the About screen for 3.5. In the process, we should serve *all* screenshots from wordpress.org and keep them out of the download package. Additionally, we should allow for these screenshots to be localized by localization teams.

We should implement a WP.org endpoint to serve screenshots from s.wordpress.org. Either we hit an API endpoint and get back a list of URLs, or just hit an endpoint directly from an img src, always serving 2x images.

[Otto42]

List of current images in the download (from wp-admin/images/screenshots):

captions-1.png
captions-2.png
flex-header-1.png
flex-header-2.png
flex-header-3.png
flex-header-media-library.png
theme-customizer.png
twitter-embed-1.png
twitter-embed-2.png

Two options:

1. Make an API endpoint (api/core/screenshots or api/core/about) to serve up array of screenshot URLs based on passed along localization params. API data could be maintained easily by simply having a static set of file listings on the API server, or have it dynamically built. Either works fine.
2. Use rewriting to serve them statically based on filename (hit to wp.org/images/captions-1.png or wp.org/images/es-ES/captions-1.png, rewrites go to s.wp for the serving of the files) and so on. Rewrite rules would have to be maintained.

Method 1 is more flexible but requires an extra API request to get the URLs. But it means we can build in backward compatibility easily by versioning the API request.

Method 2 is faster and lower on resources, but requires maintenance of the rewrite rules (something that is currently inaccessible to me), and harder to maintain over time. Versioning would need to be in the URL as well, fallback to non-supported localizations, etc.

I'm leaning toward method 1. Objections?

[azaozz]

Option 3: include only 2x images in WP. This screen is visited very rarely, using larger images won't make significant difference on network traffic and would remove any need for WP.org APIs or maintenance.

[Otto42]

Option 3 doesn't account for localization, and it doesn't help to reduce the size of the overall WordPress download.

[azaozz]

Right, but is the simplest (no maintenance or API needed). That's how it works at the moment too which has the advantage of working on local networks (no Internet) too.

If we are going to load images from WP.org, why not load all of the html / the whole screen? Or update wordpress.org/about (or make wordpress.org/about/WordPress) and include that?

[nacin]

Unless we are really worried about backward compatibility (and, looking at the public_html on wp.org, we keep *everything*), I would do method 2, and would be happy to help.

Two options for implementing method 2:

1. ​http://wordpress.org/images/core-screenshots/3.4/es_ES/some-image.png, and serve it. If es_ES doesn't exist, look one level up and serve 3.4/some-image.png (which would be the English ones).

2. ​http://wordpress.org/images/core-screenshots.png?version=3.4&locale=es_ES, and 302 to the proper image.

I feel like rather hit WP.org for four or five screenshots individually, directly from an <img> tag, than with a PHP-side API request. It might just be easier to do an API request (especially since we can then provide s.wordpress.org links).

[nacin]

The four screenshots for 3.5 are HiDPI by simply serving 2x versions and shrinking them. It adds a bit of space to the download package but I don't think we should be super concerned about that. I think we should leave this to 3.6, and simply bundle it into the same HTTP request as credits.php.

If a specific locale wants to re-do a screenshot in their own language, they can (since we do not have core language packs at this time) just include the file into dist/wp-admin/images/screenshots and we'd include it in their zip. That seems sufficient for now (and was what they've been doing).

So, closing.