| Summary: | "Places" names in dolphin etc. untranslateable | ||
|---|---|---|---|
| Product: | [Applications] kfile | Reporter: | Thomas Reitelbach <tr> |
| Component: | general | Assignee: | Peter Penz <peter.penz19> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aacid, ereslibre, ervin, karl, lueck, mikid, peter.penz19 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Thomas Reitelbach
2008-12-11 22:08:19 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. 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 > 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. 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 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 |