| Shirayuki | |
| Jul 23 2022, 11:10 PM |
| F35349765: image.png | |
| Jul 28 2022, 4:01 AM |
Steps to replicate the issue (include links if applicable):
What happens?:
TUX extends beyond the screen width.
What should have happened instead?:
All content should fit within the screen width.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| MessageTable: Prevent overflow with Vector 2022 CSS grid layout | mediawiki/extensions/Translate | master | +10 -0 |
I am able to reproduce this locally with the following configuration set:
$wgVectorGrid = true;
I looked at an easy way to fix this, but am not able to find any. It could very well be due to my lack of familiarity with the CSS grid system.
The easiest fix that I can see is to update the following configuration parameter:
$wgVectorMaxWidthOptions['exclude']['querystring']['action'] = '(history|edit|translate|page|proofread)';
This fixes the overflow problem but wastes horizontal screen real estate by limiting the content to take up a maximum of 60em or 960px on my 1920*1080 screen.
Change 816750 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):
[mediawiki/extensions/Translate@master] MessageTable: Prevent overflow in CSS grid layout
Change 816750 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] MessageTable: Prevent overflow with Vector 2022 CSS grid layout
778c46d is hopefully good as a workaround, but I consider this a bug in Vector that should be fixed in Vector. It breaks not only Translate, but also on wide templates, long edit summaries without spaces, and generally wherever there’s a wide thing on a non-width-limited page. I don’t want to see workarounds and/or broken layout everywhere, it should be fixed at one place: where it got broken.
It breaks not only Translate, but also on wide templates, long edit summaries without spaces, and generally wherever there’s a wide thing on a non-width-limited pag
This is tracked in T113101
We've added a fix for this, and the page now renders fine. The underlying issue is tracked in a separate task.
No, it isn’t. T113101 is about images only, probably even only thumbnail ones (although that’s not clear from the description), and proposes resizing them. {{Wide image}} is technically a thumbnail, but should not be resized (it’s intentionally wider than the viewport, and has a scrollbar to compensate for this when the image is wider than the content area), while resizing the edit summary is definitely out of question (in this example, the font size would need to be ~1.85px on my screen, which is a gray line, not a readable text).