GNOME Bugzilla – Bug 120605
Strings from mp.c
Last modified: 2004-12-22 21:47:04 UTC
I've just added a Danish translation of gcalctool. There are, however, a number of strings in mp.c that look like old Fortran error messages to me: > #: gcalctool/mp.c:181 > msgid "" > "*** SIGN NOT 0, +1 OR -1 IN MPADD2 CALL.\n" > "POSSIBLE OVERWRITING PROBLEM ***\n" > msgstr "" > > #: gcalctool/mp.c:457 > msgid "*** N .LE. 1 IN CALL TO MPART1 ***\n" > msgstr "" Are they really meant to be user visible strings? If so, they should be reformulated quite heavily, I think. But most of them look like assertions to me, which shouldn't be marked for translation (they are a tool for developers, not for users).
Hi. They were indeed originally FORTRAM debugging strings. Note that the user will not see any of these strings unless they run gcalctool with the -E command line option (not turned on by default). In fact there is a another whole set of strings that aren't turned on unless the user started gcalctool with the -D command line option (again, not turned on by default). In fact, there are very few strings in gcalctool if you take away those two sets. I don't consider this a bug, and am going to close it as such. If you feeling strongly otherwise, please reopen it, and convince me. ;-)
Hm, the point I'm trying to make is that either a) Those strings are really supposed to be for an end-user. In that case, the fact that it is difficult to get to them isn't really important, is it? They should be high-quality anyway. b) Or those strings aren't really for an end-user. In that case, they should not be marked for translation. I don't think you're quite realizing what it means when these strings end up in the .po files for _all_ of your translators. That means that we _must_ to do something about them - else maintaining the .po file gets unmanageable. But how are we supposed to translate old Fortran stuff like that? I had a look in the gcalctool man page. It seems that -D and -E are for debugging purposes. If that is the case, I think not having those strings translated is perfectly fine. Having less strings is also a plus. The more you can cut down on the number of strings in gcalctool, the easier it becomes to translate/maintain gcalctool and the happier we are, even if it means some work has been wasted.
Okay. You've convinced me. I think I'm too late to fix this for 2.4, so I'll work on it for the next release. Can you tell me how I go about marking it in such a way that it doesn't get translated? Thanks.
Yeah, sure, thanks a lot for looking at it. First, if it is on a file level, a very quick way is to go to po/POTFILES.in and delete the relevant filenames. That's an absolutely safe thing to do, and will ensure that the .po files don't contain the strings on next update. But you should probably also search for uses of the _(str) macro and delete the _(). For instance FPRINTF(stderr, _("*** N .LE. 1 IN CALL TO MPART1 ***\n")); becomes FPRINTF(stderr, "*** N .LE. 1 IN CALL TO MPART1 ***\n"); Else gettext will be called unnecessarily. The _() both triggers a call to gettext and marks the string for translation to the string extractor tool. If it is still on a file level, and you don't want to bother go about removing the _(), the filenames should be added to po/POTFILES.skip. Else, someone is likely to readd the filenames to po/POTFILES.in. OK?
Indeed. Many thanks for taking the time to explain this. Look for a fix in the next release (after GNOME 2.4).
Changes to fix this just checked in CVS HEAD. Fixed in v4.3.4 of gcalctool.