How to simplify the process of adding multilingual %descriptions to rpm spec?

[Mike A. Harris]

Yuan Yijun wrote:
> Greetings,
> 
> I believe that non-English speakers will be more happy to see
> localized package %descriptions, when they are using a GUI package
> management program. Most of users play Linux for fun, and they are
> willing to search software in the huge packages list, looking for
> interesting packages to install. But this fun only belongs to English
> speakers. To Chinese, there is no way for an software package to
> introduce itself.
> 
> Then how can these %descriptions be localized? If someone translate
> them and commit patches to rpm spec files, that seems a bit funny and
> boring. (Sorry for my bad vocabulary, though the single filed rpm spec
> does have its cons and pros.) How to simplify this and reduce the
> amount of work?
> 
> (There are too many excellent programs in both Core and Extras, while
> I'm trying to introduce them to other Chinese users, I believe this
> problem is essential.)

This is a rather IMHO complex problem to solve in an a way that
ends up "good" for the package maintainer, the user, and from
a software perspective too.

One solution, is to put translated descriptions into each
spec file.  That centralizes everything, but when the English
description changes, the translations are instantly out of date.
Plus, since the spec files are centrally controlled, translators
do not have CVS access to them.  There are other problems with
this method as well, and I think everyone more or less agrees
that this soluton is unacceptable overall.

Another solution, which was used in Red Hat Linux days, was a
separate package named "specspo", which contained the translations
for every package's descriptions, etc.  This was maintained in
a separate CVS repository which was publically accessible, and
so translators around the world could update the specspo
translations as necessary, without the main rpm package having
to be touched.  The disadvantages of this approach, were that
it was the responsibility of every rpm packager to update the
english entries of their packages "%description" fields and
whatnot, every single time they changed, or whenever a new
one was added or removed, or a new rpm added.  This meant double
the work for every engineer any time a package description needed
to be changed/etc.  The process of updating specspo was also
very cryptic and non-friendly, and involved hand editing a cryptic
file that was incredibly lengthy.  Very unweildy and time consuming
in general.  Also, this solution was bad because it relied on
human intervention to actually remember to do these specspo
updates, and not forget or make mistakes.  If a human mistake
was made, then the English description and translated description
would be out of sync.

In short - specspo sucks.

IMHO, the best way for this problem to be solved is for there to
be a new solution/process to be created to solve this problem,
and for there to be real software tools that automate every step
of the process on both the engineering side, and the translator
side.  Ultimately, a package maintainer really should only ever
have to edit the spec file, and from there, automated software
tools should do the rest.

I don't have a specific proposal for how we might implement this
solution, but I think the idea is worthy at least, so I thought
I'd offer it as a suggestion.

Whatever is chosen as a solution, I believe it only stands a
chance of succeeding, if it is given sufficient resources and
manpower to see it completed with an eye towards making this a
total breeze in the long term, with computers doing most of
the work, and humans doing as close to nothing as is possible.

It shouldn't be that hard for a tool to pull the spec file out
of CVS on checkin, diff it for changes to descriptions, etc.
and pull them into something visible by translators.

Just a thought...