In the German translation the root folder in the folder panel is translated as Wurzelordner. This may be the direct word-by-word-translation, but it sounds very strange and I did not know this word before. In Gnome I have seen root folder is translated as "Dateisystem". This is not a matching translation, but it definitely sounds more adequate and gives the right meaning, especially to new users. Reproducible: Always
According to KDE's standard translations [1] "root folder" should be translated as "Basisordner". Another suggestion would be "Stammordner" [2], which is also much less strange than "Wurzelordner". [1] http://community.kde.org/KDE_Localization/de/StandardUebersetzungen [2] http://de.wikipedia.org/wiki/Stammverzeichnis
This issue was fixed on January 28th in revision 1336086 http://websvn.kde.org/trunk/l10n-kde4/de/messages/kde-baseapps/dolphin.po?r1=1336086&r2=1336085&pathrev=1336086 Thanks for your reports. :)
I forgot to mention that therefore it should be "Basisordner" in KDE 4.10 (or 4.10.1) and later. If it is not, please reopen this report.
You will have only in a system started the first time in locale de in 4.10, on systems <4.10 "Wurzelordner" will stay for ever. Reason is a regression, see https://bugs.kde.org/show_bug.cgi?id=319282#c5
Ouch. :( Although, you can change it in ~/.kde/share/apps/kfileplaces/bookmarks.xml ... which is of no help for us translators and all the poor souls who do not read this. :)
Addendum for those who are confused now. Usually translations are fetched from the translation catalogues when the application (or library) ist started. Changes to the translation file are then recognised kind of instantaneously. In some places in KDE, however, translations are only read once from the translation catalogue when the application (or library) is started for the first time (or some other action (like saving something) is taken) and then written in a configuration file inside the user's home folder (~.kde/share/*). This 2nd class of translations will never receive any of the updates we (as in translators) provide. This is a known problem in KDE but not all developers fix it unfortunately. Since I created such a one-time translation in KShisen years ago when I rewrote part of it, I will better not start throwing rocks here. :D The libraries sometimes make it very hard to avoid such things. :( Again, if you want to change the string, you have to log out of KDE completely and change it in ~/.kde/share/apps/kfileplaces/bookmarks.xml Sorry for the inconvenience.
As it stands, I will reassign this to the Dolphin team. Maybe they can come up with a solution.
(In reply to comment #7) > As it stands, I will reassign this to the Dolphin team. Maybe they can come > up with a solution. Sorry, but I don't understand why you reopened this report. I'm not very familiar with this stuff because I never touched the relevant code, but my understanding is the following: (a) In the bookmarks.xml file, we should only store the English names for the "Places" (unless the names were edited manually by the user). The translated strings should then be loaded at runtime. (b) Unfortunately, (a) does currently not work, see the bug 319282 which has been mentioned by Burkhard. I have no idea what the problem is (as I said, I never worked with the relevant code), but I think it might have been caused by Peter's Places Panel rewrite for Dolphin 2.1/KDE 4.9. Please explain what other problem we should come up with a solution for. I guess there is one, or you wouldn't have reopened this report?
Hi, I'm sorry. I did not realise the report Burkhard mentioned was also about Dolphin. I just reopened and then reassigned this report because I had closed it before as "FIXED" for the German translation, which then turned out to be not correct. As it stands now, I guess closing it as duplicate of the other bug would be the proper way of handling it. Well, yes. I guess it could work if you maybe store the every string with e.g. the english term as ID. Then you just pull the string and compare it with its ID. If it matches, fill in the string and i18n should handle it correctly. If it does not match, the string was altred by the user and has to be inserted as is. But yes, as I see it it's the same issue as from the other report. So sorry for spreading confusion. :) *** This bug has been marked as a duplicate of bug 319282 ***
All right, thanks for the quick reply! In my experience, reopening a FIXED report and using it to keep track of a completely different bug (even if it has the same consequences for the user) often leads to confusion and unreadable bug reports, and should therefore be avoided IMHO.