Re: Packaging very large i18n material
-----BEGIN PGP SIGNED MESSAGE-----
El Lunes 9 de Junio de 2003 03:46, Ben Burton escribió:
> 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.
we already discussed this sometime ago, and since then there are
apt-cache show koffice-i18n-es
Status: install ok installed
Maintainer: Ralf Nolden <firstname.lastname@example.org>
Description: Spanish (es) i18n files for KOffice
This package contains the Spanish i18n files for all KOffice
> 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.
No. I would not vote for that. That is crazy for the users.
> 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.
Yes, I think that not been good, that is the best solution.
> 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.
No, that spoils the translations from the translation teams due to the
different release cycles between KDE and KDE.
> 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.
No. That is the worst solution. One throws away all the work of the
translation teams and leaves the users without that work.
> 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?
Summing up, from best to worst: option 2, option 1, option 3, option 4
(should not be even considered).
> Ben. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----