I'm moving this here from from the QA list. For those who missed the original thread, it's linked from the bug report.
http://bugs.centos.org/view.php?id=3517
-Brandon
Brandon Davidson wrote:
If you look at the spec file for specspo, the string replacement is done with a patch, so it's not just an overeager sed script... but it does seem like some of the replacements are unnecessary.
Other inappropriate translations are present for rhn-client-tools, rhnsd, and rhn-setup-gnome. The mysqlclient10 package also refers to "CentOS 9" instead of "Red Hat Linux 9". I'm sure there are others I'm overlooking.
For the next release, perhaps someone could update the patch to remove translations for upstream packages that have been removed from CentOS, as well as going over the remainder to make sure they all make sense?
On Mon, 6 Apr 2009, Brandon Davidson wrote:
I'm moving this here from from the QA list. For those who missed the original thread, it's linked from the bug report.
Not fixing the subject, sadly. no RPM issue here; possibly a patching strategy issue in specspo
also by you filed at: http://bugs.centos.org/view.php?id=3517
which bug notes at the end:
Packages with inappropriate translations include rhnlib, rhn-client-tools, rhnsd, rhn-setup-gnome, and mysqlclient10. This list is incomplete; the specspo patch is in need of a full review
and a couple more things jump out at me. By and large, I see NO dark art here, requiring that such a review and proposed fix cannot be done by anyone, diffing the present upstream original and the last shipped patches (once CentOS variant SRPMs are retrievable), and ...
frankly, who _cares_ to install packages which ** cannot ** work as upstream does not release the server side sources for the RHN, such that we cannot replicate it (it not being clear that we have a desire as a project to so proceed)
I would apply a 'lazy fix', next time we have occasion to visit the underlying packages, at most
-- Russ herrold
On Apr 6, 2009, at 5:21 PM, R P Herrold wrote:
I would apply a 'lazy fix', next time we have occasion to visit the underlying packages, at most
I would prefer a more active fix such as 1) reasonably designed markup, the PO format is quite clunky. 2) a database schema, using dgettext as a key->value retrieval mechanism has always been arcane and is sadly deficient in 2009. 3) A web infrastucture for distributing RPM pkg summary/description/ group (and for extra credit) any other scalar string identifiers associated with a package. From rpm's client POV, all that is needed is a URL to attempt remote -> local cache for use by all applications that use rpmlib. Use UUID's for additional extra credit.
But be lazy schmuck if you want. ;-)
73 de Jeff
On Mon, 6 Apr 2009, Jeff Johnson wrote:
On Apr 6, 2009, at 5:21 PM, R P Herrold wrote:
I would apply a 'lazy fix', next time we have occasion to visit the underlying packages, at most
** chuckle **
I would prefer a more active fix such as
... snip ... energetic approach outlined
But be lazy schmuck if you want. ;-)
--------------------------------------------
The context on the 'lazy' referent was not surfaced by me but my full remark was this in some discussion off the forum:
But then it seems the text source may reside on some patch we applied to a translation .po [I am in limited compute richness and cannot conveniently run this down presently]
To the extent that upstream has varied from their announced intent (by the trademark guidance piece they put out) of confining the packages needing patches to the initial two [and we ran an effort on this a few cycles back], they earn the confusion themselves. We can chase and locally fix their errors while they move forward, or we can pursue our own agendas
I think our agenda is to use good faith effort, and then fix the issue in the next point release [certainly a leisurely pace toward fixing 'cosmetic errors' essentially matches that policy used toward cosmetic matters upstream]
I do not see mention that a bug was filed, and to the extent that forum answers by 'authoritative answerers' there do not feed the bug tracker, we hide knowledge of possible errors from ourselves by leaving it only in the forum
----------------------------------------------
so, only 'sort of' lazy -- a leisurely one, sort of a copy on write of new updates ;)
-- Russ herrold
On Apr 6, 2009, at 7:32 PM, R P Herrold wrote:
so, only 'sort of' lazy -- a leisurely one, sort of a copy on write of new updates ;)
Well get some slack pink boy! ;-)
But more seriously, distributing package summary/description/group (and other scalar strings) entered my todo++ list at FOSDEM 2009.
I just keep getting distracted ...
73 de Jeff
Jeff Johnson wrote:
But more seriously, distributing package summary/description/group (and other scalar strings) entered my todo++ list at FOSDEM 2009.
I just keep getting distracted ...
Here, have a Gueuze if that gets you going >:D
Ralph
R P Herrold wrote:
On Mon, 6 Apr 2009, Brandon Davidson wrote:
I'm moving this here from from the QA list. For those who missed the original thread, it's linked from the bug report.
Not fixing the subject, sadly. no RPM issue here; possibly a patching strategy issue in specspo
I kept the subject (and hopefully the references too) in hopes that it might keep the threading for anyone that was following it across lists. If you want to change the header, this might be more helpful (and a little less reproachful too).
and a couple more things jump out at me. By and large, I see NO dark art here, requiring that such a review and proposed fix cannot be done by anyone, diffing the present upstream original and the last shipped patches (once CentOS variant SRPMs are retrievable), and ...
Hey, just because I have time to track it down for a user on the forum and file a bug doesn't mean I have time to fix it ;) I agree, though, it doesn't look too difficult to correct the immediate issue. It looks like the original patch is from hughesjr; I'll keep an eye out for the 5.3 SRPMs and submit a patch if I have time.
frankly, who _cares_ to install packages which ** cannot ** work as upstream does not release the server side sources for the RHN, such that we cannot replicate it (it not being clear that we have a desire as a project to so proceed)
My point was that we are providing translations for packages that we don't ship, and contributing to the confusion of users that do install those packages on their own. IMHO the 'right' thing do to would be to make sure that any package listed as removed in the CentOS release notes is also stripped out of the translations.
For bonus points, we could also make sure that any other changes made to descriptions or summaries are synchronized into specspo; this would probably require checking the packages listed in the release notes' modified list, comparing them to what's in specspo, and running them past the translation team as necessary.
This of course assumes that Red Hat keeps specspo relatively up to date with the actual packages' text, which may be a lot to assume.
On Mon, 6 Apr 2009, Brandon Davidson wrote:
R P Herrold wrote:
and a couple more things jump out at me. By and large, I see NO dark art here, requiring that such a review and proposed fix cannot be done by anyone, diffing the present upstream original and the last shipped patches (once CentOS variant SRPMs are retrievable), and ...
Hey, just because I have time to track it down for a user on the forum and file a bug doesn't mean I have time to fix it ;) I agree, though, it doesn't look too difficult to correct the immediate issue. It looks like the original patch is from hughesjr; I'll keep an eye out for the 5.3 SRPMs and submit a patch if I have time.
frankly, who _cares_ to install packages which ** cannot ** work as upstream does not release the server side sources for the RHN, such that we cannot replicate it (it not being clear that we have a desire as a project to so proceed)
My point was that we are providing translations for packages that we don't ship, and contributing to the confusion of users that do install those packages on their own.
It's worth pointing out (again) that we are providing *erroneous* translations. The Red Hat Network *is* the Red Hat Network - there is no CentOS Network, etc.
--- Charlie
-
Brandon Davidson -
Charlie Brady -
Jeff Johnson -
R P Herrold -
Ralph Angenendt