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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
