RFC: i18n proposal

[Havoc Pennington]

On Thu, Jul 24, 2003 at 11:42:26AM -0400, Jeff Johnson wrote: 
> Yup, one big file is much easier to hand to a per-locale translator.

This is trivial, it shouldn't dictate the overall approach. Ever heard
of "cat" ? ;-)
 
> 	a) there's a change of data type (i.e.
> 	    RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE
> 	involved, it's not just adding new text for RPMTAG_NAME or adding
> 	new LongName:/ShortName: tag. In fact, the creation of the data
> 	type was exactly the reason for a major incompatibility. Having
> 	personally survived (but barely) v2 -> v3 -> v4 -> v3 changes
> 	in rpm packaging, I wish not to go there ever again. I wasted
> 	1 year of my life already discussing the ramifications of the
> 	value contained in byte 5 of an rpm package. Have at it, enjoy,
> 	I have no desire to go there again.

I wouldn't do it this way. Another suggestion is to have the gettext
hash tables in the package file list
(/usr/share/locale/LANG/translation-domain.mo)

The translation domain might be in the RPM header. 

Then a tool such as redhat-config-packages, if the package is
installed simply calls bindtextdomain (/usr/share/locale) and uses the
gettext hash in-place; if the package is not installed it sucks the
gettext hash out of the package and puts it somewhere temporary to
use.
 
> My (and Red Hat's at the time) is
> 	specspo is great for distributions but bad for packages.

specspo isn't much good for us either, really. It's always out of date
and otherwise busted.
 
> IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in
> tar/cpio headers. Keep i18n out of packages, please.

i18n is already in the packages; if I install Gnumeric, then 
my Gnumeric has the translations with it.

It's just the RPM info itself that isn't translated. 

An alternate solution is to copy the RPM header information 
(name, etc.) into a .desktop file that's included in the package,
/usr/share/package-descriptions/gnumeric.desktop

This could be autogenerated in the spec file from %name etc.

There's no genuine difference between this and the above-mentioned
approach with /usr/share/locale/LANG/translation-domain.mo, just a
different flavor of the same.


You can't say translation just breaks if someone has packages from 3
versions of Red Hat, plus some 3rd party packages. Handling that case
is a basic requirement we need to address at some point.

Havoc