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

[Yuan Yijun]

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.)

--
bbbush ^_^

[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...

[Elliot Lee]

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. :)

Best,
-- Elliot

[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

[Nicolas Mailhot]

I honestly think the only scalable solution is in-package translation. It
does not have to be in the spec file, could be in another set of files in
the package, but it can not be pushed out of the package.

All the solutions that push this info out of packages rely on some central
authority, either at the distribution level (specspo) or at the repository
level (yum metadata). These approaches try very hard to ignore the
reality. The reality is people download and assemble packages by all the
ways imaginable, burn them on CDs, create package archive/mirrors, rebuild
tweaked SRPMS, sometimes index them with createrepo at last but the basic
unit is the package and anything not included in the package itself is
bound to be lost.

I know it's an unpalatable reality since life would be so much easier for
translators if they could ignore the distribution problem. Ignore it
however and you'll hit the same dead-end as specspo

What would be possible for example would be to attach a translation to an
existing package like you do for signatures. However great care should be
taken so when you rebuild the package the translation is not lost (ie rpm
-Uvh x.src.rpm adds the translation to SOURCES). This would permit
incremental translation, without breaking the package unit distribution
paradigm.

Regards,

-- 
Nicolas Mailhot

[Miloslav Trmač]

Toshio Kuratomi wrote:
>  Translator Goals:
>  1) Notification of package string changes.
>  2) Ability to own a package-translation similar to how other packagers
>  own a package. 
As a translator, I don't think this is what I want.
1) We already have infrastructure to show translation status, without
   explicit notification.  Explicit notification would just result in
   a lot of daily emails.
All that is necessary is regular (daily/weekly) rebuild of the list of
strings to translate, and a regular incorrporation of translated
messages to the repository (in whatever form).

2) No, I certainly don't want to handle 1237 separate "translation
   packages" in 1237 separate files.
The specspo model of a single file actually suits translators quite well
(e.g. it allows automated translation matching on package renames).
Maybe we could split the large .po file to allow better collaboration,
e.g. to 26 .po files, selecting packages by the first letter of their name.
	Mirek

[Toshio Kuratomi]

On Tue, 2005-11-15 at 18:36 +0100, Miloslav Trmac wrote:
>  Toshio Kuratomi wrote:
>  > Translator Goals:
>  > 1) Notification of package string changes.
>  > 2) Ability to own a package-translation similar to how other packagers
>  > own a package.
>  As a translator, I don't think this is what I want.
>  1) We already have infrastructure to show translation status, without
>     explicit notification.  Explicit notification would just result in
>     a lot of daily emails.
>  All that is necessary is regular (daily/weekly) rebuild of the list of
>  strings to translate, and a regular incorrporation of translated
>  messages to the repository (in whatever form).
>   
Amendment to #1:
1) Listing of package string changes (As translators often work on a
large number of packages, email notification is going to overwhelm
INBOXes.)


>  2) No, I certainly don't want to handle 1237 separate
> "translation
>     packages" in 1237 separate files.you don't want me
>  The specspo model of a single file actually suits translators quite well
>  (e.g. it allows automated translation matching on package renames).
>  Maybe we could split the large .po file to allow better collaboration,
>  e.g. to 26 .po files, selecting packages by the first letter of their name. 
#2 doesn't specify the backend.  #2 specifies that if you are
translating package foo for language hungarian, then you don't want me
to come in and retranslate it.  Do you disagree with this?

But we can add:
3) Ability to edit translations in a single file/location that can be
parsed (if necessary) by the builder into a final form.

[Miloslav Trmač]

Toshio Kuratomi wrote:
>  On Tue, 2005-11-15 at 18:36 +0100, Miloslav Trmac wrote:
>  
> >Toshio Kuratomi wrote:
> >
> >>Translator Goals:
> >>1) Notification of package string changes.
> >>2) Ability to own a package-translation similar to how other packagers
> >>own a package.
> > 
> >2) No, I certainly don't want to handle 1237 separate
> "translation
> >   packages" in 1237 separate files.you don't want me
> >The specspo model of a single file actually suits translators quite well
> >(e.g. it allows automated translation matching on package renames).
> >Maybe we could split the large .po file to allow better collaboration,
> >e.g. to 26 .po files, selecting packages by the first letter of their name.
>  
>  #2 doesn't specify the backend.  #2 specifies that if you are
>  translating package foo for language hungarian, then you don't want me
>  to come in and retranslate it.  Do you disagree with this? 
The general idea of
"owning" the translation is correct, but separating
work per-package is really too much overhead.  "Owning" a block of
packages (on the order of 100 packages, or even more) would be OK.
	Mirek