RFC: i18n proposal

[Jeff Johnson]

On Thu, Jul 24, 2003 at 12:11:43PM -0400, Havoc Pennington wrote:
> 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" ? ;-)
>  

Sure, but I've never heard of uncat. There are other technical issues,
such as reducing the size of the corpus (and the translation work involved)
by consolidating common strings into single msgid's.

Or maybe there's some option to cat that I've missed?

> > 	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.
>  

I can/will discuss this process ad nauseum, but I am adamant (particularly
if I have to do the work) in keeping i18n out of package headers.

I18n does not belong in package headers is my only non-negotiable stand.
I'm quite willing to listen to any other approach.


> > 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.
>  

You are confusing specspo and the process that creates it. And you have
never attempted "drilling".

> > 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. 
> 

Don't confuse summary/description/group with analogies for how other i18n
text is handled.

The problem space is very very different wrto rpm summary/description/group.

> 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.
> 

That sketchy process is fine by me, as the i18n is not in package metadata,
nor does it need to be imho.

I can say similar things about Name:, Packager:, Distribution: tags, I
don't believe that any of that information belongs in, (note I didn't say
"with") rpm metadata either.

But let's not get our panties too twisted yet, the (or at least my) goal
is to get the maximum amount of software in from of the maximum number
of users in as useful a fashion as possible, and I'm quite sure we agree
on that goal even if we differ on implementation details.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC