(aaaah, I was aiting for your followup, Frans..:-)) Quoting Frans Pop ([EMAIL PROTECTED]): > On Wednesday 24 October 2007, Christian Perrier wrote: > > - criterion for downgrading to prospective: > > - below 98% for sublevel 1 > > It probably won't surprise you that I have a problem with this 98% > criterium. My main argument is of course that having 2% of your strings > untranslated can make the installer completely unusable for people who > don't understand the fall-back language if that 2% happens to include key > strings.
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. 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. 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. > > For Beta releases some missing translation updates is fine with me. > But for _RC_ releases IMO all translations should be at 100% for at least > sublevel1, and preferably for most of the "optional" and "expert" > components from sublevel2. I'm having hard times buying this...and I know I don't surprise you either (this is something we never really exactly agreed even if we always found ways to negotiate...:-)). 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. Indeed, past experience shows that we always find a solution, so we're maybe nitpicking a little bit too much but I really have hard times accepting a strict 100% line....which I'll be very reluctant to apply myself (it was easier when you were the one wearing the Nasty Nitpicker hat... :-)) > 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. > 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. That would definitely be an improvement, yes. We currently distinguish the "importance" of strings on the only basis we have: the package. But for all packages, some strings are much more common than others, so another more fine-grained solution would indeed to tag them, yes. > This would allow a lot more fine-grained split than the current component > based split and allow more sublevels. > For bonus points: specify in the tag the sublevel a string should be in . Woot, that would require a lot of gettext hacking later in order to re-assemble things together. Of course, having a prioritizable po-debconf system (with more than one PO per package) would help a lot, here.
signature.asc
Description: Digital signature
