On Fri, Aug 01, 2003 at 12:22:30AM +0200, Göran Uddeborg wrote:
Jeff Johnson writes:
If the intent is to have one domain per-package, the current implementation already supports this.
I start to feel, during this discussion, goal and implementation has become a bit confused. I'm surely guilty, starting my posts by an attempt to suggest an implementation of my interpretation of Havoc's suggestion.
Yup, add LSB packaging standard, very hard to not be confused.
I'll try to clarify MY goals.
As a RHL user I want
the description (etc.), including translations, come, change, and go with the package. I don't want them to be modified when a different, technically unrelated, package is modified.
Having one domain per package and including that domain with the package, is one way to implement that. Having all descriptions in the meta-data is another way. There are surely other ways.
All agreed, although "domain" is dangerously close to implementation.
As a packager of third party packages I want
an easy way to maintain the description, and to receive translations of it.
That was why I thought around having rpmbuild pick up translations at build time from po-files laying around. If I also am the author of the software I package, it would be convenient to put all messages from the program(s) proper and the spec file description in one po file and make that available for translation. (Doing some kind of "gettext" on the spec file.) If I package someone elses software, it would be more reasonable to provide a separate po file for translators.
Manually copying translations back and forth between po files and spec files is not very convenient, obviously.
Also agreed, and noted that you (and Havoc) are also interested in the general problem, not just i18n for description/summary/group.
I am mainly concerned about rpm package format changes, as retrofitting Yet Another Solution (the next will be like my 5th attempt to get it right, sigh) into package format is not fun at all.
Other than package format changes -- a topic that I'm no longer sane about -- I'm perfectly prepared to admit that rpm currently serves neither of your goals above well, and would like to do something better.
As a translator of RHL descriptions (a.k.a. "specspo") I want
the descriptions be available in a format which is easy to translate and maintain.
Yup, must be *.po, and I'll wave my hands about "implementation".
The current specspo is fine for this! (It is huge, and took a long time to do. But that would not have been different with some other packaging.)
I'll take that as complement, just trying to do my job. Truly, what makes specspo possible -- msghack -- is a very, very tortured implementation. And implementation credit is gafton, idea was/is mine.
As a translator of other's third party packages I want
the same thing as for RHL packages, a convenient format.
Of course I would expect to get it individually for each package, and not collected together with other unrelated packages. But po files are good again.
We agree that *.po is only conceivable (i.e. works/useful/adequate/your_criteria_here)?
(implementation aside) Hacking xgettext quite possible. xgettext already knows about C and shell syntax, not hard at all to teach xgettext about *.rpm, no parsing needed. I do shudder when considering a dependency gettext -> librpm*.so, but a parallel implementation is quite sensible and doable. In fact, suggested to Drepper years ago, but there was little need.
That's several "I want"s. I'm not saying one solution should fullfill all, and I'm not at all saying they MUST be fullfilled before any other problem. But if one of them could be fulfilled, it would be better than none.
I want the same things as you, with the further constraint: I want what you want. Nothing you have suggested is unreasonable or outlandish imho.
a) configure the new translation domain in /etc/rpm/macros.specspo (or any of the zillions of places that a macro can be defined) %_i18ndomains redhat:foo
Do you envisage some way to do this automatically on (un)installation of packages? So that each package can carry it's own translations? Or just a different default value coming with the same specspo package still carrying all translations? That's would be important given my first point above. And I'm not sure exactly what you are suggesting.
Sure, macros are easily changed into something more robust. In fact, that's what macros were intended for, a lightweight and cheap, proof-of-concept, prototyping mechanism.
Note carefully that doing a) differently involves changing the rpm implementation, not the rpm package format, my only concern.
Note also that additions, like adding a domain tag to metadata, are quite doable, as long as the legacy issues of fallback can be addressed in the rpm implementation adequately.
Replacing and/or changing existing implementation is what gives me hives.
73 de Jeff