RFC: i18n proposal

[Göran Uddeborg]

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 at 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.  :-)