Bug 230963 - Statusbar needs RLM character in RTL environments
Summary: Statusbar needs RLM character in RTL environments
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: bars: status (show other bugs)
Version: 16.12.2
Platform: Unlisted Binaries Unspecified
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: rtl
Depends on:
Blocks:
 
Reported: 2010-03-16 13:25 UTC by Dotan Cohen
Modified: 2018-04-15 16:09 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Samples of eight filetype configurations and their respective statusbars (79.83 KB, image/png)
2010-03-16 13:30 UTC, Dotan Cohen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2010-03-16 13:25:34 UTC
Version:            (using KDE 4.4.1)
Installed from:    Unspecified Linux

In RTL environments the Dolphin statusbar shows incorrectly if the filetype does not start with an RTL character. This is what the RLM character is for:
http://www.fileformat.info/info/unicode/char/200f/index.htm

Please add an RLM character after the opening parenthesis. Thanks.
Comment 1 Dotan Cohen 2010-03-16 13:30:20 UTC
Created attachment 41687 [details]
Samples of eight filetype configurations and their respective statusbars

Here are eight screenshots with these combinations of filename and filetypes:
1) Filename in Hebrew or English
2) Filename with or without extension (extension always in Latin letters)
3) Filetype in English (plain text) or Hebrew (ODT, which is translated in KDE)

It can be seen that when the filetype is in English, there is always one or another display problem. However, when the filetype is in Hebrew, it always displays fine. This indicates that a simple RLM charater after the opening parenthesis wil fix the problem.

Thanks!
Comment 2 Dotan Cohen 2010-03-16 13:34:13 UTC
Note that due to bug #103788 one cannot enter arbitrary unicode characters in KDE:
https://bugs.kde.org/show_bug.cgi?id=103788

Therefore, to implement the fix the dev can use the Hebrew Lyx keyboard:
System Settings -> Language and Location -> Keyboard Layouts -> Layout tab -> Layout version -> "lyx"

The RLM character is Shift-ט (that is on the Y key) when in the Hebrew layout. You will not see anything on the screen, the RLM is a non-printing character.

I would love to commit the fix for this, if someone would teach me how to commit. I have an SVN account.
Comment 3 Diego Iastrubni 2010-03-16 14:05:13 UTC
Dotan:

Do you know what will happen in LTR environements? You need to test 4 cases:

RTL env + LTR text
RTL env + RTL text
LTR env + LTR text
LTR env + RTL text

Then, if nothing gets broken, don't type into the code a literal RLM char, but construct a QChar and append it to the string (for code readability).
Comment 4 Diego Iastrubni 2010-03-16 14:06:48 UTC
re-thinking of this... how about we fix this in the translation? It seems like the proper location.

Which string should I "hack"?
Comment 5 Dotan Cohen 2010-03-16 16:27:21 UTC
> Do you know what will happen in LTR environements?

I should have been clearer. This fix should only be made in RTL environments.


> how about we fix this in the translation?

While that is the best way for sure, there will always be new file types that come up. The translation should be fixed, but Dolphin should work on untranslated strings as well.
Comment 6 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:18:31 UTC
Resetting assignee to default as per bug #305719
Comment 7 Frank Reininghaus 2013-08-28 15:32:54 UTC
Is this still an issue in more recent versions?

Do you think that anything (except for the actual translations) still needs to be fixed?

(In reply to comment #5)
> The translation should be fixed, but Dolphin should work on
> untranslated strings as well.

The entire string in the statusbar (file name, type, and size) comes from kdelibs (to be precise, KFileItem::getStatusBarInfo()). If anything needs to be done next to the opening parenthesis, we cannot do that in Dolphin. So if you want to keep this report open, it should probably be re-assigned.
Comment 8 Dotan Cohen 2013-08-29 05:50:50 UTC
I'll take a look to see if this can be handled entirely in translation.
Comment 9 Frank Reininghaus 2013-09-09 22:28:12 UTC
(In reply to comment #8)
> I'll take a look to see if this can be handled entirely in translation.

Thanks. If you think that anything needs to be done in KFileItem::getStatusBarInfo(), feel free to reopen this report and reassign it to KIO.
Comment 10 Julian Steinmann 2018-03-31 10:23:32 UTC
Is this now implemented on the translation level? If yes, then we can close this bug.
Comment 11 Julian Steinmann 2018-04-15 16:09:16 UTC
No response -> closing. Thanks for reporting this bug, please reopen the report if you can still reproduce this behavior with newer versions of Dolphin.