Re: Packaging very large i18n material
>Hi. I'd love some input here on the packaging of very large i18n
>components of software. The specific case at hand is koffice, which
>still doesn't ship with i18n files. I'd love to get this sorted out.
>
I remember seeing this before, but I'll add my two cents again (-;
>The problem is that there is a *lot* of i18n material provided with
>koffice. There are translations for 37 different languages, coming to a
>total 21.7Mb.
>
>The question is how to actually package it. All of the available
>options have clear drawbacks. The options as I see it are as follows.
>
>1) Build a single koffice-i18n binary package.
>
>This is bad because each non-US user will be required to download all
>21Mb of translations for 37 languages just to get their own language,
>quite a big ask for users with slower/limited net connections.
>
Agreed. For those of us on pay-per-minute dialups with 56k modems, it would
be murder when we only want certain language support.
>2) Build 37 different koffice-i18n-lang binary packages (like kde-i18n).
>
>This is bad because we add another 37 binary packages to the archives.
>This is also not a solution that generalises since if we did this
>for every package in the archive that provides i18n files our package
>list would get completely out of hand.
>
This is the lessor of the 4 evils, but it might be possible to simplify a
little? Several languages are related to some degree. Maybe if the
languages could be grouped. I.E. the different asian languages would
include the various chinese and japanese localizations, the spanish group
could include the different variations like brazilian, mexican etc. I'm no
language expert, but I think this might reduce the number of different
packages to a more managable number, and still reduce the download times to
within reasonable limits.
>3) Include koffice i18n files in the individual kde-i18n-lang packages.
>
>This is bad because koffice and kde are on different release cycles.
>It's also bad because it means I have to ask Noel (the kde-i18n
maintainer)
>to do this job.
>
With differing release cycles, this is more impossible rather than just
bad. The more intelligent option would be to convince up-stream to merge
their efforts than to try to handle this at the Debian level.
>4) Don't ship koffice i18n files at all.
>
>I don't need to explain why this is bad. It's also the current
>situation, which I'd like to rectify.
>
maintaining the status quo would be the lazy option, and I've never known
you to take the lazy way out of anything (-;
>And so I honestly don't see a good solution to this. Can I please have
>some opinions on which of these solutions is least bad?
>
Well, to be honest, I think getting up-stream to merge the kde-i18n and
koffice-i18n is the best solution, but realistically I think the modified
option 2 is the more practical.
>Ben. :)
>
But these are just my observations.
Cheers,
John Gay
>
Reply to: