Red Hat Bugzilla – Bug 102254
popt messages need explicit domain with dgettext()
Last modified: 2008-05-06 19:56:55 EDT
Tested with RHL 9 and sv_SE.UTF-8 locale.
When I run /usr/sbin/kudzu --help I get the following items *not* translated
into Swedish (all other messages are shown translated):
"Show this help message"
"Display brief usage message"
These messages are not to be found in the kudzu sv.po in CVS either.
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.
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
bash$ nm libpopt.so.0.0.0 | grep gettext
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
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
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.
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.
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 126.96.36.199-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
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 firstname.lastname@example.org'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:
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: