RFC: i18n proposal

Jeff Johnson jbj at redhat.com
Mon Aug 4 17:48:02 UTC 2003


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 at redhat.com (jbj at jbj.org)
Chapel Hill, NC





More information about the devel mailing list