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.
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!
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.
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).
re-thinking of this... how about we fix this in the translation? It seems like the proper location. Which string should I "hack"?
> 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.
Resetting assignee to default as per bug #305719
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.
I'll take a look to see if this can be handled entirely in translation.
(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.
Is this now implemented on the translation level? If yes, then we can close this bug.
No response -> closing. Thanks for reporting this bug, please reopen the report if you can still reproduce this behavior with newer versions of Dolphin.