On Monday 29 October 2007, Christian Perrier wrote: > I know we may have many corner cases here and I agree partly on your > rationale, though I think that we anyway know that modifying the most > "common" strings is something we don't do without thinking deeply. At least not shortly before RC releases. But we _do_ change them (or add new ones), eh, right now. So the problem here is: what do you do when you're preparing an RC release and a translation has slowly drifted downwards (but not below your limits) and is missing translations for several key strings. > What I want to avoid here is a language being dropped because only > very few of its strings are missing. > > In such case, then the installer anyway becomes completely unusable > for this language users....as their only choice is to use English. Yes, and my statement is: if most of the installer is translated but one or more key dialogs are (partly) in English, the installer is almost as unusable! Or do you think that they will magically be able to understand those English bits just because there is little of it? > Given that the fallback language is *always* English, the situation > for the language with very few strings missing is not worse when we > keep the 98%-translated file. I don't understand what you're trying to say here. > I really don't want to penalize users of a given language because, at > the moment it was time to make the final adjustments to this language, > the one and only translator was unavailable. You know very well that I'm not talking about "final adjustments" here. Avoiding (and even reverting!) those if they have a major impact on translations and there is a real risk of even one translator not being able to update in time, is the responsibility of RMs and you as l10n coordinator. What I'm worried about is that, because we will probably only have quite few real string changes, basically any language will remain above your limit even without _any_ updates and thus will be missing key strings. > > Exceptions for sublevel1 can be made, but would explicitly have to be > > judged on a case-by-case basis, taking into account exactly _which_ > > strings are fuzzy/missing. > > This introduces arbitrary judgement which I'd like to avoid as much as > possible. I strongly disagree with the "arbitrary" qualification. IMO having a _person_ (or persons) judge the severity of missing translations on a case by case basis is a lot less arbitrary than setting some random percentage. It also avoids the situation where a translator could say "ah, I'm not going to bother about those last strings; we're already above the limit, so the translation will be included anyway". I still think that we've had *extremely* good results so far with the fairly strict policy, both for the installer itself and for the manual. The trick is in having a strict policy, but still being able to be reasonable and fair by making exceptions when there are good reasons (as I did for the Vietnamese translation of the manual for Etch, which is 100% translated even when not 100% up-to-date; getting it that way probably cost me about 4 hours of work, which I was happy to do). For me this is also about quality of our product: having a partially translated installer where users (from their PoV) are randomly confronted with English texts is _extremely_ unprofessional and would *never* be tollerated in any commercial product (yeah, I know, translations in commercial products can be horrible, but they are in general complete). Let me throw out a wild suggestion: how about including a dialog early in the installation warning if a translation is incomplete which also informs what the fall back is. At least that would inform the user at an early stage and allow him/her to abandon it _before_ (s)he's for example formatted the hard disk... > > An additional method you could consider implementing to further reduce > > the size of sublevel1 is to "tag" strings as less important (e.g. > > because they are architecture specific) and split individual strings > > out based on that. > > Woot, that would require a lot of gettext hacking later in order to > re-assemble things together. Huh? Wouldn't you only need to merge all levels together into a (temporary) single master file before merging back to the individual packages? Seems simple enough to me... And the splitting out into sublevels could be done by again first merging to a single master file and then using msggrep -C. We could use something like the following levels: - sublevel 1: default - sublevel 2: general strings not used during default installs - sublevel 3: expert strings (some low prio, some for e.g. RAID) - sublevel 4: specific to less-popular arches (powerpc, mips, sparc?) or used in experimental features - sublevel 5: same for high-end (hppa, ia64, s390) and hobby (m68k) arches I'd personally like to aim for 100% for levels 1-3; the distinction between them mainly being useful to prioritize translation work. I'd be happy to leave translating levels 4 and 5 a decision of the translators (as long as we do display something like that warning for those arches). I guess for some udebs (arch-specific ones) it would be nice to have the comment assigned automatically during the merge into the temp master file instead of having to add them in all template files individually.
Attachment:
signature.asc
Description: This is a digitally signed message part.