Thanks for taking the time to translate Banshee. I don't think this is a bug per se. Can you try asking on the mailing list and seeing if you can get the information you need? If you still think there is a missing feature or something isn't working right, we can reopen this.

When we, translators, don't find enough context to translate something, we open a bug here to ask for it. Is the way it works.

Imagine we had to join every single mailing list for every project hosted at GNOME svn ;)

this is a valid bug report about a string that is hard to translate.
aloriel, for future reference feel free to add the keyword "L10N" to such reports.

Also :

#: ../src/Core/Banshee.ThickClient/Banshee.Gui/InterfaceActionService.cs:181
msgid "ActiveSourceUIResource"
msgstr "ActiveSourceUIResource"

Also:

msgid "GenericName"
msgid "FilterQuery"
msgid "TrackView.ColumnControllerXML"
- Same as above

msgid "Listen to the Last.fm {0} station for this artist"
- What does {0} refer to?

Please please answer this and add the appropiate comments to the sourcecode before the 1.0 release. Also, I am not quite sure about how to translate the search query keywords ("skipped", "skippedon", "addedon", "released", "filesize" etc.)... Are translators even supposed to translate them? If so, what if there are more words for the same thing in the language being translated to than in English? Should we pick the most important then? What if there are less? Should we double some then?

This also applies to trunk. Updating and raising severity. It seems the Banshee devs are just ignoring this. Let's slap them with BLOCKER ;)

It seems some of the strings are actually not meant to be translated (and likely won't be used either), e.g.

  string controller_xml = source.Properties.GetString ("TrackView.ColumnControllerXml");

I think intltool/gettext sees the GetString(...) stuff and extracts the string, while this is not the Catalog.GetString() but some (completely unrelated) GetString() method that only shares the same local name (but is in fact in a different namespace).

Not sure how to fix this actually, apart from renaming the internal GetString() method (ugly, but it works).

So now that we (likely) know why these strings turn, and that they're harmless but still annoying, this is no longer a blocker ;)

Not a Banshee bug.

Comment #5 contains a Banshee question, quoted below:


msgid "Listen to the Last.fm {0} station for this artist"
- What does {0} refer to?

Please please answer this and add the appropiate comments to the sourcecode
before the 1.0 release. Also, I am not quite sure about how to translate the
search query keywords ("skipped", "skippedon", "addedon", "released",
"filesize" etc.)... Are translators even supposed to translate them? If so,
what if there are more words for the same thing in the language being
translated to than in English? Should we pick the most important then? What if
there are less? Should we double some then?

Moved this bug to Banshee again. Note that what I said in #7 should be a separate intltool/gettext bug, not this one.

Moving this back to intltool, since the string this bug was filed for was marked for translation incorrectly.  We have a GetString method on a class not related to translation, and its arguments should not be marked for translation.

If you, translators, have other strings that do appear valid but you need more context (eg comments #5 etc) you need to open separate bugs.  Thanks!

(After some discussion on IRC...)

(In reply to comment #12)
> If you, translators, have other strings that do appear valid but you need more
> context (eg comments #5 etc) you need to open separate bugs.  Thanks!

Done, see bug #545239.

moved comment #5 to http://bugzilla.gnome.org/show_bug.cgi?id=545239#c2 , because all other issues here are gettext/intltool related.

Marked as a duplicate, as you've already filed a request about GetString, yet provided no additional information, after it had been commented on.

*** This bug has been marked as a duplicate of 536445 ***