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:
- 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.
- This/these po files are made available for translation. (Talking of which, when will specspo appear in this cycle? :-)
- 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:
Rpmbuild creates a pot file containing description, summary, and group for the package being built.
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
- 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