RFC: i18n proposal

Göran Uddeborg goeran at uddeborg.se
Fri Jul 25 21:26:42 UTC 2003


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.

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?





More information about the fedora-devel-list mailing list