Page MenuHomePhabricator

In review mode, translation editor CSS causes page to flicker
Closed, DeclinedPublic

Description

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)?


Version: unspecified
Severity: normal
Whiteboard: tux-fixed
URL: https://commons.wikimedia.org/wiki/File:TranslateAccept.ogv

Details

Reference
bz34443

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:17 AM
bzimport set Reference to bz34443.
bzimport added a subscriber: Unknown Object (MLST).

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.

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.)

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).

(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.

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.

(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.

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.

Obsolete because of the interface rewrite.