This is the Qt issue similar to the one in KTextEditor:
https://bugreports.qt.io/browse/QTBUG-71489

Hello all.
I have been watching this for a while now, and I have to admit it: there are good points from both sides here.

Just my two cents, this might be much better for a simple reaon: the categories can be too many (think Office and the tabs that show up when you edit images/tables/charts/etc.)

I think WhatsThis is still used in some places, just redesigned to make it more accessible.
Hovering over buttons in Office for example shows this (for some buttons only):

In T12517#217331, @kkoma wrote:

What do you think about the password wiggle seen on the gif? And something similar with the trash icon?
(The gif I uploaded looks messy because it is grabbed from YouTube while it is being demoed by a guy who loves to move the mouse around a lot and zoom in a lot in videos, and the "back 5 seconds" OSD of YouTube is visible in the screen capture when I press Left to rewatch the big moment. Please focus on the password fiels and ignore everything else.)

I believe anything that is as subtle as Firefox animations* is fine. Anything beyond must be killed (shredding flying moving scaling rotating etc etc).
Also to me, quality-designed static photos are better than animations to illustrate very simple concepts.

Hi :)
Please tag me in case you need any RTL help.
Yes, headers are aligned based on direction before, which was bad. It's almost better to align them to the other side even if they're not translated. You never know.
And good that you spotted the issue with QML's Layouts regarding RTL:)

Let's not forget digiKam :)

I've checked Weblate in more details now, as well as the documentation. hmmm, not very bad. Proper permissions, fast browsing, checks, good UI, good editing box, etc etc..
We tried once to translate KDE docs by pootle, but it was a horrible thing at that time becuase of bad SVN integration. By that we had to have each single file translated with anything so that it can be uploaded and pushed to the server, or we can't push anything (not sure why, my teammate was doing that back then). I've removed all those files now.

In T11070#192350, @meven wrote:

Languages like Japanese and Korean are less than 70 % translated, Arabic, Hindi, Bengali and African languages are worse, despite those are spoken in countries representing millions of potential users and community members.

In D13219#499990, @huftis wrote:>

I’ve just tested this, but changing %1 to %L1 doesn’t seem work; the %L1 is displayed verbatim.

This is great! Thanks!
Same issue in here: https://phabricator.kde.org/D13219
I'm not sure if this is the correct way of fixing it, but I think there isn't any other prvoided by Qt, other then QLocale::toString. Maybe it's the easy way here :)

And what would happen to menus? How will that centered toolbar look with menus on the left?
How it will work with KDevelop for example?

Even in Qt there aren't many (if any) developers who understands RTL text. That is why many bugs I reported to Qt didn't get resolved till now.

Issue 1: https://bugs.kde.org/show_bug.cgi?id=385694 (In Qt, it happens only with bidi: https://bugreports.qt.io/browse/QTBUG-71489)
Issue 2: Yes, this happens. I don't know if a bug is reported or not. I remember seeing this with normal LTR text as well, and it got fixed. (I think some height algorithm was changed)
Issue 3: Seems related to issue 1.
Issue 4: This is new. So hitting up in the wrapped RTL text segments takes you to the beginning of the segment, not up to other segments.

Can't test, but seems fine.
Thanks for informing! :)

Wow! Great :)
Thanks for looking into this, but I'm afraid that the problem isn't with backspace/del, but with the cursor positioning, at least for RTL and mixed text.
I actually found this to be a problem in Qt after trying to solve it myself in KTextEditor: https://bugreports.qt.io/browse/QTBUG-65508
Not sure what's the root of the problem :(

