Those messages come from popt.

Actually, since those messages are wholly contained within popt, I don't see how
this can be fixed.

I'm not sure I understand -- are these messages impossible to localize in popt?
In that case, that would be a serious popt problem.

You can only have one textdomain at a time, AFAIK, so even if they're translated
in popt, you can't get to the popt translations from another translated program.
ICBW, though.

As I understood it, that seems to be exactly what dgettext() was used for -- to
allow for using translations from another domain, and commonly used in libraries.

Hm, yes. That would be something that would have to be solved in popt, not kudzu.

Yes, changing summary.

Hmmm, popt already specifies the domain "popt" explicitly using
dcgettext():

bash$ nm libpopt.so.0.0.0 | grep gettext
         U dcgettext@@GLIBC_2.0

Back to kudzu ...

Jeff, this happens with "rpm --help" too.  (rpm-4.2.1-0.11 and popt-1.8.1-0.11)
 All the option descriptions except the ones from popt are translated.

I updated my checkout and looked a little.  The first observation was that the
string "Help options:" is not marked for translation, and does not appear in the
po files.

The other two strings are trickier.  It appears like they should have been
translated.  They exist in the po file.  Their translation depends on the
existense of a symbol HAVE_DCGETTEXT, and I seem to remember we discovered some
problem with a similar construction in rpm proper some time ago.  But this does
not appear to be the same it appears, it is the dgettext call which gets
substituted correctly.

And still, the strings are not translated!  Not for rpm either!

Is this related to bug 102798?

Yes. AFAIK, it's the same thing.

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

"Help options:" translation need other fix besides #102798.

POPT_AUTOHELP macro has a message and it needs to be gettextized.
(GNOME apps use poptHelpOptions in libgnome so this bug doesn't appear.)

Created attachment 93896 [details]
popt.h diff for "Help options:" gettextize

Created attachment 93897 [details]
ja.po update which you shouldn't forget to commit with the above patch

Adding the patch breaks ABI compat. Reopen and assign
to distribution, not popt, if you wish to argue.

When did we start to need to mind ABI issues for non-Enterprise version?

This bug should be fixed up at some points of future popt versions,
anyway. This is annoying all softwares depending on popt so much.

This is no longer a popt problem, but a larger issue.

Reassigning owner.

A larger issue?

A library changed ABI without changing soname. That's bad.

If it changes soname, we can rebuild things that need it, but that will take a
while, and obviously couldn't be done in the tight RHEL3 timeframe.

So don't fix for RHEL3.
But fix for other future version of popt.
To fix with rpm 4.3 or other new rpm version might be sane.

This bug report is not a request for RHEL3 or other Red Hat's business line.

Bouncing back to rpm; either the patch can go in and the soname
changes, or it should stay out and this should be closed. Either or. 

Fixed in rpm cvs, should be in popt-1.10.8-0.10 when built.

UPSTREAM

Well...this issue already should be fixed in the popt package I added for my 
review request. It would be nice, if somebody could try the popt package I 
added to my review request and close this bug report if everything works with 
this package. Thanks.

I don't quite understand comment 22.  Popt for F7 is 1.10.2-46.fc7 and for
F8test1 1.10.2.1-1.fc8.  Is there a later rpm somewhere I could install and try?

Yes Göran, see bug #249352 - there's popt 1.12 attached. But you would have to 
rebuild the package first. If needed, I can do a mockbuild of the package for 
you if you let me know whether F7 or F8 is needed.

I can rebuild it myself, no problem.

But it didn't make any difference for me.  It seems my kudzu links popt
statically, so it's not a good test case.  At least popt didn't show up on an
ldd.  But I tried with eog instead, which does link popt dynamically.  And "popt
--help" still gives "Show this help message" untranslated, although other flags
are translated.  And this string does exist in
/usr/share/locale/sv/LC_MESSAGES/popt.mo

So unless there is something more to this than just rebuilding and installing
your popt-1.12-1, it does not seem to be enough.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

I've added a backport from CVS which should contain a fix for this issue, but 
from my look to it, this doesn't solve the problem really. Popt 1.12-3 will be 
available in Rawhide soon, feel free to test and comment.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp