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

[Toshio Kuratomi]

On Mon, 2005-11-14 at 15:04 -0500, Elliot Lee wrote:
> On Tue, 8 Nov 2005, 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.)
> 
> Currently, specspo is meant to be the means by which package strings are
> translated. However, specspo has not been maintained in a long time and
> could use a lot of love. If someone wants to pick it back up, the work
> that needs to be done is a fairly well understood problem. It's just a LOT 
> OF WORK. :)

For Extras (with it's rolling release), specspo's issues are more
pronounced than in Core.  Core has a string freeze before release that
Extras (which doesn't have a "release") lacks so translations would get
out of sync.

End-user Goals:
1) See package descriptions in the user's native language.
2) End-users don't end up downloading an update just because the
translations change.
3) End-users don't end up downloading updated specspo because
translations for a language/package they don't use is updated.

Packager Goals:
1) Transparent.  The packager does not have to think about translations.
They just happen.

Translator Goals:
1) Notification of package string changes.
2) Ability to own a package-translation similar to how other packagers
own a package.

Packager and translator goals seem like they could be solved with good
infrastructure.  Add a check for string changes into make build or make
tag that extracts necessary information and hands them off to a
translation system that emails translators of changes, updates websites,
etc.

The end-user goals point at the drawbacks of both in-package
translations and the specspo centralized translations.  Alternatives
that spring to mind: 

perpackage-perlanguage specspo.  No more downloading of unnecessary
files but it seems pretty darn unattractive.  Lots of rpm metadata
overhead, multiple new packages for each existing package...  Just say
ick.

Auto-merging of translations at make build if the description hasn't
changed:  translations are kept separate from the spec file.  When make
build is run, if the spec %description has been updated, a message is
sent to the responsible translator to update.  Otherwise the translation
is merged with the spec file and the build started.  Translations will
always lag packaging changes, but this works when %description doesn't
change too often.  Could be annoying to end-users who read a description
of one version of a package in their native language but when they go to
install on another machine, the description is in English (because the
English description was updated.)

perlanguage specspo.  The end user still has to keep it updated anytime
a description changes.  The package could be rebuilt on a time/change
basis (ie: once a month when changes occured in that month.)

Talk with Seth about pushing the issue out to rpm-metadata.  End-users
are already downloading new versions of the metadata anytime a string
changes.  rpm-metadata aware applications (yum, yumex, smart) will be
the most frequent interfaces to the packages and could see the
translations (but rpm would not).  Would localized versions of the
metadata (in separate language files) cause issues?  Currently
createrepo creates the rpm-metadata by parsing the packages.  If the
translations weren't in the packages then this is a significant
departure....

Any other ideas?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051115/62f48ac2/attachment.sig>