-- Emoticons (or should we delete this because it's useless, as discussed in the VDG room?

Just here for emoticons. We know that removing a feature will lead to a bug report, don't we?
Both Konversation and Choqok are using emotions to display emoji (even thought they are not supported officially anymore in Konvi, but that won't last for long, hopefully).
It is such a small KCM that just makes life easier for the users of those apps, why removing them? I rememberd one of the KDE goals was to implement a global text edit controls that support emoji by default. Even if we don't have that yet, but when we do, we certainly want users to be able to change the icons.
I don't plan to go to Telegram channel to get to know that. I don't need to. KDE uses Phabricator and IRC to be public to everybody and accessible, not private and require softwares and registration.

mmm, sorry. I saw this today and I just took a minute to understand it. How does this looks consistent with the theme, or even nice (really sorry)? Please teach me.
Thank you.

I am using the latest version and I really think that the background in the icon is too light. Like check the other apps (Dolphin, Firefox, KSysGuard, System Settings, etc). They don't use such light colors. Maybe with a bigger version it's fine, but the smaller (much more important and used version) is not.

Addressed comments.

Thanks for making stuff consistent! :)

Hi @dkazakov!
Well, basically (please ignore the Arabic/English text changing):
Before:

Minor changes

Update based on comments given by bond

Hi :)
tbh, I stopped working on it once I uploaded it. I'll get back to it soon, but need to fix my Linux working machine.
I will most probably change QRectFs to QRects again, and maybe make the comments a bit better.
Then I have to figure out why rendering of the items isn't updated in the moment of showing/hiding the layer.

In D14753#349840, @winterz wrote:

I'll commit this for you.
it seems to work, at least as much as I can tell.

Thanks!
I think this solved all my issues. I can for meter unit change the formatting so that tr("%1 %2", "no Prefix") is translated to "%1%2" and choose to keep the dot or remove it in the unitStrings translation. ("bit" -> ".bit", "m" -> "m")
By the way, shouldn't that also be the case for English? I don't see people write "1 m" but "1m", "200 B" but "200B", same for Hz, not sure about bits. The space is not there when abbreviation is used.

I came into anther problem, this time with the unit selection.
In Arabic, we don't put a dot between the prefix and the unit if we're talking about meters (mm, cm, km), but we do with other units (k.Byte, M.Byte, G.Byte).

Since the joining between number and format is translatable, that's great. I meant that if it is kept untranslatable, problems regarding RTL will happen.

In D15808#333012, @woltherav wrote:

Uhm, I just followed the include that was written in the documentation for button http://doc.qt.io/qt-5/qml-qtquick-controls-button.html

I understand that it's entirely up to Krita devs what suits best, but I really think that QQC1 shouldn't be used anymore. It is depracted and replaced by QQC2 (Although the latter is still lacking some stuff).
This is not a comment on this patch specifically, but to the whole QtQuick code in Krita.
Who knows, maybe I work on that one day if no one took the task.. :D

Can we please first answer this and this before going on with this? I feel they are just ignored without any reasonable explanation. Thanks.

Why not also add icons to other items instead of other X number of commits coming later by Y number of people?
Yes, some don't have “group” icon (like sort, where only ascending and descending are available), but I don't see a problem if we used any “child” one as “group”, like ascending for sorting, center for alignement, etc.

Alright. This changes many manual code to code that is dynamic, easy to understand and to maintain (for both LTR and RTL layouts).

I forgot for a second that you don't need video support. Well I'm not entirely sure if QtAV supports many audio formats, but it depends on ffmpeg which I believe support many. I have very little knowledge here and just wanted to add some info about the existence of QtAV :)

Digikam switched to QtAV once and they said it's better for cross-platform. It also has a QML interface and a similar API to Qt Multimedia. I think you should check that first before VLC.

No changes to “Misc.” from lasst screenshot.

Unique name for spacer (be in the safe side)

Add "General:" and a spacer.

Of course it be great if we can use KPluralHandlingSpinBox, but I am not entirely sure about dependencies and import stuff, so I'll keep this for real developers :)

In D15329#321804, @ngraham wrote:

These are much nicer! Can we do it this way?

One way:

The label in the Image Properties dialog didn't really change at all.

I thought that this is a feature/cool look :D
Thanks a lot!

