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