Comment 9 for bug 390062

C++ is not my primary programming language, so take these comments with a grain of salt, but I think I've found where in the code the issue is occurring.

/src/collection/sqlcollection/OrganizeCollectionDialog.cpp

In the OrganizeCollectionDialog::buildDestination method, a map is created from a string to a string, called args. The first string is the key, and the second is the value. By giving the map a key, you can look up the value associated with that key. Semantically, it is being used such that the key is the short keyword used in the dialog (like %artist, %year, etc), and the value is what that keyword represents (like "Pavarotti", or "2009").

Towards the end of the method, the .namedOptArgs method is called, which I presume replaces the keywords with their values. The issue comes about in that the keys are not wrapped in the i18n() method required for internationalization when they are used in the code as keys. (For that matter they aren't either when displayed in the dialog box during the buildFormatTip() method, but I think that's just a change between SVN and the release last used in Ubuntu -- 2.1.1). With the i18n() wrapper, those strings would be translated to their local language equivalents, so when local language equivalents come through in the QString &format argument those keys would be correctly replaced with the value the key represents.

So then we need to decide what correct behavior should be. Do we want users to (A) be able to internationalize their keywords when building the organize files string, or (B) use the English versions as a standard for all languages? I think the first is preferable, unless there issues with using UTF8 QStrings as keys in QMaps, which I don't think there will be.

In that case, simply throwing i18n() around every time that a string is used as a key to the QMap would probably change our behavior closer to (A). I would include a patch but don't have a dev box handy for generating one.

Real developers, please comment :)