This is nice! Let’s not forget that we have applications that have a name with more than 2 words (GIMP, Plasma X Explorer, KMail Import Wizard, and some others.). They aren’t many, but we don’t have any idea about 3rd-party apps. Maybe this is why applications are having horizontal items so the name can fit however long it is.
Possible solutions:

• Get rid of the name in favorites section and just use the icon.
• Resize sections and give the favorites the biggist area, then narraw down the number of allowed favorites and use a bigger item.
• Use marquee text (up and down) for long names.

In D15011#314738, @filipf wrote:

Exactly! In your second proposal I don't think the serachbox sticks out, even as it is. At least to me it looks fine. At the same time it is drawing back, albeit not totally, to old Kickoff so there would have to be good designer conceptualization and solution for how to keep it modern.

When I look at Kickoff now and just think narrowly: how can I make the search more prominent and keep designer consistency, what makes most sense to me is to reuse the horizontal blue line we already have as a Kickoff tab selection indicator, and even as the indicators of open windows and plasmoids. These lines are indeed minimalist. Unfortunately that looks terrible:

(deleted screenshot from reply)

Not even making it a classic Breeze 1px line feels right, although I guess it's a bit better:

(deleted screenshot from reply)

I've had a look at that setup. It's pretty sleek. But we have to consider that YouTube still keeps a full-fledged serachbox on their homepage, and the channel is a less important of a place. So if we apply that to Kickoff, it looks like this:

(deleted screenshot from reply)

And then when it's opened it would look like this:

(deleted screenshot from reply)

IMO we still haven't solved the problem of it not being obvious that you can search. Maybe having a search icon isn't a bad idea though, but I think we'd still have to make it more obvious somehow:

(deleted screenshot from reply)

This was just a little foray into what is possible, nothing definitive or great. In the pictures I've shortened the search box so that there is equal distance from the left and right edge of Kickoff, for symmetry reasons mostly, but also because I am a bit bothered that the Favorites tab is wasting about 60% of horizontal space on nothing and I didn't want to drag attention to the right side. This may be fixed when we get a new Home tab and isn't too important right now anyway.

Why don't we have a simple search icon that indicates that one can search in the kickoff, and once you click on it you get switched to the search layout, where you'll find a note saying you can also search by direct typing, and a “Got it” as many websites does? Youtube doesn’t force a long search input in the channel page.

The original issue (in Neon/Kubuntu task, not sure) was that Kickoff is not clear if one can search or not, because of text changing. Why not just keeping the current “Type to search” label as is, and move the user@host text up as in the patch?

In T9460#156173, @ngraham wrote:

It's important that we treat all input devices as first-class citizens. Saying, "pshah, just use a real mouse" or "nobody should click on this, the hidden accelerator gesture is more efficient" isn't acceptable. We have GUI interfaces precisely because those hidden accelerator interfaces are only suitable for power users and experts. They are critically important and we should never impair them, but we shouldn't fall into the trap of assuming they're suitable for everyone.

I'm pretty sure no one uses these buttons if they have an actual mouse, but just the wheel. And I can say that those who use the touchpad don't need to change this (I don't see a usecase where one using his touchpad instead of a proper mouse, will need to change such values that are kept in settings mostly).

I use an old laptop with 1280×800 display (not like you should really count for it, this is old).

Well, I always said that DamnedLies is much better than anything eles (Pootle/Transifex/Weblate/etc), but I think we need to keep normal SVN access available as we have lots of file in KDE that are just few strings, and the whole process of downloading translating uploading for each one will be a huge headache :)

Fix source
Add shifts

I tried to read about a way to extend the holiday if happened in a weekend day but couldn't find one.
If any day of a holiday happen to be in a Friday or Saturday (Weekend days in Bahrain), the next working day will be a holiday.
Example: Eid ul-Fitr is 3 days, starting from Thursday. It happens on Thursday, Friday, Satarday, Sunday and Monday, where Sunday and Monday are not actually holidays, but they are now so that a holiday is really a day-off and not a usual weekend day.
I'll be done once I solve this for all the holidays in the file.

In T7927#154320, @ngraham wrote:

