Last modified: 2013-03-29 08:49:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36443, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34443 - In review mode, translation editor CSS causes page to flicker
In review mode, translation editor CSS causes page to flicker
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
Translate (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
https://commons.wikimedia.org/wiki/Fi...
tux-fixed
: design
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-16 12:46 UTC by Nemo
Modified: 2013-03-29 08:49 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nemo 2012-02-16 12:46:20 UTC
Hard to describe, but because of how the content is arranged, on Firefox when you press the "accept" button, at least in Italian, is becomes much bigger ("Accetta" -> "In accettazione") and moves all the elements around, especially if the message id is long and takes all the space, to the point that sometimes your eyes cross and the cursor, which you already put where the next "accept" button used to be, needs to be moved again. On Chromium it's ok.

The video will perhaps show it better (here I manage to point the next button correctly, mostly)?
Comment 1 Siebrand Mazeland 2012-02-16 12:52:47 UTC
I know what you mean. It's something we know that needs to be addressed. It's a visual distraction, I agree. I've suggested that the button text would be allowed to go over the key name. If you have a CSS patch or something, please provide it. Otherwise it may take a while for this to get resolved.
Comment 2 Nemo 2012-02-16 12:57:23 UTC
Ok, thank you. Glad to hear it's not only my problem but I agree it's very minor. 
Should perhaps the translations of "Accepting" be made shorter in meanwhile to reduce it?

(I had to put the video on Commons.)
Comment 3 Siebrand Mazeland 2012-02-16 13:00:14 UTC
If one knows how to do it, it's probably very easy to fix... I wouldn't mess with translation lengths for this -- that shouldn't be needed. Exactly why I accept this as an issue (moved from enhancement to normal bug).
Comment 4 Nemo 2012-12-06 20:45:56 UTC
(In reply to comment #3)
> If one knows how to do it, it's probably very easy to fix...

Krinkle, Anomie, does either of you have suggestions? It's been almost a year now, and reviewing translations in Firefox really ruins my nerves with this bug.
Comment 5 Krinkle 2012-12-06 22:40:23 UTC
From seeing the video it looks like an obvious result of the current layout. I don't see how a browser doesn't cause it to flicker. It is supposed to reflow and flow back again. If it doesn't happen in Chrome that would actually be a bug.

The only solution I see is to redesign that page to not be so closely nested. That would improve UX.
Comment 6 Nemo 2012-12-06 23:10:14 UTC
(In reply to comment #5)
> From seeing the video it looks like an obvious result of the current layout.
> I
> don't see how a browser doesn't cause it to flicker. It is supposed to reflow
> and flow back again. If it doesn't happen in Chrome that would actually be a
> bug.

What happens in Chromium is that it flows, but doesn't flow back when some space is freed up.

> The only solution I see is to redesign that page to not be so closely nested.
> That would improve UX.

That's in the works too, although this specific use case is not precisely scheduled; but I hoped for a quick smart fix for the current situation.
Comment 7 Brad Jorsch 2012-12-07 14:36:36 UTC
A few possible fixes:
* Make the button fixed-width, which depending on the width might leave a large mostly-empty button and/or chop off some of the texts.
* Position the button on its own line, so it can change size without making anything else reflow. Unless it changing size makes the column resize anyway, because it doesn't look like that has a fixed width either.
* Redesign the page in some other manner.
Comment 8 Santhosh Thottingal 2013-03-29 08:49:26 UTC
Obsolete because of the interface rewrite.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links