Bug 177536 - "Places" names in dolphin etc. untranslateable
Summary: "Places" names in dolphin etc. untranslateable
Status: RESOLVED FIXED
Alias: None
Product: kfile
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-11 22:08 UTC by Thomas Reitelbach
Modified: 2009-05-03 19:41 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Reitelbach 2008-12-11 22:08:19 UTC
Version:            (using Devel)
OS:                Linux
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:
http://lists.kde.org/?t=122894845400003&r=1&w=2

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 :)
Thomas
Comment 1 Burkhard Lück 2008-12-11 22:23:33 UTC
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.
Comment 2 Albert Astals Cid 2008-12-19 23:11:33 UTC
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.
Comment 3 Peter Penz 2008-12-20 13:40:21 UTC
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...
Comment 4 Rafael Fernández López 2008-12-20 17:57:25 UTC
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.
Comment 5 Karl Ove Hufthammer 2008-12-22 00:44:46 UTC
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’
Comment 6 Peter Penz 2008-12-22 08:33:38 UTC
@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...
Comment 7 Karl Ove Hufthammer 2008-12-22 10:19:30 UTC
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?
Comment 8 Peter Penz 2008-12-22 12:03:51 UTC
> 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.

> BTW, does GNOME really use a file called
> ~/.kde4/share/apps/kfileplaces/bookmarks.xml? 

No. I think it's just important that we don't violate an existing standard without having very good reasons.
Comment 9 Karl Ove Hufthammer 2008-12-22 12:13:02 UTC
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.
Comment 10 Peter Penz 2008-12-22 12:42:22 UTC
> 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 :-)
Comment 11 Szczepan Hołyszewski 2009-01-10 14:05:20 UTC
Perhaps fixing this will also fix bug#171424?
Comment 12 Burkhard Lück 2009-02-27 09:41:36 UTC
(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.
Comment 13 Peter Penz 2009-05-03 19:41:45 UTC
SVN commit 963006 by ppenz:

assure that system bookmarks are retranslated when the user changes the language

BUG: 177536
CCMAIL: ervin@kde.org

 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