GNOME Bugzilla – Bug 536445
Calls to random object.GetString ("...") pulled out as translatable
Last modified: 2012-03-16 12:40:13 UTC
In Banshee, we have a GetString method in some class of ours, and all calls to it have their string literals pulled out as translatable.
If the corresponding file contains no translatable strings, you can put it in POTFILES.skip. But if in the same file, there are GetString that gettext should catch and others that it shouldn't, I'd say you'd better change the GetString function name in your class!
*** Bug 503844 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > If the corresponding file contains no translatable strings, you can put it in > POTFILES.skip. > But if in the same file, there are GetString that gettext should catch and > others that it shouldn't, I'd say you'd better change the GetString function > name in your class! This isn't really an ideal solution for us. We do have files that have translated strings and our own GetString calls.
Ugh, looking at MonoDevelop's code, they have enough other non "Catalog." GetString calls that they do want translated, that maybe we should just rename our method.
Well, there is no way for us to be sure that the object which GetString is being called on, is actually a gettext object. If we just outright removed the GetString check in intltool-update, I'm sure that you would also end up on the flip side, because intltool would fail to complain about files that contain strings marked for translation, which aren't in POTFILES.in. If there were some way to actually determine the object's type though, that would be a huge benefit. Of course, I think if you had a GetString method for a C++ class, you'd possibly end up with the same issue as here.
Yeah, after looking at MonoDevelop's code, I think changing the current behavior will lead to an even bigger world of pain. I changed our local methods, and am fine if you want to close this invalid/wontfix or whatever.
It is a bug, but basically unsolvable unless you rewrite intltool/gettext to do very evil things like compiling/linking/introspecting stuff (if possible at all). INVALID sounds sane to me ;)
I don't think it's INVALD. There is certainly validity, otherwise we wouldn't be agreeing that it's a problem. If I were to close it, WONTFIX would be better. Though a CANTFIX would be nice to have. There is probably some way to do what needs to be done for this to work. However, I am not sure what that would be right now. It would require traversing the code to discover the type of an object. Of course, if there are mixed GetString() calls in a file (those that are gettext, and those that aren't), we still have the issue of gettext pulling those strings out. We don't do anything special in intltool for extracting those messages into the pot file. That's done directly by xgettext.
intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009. I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping. Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.