Quoting Frans Pop (elendil@planet.nl): > 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. Just what I always did: nag the translator/translation team. Most of the time, if they're responsive/still "alive", that will work painlessly. What I fear is being forced to drop the entire language because the one and only translator is not responsive at the moment we needed him|her. Of course, there are cases where we will make exceptions (Vietnamese manual....but in that case, we *knew* quite early about the translator's unavailability). I like your suggestion of "early warning" for incomplete languages. For now, I can think of it as an hardcoded list in localechooser, for simplicity. We would then releae localechooser at the last minute, with a hardcoded list of languages that are incomplete and then display a warning immediately after users pick up a language. > > > 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. Well, my reasoning was simple: if we drop a language, then the only solution for users is installing in English, right? So, the deal is between an installer where most of the installation happens in the user's language with a few strings in English and using English only. This is what I call "not worse". Again, having a key string not translated at a key moment may be a very bad surprise if the user is completely clueless in English....which again brings the idea of an initial warning. > > 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". That never happened up to now. And not because we enforced 100%. For the sarge installer, such 100% limit was never enforced and we still reached a very good level of translations with translators doing their best to reach 100%. > 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 My proposal is as strict as the previous policy. The difference is where to put te barrier, only. > 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... Yeah, I think this brings a good improvement. Allowing us to still use the translator's work (I hate seeing the amount of investment put by someone just being dropped out because circumstances may not allow him|her to follow a fairly strict policy), while preserving the quality reputation of our product. > > > 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... Sure, but how can we automate the process of building the "sublevel" PO files ? From what I get of tour proposal, we would tag the strings somewhere (in the templates file?), then dispatch them into sublevel PO files. This is that part of the process which I don't really see easy to achieve. Unless of course you're imagining a fully manual process but, ahem, we have 1686 strings, IIRC..:-) > 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). Well, that converges towards our current 2 sublevels. > 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: Digital signature