I changed "Preferred Languages" to Russian. After that I changed it back to American English. Everything was fine but list items "Home", "Network" , "Root" and "Trash" in Dolphin's Places panel does not changed back to English. I tried to uninstall "kde-l10n-ru" package from my system, but no luck. I also tried to change language to German and back to English, but to no avail. They are still in Russian. I don't know where language settings are stored, but I have deleted Dolphin' settings from "~/.kde4/share/config" and reinstalled Dolphin. And again without any success. I successfully reproduce this bug on the VirtualBox ArchLinux machine. But the truth is I'm not quite sure that it's a Dolphin's fault. Maybe this is a problem with some localization component. As addition, the same thing happens with "Recently accessed" and "Search for" panels. "Devices" panel is always OK. Reproducible: Always Steps to Reproduce: 1. Change "Preferred Languages" in System Settings to Russian. 2. Change "Preferred Languages" in System Settings to American English. Actual Results: List items "Home", "Network" , "Root" and "Trash" in Dolphin' Places panel does not changed back to English. Expected Results: List items "Home", "Network" , "Root" and "Trash" in Dolphin' Places panel changed back to English. 22:38:54 blurred@blurred-laptop ~ $ locale -a C en_US en_US.iso88591 en_US.utf8 POSIX ru_RU ru_RU.iso88595 ru_RU.utf8 russian 22:39:02 blurred@blurred-laptop ~ $ cat /etc/locale.conf LANG="en_US.UTF-8" 22:39:20 blurred@blurred-laptop ~ $
Created attachment 79670 [details] Mixed languages in Dolphin's Places panel
Thanks for the bug report. I currently don't have a KDE system here, but I think that you can reset the names of the "Places" by removing share/apps/kfileplaces/bookmarks.xml from your .kde folder. If that works, I'm afraid that we neither can do anything to "fix" this, nor should this issue be considered a bug at all. If I'm not mistaken, what happens is the following: (a) If the mentioned file does not exist, "Places" entries are created in the *current* language. (b) You can edit the name of the "Places" at any time, and they are stored in that file, but we *never* change those names automatically. One could argue that we could always update the names of those "Places" to the current language, but then we would also overwrite any custom name that the user chose, which is obviously not a good idea.
Wow :)) Actually, everything become OK after removing ~/.kde4/share/apps/kfileplaces/bookmarks.xml I investigated a little, and things does not seem to be as your described. Look: 1. ~/.kde4/share/apps/kfileplaces is empty. Dolphin is closed. Preferred Language is English. 2. I run Dolphin. Dolphin has labels in English only. 3. I close Dolphin. 'bookmarks.xml', 'bookmarks.xml.bak' and 'bookmarks.xml.tbcache' appear in ~/.kde4/share/apps/kfileplaces. Title elements have values in English in 'bookmarks.xml' and 'bookmarks.xml.bak'. 4. I change Preferred Language to Russian. 5. I run Dolphin. Dolphin has labels in Russian only. [Why? 'bookmarks.xml' exists. And this file entirely in English] 6. I close Dolphin. Title elements' values become in Russian in 'bookmarks.xml' file. 'bookmarks.xml.bak' remains the same, in English. 7. I change Preferred Language back to English and see mixed languages in Dolphin when I open it. When I reproduce this scenario with Russian or with German as initial language, I see mixed languages on the 5th step. That is, Dolphin takes into account the presence of 'bookmarks.xml' file when this file contains non English entries. When 'bookmarks.xml' in English and my current language is, for example, German, Dolphin can't believe that I want my Places be named in English, and rewrite 'bookmarks.xml'. I guess, Dolphin just hates English :) I also tried to switch from Russian to German and vice versa and see mixed language on the 5th step. BTW, I don't understand for what 'bookmarks.xml.bak' is needed. Because I found out that if 'bookmarks.xml' does not exist, 'bookmarks.xml.bak' is just rewrited with newly created 'bookmarks.xml'. Nevertheless, thank you. I can solve this problem. And this thread may be helpful for others.
I do think it is a bug. The bookmarks is automatically created by system, and no user touch it. It should be locale aware.
Is this a regression? See https://bugs.kde.org/show_bug.cgi?id=177536 In a virtual machine with Kubuntu 11.04 KDE 4.6.2 I can switch between languages German and English (US) and have always the correct translated strings of Home / Network / Root / Trash for the language selected in Systemsettings in the Places panel.
Thanks for the addional information, Ruslan, and for your hint, Burkhard. Well, Dolphin's Places Panel has been rewritten from scratch for Dolphin 2.1/KDE 4.9 by Peter. In principle, he closely followed the QAbstractItemView-based implementation in kdelibs, but it could be that something went wrong. Unfortunately, all this code is not really trivial and straightforward, and I can't do much testing at the moment because English is currently the only language in my development environment (and I think it might take more than a few minutes to change that). In any case, we should never write non-English names to the bookmarks.xml file.
(In reply to comment #6) > ... because English is currently the only > language in my development environment (and I think it might take more than > a few minutes to change that). > http://techbase.kde.org/Development/Tutorials/Localization/Building_KDE's_l10n_Module explains how to install a language from svn, especially x-test should be used to check for a fully translated GUI.
Thanks Burkhard for the hint! I might have a look when I find myself in front of my development machine with some free time, but given how much stuff is constantly added to my inbox/TODO list by everyone, I'm not sure when this will happen. If someone else volunteered to go ahead and analyse this bug, that would be very welcome.
*** Bug 320222 has been marked as a duplicate of this bug. ***
I've run into the same problem now: I changed my system language to Arabic for some bidi testing (yes, I'm aware of --reverse; there was a need anyway) and wound up with my Places getting translated to Arabic, and changing the language back to American English didn't reverse this.
Created attachment 83516 [details] Patch Fixes the problem for me. However, this patch does not help if bookmarks.xml already contains the translated strings. In that case, it is required to delete the file manually.
Applied patch to master. 1) Changed "Preferred Language" top item from de to x-test and vice versa 2) "kbuildsycoca4 --noincremental" 3) DO NOT "rm /home/kdedev/.kde/share/apps/kfileplaces/bookmarks.xml" ! 4) Launch dolphin -> "Home", "Network", "Root" + "Trash" properly translated in the selected as top item in "Preferred Language" Now the strange thing I noticed: With step 3) "rm /home/kdedev/.kde/share/apps/kfileplaces/bookmarks.xml" I see on the first start of Dolphin less than a second the correct translations of the four Places items and then the four items switch to en_US. On the second start of dolphin (with existing bookmarks.xml + untranslated items) the four Places items are correct translated and do *NOT* switch back to en_US. I tried the same procedure in 4.12 compiled from sources with xxfooxx (=translated) items in bookmarks.xml and you are right, a bookmarks.xml with translated strings needs to be removed manually to make the patch work and write a bookmarks.xml with en_US (=untranslated) system items to disk. I can reproduce the strange behavior from master: a) no .kde/share/apps/kfileplaces/bookmarks.xml -> translations switch after less than a second back to en_US b) on second start of Dolphin (i. e. bookmarks.xml with items in en_US exists) no switch of Places items from selected locale back to en_US. On issue I see with your patch: kio4.po has 3 msgids with msgctxt "KFile System Bookmarks" and dolphin.po another 12 msgids with msgctxt "KFile System Bookmarks". Your patch introduces another msgid with msgctxt "KFile System Bookmarks" Looks to me that the patch will only work, if all 16 msgctxt strings (spread over 16 locations in kfileplacesmodel.cpp, placesitemmodel.cpp and placesitem.cpp are in sync (i. e. = "KFile System Bookmarks") How to ensure that?
*** Bug 327312 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > With step 3) "rm /home/kdedev/.kde/share/apps/kfileplaces/bookmarks.xml" I > see on the first start of Dolphin less than a second the correct > translations of the four Places items and then the four items switch to > en_US. Yes, I can confirm. Some debugging shows that this is because the "Places" entries are first shown correctly, then the bookmarks.xml file is written, and then PlacesItemModel gets notified that the file changed a little while later, re-loads it, and calls PlacesItem::setBookmark(const KBookmark& bookmark), which sets the text without translating. Could be fixed by adding another i18nc call there. But maybe there might be a risk then that a custom name that the user chose for a "Place" gets translated accidentally because it matches a string that has a translation? Maybe there is a better solution, I'll think about it. > On issue I see with your patch: > kio4.po has 3 msgids with msgctxt "KFile System Bookmarks" and dolphin.po > another 12 msgids with msgctxt "KFile System Bookmarks". > Your patch introduces another msgid with msgctxt "KFile System Bookmarks" > Looks to me that the patch will only work, if all 16 msgctxt strings (spread > over 16 locations in kfileplacesmodel.cpp, placesitemmodel.cpp and > placesitem.cpp are in sync (i. e. = "KFile System Bookmarks") > How to ensure that? I don't know :-( Can you suggest a better solution for the translation of those strings? Ideally, translators would have to translate each string only once, and this translation would be picked up from all of the different locations in KIO and Dolphin. But I don't know what the safest and most efficient way to achieve that is because I'm not familiar with the internals of the i18n system. In any case, I think that this issue is mostly unrelated to the patch because it's already there in the existing code (which was not written by myself, and I don't know if the original authors really thought about how to make life as easy as possible for the translators).
(In reply to comment #14) > Can you suggest a better solution for the translation of those strings? > Ideally, translators would have to translate each string only once, and this > translation would be picked up from all of the different locations in KIO > and Dolphin. But I don't know what the safest and most efficient way to > achieve that is because I'm not familiar with the internals of the i18n > system. > > In any case, I think that this issue is mostly unrelated to the patch > because it's already there in the existing code (which was not written by > myself, and I don't know if the original authors really thought about how to > make life as easy as possible for the translators). My concerns are not about translation problems, but to ensure a working code. Imagine someone will change the msgctxt "KFile System Bookmarks" in placesitemmodel.cpp, but overlooks the occurence of this msgctxt string in your patch for placesitem.cpp - the code will no longer work as expected!
Can you suggest a better solution?
Created attachment 83551 [details] New patch (fixes the problem Burkhard found with the patch from comment 11; see comment 12)
Apparently we have a missunderstanding or more likely I can not understand your code in attachment 83551 [details] Let me explain how gettext works: A translation catalog is a dictionary with pairs of key+string with unique keys per catalog. The key is generated from msgctxt and msgid, the string is the msgstr = translation That means i18nc("KFile System Bookmarks", "Home") != i18nc("kFile System Bookmarks", "Home"), where the second i18nc() has a lower char "k" in the msgtxt. The i18n() calls in the code work with a const string as msgctxt, but afaik the message extraction will not extract such a message. CC'ing our I18n coordinator Albert
Frank what Burkhard says is that you should make sure that the same context is passed to both this new i18n call and to the ones in placesitemmodel.cpp, otherwise it'll break, as you can see you already have comments to ensure that it doesn't change in placesitemmodel.cpp around line 769 and 908. Ideally one would use a define, but if you do that xgettext doesn't seem to work, so to be honest i don't think you can't do much other than adding another comment.
Thanks Albert and Burkhard for your explanations! I've uploaded the patch including the suggested comment to https://git.reviewboard.kde.org/r/113850/. Please let me know if there are any further problems or possibilities to improve it!
Git commit 6dd2ae4e15b52ac09859637786dddb4a028e0d4f by Frank Reininghaus. Committed on 15/11/2013 at 08:16. Pushed by freininghaus into branch 'KDE/4.12'. Update the Places Panel entries when switching the language Before this commit, we stored the translated "Places" in .kde4/share/apps/kfileplaces/bookmarks.xml. This was not intentional - it only happened because PlacesItem::updateBookmarkForRole(const QByteArray& role) always stored the translated text (returned by PlacesItem::text()) in the KBookmark. This is be fixed by first checking if the text() is equal to the translation of the text that is already stored in the KBookmark, and not updating it in that case. Note that we have to make sure that all "Places"-related use the same context "KFile System Bookmarks" to make that work. Thanks to Burkhard Lück and Albert Astals Cid for helping to fix this problem! FIXED-IN: 4.12.0 REVIEW: 113850 M +13 -1 dolphin/src/panels/places/placesitem.cpp http://commits.kde.org/kde-baseapps/6dd2ae4e15b52ac09859637786dddb4a028e0d4f