I would feel more safe if you initialized m_cursorSelectionStart and m_cursorSelectionEnd to 0 in the constructor

I'll push this next week if there is no additional comments

I'll push this next week if there is no additional comments

In D14219#297396, @sdepiets wrote:

In D14219#297294, @aacid wrote:

Should the state of the action be remembered between runs?

I didn't plan that, the quick search project field isn't saved between runs.
Performance wise it would not change anything to launch the program with the filter on.

In D14321#297359, @sdepiets wrote:

Yes I'm working on having the craft blueprint integrated. https://phabricator.kde.org/D14322
Once it's done I'll get in touch with the binary team to have it in the CI tools.

In D14219#297294, @aacid wrote:

Should the state of the action be remembered between runs?

Yes I'm working on having the craft blueprint integrated. https://phabricator.kde.org/D14322
Once it's done I'll get in touch with the binary team to have it in the CI tools.

Should the state of the action be remembered between runs?

If it works, sure let's go for it.

Change of tooltip/menuitem text

Add tooltip and move menu item to settings

Thanks indeed. Very useful! :)

I have done some testing, and the patch seems to work fine. Thanks for adding this very useful feature!

Add an icon for the menu entry

Also make sure to mention bug #224179 in the revision summary, so that it will automatically be closed when you commit the revision. See https://community.kde.org/Infrastructure/Phabricator#Add_special_keywords for instructions.

The patch adds a toolbar item, but it’s missing an icon. Could you add one? I think the one named hide_table_row will work well.

Style and invalidateFilter call fix

I think this is fine, if we let people zoom on the top area, we should let people zoom on the zoom one, but i agree with Safa this is not the actual fix for bug 375251

Changes based on inline comments

Adding @kossebau since he had at some point of history a patch for fixing this at the ki18n level. Friedrich can you comment on it?

Rebasing on Applications/18.08

I agree this is suboptimal but it doesn't require the font selection (it's only the zoom).
I can find some use cases, especially with oriental languages, where you might prefer having different sizes for your English source and your local contents so it can still help.

Thank you!
I see the problem you are solving, but this is a less optimal solution.
This way the user must change the size with every launch of the app, and this is if he knows how to :) (no to mention he should change the size of both the boxes to match, or it will be ugly looking)
A solution that is used in Linux version is much better (a font setting)

Fix tab and replace by spaces

In T8984#151155, @ltoscano wrote:

Do you mean that those markers are needed anytime there is a mixed string with a translated part (which could be LTR or RTL) and a fixed part which has always the same direction?

In T8984#151154, @safaalfulaij wrote:

First, sorry for any language mistakes.

In T8984#151124, @huftis wrote:

FWIW, I’m not sure I understand all the implications, but I think this sounds like a good idea. But I have two questions:

• Will these characters also be needed for LTR languages?

In some cases, yes they will be needed. Take this PR as an example, the same issue is with Dolphin:

First, sorry for any language mistakes.

In T8984#147458, @safaalfulaij wrote:

Well, I said the same way we'll do it for the formatting, so if we'll go with “all placeholders are locale-formatted”, then we'll go with “all placeholders are enclosed with isolation characters” :)
I'm with you that it's better to not let translators struggle with it, and make it the “by default” thing.

In https://git.reviewboard.kde.org/r/127800/, @ilic wrote:

This is a change that would greatly benefit from an auto test, sadly we don't have to have any in lokalize.

In D13219#278789, @ltoscano wrote:

https://api.kde.org/frameworks/ki18n/html/index.html references the programmer's guide:
https://api.kde.org/frameworks/ki18n/html/prg_guide.html

In D13219#278776, @huftis wrote:

I’m actually not sure how KDE’s i18n stuff is actually supposed to work now. The official(?) tutorial at https://techbase.kde.org/Development/Tutorials/Localization/i18n seems severely outdated (e.g., it talks a lot about KLocale stuff).

In D13219#271124, @aacid wrote:

I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default, pinging @ilic to see what he would think about fixing/expanding ki18n to do "the right thing" by default

In T8984#147453, @aacid wrote:

I already disagreed that method is the correct solution, so no it's not "the same way"

I already disagreed that method is the correct solution, so no it's not "the same way"

In T8984#147444, @aacid wrote:

You mean changing every single i18n() call that uses a placeholder? or something else?

I would like to discuss if we should enclose every placeholder used in KI18n with the two isolation characters

In D10009#265704, @aacid wrote:

I'm going to add a Needs changes here to remind myself to review this, given that meskobalazs is not a kde/lokalize developer i don't think it was a good idea of him marking this as accepted.

Closed by https://commits.kde.org/lokalize/c1fd23b55999974e50cfda299c55753796f81f31. (I don’t know why arc land didn’t close this automatically.)

In D13411#275934, @aacid wrote:

Maybe give it a few days before pushing in case someone objects or finds a better name for Incomplete.

I'm not convinced "Incomplete" is the best name, but people will understand what it means quickly so i think this can go in.

I’ve now (hopefully) changed this to land on master
instead of stable.

You can't add new features to a stable branch

In D13219#273311, @aacid wrote:

In D13219#273109, @safaalfulaij wrote:

https://bugs.kde.org/show_bug.cgi?id=388642

Just saying... :)

Just saying... :)

But 2018 is not a number, it's a year ;)

In D13098#270898, @huftis wrote:

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

In D13219#271124, @aacid wrote:

I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default […]

I'm not too thrilled about this to be honest, seems that this is something i18n should be doing by default, pinging @ilic to see what he would think about fixing/expanding ki18n to do "the right thing" by default

Note that I’ve tried making a similar change for the numeric columns in the table in the project view, but this broke sorting (and I don’t know how to fix it), so it’s not included in this patch.

In D13098#270610, @safaalfulaij wrote:

In D13098#270465, @huftis wrote:

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.

In D13098#270465, @huftis wrote:

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?

In D13098#270053, @safaalfulaij wrote:

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

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

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.

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.

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

In D13098#267949, @ngraham wrote:

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!

Screenshot of the UI before the patch:

I'm going to add a Needs changes here to remind myself to review this, given that meskobalazs is not a kde/lokalize developer i don't think it was a good idea of him marking this as accepted.

yeah i think that's easier to understand