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

Re: Debian Debconf Translation proposal ( again )



Jacob Sparre Andersen writes:

> Dominique Devriese wrote:
>> CURRENT KDE SYSTEM
> [...]
>> A user only installs one translation package ( for his language of
>> course ) ( or more if he wants more languages, of course ).

>> PROPOSED DEBIAN SYSTEM
> [...]
>> 2. The translators don't try to get their work
>> included in Debian packages.  Instead they provide one package of
>> their own, that they can occasionally release in sid if they want
>> to.

> Even though it would be a rather large change in the infrastructure,
> I would prefer if there was one localization package for each locale
> for each ordinary internationalized package.  So like there are
> binary packages specific to the various platforms, there should be
> l10n packages for the various locales. It would mean that `apt-get`
> would have to be modified to automatically download and install the
> appropriate (selected by the system administrator) l10n package
> whenever and application package is installed.

I disagree with this suggestion.  IMHO, it would be best to provide
one large translations package per language.  Arguments are

1. Your arguments don't hold ;p  See below.
2. It is a lot less work.
3. Your suggestion doesn't achieve the reduction of work for the
   translators, which is the intention of this proposal.

> The benefits of this system of decoupling localisation data for
> different application packages are decoupled from each other are:

>  1) You only have to have localisation data installed for
>     the packages you have installed.

This is true.  However, given the pretty small amount of translatable
template's in (almost ?) all Debian packages, this is a minor
advantage.

>  2) You can have appropriate localisation data installed
>     even if you use a different combination of versions of
>     application packages than what the translators did.

I disagree with this.  Translations should be collected per-release.
There has to be a set of translations that are as complete as possible
for every stable release, along with a string freeze to cater for
that.  In addition, translation teams can optionally provide the same
for unstable, if they think it's worth the trouble to track a moving
target.  Perhaps it's possible to version the translations to allow
for people with packages mixed from several releases.

cheers
domi



Reply to: