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