KCachegrind is loading a list of translated messages (if available) for the event type combobox, which then later on are saved to the config file. Therefore changing the language of the application doesn't translate all user visible strings. Related code for saving that information is located in libcore/globalconfig.cpp, function saveOptions(): ConfigGroup* etConfig = ConfigStorage::group("EventTypes"); int etCount = EventType::knownTypeCount(); etConfig->setValue( "Count", etCount); for (int i=0; i<etCount; i++) { EventType* t = EventType::knownType(i); etConfig->setValue( QString("Name%1").arg(i+1), t->name()); etConfig->setValue( QString("Longname%1").arg(i+1), t->longName(), knownLongName(t->name()) ); etConfig->setValue( QString("Formula%1").arg(i+1), t->formula(), knownFormula(t->name()) ); } Is there some kind of reasoning for storing these even? Reproducible: Always Steps to Reproduce: 1. Start the application while using a language different than English. 2. Change the language back to English or some other language. 3. See that the types combobox is not being updated. As a workaround one can remove the configuration file after changing the language, I assume.
The reason for this behavior is the following: The user can add arbitrary event types (use the context menu in the event type pane), and name them as he likes. Such new events must survive restarts, so event type information is saved and restored from the config. To make KCachegrind more comfortable to use with Callgrind, a few event types are known, and added the first time KCachegrind is used (ie. when the config is empty). And yes, I currently initialize the "long name" for these pre-known event types with an translation. The reasoning for that behavior is that users usually do not change language, and if they want, they can change the long names as they like, which will be persistent. So what do you suggest? We could leave the long names of known types at initialization time empty, and use the translated long name if we find for a known type, that the long name actually is empty. I am just not sure if such smartness is not even more confusing to the user as the current behavior.
That's what I thought from quickly going through the relevant source code, though the feature itself is very well hidden :-) Anyway, I would say that the default entries should follow the language changes, though how to implement that nicely is a question I don't know answer at the moment. Perhaps it'd be a good idea to ask i18n people how this should be dealt nicely.
The obvious solution is to distinguish between "default" and "custom" event types. The "default" ones should not be saved, but always regenerated at run-time instead, so that their name are always translated again into the currently chosen language. The "custom" event types should definitely be stored and therefore their names will be persistent.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!