romaine.wiki wrote:

I seem to have this problem myself as well. In my preferences the setting is on 220px while the images which heights are longer than the width are shown in a smaller size than the default 220px.

Both images here had in the past the same width and now in my screen the top one is shown much smaller than the bottom one: https://nl.wikipedia.org/w/index.php?title=Help:Helpdesk&oldid=41395234#Foto.27s_veel_te_smal_weergegeven

Is this still an issue after purging the browser cache as described in https://en.wikipedia.org/wiki/Wikipedia:BYPASS , and after attaching

?action=purge

to the URL?
I'm pretty sure this should fix it and that this happened due to http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076736.html

paulb.wiki.bugzilla wrote:

(In reply to Andre Klapper from comment #2)

Is this still an issue after purging the browser cache as described in
https://en.wikipedia.org/wiki/Wikipedia:BYPASS , and after attaching

?action=purge

to the URL?
I'm pretty sure this should fix it and that this happened due to
http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076736.html

This also happens on newly created pages (as far as I can see) so a browser cache issue as suggested seems very unlikely (and purging the browser and server cache does not help). In particular, I just created a small test page which for me shows problems on both FF and Chrome, regardless of whether I'm logged in or not:

https://nl.wikipedia.org/wiki/Gebruiker:Paul_B/Kladblok/test

These images should both show up at the same size (a width of 220px, if the user did not change their thumbnail settings) but they don't. The top picture shows up at a *height* of 220px (so a smaller width).

This is also clear from the HTML that I receive from the server, even when I do a 'wget' from a Linux command line on a machine that I never use to browse the web (remote access only).

This appears to be an intentional change; see:
https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf6#Core_changes
bug 63903.

With kind regards Mar(c)

Yes, this is intentional. See discussion in https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes and the linked RFC review meeting.

Workaround is to use an explicit size specification, if that is what you want.

Closing the bug for now, but please continue to amend the bug and/or reopen if this change does cause problems (other than just being unexpected).

romaine.wiki wrote:

(In reply to C. Scott Ananian from comment #5)

Yes, this is intentional.

Then we would like to restore this back to what it was before.

The thumb was always set in such way that all the images with thumb have the same width. This concerns thousands of images and we would like to keep them having the same image width.

Workaround is to use an explicit size specification, if that is what you
want.

We do not want to use an explicit size specification because we want our readers with an account to determine themselves in their preferences how large/small they want to see the images. (That is how thumb original was designed to!) In this way users with small screens can set them smaller, users with a very wide screen can set them larger, and especially users with worse sight can set them larger.

Reopened again. This is a very disturbing change.

romaine.wiki wrote:

https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
To summarize: the current solution is worse than the original problem!

romaine.wiki wrote:

And the result: thousands of pages look worse because of this (a problem!). While the original "problem" isn't seen as a problem at all.

There is some discussion on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Infobox_Image -- several infobox templates have already been fixed.

The issue seems to be primarily with infoboxes, which actually assume the default thumbnail width. These infoboxes probably looked wrong for users with non-default thumbnail sizes all along.

tsui wrote:

The isssue is with all images in every single Wikipedia article, not just with info boxes. Fixed widths have been abandoned years ago to give users the ability to set the default width of "thumb" to their prefered size. Noone wants to use widths set in pixel again. Now, with this change, the images on many many pages have an endless variety of widths - which is the opposite of a good layout. "thumb" should be resulting in one! default width.

Tsui: bug 35756 might be a better solution, if what you want are consistently-sized images.

tsui wrote:

C. Scott Ananian: I am not talking about square images. I mean one default width for all images (which was set with "thumb" until now). The problem is the unpredictable and always different width of all images that are higher than they are wide. There should be one(!) default width, maybe another one(!) for portraits and the option for other sizes (panoramas ...) - just as it was until now. With the change there is an endless variety of widths now, which contradicts anything I ever learned about layouting and screendesign.

(In reply to C. Scott Ananian from comment #5)

Workaround is to use an explicit size specification, if that is what you
want.

(In reply to C. Scott Ananian from comment #11)

Tsui: bug 35756 might be a better solution, if what you want are
consistently-sized images.

Some of my considerations:

• Generally, the user's "Thumbnail size" preference is intended to be respected.
• The behaviour of the "Thumbnail size" preference used to be defined as the preferred maximum width (in 1.24wmf5 and earlier versions), editors of WP expected that behaviour for years, when designing the pages.
• The image option "upright=1" currently fixes the changed default behaviour back to how it used to be.
• The configuration setting $wgThumbUpright defines the default scaling factor for images that use |upright without "=[scaling factor]".
• There isn't any configuration setting that defines the default scaling factor for images that don't have |upright specified.

My conclusion is that the only "workaround" for now, to return to how images were displayed before, is to use |upright=1 for each portrait orientated (thumb) image that is not explicitly sized. That would mean a lot of (bot) work, and symptom treatment.

A solution would be a configuration setting that defines the default scaling factor for images that don't have |upright specified. But also that would be symptom treatment.

Considering there is a new image option "square", which looks like to be intended to have the exact effect of the changed default behaviour of thumb, I don't really get why the default behaviour was changed in the first place. And to be honest, reading RFC meeting 2014-04-02 https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02 , part of the participants didn't really understand the issue, another part did understand and also knew it would break a lot of pages, and you preferred proposal #2 (the new image option "square") but unfortunately wasn't heard.

The best solution imo would be reverting the default behaviour, and those who want the square bounding box use "square".

With kind regards, Mar(c).

[Resetting previous Priority and Severity values, see www.mediawiki.org/wiki/Bugzilla/Fields for their meanings.]

This change is highly disruptive for en.Wikiquote, where defaults have been used to achieve consistent widths.
See discussion at https://en.wikiquote.org/wiki/Wikiquote:Village_pump_archive_42#Good_and_bad_alterations_in_the_new_software
I request that it be rolled back as soon a possible, pending development of a less disruptive solution to the perceived problems with having a fixed default width.

Ningauble: I've followed up on the wikiquote village pump with some more questions about wikiquote's use cases.

Mar(c): Fixing 'upright' is the second part of this same RfC, so I don't recomment using 'upright=1' as a workaround. It's just pushing the problem down the road. The preferred workaround is to specify an explicit width if your page layout expects a constant width. (As you note, the 'square' image option proposed in the RfC was voted down in favor of making the "no explicit size" and "upright" options use a square bounding box. You are encouraged to read the transcript of the RfC discussions for more context.)

Personally, the better long-term solution is providing better semantic markup for desired image size/layout, since the existing assumptions that images are a certain size/fixed width/etc are rather hostile to mobile and PDF/print rendering.

I appreciate the constructive suggestions. The existing image option mechanism is baroque and confusing. I've fixed a number of bugs and corner cases already; I'm sorry that this one is causing more pain that previous ones. But hopefully we can find some solid ways to continue to improve and simplify image options.

[FWIW, from my work on the LaTeX PDF backends (which render pages in double-column layouts), the most useful two semantic classes would be "single column image" (and image intended to fit in a single column, with height bounded to, say, 1/3 the page height and width bounded by the column width), and "full width image" (used for timelines, panoramic images, and certain diagrams) which are intended to span the full page. Using only these two semantic classes leads to pages which look consistent.]

tsui wrote:

@C. Scott Ananian: "since the existing assumptions that images are a certain size/fixed width/etc are rather hostile to mobile and PDF/print rendering"

This is exactly what your change will result in.
Authors from many different Wikimedia projects resp. Wikipedia language versions have relied on *one* standard width for images set with the parameter "thumb" until now. Now you have destroyed the layout of millions of articles because there is no more security how images are displayed. So people will start to use fixed widths set in pixel again (which we abandoned many years ago).

If you want to develop a semantic markup for the future that's fine. But right now this change of the display of images is a desaster - and it is unwanted by *any* user (=wikipedia author) who commented on it in the past days. I could not find a single user/author who welcomes it.

(In reply to Andre Klapper from comment #14)

[Resetting previous Priority and Severity values, see
www.mediawiki.org/wiki/Bugzilla/Fields for their meanings.]

Reading this page, and the comments here, I really think this qualifies as major, and priority should at least be high, given the perceived impact.

According to https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=611507317#Infobox_Image and https://bugzilla.wikimedia.org/show_bug.cgi?id=63903#c13 this has been reverted, hence this ticket could be closed and discussion could move to bug 63903?

This patch was reverted three days ago (on June 1). Are people still having problems with thumb? Please note that rendered pages are cached, so you may have to purge the cache and/or do an edit to see the effect of the revert.

Any continued issues with thumbs should continue to be discussed here.