Bug 436941

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

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.

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?

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.

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.

(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.

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)

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.