Bug 102254 - popt messages need explicit domain with dgettext()
popt messages need explicit domain with dgettext()
Product: Fedora
Classification: Fedora
Component: popt (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
Depends On: 249352
  Show dependency treegraph
Reported: 2003-08-12 18:52 EDT by Christian Rose
Modified: 2008-05-06 19:56 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 19:56:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
popt.h diff for "Help options:" gettextize (1.38 KB, patch)
2003-08-25 05:39 EDT, Nakai
no flags Details | Diff
ja.po update which you shouldn't forget to commit with the above patch (2.64 KB, text/plain)
2003-08-25 05:42 EDT, Nakai
no flags Details

  None (edit)
Description Christian Rose 2003-08-12 18:52:35 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):

"Help options:"

"Show this help message"

"Display brief usage message"

These messages are not to be found in the kudzu sv.po in CVS either.
Comment 1 Bill Nottingham 2003-08-12 22:57:07 EDT
Those messages come from popt.
Comment 2 Bill Nottingham 2003-08-13 00:25:27 EDT
Actually, since those messages are wholly contained within popt, I don't see how
this can be fixed.
Comment 3 Christian Rose 2003-08-13 06:22:08 EDT
I'm not sure I understand -- are these messages impossible to localize in popt?
In that case, that would be a serious popt problem.
Comment 4 Bill Nottingham 2003-08-13 11:22:02 EDT
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.
Comment 5 Christian Rose 2003-08-13 17:28:56 EDT
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.
Comment 6 Bill Nottingham 2003-08-13 17:39:15 EDT
Hm, yes. That would be something that would have to be solved in popt, not kudzu.
Comment 7 Christian Rose 2003-08-13 18:26:05 EDT
Yes, changing summary.
Comment 8 Jeff Johnson 2003-08-19 09:48:35 EDT
Hmmm, popt already specifies the domain "popt" explicitly using

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

Back to kudzu ...
Comment 9 Göran Uddeborg 2003-08-21 19:47:44 EDT
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!
Comment 10 Christian Rose 2003-08-22 07:15:15 EDT
Is this related to bug 102798?
Comment 11 Bill Nottingham 2003-08-22 11:18:46 EDT
Yes. AFAIK, it's the same thing.

*** This bug has been marked as a duplicate of 102798 ***
Comment 12 Nakai 2003-08-25 05:38:22 EDT
"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.)

Comment 13 Nakai 2003-08-25 05:39:42 EDT
Created attachment 93896 [details]
popt.h diff for "Help options:" gettextize
Comment 14 Nakai 2003-08-25 05:42:41 EDT
Created attachment 93897 [details]
ja.po update which you shouldn't forget to commit with the above patch
Comment 15 Jeff Johnson 2003-09-28 19:30:33 EDT
Adding the patch breaks ABI compat. Reopen and assign
to distribution, not popt, if you wish to argue.
Comment 16 Nakai 2003-09-29 07:05:51 EDT
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.
Comment 17 Jeff Johnson 2003-09-29 14:28:45 EDT
This is no longer a popt problem, but a larger issue.

Reassigning owner.
Comment 18 Bill Nottingham 2003-09-29 16:40:57 EDT
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.
Comment 19 Nakai 2003-09-30 02:12:15 EDT
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.
Comment 20 Bill Nottingham 2005-03-02 14:01:54 EST
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. 
Comment 21 Jeff Johnson 2007-01-13 09:17:48 EST
Fixed in rpm cvs, should be in popt-1.10.8-0.10 when built.

Comment 22 Robert Scheck 2007-08-09 14:28:33 EDT
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.
Comment 23 Göran Uddeborg 2007-08-10 12:00:28 EDT
I don't quite understand comment 22.  Popt for F7 is 1.10.2-46.fc7 and for
F8test1  Is there a later rpm somewhere I could install and try?
Comment 24 Robert Scheck 2007-08-10 12:09:34 EDT
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.
Comment 25 Göran Uddeborg 2007-08-10 17:45:32 EDT
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.
Comment 26 Red Hat Bugzilla 2007-08-21 01:17:29 EDT
User pnasrat@redhat.com's account has been closed
Comment 27 Panu Matilainen 2007-08-22 02:34:21 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 28 Robert Scheck 2007-08-23 19:20:19 EDT
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.
Comment 29 Bug Zapper 2008-04-03 11:29:26 EDT
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.
Comment 30 Bug Zapper 2008-05-06 19:56:53 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.