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
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC