On Fri, Aug 11, 2006 at 04:28:59PM +0300, Yavor Doganov wrote: > On Sat, 22 Jul 2006 23:23:34 +0200, Frans Pop wrote: > > On Saturday 22 July 2006 22:32, Jens Seidel wrote: > >> I really don't care about time for updates and I'm also against any > >> freeze. It's of course nice for translators if there are only minor > >> changes before a release but it should not affect the quality of > >> the English document, especially since translators may find many > >> minor issues during translation (and during the freeze). > > > > Well, here it seems our opinions really differ then. I really feel > > that when you release, translations should be up-to-date with the > > original. The only way to make that possible for translators in a > > realistic way is to have a freeze period so they can be sure they > > won't need to start all over again after they thought they were > > ready.
OK, as this thread is reopened I want to explain it a little bit: I agree that a freeze in content is a good idea. I mainly referred to changes which correct (also minor) errors such as missing packages to be installed to able to run a command, fixed command line options to the kernel, swapped diggits in a number, ... All these little errors a person makes and translators (and others) are able to find very late. Once you say there will be strictly no changes you have a buggy version, so I would like to fix these errors in as many translations as possible and to ship all others with the old state (which is what happens now to *all* translations). > > Not having a freeze is especially unfair to PO based translations > > as they may be up to date say a week before the release (within the > > freeze period). Along comes someone with a minor change, fuzzies the > > translations and, damn, the translation is released with an English > > string in it. Yep, this should not happen. Maybe it's possible to release the po based translation <x> with revision <y> which is indicated by the last update after (or shortly before) the changes violating the freeze or something like this ... > However, this does not mean that translators who cannot catch up > should end up with their translations wiped out. Imagine what will > happen if large projects such as GNOME and KDE release only with 100% > translations -- this will be very pity, and rather discouraging. If > the incomplete translation happens to be barely usable, f.i. mixed > English and translated text, the user will figure that out and can > always run the program in English or read the original manual. Yep, this was also my main argument. Frans explained that it's not always so strict so I'm no longer so worried :-)) But the same discussion is true for the translation of the debian installer as well. I think a language should be activated as soon as Christian's new language process is fullfilled, which means that the locale exist, also time zone settings, fonts, ... Only 10 translated strings in the main menu in an exotic language (or an ordinary one) make me think "wow, great job", and allows others to jump in without worrying about hard core locale/maintaining stuff ... Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
