Re: Deactivated languages
Hi,
first of all I want again to thank Christian and Frans and others for
the really good work they do related to i18n. The infrastructure, the
New Language Process and more are really great!
Even if I rant against a very special point this doesn't mean I do not
honour their work. I just want to improve it further (not for me, German
is not affected, but for others!).
I don't want to hide that I opened this issue already once or twice in
the past on debian-i18n but there was no big feedback (I can just assume
that only few active translators read this list who are not affected).
Since I hope that every developer cares about internationalisation I
raised this again, now on debian-boot (but it's really the last time). I
will of course accept every conclusion (if there will be one).
On Fri, Nov 17, 2006 at 07:02:18AM +0100, Christian Perrier wrote:
> We just decided (mostly Joey and I), in September 2004, that the list
> of supported languages was frozen at some point (in Sept 2004, when we
> were still in the mood of releasing sarge in December 2004). The key,
> at that moment, was avoiding too important changes in size, for an
> installer that was brand new for Debian, at that moment.
That's indeed still today an important reason. But unconditionally
activating a translation once it is complete (without considering the size
it adds compared to the usage of it (where is it spoken?)) doesn't solve
this, since this increases the size much more than incomplete
translations, right? So this is no argument at all!
One special point is a possible requirement for a font which could be
large. Adding 1MB for it to support 50 message strings may be indeed not
optimal (extracting only required glyphs for very incomplete
translations could reduce this maybe dramatically). But the current
exclusion rule doesn't depend on the file sizes.
> In the sarge->etch time period, I myself applied a quite loose policy,
> activating languages when they were reaching about 33%. This allows
> translators to really *test* the installer as, obviously, nothing can
> be tested if the language is de-activated.
IIRC prospective languages are also deactivated in daily builds after a
release, right?
(http://people.debian.org/~fjp/d-i/d-i_debconf5_paper.html, section
2.5.2) So Steves argument "There is no "early and often" that applies
here" is only partially true (for releases).
> So, back in August-September, it became obvious that some of these
> would be de-activated to preserve the quality of Debian Installer l10n
> as well as allow more control on the installer's size.
I agree on the size argument but not to the other one. The quality is
hard to determine. I know very ugly translations (using 7 bit
transliterations ("ae" for "ä"), 5--10 typos per sentence, obscur
grammar) which I would never remove just to make this issues go away.
Such translations are still very, very useful! (Complete illiterate
person do not work on translations.)
If someone doesn't believe the quality is good enought this person
should send patches. As long as no complains are recieved it should
always be assumed that it is of proper quality. The same happens for
new Debian packages. There does not happen a big usage test until they
are excepted, it is assumed they are useful if the oppsosite isn't
obviously and are only removed if they are unmaintained *and* contain
many bugs (or nobody uses these).
If you care about that not sufficient strings are translated allow a
fallback language (see my other mail).
> The discussion between Frans and I has been hot from time to time
> because I happen to be a little bit less strict and I naturally feel
> disappointed when I have to put l10n work aside. But, anyway, our
> views converged and we decided to deactivate languages on two
> criteria:
OK, it converged. But only during discussion of you and Frans? Don't you
think other people want to discuss this as well?
> -incomplete translation AND no activity for more than a few months
>
> -translation ratio below 90%
Both connected by "AND" or even "OR"?
Whether there is activity or not should be completely unimportant! The
current status should be considered. 10% of translated text could still
be very useful and could allow one person to install Debian who would
otherwise fail. Think about how many strings you see during a default
install.
Another very important argument: The barrier to work on a translation is
*much* lesser if it is not disabled. (People start sending patches and may
take over maintainership.)
> All these translators have been *warned* about the situation and
> several of them agreed that it would be better shipping without their
> language rather than shipping with a too incomplete AND untested
> translation.
I think it is very important to remembr that the work is not done for
translators but for users. A non-responsive translator should not affect
thousends of users!!!!
> As a conclusion, I think that what we reached is a correct
> compromise. I of course regretted that some of the translations which
A compromise among how many persons?
> *I* have spent much time on, along with translators, have finally to
> be dropped....but this may be temporary for some of them.
So you are not completely happy with the situation as well.
> Indeed, after this, a few translators/teams re-motivated themselves
> and found the resources to actually complete their work. And Frans and
I understand that there could be some reactions after announcing of
possible removings. But be honest, do you think this is the right way?
> So, please follow my daily reports in -i18n and watch for news....
I do and see that the status increases slightly. But I have to confess
that I do not see a need for 100% completed translations everywhere.
If it could be reached, it's great, but it's not required. Doing very
hard work from your side to reach this goal could maybe investigated
somewhere else where you could reach more with less work :-)
> As a lesson from this discussion, I think that, for the development of
> the lenny installer, we will have to set more precise rules such as:
>
> - the master file will be splitted in two files: one for the
> "important" D-I packages (those which are used on any type of install and
> are relevant for the most popular architectures) and another one for
> the "standard" D-I packages
It would also be possible to provide only translations of basic packages
(until the network runs or the CD is accessible) and to access
remaining stuff from outside the initrd.
> -prospective languages are activated when they reach NN% on the
> "important" file and are kept activated until we reach the RC releases
> phase
So the package sizes and the coverage of affected world population doesn't count?
That's a contradiction to your other arguments, isn't it?
> -when we prepare RC releases, we de-activate languages that are below
> NN% for the "important" file and MM% for the "standard" file, or
> languages which have got no translator activity in the last ZZ weeks.
Drop the last line!!!! Not every language changes completely in ZZ
weeks.
Please lets at least try to document all technical reasons which led to
dropped languages in the past so that it can be fixed. Ignoring it does
not help.
Jens
Reply to: