On Fri, Jul 25, 2003 at 11:26:42PM +0200, Göran Uddeborg wrote:
Havoc Pennington writes:
> I didn't mean to try to address that in detail. You could do it
> several ways. Maybe rpm-coreutils-X.Y-Z.mo ?
Ok, so you mean a separate message catalog per package, containing the
translations related to the package. That makes sense to me.
Now, let's see if I can imagine how this would be done.
Preparation for translation:
1. Descriptions, summaries, and group information are extracted from
all SPEC files. Putting descriptions and summaries in the same po
file probably makes sense, the group names could be collected in a
separate po file if convenient.
2. This/these po files are made available for translation. (Talking
of which, when will specspo appear in this cycle? :-)
3. As translations arrive, they are put in some dedicated hierarchy.
Call this H. (/var/lib/rpm/locale/... maybe, I'm sure a nice macro
could be used to define this. :-)
During package build:
1. Rpmbuild creates a pot file containing description, summary, and
group for the package being built.
2. For each language defined in H, look for translations of the
messages in the pot file made. This would be something like
msgmerge -C <file1> -C <file2> ... /dev/null <pot-file>
Where <fileN> are all translations found in H for this language.
If the resulting file contains any translations, it is included in
the package as the translations for that language.
When running things like "rpm -qi" or redhat-config-packages
1. When a description, summary, or group is to be displayed, a
translation is sought by a call to dgettext() whith a domain name
derived from the package being inspected.
The only difference from the current specspo implementation (which uses
dgettext) is:
you are moving the package derived retrieval key from the
2nd MSGID arg to the 1st DOMAINNAME arg without specifiying
what is to replace MSGID.
If you are hoping to use the MSGID from package headers as the MSGID key,
then your solution is inferior to the current specspo implementation
because the Group/Summary/Description then *must* be built into packages.
Several attempts to compile those tags directly into package headers
have all failed here at Red Hat.
So what specspo does instead is to use a two stage lookup using dgettext.
Here's the (simplified) sequence of operations for specspo:
langval = getenv(language);
setenv(language, "en_US", 1);
domain = "redhat";
msgid = dgettext(domain, "rpm(Group)");
setenv(language, langval, 1);
msgid = dgettext(domain, msgid);
Note that Using specspo maps msgid out of package metadata as well as msgstr.
Note also that domain is already being used for much what you propose.
There's absolutely nothing at all stopping anyone from adding a domain
to the colon seperated set of domains in the macro %{_i18ndomains}
and doing exactly what you propose. If there truly become thousands
of 3rd party packagers, all clamoring for their own per-package domain,
the current specspo scheme is quite sound, needs only a way to discover
thousands of domains through configuration.
Would this make sense? Is it approximately along the lines you
meant?
(To the extent you had them thought out.)
Would it be appropriate to put these package po files in some specific
hierarchy, separate from /usr/share/locale? (And do a corresponding
call to bindtextdomain() before calling dgettext().)
Is the needed information always available? Like, does rpm know
enough in time to find the po files when quering a package file, for
example?
How would one handle building single packages, not being part of a
distribution? Maybe by having an RPM directive specifying a directory
in the build tree to search for further message catalogs? Then the
translations for this package would be part of the source of the
package, which I guess would make sense.
Or am I missing too much here?
You're missing several important points:
a) msgid's, not just msgstr's, need to be handled. msgid's are not
necessarily constant, nor is there (or at least gas there been)
sufficient time late in a release cycle to manage "make world"
rebuilds to include i18n, too many things can break.
b) whatever organization you wish has to be as simple as possible
to set up in an empty chroot, i.e. the environment in which anaconda
runs during install.
c) the goal must be to have i18n tags in metadata, fetching from
the payload is a costly decompression.
Sure your scheme makes sense, but is possibly different than what rpm
has been doing since 6.2. There are consequences for having to support
multiple schemes for the indefinite future, not the least of which is
the complexity involved.
IMHO the apparent driving force for revisiting an already solved problem
is the perceived need to accomodate 3rd party package group/summary/description.
Personally, I have yet to meet (or hear of) any single person who has even
attempted the translation.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC