RFC: i18n proposal

[Jeff Johnson]

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 at redhat.com (jbj at jbj.org)
Chapel Hill, NC