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?