Re: Debian Debconf Translation proposal ( again )
Colin Watson writes:
>> There is no problem at all with dependencies, and no abundance of
>> new .debs.
> There is most certainly a problem with dependencies: every time a
> string changes the new package needs to depend on a suitably updated
> version of the translations package, otherwise apt is perfectly
> within its rights to install it later and so the translations will
> not be available at configuration time.
1. There is no translation package for every real package. There is
one translation package per language containing all of the
translations for all Debian packages.
2. Not having fully updated translations in unstable is not a problem,
and inevitable. The system concerns itself with having fully
updated translations for every stable release. Because there is a
string freeze before every stable release, a package does not need
to depend on anything to make sure its translations are up to date.
> In fact, there's an even worse problem: at the point when debconf
> .config scripts are run, a package may rely only on essential
> packages (and debconf itself). So I still don't think that having a
> separate translations package will work. You might be able to kludge
> it up in the installer, but it would break for upgrades. When you
> dist-upgrade from sarge to sarge+1, the .config scripts of all
> upgraded debconf-using packages will be run before *any* packages,
> including your proposed translations packages, are installed. Thus,
> the translations will be useless.
Ah, now I see what you mean. You're right that a new version of the
translation package would have to be installed before configuring any
other packages. However, I'm not sure whether this really is a fatal
problem for the proposal. I'm sure this requirement can be implemented.
Note that the translations packages don't need to be configured before
the other packages. They only need to be unpacked. Isn't it the case
that all packages going to be upgraded are first unpacked, and then
configured. This is not really clean though. What we really need is
for one translation package to be marked essential, based on the
user's choice of language. I'm not sure if this is possible within
the current dpkg system. Anyone have any ideas ?
> I urge you to reconsider this proposal, as I think it's fatally
> flawed.
I think the advantages outweigh the above technical problem, which can
likely be overcome.
>> By the way, I urge you to also consider the general string freeze
>> before a release as an important part of the proposal.
> That seems plausible as part of a freeze. I haven't thought it out
> to see whether I think it'd work in practice. (Most of my packages
> with debconf translations have received fairly few translations
> anyway; only the highest-profile of them stand any chance of staying
> remotely up to date.)
I think this very much illustrates the need for a better translation
system.
cheers
domi
Reply to: