Version: (using Devel)
Installed from: Compiled sources
The places in dolphin and other file dialogs are not really translateable.
The relevant strings are extracted and used for translation.
BUT: The translations are only used the first time when the an application is started, then the translated strings are stored as bookmarks in ~/.kde4/share/apps/kfileplaces/bookmarks.xml and are static from now on.
Initially this seems be a feature, which makes it possible for the user to rename places.
But this feature leads to several problems:
a) If the user started the application in english the first time, he will never ever see any translations, when he changes his language afterwards.
b) If a system is used as a kiosk-system for example it might be needed to change the language at runtime (for example imagine an internet cafe at your favorite international airport), which is impossible for the places, because the names are stored as bookmarks and therefore will not follow the language change.
c) Distributions will probably invent new names for the places, which will lead to inconsistency in documentations. The documentation will refer to "Home", while the distribution might call it completely different.
Please have a look at the thread at the KDE translators mailinglist:
A similar problem exists in kmail with the aggregation modes of the new message list. But I suspect this requires a new bug report ;-)
Thank you for looking into it :)
We offer our users the possibility to change the language system-wide via
Systemsettings and per application via Help->Switch Application Language.
They will expect this to work without exception, especially in such a
frequently used dialog like File Open/Save.
Added Kevin, Peter and Rafael that did most of the work on kfileplaces code.
Guys if you need help i18n-wise do not hesitate to ask.
I agree that this should be fixed, I hope I'll have time during KDE 4.3 for this and have assigned it to me. As soon as I've a patch, I'll contact Kevin and Rafael before committing anything...
While I agree this should be considered a bug I also think the fix is not an obvious thing. Or yes ?
The main problem is that this places are shared with Gnome, so you can switch between KDE and Gnome and still have them, so we have to take into account the specification to still be compatible with it.
There exists the same problem at other level. Imagine I have Gnome in english, and KDE in spanish. If I start Gnome those places will be saved in english, when I load them in KDE they are loaded in english, so there's no way to handle this in a really clean way IMHO if the specification does not cover this use case.
Couldn’t you just base the name that is displayed on the *location* for these ’special’ places, instead of on the stored name (just ignore it)? Something like this:
/ → Name for ‘Root‘
$HOME → Name for ‘Home’
remote:/ → Name for ‘Network’
trash:/ → Name for ‘Trashcan’
@Karl: This would introduce the issue that a user cannot rename those locations anymore. As Rafael said it's not straight forward to fix it, but I have to look at the specs first before discussing implementation details...
A different possible solution would be to always store the English name, but *display* the translated name if the URL matches (as in my previous suggestion). This would have the following effect:
1 If the file was first stored in a KDE version that didn’t have translations for the items, but the current one do, it would be correctly shown translated now.
2 If the user changes UI language, the translation would automatically change.
3 If the user renames an item, he is allowed to do that.
BTW, does GNOME really use a file called ~/.kde4/share/apps/kfileplaces/bookmarks.xml?
> A different possible solution would be to always store the English name,
> but *display* the translated name if the URL matches (as in my previous
Yes, this sounds reasonable. Hmm, it could lead to troubles in the following rare (?) use case:
* Language is set to German.
* The user adds a directory called "Preview" to the places (the directory name follows some "company rules").
* Result: the place "Preview" might be translated to "Vorschau", as most probably a translation for this string exists.
Or is this impossible? (I don't know which language table entries are used within kdelibs) But using this proposal should be straight forward.
> BTW, does GNOME really use a file called
No. I think it's just important that we don't violate an existing standard without having very good reasons.
In my proposal, the translation will *only* be used if the location is correct too, so the ‘Preview’ problem will not occur.
For example, if a user adds a directory named ‘Home’ (meaning something special in his/her language), it will not be ‘translated’ unless the location is (the expanded version of the variable) $HOME.
> In my proposal, the translation will *only* be used if the location
> is correct too, so the ‘Preview’ problem will not occur.
This sounds very good :-)
Perhaps fixing this will also fix bug#171424?
(In reply to comment #8)
> > A different possible solution would be to always store the English name,
> > but *display* the translated name if the URL matches (as in my previous
> > suggestion).
> Yes, this sounds reasonable. Hmm, it could lead to troubles in the following
> rare (?) use case:
> * Language is set to German.
> * The user adds a directory called "Preview" to the places (the directory name
> follows some "company rules").
> * Result: the place "Preview" might be translated to "Vorschau", as most
> probably a translation for this string exists.
> Or is this impossible? (I don't know which language table entries are used
> within kdelibs) But using this proposal should be straight forward.
You can simply make this case impossible by adding a unique message context like "Home in kde4 file dialog" to "Home" etc, so this could never happen.
SVN commit 963006 by ppenz:
assure that system bookmarks are retranslated when the user changes the language
M +14 -6 kfileplacesitem.cpp
M +5 -3 kfileplacesitem_p.h
M +11 -6 kfileplacesmodel.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=963006