Bug 436941 - rpm does not translate descriptions of packages
rpm does not translate descriptions of packages
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-11 05:58 EDT by Stepan Kasal
Modified: 2009-02-24 15:52 EST (History)
4 users (show)

See Also:
Fixed In Version: 4.6.0-1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-05 09:10:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch (almost) (2.09 KB, patch)
2009-01-19 10:50 EST, Stepan Kasal
no flags Details | Diff

  None (edit)
Description Stepan Kasal 2008-03-11 05:58:35 EDT
Description of problem:
When a non-English locale is set, rpm should use the gettext catalogue from
specspo to translate the summary and description of the package.
But it doesn't--observe:

   LC_ALL=cs_CZ.UTF-8 rpm -qi man-pages

and compare to

   LC_ALL=cs_CZ.utf-8 yum info available man-pages

or to the description in the "Search" tab in pirut.

Version rpm-4.4.2.3-0.1.rc1, reproducible always.

(The problem seems to be in function i18nTag, which does not translate tags
retrieved from the rpm database.)
Comment 1 Bug Zapper 2008-05-14 01:56:31 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Stepan Kasal 2009-01-19 10:50:48 EST
Created attachment 329357 [details]
patch (almost)

This diff roughly indicates how rpm should use gettext.

The patch is not usable as such; it contains at least one obvious memory leak.
Comment 3 Stepan Kasal 2009-01-19 11:46:27 EST
Actually, I'd like to make even more radical proposal:

Could we remove the specspo-using code completely?

Rationale:
1) This bug, though present in rawhide for about one year, have not brought much attention among end-users.

2) The now-popular layers over rpm (e.g. yum) does the translation on their own. Does rpm have to contain another implementation, which has end-user base close to null?

3) If you try "LC_ALL=pl_PL.UTF-8 rpm -qi gawk", you can see that the only translated strings are dates; the names of the fields are not translated. To fix this properly, rpm would have to contain some code to format the ASCII-art table after translating the field names. Is this worth the fuss? Wouldn't it be more useful to fix at least the -qi output to that it is always the same and easily parsable?
Comment 4 Jeff Johnson 2009-01-20 09:15:53 EST
There is nothing forcing anyone to use specspo with RPM. Removing
the spescpo package (or equivalently unconfiguring from RPM) and
specspo will not be used.
Comment 5 Jeff Johnson 2009-01-20 09:50:29 EST
Note that the patch in comment #2 misses an essential point, that the msgid's
needed to be changed as well as the msgstr's without upgrading a package.

Sure abusing en_US is a sick hack, always has been.

But using tag content from packages as msgid is an insufficiently general solution
because it locks the msgid stringsn into package metadata, forcing a rebuild and
upgrade whenever the msgid text is to be changed.
Comment 6 Panu Matilainen 2009-01-23 08:18:15 EST
(In reply to comment #3)
> Actually, I'd like to make even more radical proposal:
> 
> Could we remove the specspo-using code completely?
> 
> Rationale:
> 1) This bug, though present in rawhide for about one year, have not brought
> much attention among end-users.

Indeed, nobody seems to care.

> 2) The now-popular layers over rpm (e.g. yum) does the translation on their
> own. Does rpm have to contain another implementation, which has end-user base
> close to null?

Another way to look at it: does it make sense for every single tool above rpm to implement their own translation when it could be done just once in rpm?
The way rpm expects specspo to be arranged is indeed pretty sick, possible alternatives:

a) Just look up by the actual string in the package, like the patch in comment #2 does, which makes it work for current Fedora specspo

b) Look up translations by pkgname(tag), ie in the way rpm currently does the look-aside through en_US, but going directly to the translations, and change specspo to match this. This would avoid all the translations breaking by somebody changing a single character in the main package, but might make translators life slightly more difficult.

Of course, b) would break yum's own translation mechanism as it is now... 

> 3) If you try "LC_ALL=pl_PL.UTF-8 rpm -qi gawk", you can see that the only
> translated strings are dates; the names of the fields are not translated. To
> fix this properly, rpm would have to contain some code to format the ASCII-art
> table after translating the field names. Is this worth the fuss? Wouldn't it be
> more useful to fix at least the -qi output to that it is always the same and
> easily parsable?

Translating the field names is a whole other topic... feel free to file a bug at rpm.org, it's certainly more of an upstream than RH-specific issue.
Comment 7 Panu Matilainen 2009-02-05 09:10:36 EST
Oh well... I patched rawhide rpm according to specspo expectation (similar to your patch in comment #2), treating it as a Fedora specific patch at least for now:

[pmatilai@localhost ~]$ rpm -q rpm
rpm-4.6.0-0.rc4.4.fc11.x86_64
[pmatilai@localhost ~]$ LC_ALL=cs_CZ.UTF-8 rpm -q --qf "%{description}\n" man-pages
Velká sbírka manuálových stránek (dokumentace) z Linux Documentation
Project (LDP)
Comment 8 Fedora Update System 2009-02-24 15:51:53 EST
rpm-4.6.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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