Right-align all translation count columns in Project Overview
ClosedPublic

Authored by huftis on May 24 2018, 5:48 PM.

Details

Summary

Before this patch, all columns in the Project Overview tab
were left-aligned. The patch changes the alignment for the
four translation count columns (‘Total’, ‘Translated’, ‘Not ready’
and ‘Untranslated’) to right alignment.

The effect is that the counts are easier to compare across files,
since the unit, ‘tens’, ‘hundreds’ etc. parts of the numbers are
now aligned.

BUG: 394512
FIXED-IN: 18.04.2

Test Plan
  1. Open a localisation project
  2. Observe that four translation count columns (‘Total’, ‘Translated’, ‘Not ready’ and ‘Untranslated’) are now right-aligned, while they used to be left-aligned.
  3. Observe that no other columns change alignment.

Diff Detail

Repository
R456 Lokalize
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
huftis requested review of this revision.May 24 2018, 5:48 PM
huftis created this revision.

Screenshot of the UI before the patch:

Screenshot of the UI after the patch:

Column data itself looks much improved!

However, this makes the headers themselves inconsistently aligned, which will lead to bug reports of another sort (see for example https://bugs.kde.org/show_bug.cgi?id=394467). Perhaps we should also center-align all the header titles, as with the fix for that bug?

Column data itself looks much improved!

However, this makes the headers themselves inconsistently aligned, which will lead to bug reports of another sort (see for example https://bugs.kde.org/show_bug.cgi?id=394467). Perhaps we should also center-align all the header titles, as with the fix for that bug?

No. Headers should always use the same alignment as the data. That’s the recommendation for table design in general (see, e.g. Stephen Few’s book ‘Show Me the Numbers: Designing Tables and Graphs to Enlighten’ (Second Edition), or this presentation https://www.darkhorseanalytics.com/blog/clear-off-the-table).

The bug report you refer to (filed by me, BTW), was about *inconsistent* alignment, i.e. where the alignment for the headers and the data were different, e.g. the headers were left aligned while the data was right-aligned, making the header appear very far away from the data if the column is made wide. With this patch, they’re all consistent, i.e. all left-aligned (for text columns) or right-aligned (for numeric columns).

Oh haha! Sounds like you're the alignment expert. UI looks good to me.

aacid added a comment.May 24 2018, 8:04 PM

Looks good to me, if you want to make sure header and data alignment is the same maybe you can find a way to only have one switch instead of two (i.e. make data call headerData or viceversa or make them both call a new function) that way we enforce they're the same.

huftis updated this revision to Diff 34967.May 27 2018, 12:37 PM

I’ve used @aacid’s suggestion, and now ProjectModel::data() calls ProjectModel::headerData(), to ensure that the column alignment is consistent between column headers and column data.

aacid accepted this revision.May 27 2018, 3:36 PM
This revision is now accepted and ready to land.May 27 2018, 3:36 PM
This revision was automatically updated to reflect the committed changes.

Sorry for reaching late.
This is a nice imporovment, it just needs one bit to work with RTL layouts as well :)
Right now, and before this patch, it's being displayed correctly (aligned to right).

From http://doc.qt.io/qt-5/qt.html#AlignmentFlag-enum:

If the widget's layout direction is Qt::RightToLeft (instead of Qt::LeftToRight, the default), Qt::AlignLeft refers to the right edge and Qt::AlignRight to the left edge. This is normally the desired behavior. If you want Qt::AlignLeft to always mean "left" and Qt::AlignRight to always mean "right", combine the flag with Qt::AlignAbsolute.

So we need to combine Qt::AlignRight with Qt::AlignAbsolute.
I didn't check Lokalize with this patch, but I supposed that numbers in RTL layout will be aligned to left now.

Thank you! :)

huftis added a comment.EditedMay 29 2018, 7:17 PM

Sorry for reaching late.
This is a nice imporovment, it just needs one bit to work with RTL layouts as well :)
Right now, and before this patch, it's being displayed correctly (aligned to right).

Hm, I’m trying to test this, but I’m not sure how I can get a RTL layout. If I run

LC_ALL=ar_en.UTF-8 lokalize

I get some Arabic-looking digits in the four translation count columns, but they are left-aligned (before the patch). But they should be right-aligned?

Hm, I’m trying to test this, but I’m not sure how I can get a RTL layout. If I run

LC_ALL=ar_en.UTF-8 lokalize

I get some Arabic-looking digits in the four translation count columns, but they are left-aligned (before the patch). But they should be right-aligned?

I'm not entirely sure how this works for English base system.
Normally you would do lokalize --reverse and check the RTL layout. This should keep everything in English but simulate a RTL language being used.

I get some Arabic-looking digits in the four translation count columns, but they are left-aligned (before the patch). But they should be right-aligned?

I'm not entirely sure how this works for English base system.
Normally you would do lokalize --reverse and check the RTL layout. This should keep everything in English but simulate a RTL language being used.

Thank you. lokalize --reverse works for me. I’ve now modified the behaviour so that the numeric columns are right-aligned for *both* RTL and LTR languages: https://cgit.kde.org/lokalize.git/commit/?id=83590be3996e2c2013f69ce8a850f508c4db9d53

Thank you. lokalize --reverse works for me. I’ve now modified the behaviour so that the numeric columns are right-aligned for *both* RTL and LTR languages: https://cgit.kde.org/lokalize.git/commit/?id=83590be3996e2c2013f69ce8a850f508c4db9d53

Thank you very much!
Since you played a bit with Lokalize, there is one small bit that stops me (and maybe others) from using it on Windows, that is that the font size of the source and target edit boxes is too small.
Would you please check if it can be fixed easily? I tried to make it a configurable value (like on Linux) but it's a bit more complicated for me :)

I don't know why everything seems small in the Windows version. Menu text is the smallest readable size. The translation units list is small, the edit boxes are small, the unit metadata is small, even the "options" button is small.

Thank you and sorry for mixing things in this patch.