Ubuntu

Organise Files dialog, keywords aren't translated

Reported by m4v on 2009-06-20
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Amarok
Confirmed
Medium
amarok (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: amarok

When organising files using the "Organise Files" dialog (right click in any file in your collection) with a spanish locale (I guess is the same in other locales) and in the avanced mode, there's a summary of keywords I can use, they are all translated in spanish ( %artista, %año, etc), but the ones I have to use in the text box must be in english (%artist, %year, etc) see the attached screenshot.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: amarok 2:2.1.1mysql5.1.30-0ubuntu1~jaunty1
ProcEnviron:
 LANGUAGE=es_AR:es
 PATH=(custom, user)
 LANG=es_AR.UTF-8
 SHELL=/bin/zsh
SourcePackage: amarok
Uname: Linux 2.6.28-13-generic x86_64

m4v (m4v) wrote :
Andrew Ash (ash211) wrote :

Thanks for the bug report, m4v. This internationalization bug should be reported upstream on bugs.kde.org

I'm confirming this bug in Ubuntu now.

Changed in amarok (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in amarok:
status: Unknown → New

Version: amarok 2:2.1.1mysql5.1.30-0ubuntu1~jaunty1 (using KDE 4.2.4)
OS: Linux
Installed from: Ubuntu Packages

[Forwarded from Ubuntu bug 390062 -- https://bugs.edge.launchpad.net/ubuntu/+source/amarok/+bug/390062]

When organizing files using the "Organise Files" dialog (right click in any file in your collection) with a Spanish locale (I guess is the same in other locales) and in the avanced mode, there's a summary of keywords I can use. They are all translated in Spanish ( %artista, %año, etc), but the field only accepts English keywords (%artist, %year, etc). See http://launchpadlibrarian.net/28156768/amarok_organise_dialog.jpeg

The solution would be to have the keywords in the QLineEdit be translated when they are used to determine paths to organize files to.

Myriam Schweingruber (myriam) wrote :

Andrew, I very much doubt this is a problem in KDE itself, more likely to be a bad translation import in Kubuntu, so reporting translation issues upstream is not really useful in this case AFAICT. This should change in 9.10, hopefully.

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

Changed in amarok:
status: New → Confirmed

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.

Changed in amarok (Ubuntu):
status: Confirmed → Triaged
tags: added: i18n kubuntu

Setting the version to git.

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

Changed in amarok:
status: Confirmed → Fix Released
Mackenzie Morgan (maco.m) wrote :

Organise Files dialog no longer exists, so closing this report

Changed in amarok (Ubuntu):
status: Triaged → Invalid
Changed in amarok:
importance: Unknown → Medium
m4v (m4v) wrote :

Using Amarok 2.3.2 and the Organise Files dialog does still exists, dunno... reopening as keywords are still unstranslated.

Changed in amarok (Ubuntu):
status: Invalid → Confirmed

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?

Changed in amarok:
status: Fix Released → Confirmed

*** 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
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
Amarok v2.8.0

It's fixed in amarok v2.8.0

Created attachment 83912
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.

Rohan Garg (rohangarg) wrote :

Fixed in Saucy and Trusty

Changed in amarok (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.