In T7927#154291, @rkflx wrote:

Again, not true! Did you actually try this or look at the code before commenting? Changing the font name of all fonts via the button won't change the fixed font. (The only oddity is that changing the size will make the small font the same size as the other fonts.)

Ah, indeed I had not used it, because I assumed that "Adjust All Fonts" will adjust all fonts. When a button will manifestly not do what its label says it will do, that's a problem.

In D14733#306325, @bruns wrote:

You should start with
a) a use case
b) show it actually matches the needs of different languages.

For e.g. englisch and the most european languages, two different positions are sufficent. Also, the AndListType and the UnitListType are identical. What is missing is a format where no conjunction is used, i.e. all lists elements are joined using ', '

Fix test
No unrelated changes

In T7927#154285, @ngraham wrote:

In T7927#154109, @rkflx wrote:

How about a simple plus/minus button, which affects all different font types at once? (IOW, providing an inline "easy" alternative to the Adjust All button for a single topic.)

I could get behind that. The Adjust All Fonts... button has always rubbed me wrong because it will always produce incorrect output for the Fixed Width and Small fonts that then needs to be manually fixed. If we implement your suggestion, I'd be okay with the original proposed separation with the font settings on one tab and the anti-aliasing settings on another tab.

Tbh I don't fully understand the struct and find statments (just saw working similar code and edited-copy-pasted). I prefer if someone can continue this instead of me.

Can we please take a look at this before continuing here?

Yes. As you said, these are symbols. For the names there may be transliterations, the symbols stay the same, to avoid ambiguities. This also matches my experience with datasheets, the text may be chinese, but measurements are given in SI units.

Since this turned already into a discussion, shall we use %Lx version for KF5 libraries using Qt's translation system? I mean in the source text.

Worked great, thanks!
Maybe you should use largeValue instead of largevalue.
But please take an approval from a developer, it worked for me but I have no idea if it can cause any trouble :)

In D14345#297340, @ngraham wrote:

1. Does this mean that PlasmaComponents is semi or fully deprecated or "legacy", and we should be porting Plasma stuff to Kirigami instead?
2. Since there's no Kirigami TextField, what do we do with this patch? Is there any reason why we can't improve the PC3 TextField to match the features that the PC2 TextField has? Or should we create a Kirigami TextField instead and port current PC2/3 clients to use it?

Great! Now I know why the port to PC3 didn't start :D
Now to the patch. First, by this we will allow the user to get text under the icon, which will be impossible to read.
Second is what I'm here for :)
The clear button placement and icon should not follow the locale, but the actual text imh. You can write Arabic in an English system, and vice versa.

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)

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?

First, sorry for any language mistakes.

In T8984#147453, @aacid wrote:

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?

Small question, why we're not using QQC2-based controls?

In D13219#273311, @aacid wrote:

Just saying... :)

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

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

Btw, the qt tag is from Qt3 days. I'm not sure if it must be richtext, if so then a simple html or even KUIT markups are better choice :)

In T8198#133378, @woltherav wrote:

In T8198#133145, @safaalfulaij wrote:

Hi :)
I'd like to thank you all for the work done on supporting SVG and RTL text. This is really appreciated.

I was testing one of the last nightly (or beta) builds and found out that the direction of Arabic text is LTR. The special SVG "direction" property is needed for the direction to be applied.

Another small issue: If you typed a LTR sentence and then hit Enter then typed a RTL sentence, (and you applied the direction property to the RTL one), you'll get this: :)

Font-variant for all sorts of open type features. (This will require modifying QT itself to get access to Harfbuzz)

This will be really beneficial for many software, but I'm not sure Qt will expose that stuff so easily...
As you know, Scribus went the long way and added support by using HarfBuzz directly.

That's all. Thanks!

Could you please report a bug for these at bugs.kde.org? Phabricator comments are too difficult to track bugs in.

(Also, add a screenshot of what it looks like in the editor then)

Hi :)
I'd like to thank you all for the work done on supporting SVG and RTL text. This is really appreciated.