[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Debconf Translation proposal ( again )

Colin Watson writes:

> On Wed, Jan 07, 2004 at 04:56:01PM +0100, Dominique Devriese wrote:
>> Colin Watson writes:
>> > 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.

> Yes, I've understood that now, but I don't think it changes
> things. In fact, it exposes you to concerns such as "where do you
> put translations for templates in non-free packages?" and "what
> happens if a security update to stable needs to change a
> translation, for instance because the debconf template gave
> dangerous advice?". The latter in particular would make the security
> team's job much more difficult.

That's a pretty far-fetched example, no ?  Anyway, if you change the
base template in the main package, then the translations will no
longer be used, as they were for another string.  So the proposed
system is equivalent to the current situation in this respect.

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

> It does if it wants to handle upgrades correctly. Users should not
> need to be aware of a string freeze, and should not have to manually
> upgrade any translations package first.

I agree that users shouldn't have to do it manually.  It should be
solved within dpkg.  I don't see why a technical solution for this
wouldn't be possible.  If necessary, we should special case it, as
there already are special cases for other packages.

> Also, if you only concern yourself with stable, then you lose a
> valuable component of testing by users in unstable.

As I said, it is only *required* that the translations are available
for a stable release.  Translators can optionally maintain a version
of their translations in unstable.

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

> Nobody has apparently even tried for more than half a dozen or so
> languages. Filing bugs is really not that hard; a trivial script can
> do it semi-automatically if you want. I think this illustrates the
> need for better translators first. :)

Debian has had a translation infrastructure for years.  Face it, the
requirements are too high, the rewards are too low in order for Debian
to attract qualified and interested translators.  Something needs to
change to make the role of translator more attractive.  Giving them
direct responsibility over their own package and making translation
generally more comfortable has the potential to achieve this.


Reply to: