Not sure if this is an issue with KDE, I suspect a downstream problem...

I'm wondering why this was re-assigned to me, from my POV it seems quite "possible" that you are letting people translate the keywords but you are not accepting them translated when the user inputs them.

Is this re-assignement a strange way to ask for help or it's just a "we don't care about i18n let put the bugs under a carpet"?

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 :)

Teo: reping about this :)

This is not trivial, if these strings are not translated and handled consistently in the parser there could be issues. Andrew, if you're still interested feel free to prepare a patch for (A), also taking into consideration that this stuff will reflect on the guess tags dialog too.
Target for merging would be post-2.2.

Setting the version to git.

Closing this for now, since we deactivated the "Organize Files Dialog" in Amarok 2.2.1

I'm using Amarok 2.3.2 from Kubuntu's repos and the "Organize Files Dialog" is indeed there, did it came back?

keywords are still untranslated, can somebody confirm me if this is a downstream or upstream problem?

Reopening. Teo?

*** Bug 258802 has been marked as a duplicate of this bug. ***

I'm using Amarok 2.4.0 and this problem is solved by me (Kubuntu 11.04).

(In reply to comment #11)
> I'm using Amarok 2.4.0 and this problem is solved by me (Kubuntu 11.04).

I don't believe this, because there is not message "filetype" in the translation template (amarok.pot), and the other messages from it like "artist" and "year" are only used for the collection filter.

Created attachment 61337 [details]
Amarok-Organize Files

I added an image from Amarok 2.4.0 - keywords are not translated.

Thanks for the screenshot. Apart from the Keywords themselves everything is ready to be translated in the source, so that one missint sentence could alos be done by the translators:

src/dialogs/FilenameLayoutDialog.cpp:

270:
syntaxLabel->setText( i18nc("Please do not translate the %foo% words as they define a syntax used internally by a parser to describe a filename.",
// xgettext: no-c-format
"The following tokens can be used to define a filename scheme:<br> \
<font color=\"%1\">%track%</font>, <font color=\"%2\">%title%</font>, \
<font color=\"%3\">%artist%</font>, <font color=\"%4\">%composer%</font>, \
<font color=\"%5\">%year%</font>, <font color=\"%6\">%album%</font>, \
<font color=\"%7\">%albumartist%</font>, <font color=\"%8\">%comment%</font>, \
<font color=\"%9\">%genre%</font>, %ignore%."
, m_color_Track.name(), m_color_Title.name(), m_color_Artist.name(), \
m_color_Composer.name(), m_color_Year.name(), m_color_Album.name(), m_color_AlbumArtist.name(), \
m_color_Comment.name(), m_color_Genre.name() ) );


288:
syntaxLabel->setText( i18nc("Please do not translate the %foo% words as they define a syntax used internally by a parser to describe a filename.",
// xgettext: no-c-format
"The following tokens can be used to define a filename scheme: \
<br>%track%, %title%, %artist%, %composer%, %year%, %album%, %albumartist%, %comment%, %genre%, %initial%, %folder%, %filetype%, %discnumber%." ) );

The keywords are non-trivial to translate...

The original issue was that keywords couldn't be used in its translated form. Keywords were translated in the dialog layout, but the parser only worked with keywords in English, it was inconsistent.

So either keep everything in English or make sure everything works with the translated keywords. I think right now Amarok is using the former option, though I believe that the later would be the ideal for non-english speakers.

reproducible with amarok 2.6

Created attachment 83910 [details]
Amarok v2.8.0

It's fixed in amarok v2.8.0

Created attachment 83912 [details]
Amarok v2.8.0

Sorry, my fault. I didn't understand what you talked about. In v2.8.0 amarok use non-translated keywords with translated commentaries.