Jeff Johnson writes:
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.
The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead.
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.
That was how I thought about it. But I guess it is not really critical. You could continue the current practice of using a po-file for a key-value lookup, and still have one po file per package as I suggested.
I haven't fully understood why it is such a good idea. I thougt gettext was designed to avoid having opaque keys, and instead use the English language message directly as the key. And this seems to go contrary to that, back to the catgets() inteface.
But again, this is not really the same issue.
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.
But I want each package to have its own domain. There is no easy way to automatically add a domain to i18ndomains on package installation, and remove it on uninstall, is it?
You're missing several important points:
I'm sure I am.
a) msgid's, not just msgstr's, need to be handled. msgid's are not necessarily constant,
If I update specspo, it may result in that descriptions of already installed packages change or disappear. Is it this sense of "not ... constant" you refer to?
I consider that a bug. One of the bugs I'm trying to solve here.
If I do "rpm -qip xmms-1.2.7-1.i386.rpm", with specspo installed, I get a description not mentioning MP3. If I uninstall specspo, or change to locale C or so, I get the package's original description, mentioning MP3.
Similarily, if I to "rpm -qi mpg321" on a system which still has this package, but current specspo, I don't get the description translatied. There was a translation, but it is not part of current specspo.
In both cases, the messages, and translations of them, which existed at the time of package generation is better than the current situation. They ought to come and go with the package itself.
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.
That could of course be a problem.
To me it seems it would be possible to freeze descriptions of the new packages earlier. Like already by now in the current cycle. And also make them available for translation at this time. Then they could be there when the final build is done.
But I realise I don't know the internals of these routines.
c) the goal must be to have i18n tags in metadata, fetching from the payload is a costly decompression.
I must have misunderstood something. In message 20030724114226.Q18401@devserv.devel.redhat.com you said:
IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please.
I understood that to mean that you did not want the translations in the metadata. So I tried to sketch things obeying that, putting them elsewhere.
But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...". As I understand it, this does become package metadata; at least it winds up in the Packages database file.
As you pointed out, this lacks coding information. Also, putting all translations in the spec file is not very convenient. They need to be fetched externally at build time. But if this is an acceptable method, these problems probably could be solved.
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.
Point taken.
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.
Are we talking about translations of descriptions at all? Or only through external po files?
I always include Swedish versions when I build packages of my own. (After rhcontrib.bero.org died, I've mostly circulated them among friends. Some could probably still be found out there; rpmfind found a stickers package for example.)
I may be uncommon doing this. But then again, including translations in the SPEC file is not very convenient. And is "%description -l" documented anywhere except for the change log and the source code? There is a chance not everybody is aware of the possibility. :-)