Last modified: 2014-04-26 01:39:43 UTC
I go to <https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/PrivacyPolicyDiscussion_Rory1> and click: Preview all approved translations en, ar, de, es, fr, ja Where "Preview all approved translations" is a link that takes me to <https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/preview/PrivacyPolicyDiscussion_Rory1>. I don't see any banners at <https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/preview/PrivacyPolicyDiscussion_Rory1>. Perhaps I'm simply doing something wrong.
Right, sorry about that. I've disabled previews temporarily, we are implementing thus: https://mingle.corp.wikimedia.org/projects/fundraiser_2012/cards/1065 Long story short, we'll render a PNG of each banner and use that as the preview.
(In reply to comment #1) > Long story short, we'll render a PNG of each banner and use that as the > preview. Err, why? (I looked at <https://mingle.corp.wikimedia.org/projects/fundraiser_2012/cards/1065>, but couldn't figure out why anyone would voluntarily generate images of HTML/CSS/JS snippets. If there are tech requirements or background notes written out somewhere about this, feel free to link.)
cos it takes forever to render. Often the browser will just give up on much of the previews. Once they are static images, they can be cached by the client, and will pretty much load instantaneously. Unfortunately, there will be a new staleness issue. We're thinking, the edit page will have a live preview, but everywhere else you will get the screenshot. Thoughts?
(In reply to comment #3) > Unfortunately, there will be a new staleness issue. We're thinking, the edit > page will have a live preview, but everywhere else you will get the > screenshot. Another reason we got rid of the live previews was because for fundraising banners (or any autohide banner) the live preview seemed to have about a 5% chance of working -- I could not determine a reliable way to resize the portal dynamically for the banner because there is no way to determine when the browser has actually finished rendering the DOM tree. The best solution I came up with was to have the in frame JS poll for the banner size every second or so and update the containing page accordingly but that's a somewhat silly load to have if we don't need it.
(In reply to comment #3) > cos it takes forever to render. Often the browser will just give up on much > of the previews. It takes forever to render a very simple HTML banner? I don't follow. If the issue is rendering many banners, the solution is simply to not do that. I'm still pretty lost here. Are there docs explaining this idea, its rationale, and sign-offs by others who agree that this is the best solution to the problem? Rendering images seems like a really bad idea. It'll destroy almost any value in being able to preview the banner, as the user won't be able to test hover state, click-ability, cross-browser performance, etc. Plus, as you note, you'll then have stale images that will need to be updated/purged.
Please do start a discussion about this feature, it would be helpful. I don't know which venue is best, but I suspect you're the wizard at that sort of thing! The situation as I see it is, a few months ago we had previews that didn't work at all, and "dropdown" banners were escaping their boxes and fucking up all the javascript on CN admin pages. We threw some medicated rags on the problem by isolating previews using iframes, but that was totally broken in different ways than before. To address your main concern, rendering in an iframe is technically not just displaying a bit of HTML--it is a full request to a mediawiki page, which takes a long-ass time and a lot of client processing power. Once you get a few of these on one page (especially bad in the "add banner" pagers), your browser melts down. Using images solves all of these problems, it lets us do the rendering in a controlled fashion, with error checking (for example, "is height == 0px?"). It loads extremely quickly under any client. If you want to actually test banner clicky stuff, none of the preview implementations have ever been appropriate. There are deviations from production conditions which make your tests worthless. Instead, you should "preview on-wiki", the only preview feature I personally find useful. All the other crap is just window dressing, which gives admins a rough guide to which of the million poorly named campaigns contains a particular banner. Thank you for lighting the kindling beneath us, though, just be aware that any further improvements to the preview situation are probably gonna take months. I really think we've exhausted the obvious strategies here. Come up with something creative! If you can find a "very simple HTML" solution somehow, I'd be willing to do the coding.
I remember the feature fondly, and look forward to having it back. In the meantime though, without questioning the prioritization of the fix, could the "Preview all approved translations" link be made less misleading for the time being? For example, we could remove the link and change the text to "Preview approved translations", but link each language code in the comma-separated list below (en, de, fr, ...) to the corresponding translated banner preview.
