Version: (using Devel) Installed from: Compiled sources Please see this discussion, which explains the issue (it started as a bug in kfile, but there is a similar bug in KMail, as explained in one of the messages): http://lists.kde.org/?t=122894845400003&r=1&w=2 Basically, the problem is that the names of the various aggregation views (e.g., ‘Activity by Date, Threaded’) are fixed after you first start KMail. This means that if you first start KMail in English (or KMail isn’t completely translated to your language the first time you start it), the names of the view continue to only be shown in English. This also means that it’s impossible to improve the translations or the original English names for people that have launched KMail at least once, which is very unfortunate.
If you need help i18n-wise do not hesitate to ask.
The skin and aggregation names are user definable: they must be created on the first startup, there is no other way... I accept suggestions on how to fix this :)
I don't see an easy way to fix this. I think the situation is the same for templates.
The obvious solution is, where you store this "skin and aggregation names" add a flag that defines if it is user created or default created. If it's user created the name is shown directly. If it is default created, you store the name in english but pass it through i18n to show it to the user. Once the user edits a default created entry it stops being default created and switchs to user created.
Couldn’t the names just be stored internally as codes (e.g., ‘$1‘, ‘$2‘) and then automatically converted to the real names on display? Then the user can also edit all properties of a view (fonts, colours, etc.), and the internal name will not be lost, and will change if you change language or the official English name changes. Only if the user actually changes the name will this relation be lost. (When storing a view, check if the name matches one if the names associated with ‘$1‘ to ‘$n‘, and if so, store the code instead.)
One note on my last comment. When storing the view, it should be checked if the name matches one of the *translated* names of the codes. The (possibly) translated name will always be the same between when you start to edit a view and when you store the view, and the internal code will now never be lost.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.