I'll reply to a couple of points. For the most part I'll wait for input from other translators first.
On Saturday 22 July 2006 22:32, Jens Seidel wrote: > No, I was indeed very horrified when I read your mail. There was > (initially) no influence from the debian-boot list. But you're right, > lets discuss this more seriously. Well, the policy has been in place for a couple of releases already. This is not really something new. Thanks though. > 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. 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. > On the other side other people could easily fix this by copying English > parts into the translation to define missing labels, ..., of course > without updating translation check markers. Correct, like the pt and it translators have done. It still is the responsibility of the translator to do this. > I for example would do this but I strongly remember your decision that > *nobody* (except you and Christian) should touch other translations for > any reason! This includes also FTBFS issues. > (Remember that also few translators just translate and do not try to > build the documents, so they do not recognize build errors.) Correct. I regularly _do_ check and correct FTBFS issues BTW. Some can be quite tricky to track down for translators. I'm aware of that and often help out. In most cases I will mail the diff to the translator afterwards or ping them on IRC so they can check the fix. OTOH, I have also seen cases where it turned out a whole sentence was missing. That is very easy to overlook if you don't speak the language, so therefore the general policy to not mess with translations, especially if you don't speak the language. > > There have been some important changes in partitioning and preseeding > > since the last release. I _do_ feel that doing an official release > > where translations contain outdated information is a disservice to > > users. > > I more or less agree but also think that this needs to decided > individually for each case. If a translation doesn't update after a > minor fix in the English manual it's not very important. Which is what I do as release manager and is open to discussion. As I've said in my previous mail, translators can always contact me if there are special circumstances. The phrase "may be excluded" indicates this IMO; it also indicates that I _will_ look at the individual cases at release time and make a final decision then. > And it only affects XML, not PO files! I don't agree with that. > If you want a good translation status, kindly ask translators, do not > threaten! I kindly asked translators over a week ago. > I really, really do not understand your statement. A partly translated > document (PO based) is much much better than no document! Think about > this again, ask others, ...!!!!! > > You should not penalize thousands of users just because a single > translator (or maybe two) were unable to finish it! Once you drop such > a document you likely also lost the translator. We are only talking about an intermediate release here. People who already have the translation installed, can just keep it installed (it will just be marked obsolete in aptitude for a while). Trust that I will make every effort to have as many _up-to-date_ translations when Etch releases. I feel that this release policy contributes to this end. Note also that I apply the same criteria on myself: the Dutch translation is not included even though it is almost always up-to-date. > > A translator is even free to not translate that part. If someone does > > decide to do that, I would suggest to discuss that with me so I can > > take it into account when writing these updates. > > This seems inconsistent which what you wrote above, where you wanted to > drop a translation if it's not (nearly) up-to-date. Not really. There is a difference between fully translated and up-to-date. Up-to-date means that all text is based on the _current_ English version; fully translated means that all text is actually translated. Both are goals, but for intermediate releases up-to-date weighs a bit heavier with me. For PO-based translations up-to-date for me also means not having _random_ strings in English. Having a specific chapter (a whole PO file) or a section untranslated could be acceptable. > > I feel that users have a right to expect a released translation to > > contain the same information as the original and I feel that is more > > important than this point. > > A simple message similar to "This document is not fully translated" at > the beginning of the document would inform the user as well. The user > could open the English document in this case. It also is no argument at > all for PO file based translations. And who would activate such a message? The responsible translator who is not responding? > > If there are personal reasons why a translation cannot be completed, > > the translator is of course free to reply to my "call for update > > translations" and discuss the situation. > > Why do you care about the reasons? I don't need to know the actual reason, but I do want to discuss where the outdated or untranslated parts are and maybe suggest to update certain parts before the release. And I also want to know that the translator is not fully MIA.
pgpAevS1QJ4VU.pgp
Description: PGP signature
