Re: Splitting up documentation/translations?

[Shaun McCance <shaunm gnome org>]

On Thu, 2004-08-12 at 04:07, Danilo Šegan wrote:
> Enver, Shaun,
> 
> Today at 10:34, Enver ALTIN wrote:
> 
> > On Wed, 2004-08-11 at 20:04 -0500, Shaun McCance wrote:
> >> Let's assume all the translations will be roughly equal size.  I know
> >> it's a terrible assumption, but I'm lazy.  so ((1159 / 48) * 3.1M) gives
> >> us nearly 75M.
> >> 
> >> Seventy-five megabytes!
> >> 
> >> At some point, we're going to have to figure out something clever forn,
> >> packaging translations of documentation.
> >> 
> >> I don't have any objections or anything about what you're doing right
> >> now.  I just thought this somewhat-related tidbit was interesting.
> >
> > This brings yet another question about the process of translation and/or
> > documentation. I mostly use en_US and sometimes tr_TR locale so I, like
> > many others, don't care if my system has translations/documentation in
> > other languages.
> >
> > Maybe we could pack the whole translation and documentation in per-
> > language modules sometime in the future. So Joe R. Hacker from foo-
> > distro-gnome-team would pull those modules and pack them as .fpm
> > packages, and Joe User would have only those he wants installed. I doubt
> > if that would help anyone on translation of documentation teams, though.
> 
> Splittting-up documentation translations seems a hell of a lot easier
> than splitting up GUI translations.  The reason is that you can
> install translated documents separately — they're standalone.
> 
> With GUI stuff, you'd have to go through lot of manual tasks while
> updating.  If you get a PO file (or MO file — it's easily parsed),
> you need to merge translations into existing .desktop, .schemas, ...
> files.  intltool-merge can do this (provided you mark _Name, _Comment,
> ... and similar), but you need to know which files to update.
> 
> I'll think some more about all this, but it seems many changes to the
> build system will be required, so this will probably affect developers
> more than it would affect translators and localizers.

It's not really all that difficult to do this.  It isn't trivial, but
it's certainly not the hardest project I've seen.  Ideally, maintainers
wouldn't have to do much work.  I'd give them the build utilities, and
they'd use them.

So would the C docs ship with the package itself, or also as a seperate
package?  If they ship completely seperately, we would have the added
advantage of being able to do extra incremental docs releases without
having to re-release the package.  But then we'd have packages being
shipped with no built-in documentation.  I fear that build tools and
external packagers and just plain people downloading and installing on
their own will manage to fail to get the docs.

I'm also concerned about the number of packages this would give us. 
Right now, we have over 20 packages shipping with user documentation. 
If we figure 60 locales (which is how many translations gnome-games
has), then we're looking at adding an additional 1200 packages into
every single release.

There's also the option of having one big über-gnome-docs package, and
seperate releases for that for each locale.  So all of the C user docs
in all of GNOME would be in this package, and then we would have 60
releases of this, one for each locale.  I don't care for this approach
myself, because it makes it more difficult to install any single GNOME
program on its own.

Alternately, with clever build tools (which are on one of my burners
somewhere, I swear), I could rather easily add a configure option like
--with-doc-locales so people could choose which locales to install at
compile time.  This doesn't help tarball size, but it helps installation
size.  But this doesn't help people on distros with their own packaging
system, which is nearly all the big ones.  (Yeah, yeah, yeah, I know
that Gentoo users can add this to some sort of flag somewhere and just
be done with it.  I know.  Seriously.  Don't email me.)

--
Shaun