RFC: i18n proposal

[Enrico Scholz]

[ f'up2 to rhl-devel; the starting point of this thread is available at
  http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ]

hp at redhat.com (Havoc Pennington) writes:

> On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote: 
>> 
>> Other thoughts or comments?
>> 
>
> Probably works for now (we've been doing it forever), but in the end
> the only right thing has to be that translations are part of the
> package being translated.

I see a problem in the maintenance of these translations. With the
specspo approach, there is one big .po-file which is updated by the
translators. When making the translations a part of the package, there
will be either thousands of small .po-files on the distribution side
(Fedora, Red Hat) or the package author has to maintain his .po files
himself.

IMHO, the latter option will not work because this will result in a
maintainance nightmare: since there are not enough translators, every
translator has to look after several packages, has to communicate
with the author and the author has to release packages with updated
translations very often. And this for every language...


So, there stays only the thousands of small .po-files case where the
translator has to choose one of them. Clicking hundreds of time in the
browser to download the files sounds very annoying and error-prone to
me.

Sure, you can hide this complexity with tools but such tools must be
written first and it will need a lot of work to make them as powerful
like the current solutions (e.g. the Emacs po-mode).

Another advantage of the big .po file is, that common strings
(e.g. group-names) need do be translated once.



> Say you are using redhat-config-packages or another package tool. You
> see a list of packages. You should see nice user friendly names of
> those packages in your own language

Ok; but I do not think that this is a matter of translations. To make
this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which
defaults to the value of 'Name:' must be created. This new tag can be
added to the fields going to be translated.

But I think, only a few packages will profit from this; e.g. consider
the 'docbook-style-*' packages. What will you use for 'LongName:'? When
using e.g. _("docbook tools") the package-tool will present dozens of
_("docbook tools") and user is forced to enable either the raw-view or
to look at 'Summary:' to see which package it is.


> Also you want translated descriptions of course.
>
> I see no way to reliably do this using specspo. You have to somehow
> bundle the translations into the RPM package, and also install them
> when the RPM is installed.

You are right; specpo has disadvantages. E.g. you will have to download
the several mebibytes sized package for every small change in the
translation. There is a time-gap between package- and specspo-release
also.


> Otherwise mixing packages from different sources (including different
> OS versions) *will* break.

IMHO, this is not a big problem. The average user (who wants/needs
translations), will use the big repositories (the upcoming Red Hat
Linux Project, Fedora, Freshrpms, ...) which can provide their
specspo-packages.

There is an issue with rpm that is not easy to "register" such packages;
but for now, this can be solved with some %triggers and Jeff is open for
ideas how it can be improved in "better" ways.


> One approach would add a "PoFilesDir: foo" field to spec files, ...

Very interesting idea. Because I do not like decentralized maintainance
of po-files, I would apply it in the following way:

* The build-hosts of the repositories which are maintaining the translations
  are "authoritative" regarding translations. "authoritative" means that
  there are global macros like

  | %_i18n_update_pofiles       1
  | %_i18n_translation_domain   fedora-i18n

  This i18n domain is maintained in the current way: there is a big .po
  file for every language, translators update it through cvs and release
  manager compiles it to a .mo-file.

* while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package
  gets

  - a tarball with *.po-files containing the trasnlated strings of the
    package
  - a tag like 'PoSources: <tarballname>'

  non-authoritative hosts will not touch this tarball or tag.

* when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the
  operations mentioned by you already (make update-po) will be executed
  and rpm creates translated headers by executing

  | gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...])

  for every supported language.

  'rpmbuild --rebuild' will not differ on authoritative and non-authoritative
  hosts.


Problems:

* it is not implemented yet



> It might be nice if there were some way to add translation resource
> bundles to an RPM *after* building the RPM,

Yes; you will need to modify the headers (change localized language tags
and increase release) and you will have to update the po-tarball. On the
first glance, this does not look very complicated.




Enrico